Pre-mortem

What it is

The pre-mortem was formalized by cognitive psychologist Gary Klein in “Performing a Project Premortem,” Harvard Business Review (September 2007). Klein drew on research by Deborah Mitchell, J. Edward Russo and Nancy Pennington — “Back to the Future: Temporal Perspective in the Explanation of Events,” Journal of Behavioral Decision Making (1989) — which showed that asking people to imagine an outcome has already happened and explain why produces substantially richer and more accurate risk identification than asking them to forecast what might happen.

Klein’s technique is simple. Before committing to a plan, gather the team. Tell them: imagine it’s six months from now and this project has failed spectacularly. Everyone agrees it’s a disaster. Each person then writes down the reasons for the failure, as if documenting history. The group shares and clusters the reasons. The highest-frequency and highest-impact ones become explicit mitigations in the plan.

The pre-mortem isn’t a pessimism exercise; it’s a risk-surfacing one. Teams that skip it tend to discover known-but-unsaid risks only at the post-mortem, when the cost of acting on them has risen from cheap mitigation to expensive recovery. A 20-minute pre-mortem routinely pays for itself several times over in avoided rework.

When to use it

Run a pre-mortem when:

• You’re about to commit to a meaningful plan — a sprint goal, a migration, a launch, an architecture change, a new process.
• The team has information that the plan doesn’t reflect. Concerns, prior experience, pattern-matching from past failures. The pre-mortem lets those surface without requiring anyone to be the lone voice of dissent.
• There’s a track record of the same failure mode showing up across projects. Pre-mortems are the easiest way to inject the lessons from prior work into the next plan.
• You’ve just finished a retrospective and want to prevent next sprint’s failure from mirroring the one you’re discussing. Run a pre-mortem at the start of the next planning session.

Don’t run a pre-mortem when:

• The problem has already happened. That’s a 5 Whys, fishbone or retrospective.
• The plan is routine and low-stakes. A pre-mortem on “we’ll fix this typo” is theater. Reserve the ritual for decisions with meaningful consequence.
• The team hasn’t committed to the plan yet. A pre-mortem on a hypothetical plan becomes a plan-critique session and loses its power. Commit conceptually first, then pre-mortem the commitment.
• The team is in a psychological-safety crisis. A pre-mortem needs people to feel free naming risks. If they don’t, start with a TRIZ round to surface sabotaging behaviors safely, then return to pre-mortem once the floor feels open.

The planning workshop can include a pre-mortem as the final step before the team commits to the next sprint — it’s the last chance to name the risks while changes to the plan are still cheap.

How to run it

Total time: 20–25 minutes. Stretches to 35 for a large team or a high-stakes plan.

Set the scene (2 min). State the plan concisely — what’s being committed to, over what horizon, for what outcome. Then frame the pre-mortem: “imagine it’s six months from now. This plan has failed. Not just missed its target — failed publicly and unambiguously. Everyone agrees it was a disaster. Your job for the next five minutes is to write down the reasons why.”

Silent generation (5 min). Each participant writes failure reasons on stickies, one per sticky, silently. Insist on the past tense — “because we didn’t…” or “because the vendor…”. The past tense is what triggers the prospective-hindsight effect. If people slip into present- or future-tense worry-language, redirect them.

Round-robin share (8–10 min). Each person reads their stickies aloud as they place them on the board. No debate, no ranking yet — just capture. The facilitator clusters visibly similar items as they land, but resists the urge to filter. Even duplicates matter — high frequency is itself a signal.

Cluster and rank (5 min). With everything on the board, group by theme. Then dot-vote: three dots per person, placed on the failure reasons they believe are most likely to actually cause the disaster. The top clusters become the action shortlist.

Assign mitigations (5 min). For the top three clusters, decide who owns a mitigation and what it looks like. Add the mitigation to the plan explicitly — as a sprint task, a monitoring alert, a check-in cadence or a go/no-go criterion. If the mitigation can’t land in the plan, the pre-mortem didn’t do its job.

Book the follow-up (1 min). Put a calendar note at the plan’s midpoint: “Check: are any of our pre-mortem risks showing up?” This is what converts the pre-mortem from a workshop artifact into a live risk register.

Worked example

