Agile Change Management – No Matter how Difficult
By Andy Jordan | 30 August 2017
I always enjoy meeting executives who tell me how Agile their organisations are...
They wear it like a badge of honour as if to demonstrate they can bust the stereotype of not being able to adapt to new ways of working, or to embrace new and slightly non-mainstream concepts. Of course few of them are as agile (small a or large A) as they like to think, but at least they recognise they should be – that’s a start. However, one thing I have noticed is that most of those executives impose limits on their embracing of Agile. It’s a fine idea to use Agile techniques in project delivery, and bonus points if you do it outside of IT, and the more progressive executives are now moving towards Agile planning – I touched on that in my last blog. But what about some other areas – what about change management for example? My view of Agile in that arena tends to strike fear in most executives.
See here’s my premise. Projects are undertaken to achieve business results – market share, revenue, profitability, etc. Sometimes that’s direct – reducing costs through automation for example, and sometimes it’s indirect – deliver a best in class product and customer retention and acquisition rates will drive the top and bottom lines. Regardless of how it is achieved, projects must deliver business performance, and in the current operating environment of virtually every industry that’s a fairly fluid concept.
That means projects must expect to experience change. The operating environment, customer expectations, ability to deliver and any number of other variables will have changed between the approval of the initiative and the delivery of the outputs that will enable that business performance to be achieved. Historically we reported those variances against the triple constraint and moved on with some attempt at mitigating the damage. Today we must make a series of small scale adjustments to those constraints to ensure the project delivers ‘on benefit’. Regardless of the methodology being used to deliver the project it requires agile change management – decision makers as close as possible to where the work is happening making multiple minor adjustments. That will replace the traditional approach of occasional major adjustments occurring only after approval by a change control board.
The key is to have change approval as close as possible to the work – the project team or perhaps the project manager (but no further removed). Communication to stakeholders still happens but it is with the principle of asking for forgiveness rather than permission. Changes must be approved where the work occurs for the optimal performance against business expectations to be retained, and this is where the colour tends to drain from the faces of executives. They are hearing me tell them that optimal Agile performance means their most critical initiatives are going to be modified by frontline team members and they will only find out about it after the fact.
I can understand why this is scary, but this is agility – if you want an organisation that can pivot and adjust with minimal delay and disruption you need to empower the people doing the work to initiate those changes.
That’s what being an Agile organisation means.
Andy Jordan is a program and project management thought leader and President of Roffensian Consulting Inc.
The material published in the Blog area of this website, is provided independently by our bloggers and any opinions expressed are those of the individuals and not necessarily of the Agile Business Consortium. The Agile Business Consortium does not accept any legal responsibility for any content or opinion published in the Blog area of this website.