pre-mortem

Use for a pre-mortem, or before committing to a plan, launch or migration: "what could go wrong?", "stress test this plan", "how might this fail?", "risks before we ship". Assumes failure, lists causes, ranks them and sets mitigations. Skip for explaining a failure that already happened.

Gary Klein's technique: imagine the plan has already failed, then work backward to explain why. Assuming failure makes it safe to name risks that optimism hides.

When to use

• Before a launch, migration, reorg, contract, hire, architecture change or any hard-to-reverse commitment.
• "What could go wrong?", "stress test this", "play out the failure".
• A plan everyone likes and nobody has attacked.

Skip: explaining a failure that already happened, or reviewing the logic of an argument rather than a plan.

Before you start

1. State in one block: Plan (what, who, by when), Failure definition (what "failed badly" means, observable), Horizon, and Pass (Imagine, Causes, Rank, Mitigate, Decide).
2. Gather first. Read the plan, timeline, dependencies, past incidents and similar launches before generating causes. Ask up to 3 questions only for what tools cannot answer.
3. Light path. Small ask: 6 causes, top 3 ranked, one mitigation each.

Steps

1. Imagine

Write one sentence in the past tense: "It is [date]. The [plan] failed badly: [failure definition]."

2. Causes

List reasons it failed. Cover different angles so they do not cluster: people and skills, process and timeline, technology and dependencies, customers and market, money, external events. Add one inversion prompt: "What would guarantee failure?" and list what you would then have to avoid. Each cause is a specific story ("the vendor API changes its rate limit during launch week"), not a category ("vendor risk").

3. Rank

For each cause give a plain-language likelihood, impact if it happens, and an early warning sign. Keep the top 5-8.

Cause	Likelihood	Impact	Early warning

4. Mitigate

For each top cause choose one:

• Prevent: change the plan so it cannot happen.
• Detect: a metric or check that shows it early.
• Respond: a rehearsed fallback.

Add an owner (or "to be assigned").

5. Decide

• Plan changes to make now.
• Tripwires: conditions under which the plan is paused, changed or stopped.
• Go / no-go statement: go as is, go with changes, or hold until named risks are reduced.

Pitfalls

• Generic risks ("scope creep") with no story. Write what it looks like when it happens.
• Everything high likelihood and high impact. Force a ranking; a list where all items matter does not guide action.
• Mitigations nobody owns. Name an owner or mark it unassigned.
• Using it on something already failed. That is a postmortem; use a root-cause method.
• Treating the output as a promise that nothing else will go wrong. Revisit at each tripwire.

Worked example: references/example.md.

Checklist

• Plan, failure definition and horizon stated
• Failure written in the past tense
• Causes are specific stories across several angles, plus an inversion prompt
• Ranked with likelihood, impact and an early warning sign
• Mitigations are prevent, detect or respond, with owners
• Tripwires and a go / no-go statement