5-15 minute pre-mortem before committing to any project plan — assume failure occurred and list 3-5 specific causes to surface invisible risks

Why This Is a Rule

Gary Klein's pre-mortem technique exploits a psychological asymmetry: people are much better at explaining past failures than predicting future ones. When you ask "What could go wrong?" the brain produces generic, abstract risks ("something might delay us"). When you say "The project has failed — why?" the brain produces specific, concrete failure causes ("the API integration took three times longer because their documentation was wrong"). The temporal reframe — from prospective to retrospective — unlocks a different mode of causal reasoning.

Research by Mitchell, Russo, and Pennington showed that prospective hindsight (imagining the outcome has already occurred) increases the number of identified risks by 30% compared to standard forward-looking risk analysis. The mechanism is that the retrospective frame eliminates the optimism bias that contaminates forward-looking analysis: when the failure has "already happened," there's no motivation to downplay risks.

The 5-15 minute constraint serves two purposes: it prevents the pre-mortem from becoming an anxiety exercise (unlimited time produces unlimited worries), and it forces focus on the most likely failure causes rather than exotic scenarios. The 3-5 specific causes constraint ensures concrete, actionable risks rather than vague concerns. Each cause should be specific enough to suggest a preventive action.

When This Fires

• Before committing to a project timeline, budget, or scope
• Before making irreversible resource allocation decisions
• When a plan feels "solid" but you want to stress-test it
• Complements Start project estimates with reference class forecasting from 3-5 comparable past projects — base rates beat inside-view planning (reference class forecasting) with the risk-identification dimension of estimation

Common Failure Mode

Perfunctory pre-mortem: listing obvious risks ("might run out of time," "scope might creep") that don't surface genuinely new information. The pre-mortem should produce at least one failure cause that surprises you — something you hadn't considered in forward planning. If nothing surprises you, you're not doing it honestly.

The Protocol

(1) Set a timer for 5-15 minutes (scale with project significance). (2) State the premise: "It is [future date]. This project has failed. What happened?" (3) Write 3-5 specific failure causes. Each should be concrete: not "timeline issues" but "the data migration took 3 weeks instead of 1 because we discovered legacy format incompatibilities." (4) For each cause, ask: "Is this preventable? What would we need to do now to prevent or mitigate it?" (5) Incorporate the most likely preventive actions into the project plan. Adjust the timeline and resource allocation based on the risks the pre-mortem surfaced. If the adjusted plan is unacceptable, that's critical information — better to know before committing than after.