Having been convinced to lead a large change program, you will quickly find that the devil tends to reside in the details… You suddenly find your self moving from a program scope that fits on 3 PowerPoint slides to 20 people addressing detailed design, coding and testing with thousands of Jira tasks popping up all over the place. Execution of the change program will uncover large amounts of “bits and pieces”. The amount of changes soon becomes unmanageable. The feeling of being completely overwhelmed seeps into every nook and cranny of your program organization. You start regretting not staying in your comfortable position as line middle manager with a stable 9-5 job doing compliance reporting.
All the good intentions of simplification, modernization and platform uplifts seem to be easily forgotten when the actual deliveries are being designed. “Nice-to-haves” start to become “must-haves” when requirements owners are faced with functionality being left out or post-poned.
You also realize that you are transforming an area that has been neglected for a long time. Business and IT owners seem to think “finally! My turn! It’s time to get everything done, and then some…” as soon as the funding was approved. This might be their only chance this century to get a particular feature.
Oh yeah, and as time goes by within the cozy walls of your large change program, the world has the audacity to move along with no regards to the consequences for your progam; even if your CEO has said you are doing the most important job in the company. Your original scope might not be robust enough to withstand disruptive threats to your company’s market shares, major regulatory changes, or the introduction of another change program even more important than what you are managing. Handling these kinds of changes if you are not rigged to efficiently change your scope will be a nightmare, probably a full stop, audit, then maybe restart situation.
Finally, with the “too big to fail” initiatives the actual benefits of implementing changes tend to be forgotten along the way. They are either drowning in macro-economic perspectives, or an original hypothesis on benefit realization trumps the experiences building up during project execution. As the project moves along, the people designing and implementing the solutions get better insight into opportunities and weaknesses. They are better positioned to define actual benefits than an upfront analysis based on… well probably pretty much nothing tangible…
Large change programs need to implement a strong governance system to manage the overall scope and the benefits associated with it. The governance system must cater for adjustments of goals as the program learns and external forces drive changes in expected outcome.
This should be done in combination with a well-communicated stepwise approach to deliveries, continuously challenging the actual benefits of the work to be done, and having a sober approach to when a project or project deliveries should just be deemed business as usual and managed by the line organization (business and IT).
Oh yeah: if your agile-schmagile backbone now yells “hey hey hey – “strong scope and benefit governance! That’s waterfall! This is the Devil’s work!”, there is nothing stricter than regular backlog grooming. «Governance» and «scope and benefit management» does not automatically imply huge spreadsheets, ITIL, 1998-style change management tools or incomprehensible business case models. Modern tools for planning and assigning tasks, running automated tests, documenting decisions etc are great, but need to scale to program level. and be well aligned with systems or vendors not up to date with this way of work.
There is also usually some work to be done to convince PowerPoint and Excel loving program managers to embrace modern tooling originating from the IT world. It might seem like a techy detail to them; not something they should be bothered with. So show them the benefits. The cool graphics on stats and ways of monitoring progress. The PowerPoint integrations and plug-ins. They’ll love it!
Now, all this seems pretty straightforward. Trust me, it really isn’t. Some stuff to keep in mind when after finishing the bottle of champagne celebrating investment approval:
- It takes time to set up and introduce program level systems and tooling, and most plans tend to underestimate or simply ignore the effort. 2 years down the line when everyone feels the strain of not having done this properly in the beginning, is probably not seen as a good time to start…
- Aligning scope across teams or sub-projects is notoriously difficult, especially if you are making changes to legacy systems. Having worked hard to make teams as autonomous as possible in the beginning will pay of, but it requires that business and IT are well aligned and present together in the teams
- Benefit tracking for large platform projects or major systems renewals is difficult compared to programs dominated by new features or product development
- If you are dependent on deliveries from vendors, the flexibility you aim to build into your scope and benefit tracking may be severely restricted by a contract or a vendors own change and release management regime
- You will need to manage different views on both scope and benefit tracking – your developers, your controller and your steco probably do not share the same hands-on experiences, but they all need to get connected through some magical system
- You will need to integrate in a pragmatic way to systems and organizations impacted by your change program, but that are not a part of it. They will most likely have their own change management, and will not have the bandwith or see the needs to adopt to your structure
… and finally – don’t forget that probably a major part of your scope and benefits are related to organizational changes. New processes, Customer features, products to be launched or terminated, new roles and collaboration, training and business support etc. Make sure the guys and gals working with those parts of the change program are tightly involved in setting up your system. Otherwise it will probably be dictated either by IT people og PMOs, resulting in either something too techy or too bureaucratic.
The Good, the Bad and the Pragmatist 