One-sentence positioning: Compared with a post-mortem, a pre-mortem pretends in advance that it failed — using the psychological frame of "this has already failed,"to release doubts suppressed by silence within the team. Klein's research shows it can identify risks that would otherwise be missed by 30%.
When to Use (TRIGGER)
- About to launch a new project / about to make an irreversible decision (funding, hiring a senior person, product launch)
- The team has entered a high-morale period of "this is definitely going to succeed" (the most dangerous moment)
- The plan has already been approved in front of leadership, but you have a knot in your gut
- On the eve of an important milestone (not too early; it should be when "the plan has taken shape but you haven't gone all in yet")
When Not to Use (ANTI-PATTERN)
- The decision is low-stakes and easily reversible (just try it directly; don't go through a process)
- The decision has already been made and is irreversible (at this point it is time to prepare a post-mortem rather than a pre-mortem)
- Team trust is low (in a low-trust team, a pre-mortem turns into an opportunity to attack each other)
- The time window is extremely tight (< 1 hour); switch to the OODA Loop for a quick risk check
Steps (STEPS)
1. Set the time-machine scenario (5 minutes)
Gather the team; the fixed opening line is:
"Assume it is now 12 months later. The X project we launched has completely failed — not partially failed, but failed catastrophically. Each person spends 3 minutes writing on paper: what are the specific reasons for the failure?"
Key framing:
- Past-tense narration: use "failed" rather than "might fail"
- Write independently: do not discuss first; avoid groupthink
- The failure must be specific: not "poor execution," but "Q2 churn rate was 35%, mainly because users could not understand step 3 of onboarding"
2. Read aloud in turn + categorize (15 minutes)
- Each person takes turns reading aloud their own reasons for failure,interruptions and debate are not allowed
- The facilitator categorizes on the whiteboard:external factors / team execution / the product itself / market assumptions / resources
3. Evaluate each reason (20 minutes)
Evaluate each reason for failure:
- Likelihood (1-5)
- Impact (1-5)
- Mitigability (Y/N) — can we do something right now to reduce the risk?
4. Convert into action items (15 minutes)
For reasons that are "high likelihood × high impact × mitigable," define specific:
- Preventive measures: what to do now to reduce the probability of occurrence
- Early signals (tripwire): what indicators show that this risk is materializing
- Response plan: what to do when it happens, who is responsible
5. Write it into the decision record
Do not let the output of the pre-mortem disappear. Write the identified top 5 risks + response plans into the project README or ADR, and review them regularly.
Decision Checklist
- Used an opening in the past tense ("failed") rather than the future tense ("might fail")
- Each personIndependentStart the discussion only after writing (to avoid anchoring)
- Each failure reason is specific down to "metric + reason"
- The Top 5 risks have clear tripwire metrics
- Someone is responsible for outputting it into the project archive (it doesn't disappear when the meeting ends)
Real cases
Case 1: Application in a NASA project
NASA did not do pre-mortems early on. After the Challenger space shuttle disaster, it systematically introduced the "devil's advocate system" (essentially a variant of pre-mortem). Before subsequent missions, it forced one engineerto be specifically responsible for playing the role of "this time it will fail", listing all failure paths, and the team had to respond to each one.
Case 2: Klein's own research data
Klein compared pre-mortem groups vs no-pre-mortem groups across multiple corporate R&D projects:
- Number of risks identified within 30 days after project launch: the pre-mortem group had more 30%
- Among these additionally identified risks, about 60% were blind spots completely unthought of before the pre-mortem
- Team members' "overconfidence bias" toward the project dropped significantly, butmorale did not decrease(because it is a psychological frame of "finding problems to ensure success")
Case 3: An engineering team launching a new payment system
Top risks output by a certain team's pre-mortem:
- "Reason for failure 12 months later: we assumed the reconciliation file format with the bank API was fixed, but the bank changed systems and changed the format, and we did not notice for 3 weeks"
- → Prevention: daily reconciliation + format hash monitoring
- → tripwire: alert immediately if reconciliation failure rate > 0.1%
- Four months after launch, the bank indeed changed the format — the tripwire triggered, it was discovered within 2 hours, avoiding millions of abnormal transactions
Relationship with other frameworks
- The P step of WRAP is essentially pre-mortem
- Inversion is a broader version of pre-mortem — pre-mortem is "assume failure", while inversion is "think in reverse about any problem"
- post-mortem is after the fact, pre-mortem is before the fact; both require a blame-free culture
- Pair with second-order-thinking to assess the chain consequences of each risk
Common pitfalls
- Becoming formalism: holding a 1-hour meeting, filling out a form, then archiving and forgetting it — response: risks must be turned into tripwires + owners
- Politicization: using pre-mortem to attack someone else's project — response: it must be hosted by the project owner themselves
- Doing it too early: doing a pre-mortem before the project has taken shape results in all invalid abstract worries — response: do it after "the plan is already specific enough to draw the critical path"
- Doing it too late: doing it after contracts are signed/people are hired — response: do it before the point of no return
References
- Gary Klein, "Performing a Project Premortem", Harvard Business Review, Sep 2007
- Daniel Kahneman, 《Thinking, Fast and Slow》(2011) cites and endorses it
- Gary Klein, 《The Power of Intuition》(2003)