prm-pre-mortem-analysis

name	prm - Pre-Mortem Analysis
description	Gary Klein's technique - assume it went wrong and ask why. People are better at explaining past events than predicting future ones.
output	{"format":"prose"}

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