pre-mortem git:20260615.6d899e8A

Immutable. This exact content is served forever at /api/v1/blob/c1b99c7fef55c003.

---
name: pre-mortem
description: "Prospective hindsight — imagine the project already failed, then diagnose why. Surfaces hidden risks before commitment."
group: thinking
keywords: [pre-mortem, risk, failure, retrospective, prospective, planning, stress-test]
task_strategies: [spike, investigation]
stream_affinity: [roadmap, research]
allowed-tools:
  - Read
  - Glob
  - Grep
  - AskUserQuestion
status: experimental
source: "Gary Klein — Sources of Power (1999); Klein et al. — Performing a Project Premortem (HBR 2007)"
acquired: "2026-06-15"
---
# Pre-Mortem

**Imagine the project already failed. Now find out why.**

Gary Klein's prospective hindsight technique — forces the brain into a different mode than optimistic planning. Retrospective analysis of a hypothetical failure produces 2× more failure causes than prospective analysis.

---

## When to use

- Before committing to a plan, architecture, or major decision
- When the team is too confident or too aligned (groupthink risk)
- Before a launch, migration, or irreversible change
- When someone asks "what could go wrong?"

---

## Step 1 — Set the scene

State the project, plan, or decision clearly. Then say:

> "It is [6 months / 1 year] from now. We went ahead with this plan. It failed completely. What happened?"

If the subject is unclear, ask:
```
AskUserQuestion: "What plan or decision are we stress-testing?"
```

---

## Step 2 — Generate failure causes

Spend 5–10 minutes generating every plausible failure cause without filtering. Use these lenses:

| Lens | Prompt |
|------|--------|
| **Technical** | What broke, crashed, couldn't scale, or had a hidden bug? |
| **Human/team** | Who burned out, left, got blocked, or misunderstood? |
| **Assumptions** | Which assumption turned out to be completely wrong? |
| **Dependencies** | What external system, vendor, or partner let us down? |
| **Market/context** | What changed in the world that made this irrelevant? |
| **Execution** | What did we fail to actually do? Where did we slip? |
| **Second-order** | What succeeded but caused something else to fail? |

Output: a raw list, no evaluation yet.

---

## Step 3 — Rank by impact × probability

Score each cause:
- **Impact** (1–3): How bad is this failure if it happens?
- **Probability** (1–3): How likely is it given our current plan?

Sort descending by `impact × probability`. Top 5 are the critical risks.

---

## Step 4 — Write the obituary (optional, high-stakes decisions)

Write a one-paragraph "obituary" for the project as if a journalist wrote it. Forces narrative coherence — reveals the single storyline that connects the top failure causes.

---

## Step 5 — Design preventions

For each top-ranked cause:
1. What early warning signal would appear before this failure materializes?
2. What specific change to the plan would prevent or reduce it?
3. Who owns the monitoring?

Output format:
```
Risk: [cause]
Signal: [early warning]
Prevention: [plan change]
Owner: [role/person]
```

---

## Step 6 — Decision

After working through the top risks:

```
**Pre-Mortem verdict for [project/decision]**
Critical risks: [top 2-3]
Plan changes recommended: [list]
Go/No-go: [proceed / modify / stop]
```

---

## Notes

- Separate generation from evaluation — don't judge causes during Step 2
- Silent individual generation first, then share, reduces anchoring bias
- Even if no plan changes result, the exercise calibrates the team's risk model
- Pair with `/brana:inversion` for maximum coverage (inversion finds what to avoid; pre-mortem finds what will go wrong)