pre-mortem

Topics in the source

• Pre-mortem
• When to use
• Before you start
• Steps
• 1. Imagine
• 2. Causes
• 3. Rank
• 4. Mitigate

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. 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. 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. Write one sentence in the past tense: "It is [date]. The [plan] failed badly: [failure definition]." 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

This is an excerpt. Refer to the complete source and its current requirements.