Pre-Mortem

Purpose

The Pre-Mortem flips traditional risk analysis on its head. Instead of asking "what could go wrong?", the team assumes the project has already failed spectacularly and then brainstorms reasons why. This prospective hindsight unlocks risks that optimism bias normally hides, producing a richer and more honest risk register before work begins.

At a glance

How to run

1. Frame the project (3 min): Briefly describe the initiative, its goals, and timeline.
2. Announce failure (2 min): Tell the group: "Imagine it is six months from now. This project has failed completely. What happened?"
3. Silent brainstorm (8 min): Each person writes as many failure reasons as possible on sticky notes.
4. Share round (8 min): Go around the table; each person reads one reason per turn until all are shared.
5. Cluster and prioritise (5 min): Group related risks and dot-vote on the most likely or most damaging.
6. Mitigate (4 min): For the top 3–5 risks, brainstorm one preventive action each.

Materials needed

• Sticky notes and markers
• Whiteboard or flip chart
• Dot stickers for voting
• Timer

Pitfalls & common mistakes

• Being too polite: The exercise only works when people voice uncomfortable truths. Normalise candour.
• Skipping mitigation: Listing risks without actions creates anxiety, not preparedness.
• Leadership bias: If a senior leader dismisses a risk, others shut down. Leaders should contribute last or silently.
• Scope creep: Keep focus on the one project; do not let it become a general gripe session.

Inclusion & accessibility

• Silent writing levels the playing field for introverts and non-native speakers.
• Allow anonymous submission if the topic is politically sensitive.
• Provide the scenario prompt in writing so hearing-impaired participants can follow.

Variations

• Pre-Mortem + Pre-Parade: After the failure brainstorm, do a second round imagining wild success and what caused it.
• Timed rounds: Set a 2-minute timer per person for faster energy.
• Anonymous digital Pre-Mortem: Use a shared doc or tool for fully anonymous input.

When NOT to use this

• After the project has already launched — use a retrospective or post-mortem instead.
• When the team has no influence over the project’s direction — surfacing risks they cannot address is demoralising.
• When the group lacks basic context about the project — provide a briefing first.

Source & further reading

• Gary Klein, "Performing a Project Premortem", *Harvard Business Review* (2007)
• Daniel Kahneman, *Thinking, Fast and Slow* (2011) — prospective hindsight
• Gamestorming: Pre-Mortem