What is a pre-mortem?

A pre-mortem is a planning exercise where the team imagines the program has already failed and works backward to explain why. Instead of asking what might go wrong, which invites optimism, you assume failure as a fact and ask what caused it. That small shift gives people permission to voice doubts they would otherwise keep quiet, and it surfaces risks a normal risk review misses.

How do you run a pre-mortem?

Gather the team, set the scene with a date in the future, and say the program failed. Have everyone independently write down the reasons before anyone speaks, so the loudest voice does not anchor the room. Collect the failure modes, group the duplicates, score each by likelihood and impact, and assign a prevention and an owner to the ones that score high. The output is a short list of concrete actions, not a pile of worries.

What is the difference between a pre-mortem and a risk register?

A risk register is an ongoing list you maintain through the program. A pre-mortem is a one-time exercise, usually at kickoff or a major gate, designed to generate that list in the first place. The pre-mortem uses imagined failure to pull out risks that polite optimism would hide. What it produces should flow straight into your risk register or RAID log to be tracked.

When should you do a pre-mortem?

Run one at the start of any program big enough to hurt if it fails, and again before a major irreversible step like a launch or a cutover. Early is better, because the cheapest time to prevent a failure is before you have committed to the path that causes it. A pre-mortem an hour before launch is still useful, but most of its value is gone.

Pre-Mortem Worksheet

Assume the program already failed and work backward to find out why, while there is still time to prevent it. List the failure modes, score each by likelihood and impact, and assign a prevention and an owner. Everything saves in your browser. No signup.

Program name

Imagined failure date

What failed and why	Likelihood	Impact	Score	Prevention / mitigation	Owner

1-6 Low - note it 7-12 Medium - plan a prevention 13-25 High - act before kickoff

How to run a pre-mortem

A pre-mortem flips the question that kills honest risk conversations. Instead of asking what might go wrong, which people answer with cautious optimism, you state that the program failed and ask the team to explain why. Assuming failure as a fact gives everyone permission to say the thing they were too polite to raise, and that is where the real risks come from.

Run it early. Set a date in the future, declare the program a failure, and have each person write their reasons down before anyone speaks, so the room is not anchored by the most senior voice. Then group the answers, score each failure mode by likelihood and impact, and assign a prevention and an owner to the ones that score high. The output is a short list of concrete actions you feed straight into your risk register or RAID log.

Common mistakes to avoid

Asking "what could go wrong" instead of "why did it fail." The framing is the whole technique. Assume failure happened.
Letting the loudest person go first. Have everyone write silently before the discussion or you only hear one view.
Stopping at the list. A failure mode without a prevention and an owner is just a worry. Assign both.
Running it too late. The value is in prevention, and prevention needs time. Do it at kickoff, not the night before launch.

For more on surfacing risks before they derail a program, read managing dependencies across eight engineering teams over in the Insights.

Built by Arsenii Samoilov, a Senior Technical Program Manager with 19+ years at Intuit, Atlassian, Adobe, Salesforce, Roku, and Apple. If your team needs help standing up program governance, get in touch.

Read the Insights →