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