On this page (10 sections)
A pre-mortem asks the team to imagine the project has already failed, then explain why. Everyone writes why this project failed, then the team works back to the early warning signs it could watch for, how we prevent it and what we do now. It's a post-mortem in reverse, held while there's still time to avoid the failure.
The four columns
| Column | What goes here | Example note |
|---|---|---|
| 💥 Why this project failed | Reasons for failure, written as if it already happened | "The data migration ran three weeks over and we missed the launch." |
| 🚩 Early warning signs | What you'd see first if that failure were starting | "A test migration of one customer takes more than a day." |
| 🛡️ How we prevent it | Changes to the plan that make the failure less likely | "Migrate the five biggest customers first, two weeks before launch." |
| ✅ What we do now | Actions that start this week | "Test-migrate a copy of the largest account by Friday." |
"Failed," not "might fail." "What could go wrong?" gets polite, general answers. "It's six months on and the project failed; why?" gets specific ones, because people explain a fact instead of raising an objection.
Where it comes from. Gary Klein described the method in "Performing a Project Premortem" in Harvard Business Review (September 2007). In his version, the team hears the plan, imagines it failed, writes down reasons alone, then shares one reason each in turn until the list is complete. Klein cites 1989 research by Deborah Mitchell, Jay Russo and Nancy Pennington which found that imagining an event has already happened ("prospective hindsight") improves people's ability to identify reasons for future outcomes by 30%. His stated aim is to make it safe for people who doubt the plan to say so.
In Retro Rabbit
The Pre-Mortem template in Retro Rabbit
Pick Pre-Mortem from the format library when you create a Team Room (or later in its Settings) and the board starts with its four columns. Your team adds notes during the sprint, with or without their name shown, then votes on what to talk about.
Pre-Mortem · Sprint #14
Example notes
Why this project failed
- Data migration ran three weeks over and we missed launch2 votes
- Partner API wasn't ready, so we built against guesses4 votes
Early warning signs
- A test migration of one customer takes more than a day5 votes
- Still no sandbox date from the partner by the 15th3 votes
How we prevent it
- Migrate the five biggest customers first, two weeks early3 votes
- Build against a mock so the partner date can slip2 votes
What we do now
- Test-migrate a copy of the largest account by Friday1 vote
- Ask the partner for a sandbox date in writing this week1 vote
- Why this project failed
- Early warning signs
- How we prevent it
- What we do now
14-day free trial · No credit card
When to use it (and when not to)
Use it when:
- the team is about to commit to a plan: a project, a launch, a migration, a vendor switch
- the project is expensive to get wrong or hard to undo
- you sense quiet doubt, but nobody wants to be the pessimist
Pick something else when:
- there's no plan yet. You can't imagine a plan failing if it doesn't exist; agree on the goal with a futurespective first.
- the team is brand new and anxious. Failure stories can rattle people who don't trust each other yet; Hopes and Fears is gentler.
- the failure already happened. Use an incident review or a project post-mortem.
How to run it live (45 minutes)
| Time | Step |
|---|---|
| 0–3 min | Check open action items |
| 3–7 min | Brief the plan and announce the failure |
| 7–15 min | Write failure reasons alone, then post them |
| 15–23 min | Go round: one new reason each |
| 23–27 min | Group and dot vote |
| 27–40 min | Top three: warning signs and prevention |
| 40–45 min | What we do now, with owners |
- Check the carry-over. If the Team Room has run retros before, look at Previous Retro and Old / Unresolved Items in the Action Items panel. An item left open last quarter may already be a failure reason.
- Brief, then announce. The project lead spends two minutes on the plan. Then say it as fact: "It's the end of March. The project failed."
- Write alone first. Set the shared timer for eight minutes. Everyone lists reasons on paper or in their own notes for three minutes, then posts them. Lists written alone are more varied.
- Go round. Each person reads out one reason not yet on the board, until nobody has anything new. Nobody defends the plan yet.
- Vote. Drag duplicates together, then dot vote with three votes each on the failures most likely or most damaging. Sort by Most Votes.
- Work back from the top three. What would we see first? What change prevents it? Fill in the middle columns.
- Decide what starts now. Each top failure gets at least one item in the last column, with an owner.
How to run it async over a sprint
A pre-mortem works async across time zones, or when a big plan needs thinking time. Run it in the project's first week.
- Day 1: share the plan, start the retro with Pre-Mortem (Try a different format in Start New Retro) and post the scene as the first note: a date, and "The project failed. Why?"
- Days 1–3: everyone posts at least three failure reasons, written before reading the board. Turning off Show Name helps when the plan belongs to someone senior.
- Day 4: the facilitator groups duplicates and everyone votes.
- Days 5–6: owners of each part of the plan add warning signs and prevention for the top failures.
- The day before the meeting: read the CarrotIQ summary of each column.
- Meeting: a 20-minute call to agree what starts now, or a written round where owners accept by end of day.
Afterward, keep watching the warning signs: a pre-mortem pays off when someone spots one months later. More in how to run an async retrospective.
10 example prompts
Why this project failed
- What did we assume would work that didn't?
- Which dependency let us down?
- What did we find out too late?
- Why did the people who doubted the plan stay quiet?
Early warning signs 5. What would we see in the first month if this were going wrong? 6. Which number would move first?
How we prevent it 7. What could we do first, so that we fail cheaply? 8. What would we cut if we had to?
What we do now 9. What can we test this week? 10. Who watches each warning sign?
Facilitator tip and a common pitfall
Tip: make the failure vivid and certain. Don't hedge with "imagine it struggled a bit". Give a date, say the project failed, and add a detail: "The pilot customer canceled." People take a certain failure seriously.
Pitfall: a long list and no changes. Teams enjoy writing failure stories, then leave with a scary list and the same plan. If nothing in "How we prevent it" changes scope, order, staffing or dates, it was a venting session. For each top failure, ask: what are we doing differently because of this?
How AI helps with this format
On Pro AI (and during the free trial), CarrotIQ handles the admin:
- Group names. Drag "migration overran" onto "customer data messier than expected" and CarrotIQ names the group, for example "Data Migration Delays".
- Summaries. The Sprint Summary condenses each column and the board. The first column's summary is a plain-language risk list for stakeholders.
- Suggested action items. CarrotIQ Suggest drafts an action from the notes, weighting the most-voted ones. It's a first draft for "what we do now".
Example action items
Each top failure should change the plan or give someone a sign to watch.
| Failure | Action item |
|---|---|
| "Data migration ran three weeks over" | "Yuki test-migrates a copy of the largest customer by Friday and posts the time. If it's over a day, we re-plan the migration." |
| "The partner API wasn't ready in time" | "Mateo asks the partner for a sandbox date in writing this week. If there's none by the 15th, we build against a mock first." |
| "We built the wrong thing for the pilot customer" | "Sofia books three calls with the pilot customer's users before sprint 2 and shares notes." |
| "The one person who knew the billing code left" | "Amara gets a second developer to pair on every billing change this quarter. Check at each retro how many PRs had two names." |
At each retro, the Previous Retro tab shows these, and Old / Unresolved Items keeps older ones visible. See retrospective action items that actually get done.
Use this template in Retro Rabbit
- Start a 14-day free trial. No card is needed.
- For one retro, click Try a different format in Start New Retro and pick Pre-Mortem: it applies to that retro only, and your Team Room keeps its usual columns. To make it the room's format, choose it under "Browse all formats" when you create your Team Room, or later in the Team Room's Settings.
- Before you invite the team, post the failure scene as the first note: "It's the end of March. The project failed. Why?"
The board stays in the Team Room's history, so you can compare it with the project's end. See pricing for plans.
Related formats
- Futurespective: imagine success first, to agree on the goal
- Hopes and Fears: a gentler kickoff for a new team
- Sailboat: track the risks as rocks, sprint by sprint
- Project post-mortem template: at the end, compare what happened with what you predicted
- More formats in Kickoff and planning
- All retrospective templates
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 it in Harvard Business Review in 2007. Treating the failure as certain makes people more specific, and more willing to say what worries them.
What's the difference between a pre-mortem and a post-mortem?
A post-mortem looks at a failure that happened. A pre-mortem looks at one that hasn't, while there's still time to prevent it. Run a pre-mortem at kickoff and a project post-mortem at the end; comparing the two shows which risks you saw coming.
When should you run a pre-mortem?
After the plan exists but before the team commits to it: at project kickoff, before a big release or before a migration. Too early and there's no plan to test; too late and nobody wants to change it.
How long does a pre-mortem take?
About 45 minutes for one project and a team of five to nine. Projects with several teams or many dependencies can need 90 minutes.
Who should attend a pre-mortem?
Everyone who knows the plan well enough to see how it could fail: the team, the project lead and the people the project depends on. Quiet experts matter most; the format exists to make it safe for them to speak up.
Is a pre-mortem the same as a futurespective?
Both start in the future. A pre-mortem imagines failure to find risks; a futurespective imagines success to agree on a goal. Some teams run both, success first.
Run this retro in Retro Rabbit
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