Pre-mortem Facilitator

Overview

A pre-mortem is a risk identification exercise where the team imagines a project has already failed, then works backwards to figure out why. Instead of asking "what could go wrong?", you ask "it went wrong, so what happened?" That simple shift in framing unlocks substantially more honest and creative thinking about risks.

Traditional risk brainstorming suffers from optimism bias. People are reluctant to raise concerns about a plan the group is excited about. Pre-mortems bypass this by making failure the starting assumption, which gives everyone permission to voice doubts without appearing negative.

This tool guides you through the full pre-mortem process step by step: defining the project, brainstorming failure reasons, categorising and scoring risks, visualising them on a risk matrix, and assigning mitigation actions. Everything runs in your browser. Nothing is stored or sent to a server.

Facilitator

The Science Behind Pre-mortems

The pre-mortem technique was popularised by psychologist Gary Klein in 2007. It is grounded in a research finding called prospective hindsight: imagining that an event has already occurred increases the ability to identify reasons for that event by up to 30% compared to simply imagining a future event.

The study by Mitchell, Russo, and Pennington (1989) demonstrated that when people assume an outcome has happened, they generate more specific and more plausible explanations than when they are asked to predict what might happen. The pre-mortem leverages this cognitive shift deliberately.

Beyond the research, pre-mortems also counteract two well-documented biases. Optimism bias causes teams to underestimate risks when they are excited about a plan. Groupthink discourages individuals from raising concerns that go against the group consensus. By starting from the assumption of failure, both biases are neutralised because dissent becomes the expected contribution.

When to Run One

• Project kick-offs. The ideal moment is right after the team has agreed on the plan but before execution starts. Everyone is informed enough to identify risks but there is still time to adjust.
• Before major launches. Product launches, system migrations, and large deployments all benefit from a final check on what could go wrong. A 30-minute pre-mortem can surface risks that weeks of planning missed.
• Strategy changes. When the organisation shifts direction, there are always risks that get overlooked in the excitement of the new strategy. A pre-mortem forces the team to think about execution realities.
• Before high-stakes decisions. Any decision with significant, hard-to-reverse consequences is worth a pre-mortem. Mergers, major contracts, and platform changes are good examples.
• At regular intervals on long projects. For multi-quarter initiatives, running a pre-mortem every few months keeps the risk register fresh and catches new risks as circumstances change.

Best Practices

• Individual brainstorming first. Give people 3 to 5 minutes to write down failure reasons silently before sharing. This prevents anchoring on the first idea someone says aloud and ensures quieter team members contribute.
• Encourage wild ideas. The best pre-mortems surface risks that feel uncomfortable or unlikely. Create a safe space where "that would never happen" is not an acceptable dismissal. Sometimes the unlikely risks are the most damaging.
• Separate brainstorming from evaluation. Do not rate or discuss risks during the brainstorming phase. Get everything on the table first, then categorise and score afterwards. Premature evaluation kills creativity.
• Focus mitigations on the top risks. You do not need an action plan for every risk. Concentrate on the high-impact, high-likelihood items. Trying to mitigate everything dilutes focus.
• Assign clear owners. Every mitigation action needs one person responsible. "The team will handle it" means nobody will handle it.
• Keep the report visible. Share the pre-mortem report in a place the team checks regularly. If it disappears into a folder, it will not influence decisions.
• Time-box the exercise. A good pre-mortem runs 30 to 45 minutes. Five minutes for brainstorming, ten for discussion and rating, and the rest for mitigations. Longer sessions tend to lose energy.

Common Mistakes

• Superficial risks. "Communication breakdown" is not specific enough to act on. Push for concrete failure scenarios: "The backend team does not know about the new API contract until the week before launch." Specific risks lead to specific mitigations.
• Skipping mitigations. Identifying risks without deciding what to do about them is a half-finished exercise. The pre-mortem only creates value if it changes behaviour. Always end with actions.
• Only including project leads. The people closest to the work often see risks that leadership misses. Include engineers, designers, and anyone who will be doing the hands-on delivery.
• Treating it as a formality. If the team senses that the pre-mortem is a checkbox exercise and nothing will change, they will not engage honestly. Show that you take the output seriously by acting on it.
• Anchoring on a single category. Teams often fixate on technical risks and ignore people, process, or external risks. Use the categories to check your coverage across all five areas.
• Running it too late. A pre-mortem after the project is 80% done has limited value. The earlier you run it, the more options you have to adjust the plan.

Related Tools

Related Templates