A vast majority of old school enterprise guys and gals like me probably have a hidden shrine somewhere in our basements in honor of Kotter. His 8-steps process for leading change has been one of the most influential self-help books for enterprise architects, IT strategist and CIOs struggling to find a way to explain to executives that something has to be done with all the legacy mess and out-of-control modernization backlog. The accumulated number of powerpoints structured around these 8 steps probably stack up to a mile or two.
Quite frequently however, the change that has been instituted has resulted in some mastodon of a project. With a massive scope to finally replace everything in one simple, beautiful black box of a «smart» contract that the CPO convinced the CEO was a great idea. All the while quoting you and the great vision you presented a fortnight ago. Yippi!
So there you are – the sucker who managed to convince the stakeholders that change was oh, so necessary, but sort of missed the part about how to execute. What to do – stuck with a Too-Big-To-Fail program that every engineer blames you for? Well, at least the Pragmatist has a couple of rules on how to minimize (well, sort of, kinda…) the damage. Actually there are five of them, with five strong runner-ups.
Now you might think “hey! These are Captain Obvious’ top 5 rules! How dare you steal his intellectual property!”, but the amount of tax dollar money wasted due to not listening to the good, ol’ capt’n is staggering.
So here goes. Let’s start with number 1.
#1 Aim for a stepwise implementation approach.
Creeping scope delays, risk related to large “big bang” releases, unmanageable cost increase etc are all issues related to large projects with very coarse staging, or no staging at all.
These issues are usually – no, always! – best managed through splitting the main phases into smaller steps; catering for proven results along the way.
An added bonus to this approach is the ability to celebrate success through actual deliverables. You can also adjust the target solution as you go along.
“Well, duh”. This should be project 101. Still, it seems that gravity pulls large changes towards few stages/steps, and large roll-outs. Maybe less so in recent years; but still. There are probably many reasons for this phenomenon:
- Developing a practical and feasible plan that combines decommissioning and refactoring legacy complexity with development of “new stuff” is extremely complex. There are loads of compromises to be made, many temporary solutions and a continuous flow of “slightly less than good enough” in order to actually deliver something of value. The only best practise pattern to solve this mess is Hard Work, and for some reason that is not necessarily on people’s list of preferred patterns.
- There is a cultural divide between the agile world and the realm of more classic projects. There seems to be an unwillingness to find practical hybrids that cater for the need to use the best of these two worlds to solve complex and effort consuming problems. The result is a complete lack of best practices.
- Managing a stepwise approach with the ability to adjust the direction throughout execution seems to be a headache when there is sourcing involved. There is often a somewhat old-fashioned approach to procurement; particularly within the public sector. There tends to be a preference to using hard milestones in contracts for leverage, instead of something mutually beneficial that will give flexibility to adjust timelines.
- And finally perhaps the main obstacle: executives sometimes (too often?) have a combination of impatience and illusions of grandeur at the core of their leadership philosophy: This makes large deliveries – in combination with a «work smarter, not harder» attitude – very attractive to decision makers. Perhaps even have the two only phases run with a significant overlap? Will be cheaper and finished earlier!
Being the pragmatic IT middle management 40 something you are, you just have to deal with this, and take the bull by the horns. All though you probably should not have gone along with a huge change program in the first place – at least make sure you influence the implementation and migration strategy and the roll-out plans in the program. There is research to back you up. Loads of experience. Probably also a few theoretical patterns and “best practices”, but in the end there is just Hard Work in front of you.
Some pragmatic tips and hintson how to convince your stakeholders:
- Refer to research and facts; if you have some McKinsey-facsimile you can use; that is great. Use phrases like “excelling at core project-management practices, such as short delivery cycles and rigorous quality checks”.
- Focus on the pros of the stepwise approach (early benefit realization, quick adaptation to market dynamics, risk reduction, user oriented approach), and don’t make all the challenges ahead too dominating. It IS complex to do a large change initiative with legacy dependencies in steps; but it just isn’t feasible any other way. So focus on risk mitigation instead, and save the (albeit great!) complexity and risk slides for the architects and team leads; not the CPO and CMO.
- Separate the presentation and decisions on the overall staging approach from the details of the actual plan. The plan will change frequently when you start (and learn from) actual design and implementation work, but the overall approach should be quite constant. You probably need to find some kind of logical dimensions to slice and dice the scope into; functionality, domains, products, users, customer segments, features, technology, something. This will be your approach, or staging strategy if you will. We will get to that in #3. (…the suspense!)
- Make sure there are dedicated resources handling the dependencies and different kinds of temporary solutions and technical solutions to actually make the solutions work. If you have fully emerged into the autonomous team-bonanza, make sure managing these dependencies are clearly stated in the team mandates, and that there is structured governance to manage it across all teams. Oh yeah, and make sure the teams have some grumpy pragmatists in their midst to challenge the “let’s solve everything through microservices!” hipsters.
- If you are challenged on the business case of a stepwise approach (“this will take too long time and cost too much”), counter it with early and frequent benefit realization, add in risk calculation of cost overrun with half a year delay, and the financial consequences related rule #2.
So there you go. Now run along and make those beautiful powerpoints!
…and on a final note: if it is impossible to find steps with manageable scope in combination with a high level, overall timeline that is acceptable for key stakeholders, the total scope is probably too large… Just sayin’.
Next time: “#2: Plan for downscoping/rescoping. It will happen. Really. It will».
The Good, the Bad and the Pragmatist 