thinking-pre-mortem

1# Pre-Mortem Analysis
2 
3**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.
4 
5## When to Use
6 
7- Before kickoff, major technical commitment, high-risk sprint work, launch, or release.
8- After a plan looks solid but before execution, especially when optimism or overconfidence is likely.
9- When a decision is costly to reverse and risks are still implicit rather than enforced.
10 
11## When NOT to Use
12 
13- Work is small, local, and cheaply reversible — skip the ceremony.
14- You are mid-incident under time pressure — act now (OODA / scientific method); pre-mortem is pre-execution.
15- You would only emit generic risks ("scope creep", "requirements unclear") that do not bind to this plan.
16- Risks are already enforced by live gates (CI, canary, rollback, alerts) with no residual unlisted path.
17- A mature risk register already covers the same specific failure paths with owners and checks.
18 
19## Procedure
20 
211. **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.
22…