What is a pre-mortem retrospective?
A pre-mortem is a risk session you run at project kickoff, before scope, dates and budgets are locked in. The team pictures a specific future: it's six months from now and the project has failed. Each person then writes down why it failed, as though the failure has already happened. Psychologist Gary Klein developed the technique and described it in his 2007 Harvard Business Review article "Performing a Project Premortem." It builds on research into "prospective hindsight," which found that imagining an event has already occurred helps people come up with more specific reasons for it. The framing is what makes it work. Ask a team "what could go wrong?" and you get polite, generic answers like "scope creep" or "communication issues." Ask "why did it fail?" and people name real causes: the vendor API that was never load tested, the stakeholder who wasn't consulted, the one engineer holding all the knowledge. Treating failure as a given also makes it safe to voice doubts that would otherwise sound negative or disloyal during an optimistic kickoff. This pre-mortem template moves through four steps in TeamRetro. First, list the reasons the project failed. Then identify the early warning signs, agree on prevention steps, and finish by giving each top risk an owner and a date. The last step matters most. A risk without an owner and a deadline is usually forgotten by the end of the first week. Use anonymous ideas so seniority doesn't shape what people write, and for distributed teams, collect ideas asynchronously over a day, then meet only to vote and assign owners.
Pre-mortem retrospective format
It failed. Why?
It's six months from now and the project failed. Write each reason as if it already happened.
This column is the core of the pre-mortem. Set the scene clearly: the project is over, it failed, and everyone knows it. Ask people to write in the past tense ("We missed the launch because...") since this framing produces more concrete causes than speculating about what might go wrong. Keep ideas anonymous so senior voices don't anchor the room. Give 8–10 minutes of silent writing, encourage one reason per idea, then group similar ideas and vote to find the top risks to carry forward.
Early warning signs
What would we notice first if this started to happen?
Early warning signs turn vague fears into things the team can watch for. For each top risk from the first column, ask what the first observable signal would be: a metric, a missed checkpoint, a pattern in standups. Push for signals that are specific and measurable. "Morale drops" is hard to track. "Two sprints in a row with carry-over above 30%" is easy to spot. These become the triggers the risk owners monitor.
How we prevent it
What can we do now to stop this from happening?
This is where the team moves from worry to action. Focus on the highest-voted risks only, usually three to five. For each one, ask what the team can do this week or this month to reduce the likelihood or the impact. Favour small, concrete steps over large process changes. If a prevention idea needs approval or budget, note who needs to be asked. Keep the energy practical; the goal is a shorter list of actions people will do.
Owners and next steps
Who owns each top risk, and by when?
This column is the point of the whole session. Every top risk needs one named owner and a date, or the fears collected today fade before week one ends. Owners don't have to fix the risk alone; they are responsible for watching the warning signs and making sure the prevention step happens. Capture each one as an action in TeamRetro so it carries into future retrospectives, and schedule a quick check-in at the first milestone to review progress.
When to use this retrospective
- At the kickoff of a new project, product launch or major initiative, before scope, dates and budget are finalised.
- Before a high-stakes milestone such as a migration, go-live or contract signing, where a late surprise would be expensive.
- When a team is unusually optimistic about a plan and quieter members may be holding back doubts.
- When starting work with a new vendor, partner or cross-functional group whose dependencies are not yet well understood.
- At the start of a new quarter or program increment, to stress-test the plan before the team commits to it.
Suggested icebreaker questions
- What's the most memorable plan you've seen go wrong, at work or in life, and what was the first warning sign?
- If this project were a movie, what genre would the failure version be?
Want a warm-up your team plays, not just answers out loud? Browse free icebreakers →
Ideas and tips for your retrospective meeting
- Run the pre-mortem at project kickoff, before commitments are locked in. Never run it mid-crisis, when the team needs to solve problems and imagining failure only adds anxiety.
- Keep ideas anonymous. If names are visible, the most senior person's fears anchor the room and everyone else writes thin agreement.
- Insist on past-tense framing in the first column. "Why did it fail?" produces more specific, realistic risks than "What could go wrong?", so gently rephrase ideas that slip back into hypotheticals.
- Vote to narrow the list to three to five top risks before discussing prevention. Trying to address every idea spreads the team too thin and nothing gets done.
- Don't end the session until each top risk has one owner and a date. Without them, the risks you collected are forgotten before week one.
- For distributed teams, go async: collect ideas over a day across time zones, then meet for 30 minutes only to group, vote and assign owners.