Every time I get into my car, I put on my seatbelt. A few seconds after I turn on the engine, the yellow light of the airbag turns off, reassuring me that if needed, the airbag is ready to deploy. Not that I am planning to ever need them, but good to know. Similarly, in the plane before take-off, there is a safety briefing. Good to know how to get out of the aircraft in case of an emergency - hope never have to apply that knowledge. The vast majority of us never have had to rely on the seatbelt, the airbag, or the brace position and the escape slide. Yet we don't debate the need - it is obvious. That makes it all the stranger that when it comes to high stakes, high complexity projects and programs, we let failure surprise us with catastrophic consequences.
Fail to plan
"If you fail to plan, you are planning to fail" - wise words that are attributed to both Benjamin Franklin and Winston Churchill. But the statement is incomplete - you should plan for success, but you must also plan for failure. This is a lot more difficult, as there are few ways to succeed, and many opportunities to fail. Basically, it is much harder to plan for failure - the more complex a program is, the fewer paths there are for success, yet the paths to failure are growing exponentially in number. And it is easy to understand to plan to succeed, but why plan for failure?
Imagine you must drive to an unfamiliar place, and there is no GPS available (if you are of my generation, you don't have to imagine; I am sure we all have an entertaining story to tell). You plan the trip by writing out the directions - take highway x, exit y, turn left after the third traffic light on street z, and so on. You have successfully planned the route. But what if exit y is closed? Did you bring the map with you (no, there is no automatic route recalculation on a printed route description)?
The printed route plan is analogous to your project plan. It is a carefully crafted document of steps that need to be completed at a specific date. The more complex a program, the more parallel interdependent tasks there are (back to the route planning analogy: several cars traveling to the same destination over different routes, that must arrive at the same time). Every missed interdependency cascades into more late tasks, and the program is at risk of being branded as failure.
It is inevitable that things don't go as plan in a complex program. Yet, we meticulously plan for success, and completely ignore the possibility of failure.
Plan to fail
There are two elements for planning for failure: contingency and consequence planning. Contingency planning is needed to get things back on track after something unforeseen happens, and consequence planning for times when it is not possible to get back on the same track. Typically, we spend all our time planning the one path to success, and only a fraction on the risks. Given that there are many more ways to fail than to succeed, that makes a lot less sense than we all think. We should spend at least as much time planning for failure, as we do for success. Because if it can go wrong, chances are that it will.
Contingency and Consequence
Contingency plans are needed to get you back on track - the little detour that puts you right back on the road. A consequence plan is invoked when you cannot back on the right track at the right time. It is damage control. But in relation to what are we actually planning the contingencies and consequences? Mostly, energy is spent to get back to the original project plan. Usually this is not possible, and the overruns on the project keep snowballing. Any contingency and consequence plan should be made in relation to the project outcome of the program, not the plan of the program itself; the plan is not the outcome. Because we invested so much time into creating the plan, it is difficult to let it go. however, you should redo the plan from the current position as a new starting point and re-evaluate all the dependencies. The simpler your plan is, the easier this is done. Therefore, a fail fast methodology means having a plan that is by nature reset after each iteration deliverable.
The futility of post-mortems
When things have not gone well after a lengthy program, it is deemed proper to perform a post-mortem. After all, we have been presented with a very costly lesson, we might as well learn it. The problem is, we never do. The next journey we embark on constitutes of a mix of different and the same things that could pose a risk to success. No matter how many lessons learnt we document, there is always a new one lurking in the shadows - and not to mention the things we keep doing over and over, no matter how well we document the inevitable result. A post-mortem (if done at all) is an exercise to feel good about the failure (at least we learnt something), but it rarely results in actual changes in the program outcomes.
Optimise your route to success
I cannot provide a recipe for success, but over the years I have noticed a pattern that will provide better chances of achieving program success:
· Adopt a fail fast methodology, expect to fail fast, and be prepared to change the approach
· Document the benefits of the outcome of the program, that will be referred to when plans (inevitably) change
· Make the critical path visible in the program and do a complete risk assessment on each task on the critical path. Evaluate the requirement to invoke contingency plans (risk management) and consequence plans (issue management) daily for the tasks at hand
· Assess risks and issues on non-critical path elements weekly. Also re-assess if an occurrence of an issue changes the critical path
· Spend at least as much time on planning for contingencies and consequences on the critical path - assess the consequence and contingency plans weekly, be ready to execute every single day
Things will not go according to plan, that is a given, with the above, failure is part of the plan, and with the right adjustments early on, will have a better chance to lead to success.
Originally posted: 17 August 2017