Pre-Mortem Analysis
Core rule: Prospective hindsight beats "what could go wrong?" Assume the plan has already failed (past tense), generate concrete failure paths, reverse them into prevention requirements, and bind each top path to a verifiable plan change.
When to Use
- Before kickoff, major technical commitment, high-risk sprint work, launch, or release.
- After a plan looks solid but before execution, especially when optimism or overconfidence is likely.
- When a decision is costly to reverse and risks are still implicit rather than enforced.
When NOT to Use
- Work is small, local, and cheaply reversible — skip the ceremony.
- You are mid-incident under time pressure — act now (OODA / scientific method); pre-mortem is pre-execution.
- You would only emit generic risks ("scope creep", "requirements unclear") that do not bind to this plan.
- Risks are already enforced by live gates (CI, canary, rollback, alerts) with no residual unlisted path.
- A mature risk register already covers the same specific failure paths with owners and checks.
Procedure
- Set the failure frame in past tense: "It is [post-deadline date]. The plan failed: [rollback / data loss / no adoption / SLA breach]." Explaining a happened failure is required; predicting one is not enough.
- Generate failure reasons before filtering: sweep technical, process, assumptions, dependencies/external, and people. Force a second pass: "What did the plan most need to be true that was not?" Collect breadth first (aim for many distinct reasons); do not rank mid-sweep.
- Prioritize: group by theme; score likelihood × impact; keep the top 3–5 concrete risks (drop generics that do not bind).
- Failure-first reverse analysis (absorbed reverse path): for each top risk, (a) restate the failed outcome in past tense, (b) list necessary/enabling conditions that had to be true for that failure, (c) invert each condition into a verifiable prevention requirement (avoid/require rule + check), (d) bind owner, verification checkpoint, and ship/stage gate.
- Mitigate and update the plan: for each top risk, attach mitigation steps, spike/contingency if needed, and the reverse-analysis prevention requirements as explicit plan gates. A pre-mortem with no plan change is incomplete.
- Stop when top risks each have a bound mitigation or prevention gate, or when further reasons are only generic restatements — then ship the updated plan, do not keep brainstorming.
Output
- Failure scenario — past-tense disaster frame with date and failed outcome.
- Failure reasons — unfiltered list, then prioritized top 3–5 with likelihood × impact.
- Reverse paths — for each top risk: necessary conditions → inverted prevention requirements.
- Mitigations — owner, verification checkpoint, ship/stage gate per top risk.
- Plan deltas — concrete tasks, spikes, contingencies, and gates added to the plan.
Verification
- Falsify/stop: if no plan-specific failure path can be stated in past tense with necessary conditions, stop — you are generating theater, not risk. If a "mitigation" has no verification checkpoint, it is not done.
- Over-application guard: do not pre-mortem reversible chores, mid-incident firefighting, or systems that already enforce the same paths. Do not leave abstract risks as "mitigate later"; either invert them into gates or drop them as non-actionable.
