Thinking about starting an exciting new project? Before you commit lots of time and resources to it, try testing its feasibility with a pre-mortem.
It often seems like most projects that get started are doomed to failure from the offset. They either miss their deadline, or they run over-budget, or both! One reason for this is that there is neither a clear enough understanding of the scope of the project, nor its risks, before it is kicked into action. The pre-mortem meeting is a great tool to counter some of these common problems.
I first learned about pre-mortems from the story of the Lieutenant General Paul Van Riper‘s glorious and disruptive involvement in the Millennium Challenge 2002 war-game, where he overcame a vastly superior opponent through unconventional strategies and tactics. If you want to read an entertaining account of this story I heartily recommend “Blink” by Malcolm Galdwell (a favourite of mine).
I am not at Van Riper’s level yet, but here is a simple guide that can help you achieve the (seemingly) impossible.
Step-by-step guide to pre-mortems
- Gather together a wide group of people in your organisation; do not fall into the trap of thinking the best ideas come from some particular team of “brilliant” people – its not true!
- Present the group with description of your project: your mission. Make this is as clear as possible.
- Ask the group to imagine that it is 6 months in future and your mission has failed.
- Get the group to provide as many explanations as possible for why this failure has happened. Do not filter their thinking in any way. Imagine you are all around a dead body preforming a post-mortem (or autopsy for you American readers out there). It can be helpful to solicit your group’s ideas a few days in advance of the meeting; some people prefer to take some time to collect their thoughts and may not be confident to speak up in a busy, fast-paced, meeting environment.
- (In the meeting) go through the suggested reasons for failure, and discuss them as a group.
- Rank reasons based on how scary / likely they seem to be.
- Magically rewind the clock back to present day and use your list of scary-reasons-for-death to save your patient before they die. You may find that it is not reasonable to assume you can save the patient – the risks involved are just too many or too extreme. If that is genuinely the case, then save yourself the time and money and do something else. Do not pursue this project!
Winding back the clock – risks
The magic of the pre-mortem really lies in that last step – where you wind back the clock. Your scary-reasons-for-death list transforms into a list of project risks. You can now start to plan out your project in relation to these risks, which is a whole endeavour in itself (and a topic for another post), but in general there are a few things to consider. As you started sorting your risks by “scariness” you likely noticed that you could cluster them together into categories, either by technical discipline or by process step (i.e. resourcing, deployment, operation, support, etc).
You are going to want to assign clusters of risks to owners. These owners are then responsible for transmuting your risks into actions that will drive project success. In other words they have to come up with an action (or actions) which would mitigate each risk, and they are responsible for making sure that mitigation action is carried out. The outcome here should be a beautiful, actionable, risk register.
Stay tuned for the next instalment, where we look at the magic of risk registers in more detail, we will describe project plans as devices that optimally retire total risk-exposure as a function of time, and we will even draw a graph (wild!). Until then, happy pre-mortem-ing (how catchy).