Pre-Mortem Analysis
Input: $ARGUMENTS
Interpretations
Before executing, identify which interpretation matches the user’s input:
Interpretation 1 — Stress-test a plan before launch: The user has a specific plan or project about to begin and wants to assume it failed, then work backward to find the likely causes — classic pre-mortem to surface hidden risks. Interpretation 2 — Surface unspoken concerns in a group: The user is leading a team that seems overly optimistic or where people are hesitant to voice doubts — they want to use the pre-mortem format to give people permission to name risks. Interpretation 3 — Compare plans by failure profile: The user is choosing between multiple approaches and wants to run a pre-mortem on each to see which has the most dangerous or most likely failure modes — using failure analysis as a decision input.
If ambiguous, ask: “I can help with stress-testing a specific plan, surfacing unspoken team concerns, or comparing plans by their failure profiles — which fits?” If clear from context, proceed with the matching interpretation.
Overview
Invented by Gary Klein. Instead of asking “What might go wrong?” (prospective), assume “It went wrong” and ask “Why?” (retrospective). People are better at explaining past events than predicting future ones.
This cognitive reframe makes failure modes easier to identify.
Goal
Identify failure modes BEFORE they happen by assuming the project failed and searching for causes. Inversion makes failure identification easier than direct risk assessment.
Steps
Step 1: Describe the Plan
Summarize the plan/project being analyzed. Include: Goal, approach, timeline, key assumptions.
Output: Plan summary
Step 2: Assume Total Failure
Project forward to end of timeframe. Assume the project has COMPLETELY FAILED. Make it vivid: “It’s [date]. The project has failed spectacularly.”
Output: Failure scenario
Step 3: Brainstorm Failure Causes
Working backward from the failure, list all plausible causes. Use prompts to ensure coverage of different failure types.
Each person/perspective should generate causes independently before sharing (reduces groupthink).
Output: List of failure causes
Step 4: Assess Likelihood and Impact
For each cause, estimate:
- Likelihood (High/Medium/Low)
- Impact if it happens (High/Medium/Low)
Focus attention on High-High and High-Medium items.
Output: Prioritized failure causes
Step 5: Identify Warning Signs
For each high-priority cause, ask: “What early signs would indicate this is happening?”
Good warning signs are:
- Observable before the failure
- Specific enough to detect
- Early enough to respond
Output: Warning signs for each cause
Step 6: Develop Mitigations
For each high-priority cause, develop:
- Prevention: How to stop it from happening
- Contingency: What to do if it happens anyway
Be specific about actions, owners, timing.
Output: Mitigation plans
Step 7: Update the Plan
Incorporate mitigations into the original plan. Add monitoring for warning signs. Document contingencies.
Output: Updated plan with pre-mortem insights
When to Use
- Before launching project/initiative
- Before major decision
- When planning has been optimistic
- To stress-test a plan
- To surface concerns people are hesitant to voice
Verification
- Failure was assumed vividly and specifically
- Multiple failure categories were explored
- Causes were assessed for likelihood and impact
- Warning signs are observable and early
- Mitigations are specific and actionable
- Plan was updated with insights