The Power of the Pre-Mortem: Anticipating Failure Before It Happens
Most project teams approach risk identification with an implicit optimism bias. The project plan has been built, sponsors are committed, and the team has invested weeks in the work. In that context, raising a concern that the project might fail feels like disloyalty or defeatism. Individuals who have reservations about the plan may stay silent rather than risk being seen as obstructing progress. The risks that project teams discuss in formal workshops are often the ones everyone already knew about, not the ones that are genuinely uncertain or that challenge the assumptions embedded in the plan. The pre-mortem is a technique specifically designed to defeat this dynamic.
What a pre-mortem is and why it works
The pre-mortem was developed by research psychologist Gary Klein as a practical application of prospective hindsight — the cognitive technique of imagining that an event has already occurred and working backwards to explain why. Research shows that imagining a future event as a completed fact generates more accurate and detailed explanations than trying to predict what might go wrong in the future. The pre-mortem applies this insight to project planning: instead of asking "what might go wrong?", the team is told "the project has failed — it is 18 months from now and the project failed. Why did it fail?" This single reframe changes the exercise substantially.
The pre-mortem works for two reasons. First, it is psychologically easier to identify failures when failure is assumed, not feared. Permission to imagine failure removes the social cost of raising concerns. A team member who says "I think we are underestimating the integration risk" in a conventional planning meeting is challenging the plan. The same team member who says "in my scenario, the project failed because we underestimated integration risk" is participating in the exercise. The identical concern lands differently. Second, the pre-mortem surfaces disagreements about the plan that might not emerge in a positive planning conversation. When everyone is asked independently to generate failure scenarios, the spread of answers reveals which assumptions are truly shared and which are held by some team members but not others.
How to run a pre-mortem
Set the context. Gather the core project team — including representatives of the key functions and dependencies. Confirm that everyone understands the project plan, the key milestones, and the definition of success. The pre-mortem only surfaces useful information if participants have a clear understanding of what the plan actually says.
Assume failure. Tell the group: "It is [date, 12 to 24 months from now]. The project has failed. It did not deliver what it was supposed to deliver, on time, within budget, and to the expected quality. It is a clear and undeniable failure." The time horizon should be long enough to encompass the full project delivery, not just the near-term milestones.
Generate causes independently. Ask each participant to spend five to ten minutes writing down every cause they can think of for the failure — independently, before any group discussion. Independence is essential: the goal is to capture the full range of concerns, not to reach a premature consensus. Experienced pre-mortem facilitators often ask participants to generate at least five causes, even if the first few feel obvious, because the later items in the list are typically more insightful.
Share and prioritise. Go around the room, with each participant contributing one cause at a time until all causes have been shared. Record all of them visibly. Avoid evaluation during the collection phase — every cause is valid until the list is complete. Then group the causes by theme and work with the team to prioritise by likelihood and impact. The themes that appear repeatedly across participants deserve particular attention — they represent genuinely shared concerns that the plan may not adequately address.
Update the risk register and project plan. The pre-mortem is not an end in itself. The output is a prioritised list of failure causes that should be evaluated against the existing risk register. Causes not already on the register become new risks. Causes already on the register that appeared frequently in the pre-mortem may warrant a higher probability or impact rating. Some pre-mortem causes will be actionable immediately — a mitigation that can be built into the plan before it is baselined.
When to use a pre-mortem
The pre-mortem is most valuable at three moments: at project kick-off, before major milestones or phase gates, and when risks feel hard to articulate. At kick-off, it identifies the structural risks embedded in the plan while there is still time to address them. Before a major milestone, it surfaces the execution risks that have emerged since planning — the ones the team privately worries about but has not formally registered. The pre-mortem is a complement to the risk register, not a substitute. It surfaces risks that conventional identification misses because of optimism bias and social pressure. Used consistently, it is one of the highest-value investments a project team can make before committing to a baseline.
If your organisation is looking to strengthen its project risk practices beyond conventional risk workshops, XNM's program and project delivery advisory can help you build the facilitation skills and governance practices that turn exercises like the pre-mortem into standard project discipline.