How to run a project pre-mortem meeting

What a pre-mortem is

Psychologist Gary Klein described the method in Harvard Business Review in 2007. Team members assume the project they are planning has just failed, then generate plausible reasons for that failure.

The point is to make it safe to speak up. Klein writes that one reason projects fail is that people keep their reservations to themselves during planning. A pre-mortem asks for exactly those reservations, while the plan can still change.

How it differs from a postmortem and a kickoff

A postmortem looks back at an incident that really happened. A pre-mortem looks forward at a failure that hasn't happened yet, while the plan can still change.

A kickoff agrees the project's purpose, scope and owners. The pre-mortem tests that plan. Klein runs it as part of the kickoff, once the plan has been discussed. On a large project, you can give it its own slot.

When to hold it and who to invite

Hold it after the plan exists but before the team commits to it. Atlassian's Team Playbook runs it before a project starts, and suggests a shorter version during sprint planning.

Size: Atlassian suggests 3 to 11 people.
Who: the people doing the work, plus anyone who knows where similar projects went wrong.
Time: Klein says it can take as little as 20 to 30 minutes. Atlassian's version takes 60.
Materials: a whiteboard and sticky notes, or a shared document for remote teams.

A 60-minute pre-mortem agenda

This agenda combines Klein's steps with the voting and discussion steps from Atlassian's play. Shorten the discussion block if you only have half an hour.

Time	Step	What happens
5 min	Set the scene	Recap the plan. Then ask people to imagine looking into a crystal ball: the project has failed. Not slipped, but a fiasco.
5 min	Write silently	Everyone writes down the reasons it failed, alone. Klein gives this two minutes.
15 min	Go around the room	Each person reads their top reason, one per turn, with no repeats. The leader goes first. Capture every reason where all can see it.
5 min	Group and vote	Merge duplicates. Each person gets three votes for the biggest threats.
25 min	Plan the top risks	Take the top three. For each, judge likelihood, impact and ease of prevention, and agree at least one action.
5 min	Recap actions	Read back every action with its owner and due date.

Facilitate it well

Klein names three common mistakes. Each one quietly turns the pre-mortem back into an ordinary risk review.

Asking "What can go wrong?" instead of stating that the project has failed. Klein calls that the non-challenging question.
Letting the pace drag. Move quickly around the room to keep energy up.
Letting one person, often the most senior, read out their whole list. Take turns, one reason each.

What to leave with and how to follow up

The meeting should produce a short, owned plan, not just a list of worries. Atlassian notes that giving each action an owner and due date makes it more likely to get done.

A risk list: every reason raised, with the top risks marked.
For each top risk: likelihood, impact and how easy it is to prevent.
Mitigations: at least one action per top risk, each with one owner and a due date.
Follow-up: store the list where the team can find it, add actions to your project tracker and revisit the list as the project runs.

A hypothetical worked example

For example, a seven-person team plans to move customers to a new billing system over one quarter. The project lead opens: "It's the end of the quarter, and the migration has failed."

After two minutes of writing, the round robin surfaces nine reasons. The three with the most votes are: invoices went out wrong in the first month, the finance team wasn't trained in time, and the old system's data needed far more cleanup than planned.

Risk	Mitigation	Owner and due date
Wrong invoices in month one	Run both systems in parallel for one billing cycle and compare totals	Engineering lead, before cutover
Finance not trained	Two hands-on sessions using test accounts	Finance manager, two weeks before cutover
Data cleanup underestimated	Sample 200 customer records now and size the cleanup	Data analyst, end of week two

Keep the risk plan from getting lost

After a meeting in Bridge, the structured notes include a summary, decisions and follow-ups. Action items assigned in the meeting also appear in the Action items list on Home.

You can create a custom recap template, for example with sections for risks, owners and mitigations. Then file the meeting in a shared space, so people with access can reopen the list when the team revisits the plan.

Sources & further reading

Keep readingHow to run a project kickoff meeting →