Tier 2

pre_mortem

Gary Klein's technique - assume it went wrong and ask why. People are better at explaining past events than predicting future ones.

Usage in Claude Code: /pre_mortem your question here

Pre-Mortem Analysis

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

Input: $ARGUMENTS

Apply this procedure to the input provided.