Pre-Mortem
Prospective failure analysis that defeats optimism bias by assuming failure first, then working backward to surface risks, early warnings, and escape hatches.
Based on Gary Klein's pre-mortem technique: Instead of asking "will this work?" (which triggers optimism bias), this skill forces the question: "It's 6 months from now and this has completely failed. What went wrong?"
Key distinction from swing-review:
swing-reviewexamines the CURRENT state — "what's wrong NOW?"swing-mortemexamines the FUTURE — "what will go wrong LATER?"- Adversarial review finds existing flaws. Pre-mortem anticipates flaws that don't exist yet.
Rules (Absolute)
- Never produce generic risks. Every failure scenario must name specific technologies, quantities, timelines, or conditions. "The database might not scale" is banned. "PostgreSQL connection pool exhaustion at >2,000 concurrent users due to long-running analytical queries holding connections for 30s+" is acceptable.
- Exactly 5 scenarios across 5 categories. One Technical, one Organizational, one External, one Temporal, one Assumption. No category may be skipped, no category may have more than one scenario.
- Leading indicators must be observable and measurable. "Watch out for problems" is banned. Every indicator must specify what to measure, what threshold signals danger, and where to observe it.
- Circuit breakers must include a specific trigger condition. "If things go wrong" is banned. Every trigger must be a measurable condition with a concrete threshold.
- The swing-mortem summary is MANDATORY. It is the BLUF of the analysis. It must appear at the end and synthesize the highest risk, its leading indicator, and its escape hatch in one paragraph.
- Assume complete failure. Not partial, not "underperformance." The premise is total failure. This extreme framing is what forces creative risk identification — do not soften it.
- Specificity over coverage. One deeply analyzed, plausible failure scenario per category is worth more than five shallow ones. Depth beats breadth.
Process
Execute these 6 phases sequentially. Do NOT skip phases.
Phase 1: Set the Failure Frame
Establish the temporal and contextual frame before any analysis.
FAILURE FRAME
─────────────
Subject: [what is being analyzed — plan, decision, architecture, launch]
Timeframe: [when failure is discovered — default 6 months, adjust to context]
Failure statement: "It is [timeframe] from now. [Subject] has failed completely.
Not partially underperformed — completely failed. The team is conducting a
post-mortem. What went wrong?"If the subject is ambiguous or too broad, ask one clarifying question before proceeding. "Analyze our project" is too vague. "Analyze our migration from MongoDB to PostgreSQL for the user service" is actionable.
Before generating scenarios, gather context:
- If code/architecture exists, read relevant files to ground scenarios in reality
- If a project plan exists, examine timelines and dependencies
- If prior decisions are documented, review the rationale and constraints
Do not generate scenarios from imagination alone when concrete artifacts are available.
Phase 2: Failure Scenario Generation
Generate exactly 5 failure scenarios, one per category. Each scenario must be a specific, plausible narrative — not a generic risk label.
Category 1: Technical
The technology didn't work as expected. Name the specific technology, the specific failure mode, and the specific conditions under which it failed.
Category 2: Organizational
Team, process, or communication broke down. Name the specific team dynamics, handoff points, or process gaps that caused failure.
Category 3: External
Market shifted, competitor moved, regulation changed, or a dependency broke. Name the specific external force and its specific impact.
Category 4: Temporal
Timeline was wrong. Name what took longer (or what window was missed) and by how much, with the specific cascading consequence.
Category 5: Assumption
A core assumption turned out to be false. Name the specific assumption, why it seemed reasonable at the time, and what reality turned out to be.
Format each scenario as:
SCENARIO [N]: [Category] — [Title]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
What happened:
[2-4 sentence specific narrative of how this failure unfolded]
Why it was plausible:
[1-2 sentences on why this wasn't obvious beforehand]
Concrete consequence:
[Specific, measurable impact — revenue lost, users affected, time wasted, data compromised]Phase 3: Likelihood x Impact Matrix
Rate each scenario and determine priority:
RISK MATRIX
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
| # | Category | Scenario | Likelihood | Impact | Priority |
|---|----------------|----------------------|------------|--------------|----------|
| 1 | Technical | [title] | H / M / L | Cat/Sev/Mod | [rank] |
| 2 | Organizational | [title] | H / M / L | Cat/Sev/Mod | [rank] |
| 3 | External | [title] | H / M / L | Cat/Sev/Mod | [rank] |
| 4 | Temporal | [title] | H / M / L | Cat/Sev/Mod | [rank] |
| 5 | Assumption | [title] | H / M / L | Cat/Sev/Mod | [rank] |Likelihood: High (>50%), Medium (15-50%), Low (<15%) Impact: Catastrophic (project killed, irreversible damage), Severe (major rework, significant loss), Moderate (setback, recoverable with effort)
Priority scoring:
- High + Catastrophic = P1
- High + Severe OR Medium + Catastrophic = P2
- Medium + Severe OR High + Moderate = P3
- Everything else = P4
Select the top 3 by priority for detailed analysis in Phases 4-5. In case of tie, prefer higher Likelihood.
Phase 4: Leading Indicators
For each of the top 3 risks, identify 2-3 early warning signals. These are observable, measurable conditions that would indicate the failure mode is beginning to materialize — before it's too late.
LEADING INDICATORS — Scenario [N]: [Title]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Indicator 1: [Name]
Measure: [What specifically to track]
Threshold: [At what value does this become a warning]
Where to observe: [Dashboard, log, metric, report, or manual check]
Lead time: [How far in advance of failure this signal appears]
Indicator 2: [Name]
Measure: [What specifically to track]
Threshold: [At what value does this become a warning]
Where to observe: [Dashboard, log, metric, report, or manual check]
Lead time: [How far in advance of failure this signal appears]Every indicator must pass the "intern test": could a new team member, given this description alone, determine whether the threshold has been crossed? If not, make it more specific.
Phase 5: Circuit Breakers
For each of the top 3 risks, define the decision framework for when and how to change course.
CIRCUIT BREAKER — Scenario [N]: [Title]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Trigger:
[Specific measurable condition that activates this circuit breaker.
Must be a concrete threshold, not "if things go wrong."]
Fallback:
[The alternative path. What do you switch to? Be specific about
the replacement approach, not just "find another way."]
Cost of delay:
[What do you lose by waiting one more week/sprint/month for more
information before activating the fallback? Quantify if possible.]
Decision owner:
[Who has authority to pull this trigger? Role, not name.]Phase 6: Pre-Mortem Summary (BLUF)
Synthesize the entire analysis into one paragraph. This is the most important output — the reader should be able to read ONLY this paragraph and walk away with the critical insight.
Format:
PRE-MORTEM SUMMARY
━━━━━━━━━━━━━━━━━━
The highest risk to [subject] is [specific scenario from top priority].
You'll know it's happening when [