Framework library · Risk management and assessment
Pre-mortem
A pre-mortem asks the team to assume the project has failed, at a stated date in the future, and to write down the reasons. Treating the failure as a fact rather than a possibility makes it easier to name specific causes, and gives people with doubts permission to voice them. The output is a list of reasons, the early signs that each is happening, and changes to the plan.
Use it when
- A plan is about to be approved and the team has worked on it long enough to stop seeing its weak points.
- The project depends on a partner, a regulator or a technology the team does not control.
- The team is senior, confident or recently successful, so doubts are unlikely to be raised unprompted.
- You have a risk register and want to find what it misses.
Avoid it when
- The plan has already been approved and cannot change. The exercise then produces worry without action. Manage what is left with a risk register.
- You need scores, owners and review dates for known risks. That is a risk register; the pre-mortem feeds it.
- The failure you fear is a single severe event with known causes. A bow tie shows its threats and barriers more clearly.
- The sponsor punishes bad news. Fix that first, or the reasons people write down will be the safe ones.
How to run it
Brief the plan, then declare it a failure
"It is March 2028. The launch has failed. Take three minutes to write down every reason why." Be specific about the date and about what failure means.
Write reasons alone and in silence
Each person writes independently, so the first confident voice does not set the agenda.
Collect one reason per person in turn
Go round the room, one reason each, until the lists are exhausted. The sponsor goes last.
Mark which reasons are new
Compare the list with the risk register. The reasons it does not already contain are the main output.
Name an early warning sign for each
Something observable months before the failure, such as activations below 5% of eligible customers after three months.
Change the plan
For the likeliest reasons, change the plan itself or add a mitigation with an owner. Revisit the list at each milestone.
Work through it
Answer the questions below, or load the worked example to see a finished one. The drawing updates as you type. Export the result as a PowerPoint deck, a Word document, an Excel workbook, a PDF or plain text.
What you type stays in this browser, so you can close the page and come back to it. It is not sent to Blue Prysm or anyone else, and the exports are made here, on your device. Privacy policy.
Mistakes to avoid
- Asking what might go wrong instead of declaring that it did. The hypothetical framing brings back the hedged, general answers the method is meant to avoid.
- Letting the sponsor speak first, so everyone else edits their list to match.
- Stopping at the list. A pre-mortem that changes nothing in the plan was only a rehearsal of anxiety.
- Dismissing uncomfortable reasons as unlikely without evidence. Those are often the ones the register is missing.
Where it comes from
Gary Klein, "Performing a Project Premortem", Harvard Business Review, September 2007. It draws on research into prospective hindsight by Mitchell, Russo and Pennington ("Back to the future: Temporal perspective in the explanation of events", Journal of Behavioral Decision Making 2(1), 1989), which found that imagining an outcome had already happened increased the number of reasons people gave for it. The study counted reasons; it did not test whether they were right. Source.
Use it with
Further reading
Work through it with us
The frameworks here are free to use as they stand. If you would rather work through the question behind this one with us, these are the ways an engagement starts.