It failed. Why?

It's six months from now and the project failed. Write each reason as if it already happened.

We relied on the payments vendor's sandbox and never tested against production limits. Launch day traffic took the checkout down.
Only Priya understood the data migration scripts. She went on leave in month three and everything stalled.
Legal reviewed the terms of service two weeks before launch and we had to rebuild the consent flow.
Early warning signs

What would we notice first if this started to happen?

Vendor support tickets taking longer than two days to get a response.
The same person is tagged on every migration pull request review.
New tickets appearing mid-sprint with 'quick request from sales' in the description.
How we prevent it

What can we do now to stop this from happening?

Run a load test against the vendor's production environment in sprint two, before we build on top of it.
Pair someone with Priya on the migration scripts and document the runbook by end of month.
Book a legal review of the consent flow during design, not after build.
Owners and next steps

Who owns each top risk, and by when?

Marco owns the vendor load test, due end of sprint two.
I'll pair with Priya on migration and we'll publish the runbook by the 15th.
Dana will book the legal review of the consent flow before design sign-off next Friday.

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.

Frequently asked questions

What is the difference between a pre-mortem and a post-mortem?
A post-mortem happens after a project ends or fails and looks back at what actually went wrong. A pre-mortem happens before the work starts and imagines the failure in advance, so the team can prevent it while there's still time to act.
Who created the pre-mortem technique?
Psychologist Gary Klein coined the pre-mortem and described it in his 2007 Harvard Business Review article "Performing a Project Premortem." It draws on research showing that imagining an outcome has already happened helps people identify more specific reasons for it.
How long does a pre-mortem take?
Most pre-mortems take 45–60 minutes for a team of five to ten people. With the async option, the live meeting can shrink to around 30 minutes because ideas are already collected before the call.
When should you run a pre-mortem?
Run it at project kickoff, before commitments such as scope, deadlines and budgets are locked in. Avoid running it mid-crisis, when the team needs to focus on solving real problems.
Why should pre-mortem ideas be anonymous?
When names are visible, people tend to echo the concerns of the most senior person in the room. Anonymous ideas surface the risks people actually worry about, including ones that implicate leadership decisions.
Can a pre-mortem be run asynchronously?
Yes. Distributed teams can collect ideas in TeamRetro over a day, then meet only to group, vote on the top risks and assign owners with dates.
Ready to run this retrospective?Try this retrospective live