On this page (9 sections)
A pre-mortem is a meeting where the team assumes its project has already failed, then writes down why. Run it after the plan exists and before anyone commits: 45 minutes, starting with everyone writing alone, ending with a short list of changes to the plan that start this week.
It only takes one sentence to set up, and most of the value comes from what that sentence does to the room. Below: a free pre-mortem template you can copy, a minute-by-minute agenda, what to say as the facilitator, a worked example, and an honest look at the evidence.
What is a pre-mortem?
Gary Klein described the method in "Performing a Project Premortem" in Harvard Business Review in 2007. His starting point is that people who doubt a plan often stay quiet during planning. Declaring the project dead changes what speaking up means: you're no longer objecting to the plan, you're answering a question.
One sentence changes the answers
"What could go wrong?"
- Sounds like an objection to the plan and the person who wrote it
- Gets general answers, such as "scope creep" and "timeline risk"
- The most senior person's opinion sets the limits
"It failed. Why?"
- Doubts become explanations of something that has already happened
- Gets specific answers, such as "the data migration ran three weeks over"
- Everyone is expected to contribute, including the plan's author
Klein's version, as summarized in Jason Collins's course notes, has five steps: brief the team on the plan, say the project has failed, have everyone write down reasons alone, share one reason each until the list is complete, then review the list for ways to strengthen the plan.
It isn't the same as the other meetings it gets confused with:
| Looks at | When | You leave with | |
|---|---|---|---|
| Pre-mortem | A failure that hasn't happened | Before committing to a plan | Changes to the plan, signs to watch |
| Risk register | Risks people already know about | Throughout the project | A maintained list with owners |
| Post-mortem | A failure that did happen | After it's over | Causes and fixes for next time |
| Futurespective | A success that hasn't happened | Before the work starts | A shared goal |
A free pre-mortem template
Copy this table into any doc or spreadsheet. Each column has a prompt to read out, and one example so people can see the level of detail you're after.
| 💥 Why this project failed | 🚩 Early warning signs | 🛡️ How we prevent it | ✅ What we do now |
|---|---|---|---|
| Written as if it already happened. | What we'd see first if this started to happen. | Changes to the plan that make it less likely. | Something that starts this week, with one owner. |
| "The data migration ran three weeks over and we missed the launch." | "A test migration of one customer takes more than a day." | "Migrate the five biggest customers first, two weeks before launch." | "Test-migrate a copy of the largest account by Friday." |
Retro Rabbit has the same four columns ready to use as the Pre-Mortem template. The table above is free to use anywhere; running it in Retro Rabbit needs the 14-day trial, as there's no free plan.
How to run a pre-mortem in 45 minutes
Book it for a team of five to nine who know the plan: the team, the project lead, and the people you depend on. Share the plan a day ahead, so the meeting isn't the first time anyone reads it.
The 45-minute pre-mortem
Atlassian's version runs 60 minutes, with more time for grouping and voting.
-
0–7 min
Brief, then announce
A quick look at any open actions, two minutes on the plan, then state the failure as a fact.
-
7–15 min
Write alone
Everyone lists reasons on their own, in silence.
-
15–27 min
Go round and vote
One new reason each, until nobody has any. Then group and dot vote.
-
27–40 min
Work back
For the top three, name the warning signs and how to prevent them.
-
40–45 min
Commit
Agree what starts this week, and give each item an owner.
If you have more people or several teams involved, Atlassian's 60-minute version gives everyone three votes and spends 10 minutes on each top topic. Its framing is softer, though: it asks what could go wrong, rather than declaring the project dead.
What to say
The opening is the whole trick, so don't hedge. Pick a date and add one detail.
Then protect the next few minutes:
- Say that doubts are the point. The plan's author goes along with it, and ideally goes first when you share.
- Nobody defends the plan yet. If someone says "but we've handled that", thank them and write the reason down anyway.
- Keep writing alone. Lists written alone are more varied. If people can see each other's notes as they write, ask them to draft on paper first.
Prompts for when the list runs dry
Assumptions
What did we assume would work that didn't? What did we find out too late?
Dependencies
Which team, vendor or approval let us down? Who outside this room could have stopped it?
People
Who left, or got pulled onto something else? What did only one person know?
The unsaid
What did some of us see coming and not say? Why did it feel easier to stay quiet?
A worked example
This example is made up, to show what useful notes look like. Imagine a team moving customers from an old billing system to a new one over two quarters.
The announcement: "It's the end of June. The billing migration failed. We rolled back after two weeks, and finance is reconciling by hand."
| Why it failed | Warning sign | Prevention | Starts this week |
|---|---|---|---|
| Old invoices had formats nobody documented, and the import rejected a third of them | More than 5% of a sample import fails | Sample 500 invoices across all years, not just recent ones | Tomás runs the sample import by Friday and posts the failure rate |
| Finance found out about the cutover date from an email | Finance has no named person on the project by week 2 | Add a finance lead to planning and let them sign off the date | Priya asks the finance director to name someone by Wednesday |
| Rollback was never tested, so it took days | No rollback rehearsal by the first milestone | Rehearse rollback in staging before any customer moves | Sam adds a rollback rehearsal to the first milestone |
| The one person who knew the old system went on leave in May | Only one name on every change to the old system | Pair a second engineer on old-system changes now | Elena pairs with Jun on the next two changes |
Notice that the last column isn't "be careful with invoices". Every item changes something, or finds something out, before the plan is locked.
What to do with the results
The meeting is cheap. The value comes from what changes afterward.
From a list of failures to a better plan
-
1
Change the plan
For each top failure, ask what you're doing differently because of it: scope, order, staffing or dates. If nothing changes, you held a venting session.
-
2
Name a watcher for each warning sign
Give each one an owner and a check date. A warning sign nobody is watching won't warn anyone.
-
3
Start something this week
Prefer actions that find something out quickly, such as a test migration, over ones that only make the plan longer.
-
4
Come back to it
Revisit the list at each milestone. Then compare it with what actually happened in your project retrospective.
Not every reason needs a response. Klein's method leaves it to the project lead to review the list, and teams often rate each threat by how likely and how damaging it is. Accept the rest knowingly, and say so.
Does a pre-mortem actually work?
The academic evidence is thinner than most articles suggest. Jason Collins's review of the research is the most careful we found, and it's worth reading if you're being asked to justify the meeting.
What the research measured
~30%
more reasons generated when an event is imagined as certain (Mitchell, Russo and Pennington, 1989). The study counted reasons and didn't assess their quality.
178
students compared methods for judging a plan (Veinott et al., 2010). Imagining failure cut confidence in the plan about twice as much as listing pros and cons, or cons alone.
101
experienced program managers and engineers (Gallop and Bischoff, 2016). Pre-mortem teams found more high-quality risks than brainstorming teams.
Source: Jason Collins, course notes on behavioural economics and corporate decision making
Two cautions. The often-quoted line that a pre-mortem makes people 30% better at identifying the correct reasons overstates that first study: Collins points out it counted reasons, not correct ones. And we found no study showing that projects with a pre-mortem fail less often. What the research supports is narrower: more reasons, less overconfidence, and at least one result showing better risks. For a 45-minute meeting, that's a fair trade, as long as you don't promise more.
Common pre-mortem mistakes
| Mistake | What it looks like | Fix |
|---|---|---|
| Hedging the failure | "Let's imagine things went a bit badly" | State a date and a specific outcome, as fact |
| Running it too late | The plan is announced and the budget is signed | Hold it before you commit, while changes are cheap |
| Talking before writing | The first speaker sets the theme for everyone | Eight silent minutes first |
| The boss defends the plan | Every reason gets an argument | Plan owners listen until the list is complete |
| A long list and no changes | Everyone leaves worried, with the same plan | Each top failure must change the plan or name a watcher |
| Forgetting it | The list never gets looked at again | Revisit at each milestone and at the project's end |
Run your pre-mortem in Retro Rabbit
The Pre-Mortem format gives you the four columns on a shared board, for one retro or as a Team Room's default.
- People who can't make the meeting can still contribute. The board can stay open for a few days ahead, which helps across time zones and gives people time to think. Retro Rabbit doesn't hide notes while people write, so ask everyone to draft their reasons before reading the board.
- Doubts can go up without a name. Turning off Show Name posts a note as Anonymous, which helps when the plan belongs to someone senior. On a small team, writing style can still give someone away.
- CarrotIQ handles the admin. On Pro AI and during the trial, it suggests groups for duplicate reasons, summarizes each column, and can draft an action from your most-voted notes.
- What you decide comes back. Each action has an owner, is due by the next retro by default, and shows up at the next retro's check-in as Done, Keep or Drop.
Start a 14-day free trial, with no card, and post the announcement as the first note: a date, and "The project failed. Why?" See pricing.
Related
Frequently asked questions
What is a pre-mortem?
A planning meeting where the team assumes the project has already failed and writes down why. Gary Klein described the method in Harvard Business Review in 2007. Treating the failure as a fact makes it easier for people to raise doubts they'd otherwise keep to themselves.
Is there a free pre-mortem template?
Yes: copy the four-column table in this post into any doc or spreadsheet, for free. The columns are why this project failed, early warning signs, how we prevent it, and what we do now. Retro Rabbit has the same format ready to use during its 14-day trial; it has no free plan.
How long does a pre-mortem take?
About 45 minutes for one project and a team of five to nine. Atlassian's version runs 60 minutes. Projects with several teams or many dependencies can need 90.
What's the difference between a pre-mortem and a risk register?
A risk register records risks someone has already thought of, usually in cautious language. A pre-mortem is a way to find the ones nobody has said out loud. Feed its top results into your risk register if you keep one.
When should you run a pre-mortem?
After the plan exists and before the team commits to it: at project kickoff, or before a big release or migration. Too early and there's nothing to test. Too late and nobody wants to change the plan.
Does a pre-mortem actually work?
The evidence is promising but thin. Small studies found that imagining a failure produces more reasons and lowers overconfidence, and one found more high-quality risks than brainstorming. We found no study showing that projects which ran a pre-mortem fail less often.
Run retros that actually lead to change
Your team adds notes during the sprint, CarrotIQ groups and summarizes them and suggests action items, and unfinished items carry into the next retro.
14-day free trial · No credit card