Pre-mortem

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