Whimsical LogoWhimsical LogoWhimsical Logo

Brand
Get all logo versions.
Download

Premortem Template

A premortem is the postmortem you run before the project: the team imagines the work has already failed and works out why, while there's still time to act. Gary Klein introduced the method, and research on prospective hindsight shows the failed-already framing finds about 30% more causes. This template runs it in four prompted steps: what might go wrong, the consequences, the mitigations, and what to do next.

Four premortem steps with a worked example threading through them.

What's included

  • Four prompted steps. What might go wrong, what consequences might we experience, how can we mitigate these risks, and what should we do next.
  • A worked example. A real thread runs through the steps: a confusing product change, support overwhelmed, multi-channel communication, a messaging plan.
  • A project header. Name and description slots so the premortem stays scoped to one plan.
  • Voting built in. Prioritize which failure scenarios deserve mitigation; the tip explains the thumb-icon voting flow.
  • A timer tip. Timebox each step with the built-in timer so the worrying ends and the planning starts.

Why run a premortem?

  • Hindsight, before it costs anything. Saying 'the project failed because…' surfaces causes the conditional 'what could go wrong?' never does; the research puts the gain around 30%.
  • Permission to dissent. Asking everyone to describe the failure makes doubt a contribution instead of disloyalty; the quiet skeptic finally talks.
  • It counters the planning glow. Right after planning, teams are at peak overconfidence; the premortem is the scheduled correction.
  • Consequences get sized. The dedicated consequences step, which most premortem templates skip, tells you which risks are worth mitigation budget.
  • It ends in actions, not anxiety. Steps three and four convert the failure stories into mitigations with owners.

How to use this template

  1. Set the scene. Name the project, then tell the team: it's six months from now and this project failed completely.
  2. Write the failure stories. Everyone adds what went wrong, silently and specifically; past tense does the work.
  3. Size the consequences. For the biggest risks, write what actually happens if they land: churn, missed dates, support load.
  4. Design mitigations. For each risk worth the effort, write how to avoid it or blunt it.
  5. Commit to next steps. Turn mitigations into actions with owners; fold them into the project plan itself.
  6. Revisit at milestones. Re-read the board mid-project; the risks you predicted are the cheapest monitoring system you own.

Premortem vs postmortem

One price difference separates them: the postmortem's lessons cost a real failure; the premortem's cost a meeting. The postmortem analyzes what happened, assigns systemic causes, and improves the next project. The premortem imagines the failure first, harvests the same causal insight, and improves this project, the one you can still save. The catch is honesty: a postmortem has evidence to keep it grounded, while a premortem only works if the team genuinely commits to the failure story instead of listing comfortable risks.

Frequently asked questions

  • A premortem is a planning exercise where the team assumes the project has already failed and works backward to explain why, before work begins. Gary Klein described the method in Harvard Business Review in 2007. It inverts the postmortem: instead of learning from a real failure, you harvest the lessons from an imagined one while the plan can still change.

  • Tense. 'What could go wrong?' invites hedged, polite maybes. 'The project failed; what happened?' forces specific stories, and the research behind it, on prospective hindsight, found that imagining an event as already having occurred improves people's ability to identify its causes by roughly 30%. The same shift also licenses dissent: describing the failure is the assignment, so nobody looks negative doing it.

  • After the plan exists and before the work starts: the kickoff window. That's when the team knows enough to imagine specific failures and the plan is still cheap to change. Big launches, migrations, and anything with a hard date deserve one; a sprint-sized premortem can run in twenty minutes. Running one mid-project works too, before a major milestone, while course corrections are still affordable.

  • Timing, and what the lessons can still change. The postmortem happens after something real went wrong: you analyze, you learn, and the cost is already paid. The premortem happens before, on an imagined failure, so the lessons arrive while they can still change the plan. They use the same muscle, causal storytelling, which is why teams that run good postmortems pick up premortems quickly. Run both; they bracket the project.

  • A risk assessment is an ongoing, analytical document: risks logged with probability and impact scores, maintained through the project. A premortem is a one-session, imaginative exercise that exploits a psychological trick, and it surfaces the fears people would never type into a register. They feed each other: run the premortem to find the risks honestly, then carry the keepers into the risk register with owners.