A six-person product team is about to start a sprint whose goal is to migrate the user-authentication system from a legacy in-house service to a third-party identity provider (IdP). They run a pre-mortem at the end of sprint planning. Here’s what lands on the board after the silent-generation round:

The dot-vote surfaces two top clusters: Testing and External (the IdP’s limits). Rollback is third. Those are the mitigations the team commits to before the sprint starts:

• Testing. A dedicated story for SSO-fixture coverage, owned by QA, must land in week 1 of the sprint. Cutover is blocked until the fixture set passes.
• External. The team schedules a load test against the IdP’s sandbox at 2x expected launch volume, and gets written confirmation from the vendor of the production rate-limit ceiling. If the sandbox numbers don’t match the written ceiling, cutover is rescheduled.
• Rollback. Mid-week rollback rehearsal is added to the plan. The team practices the full cutover-and-revert sequence against staging before touching production. The rollback runbook is updated to reflect the actual time-to-revert measured in the rehearsal, not the aspirational one.

What didn’t make the mitigation list. Compliance, Rollout timing, Behavior and Scope each got one or two votes — they’re tracked as a watch-list but don’t get dedicated mitigation work this sprint. The team’s accepted failure-risk budget isn’t zero; it’s the long tail of low-vote items. Trying to mitigate all eight reasons would itself be a source of failure (scope overload), which is exactly the kind of thing a pre-mortem of a pre-mortem would catch.

Common failure modes

• Future-tense risk talk instead of past-tense failure talk. Stickies read “we might not have enough time” or “I’m worried about the vendor.” Symptom: the team is doing risk-brainstorming, not pre-mortem. Fix: the facilitator redirects — “rewrite that as ‘we failed because…’”. The tense matters. Prospective hindsight is the mechanism; without it, you’ve got a generic risk discussion.
• No mitigation lands in the plan. The team has a great pre-mortem conversation, everyone agrees the risks are real, nothing changes in the sprint plan. Symptom: the ritual happened but the plan didn’t update. Fix: the pre-mortem isn’t done until mitigations are added to the committed plan. If they can’t be, either the plan isn’t flexible enough or the risks aren’t real enough. Either way, something’s wrong.
• Mitigating everything. The team adds mitigations for all eight failure reasons, the sprint balloons 30 percent, it fails under the weight of its own mitigations. Fix: dot-vote ruthlessly. Mitigate the vital few; accept the risk on the long tail and put it on a watch-list.
• Running a pre-mortem on a plan nobody believes. If the team hasn’t actually committed to the plan, the pre-mortem becomes a litany of reasons the plan is bad, and the meeting drifts into plan-critique. Fix: commit first. The question isn’t “is this a good plan?” but “given that we’re doing this, what kills it?”
• Treating the pre-mortem as an alternative to testing. The team feels good because they named the risks, and skips the testing they’d have done anyway. Fix: naming risks isn’t mitigating them. The pre-mortem’s output is a mitigation list — the mitigations still have to happen.

References

In the playbook

• Planning workshop — the natural home for a pre-mortem, run at the end of planning before the team commits.
• 5 Whys — the retrospective counterpart; pre-mortem is to plans what 5 Whys is to outcomes.
• TRIZ — the psychological-safety primer; run TRIZ first when the team is too conflict-averse to name real risks in a pre-mortem.
• My formula for running a successful workshop — the meta-framework every workshop in the Guides section follows.

External references

• Gary Klein, “Performing a Project Premortem,” Harvard Business Review (September 2007) — online copy. The canonical four-page article that popularized the technique.
• Deborah J. Mitchell, J. Edward Russo & Nancy Pennington, “Back to the Future: Temporal Perspective in the Explanation of Events,” Journal of Behavioral Decision Making, Vol. 2, No. 1 (1989) — the underlying prospective-hindsight research that Klein built on.
• Gary Klein, Sources of Power: How People Make Decisions (MIT Press, 1998) — broader context for Klein’s naturalistic decision-making program, of which pre-mortem is one technique.
• Daniel Kahneman, Thinking, Fast and Slow (Farrar, Straus and Giroux, 2011) — cites pre-mortem as one of the few practical debiasing techniques with evidence behind it.
• Atlassian Team Playbook, Pre-mortem — a modern workshop-ready adaptation.