| name | premortem-plan-check |
| description | Before finalizing any plan, run a premortem — assume the plan has already failed, list the likeliest causes, and reshape the plan with mitigations before presenting it. Use this whenever producing something that will be executed later: project plans, rollouts, proposals, timelines, migration or launch schedules, research plans, event logistics, hiring or content plans, implementation plans for code changes. Trigger even when the user just says "draft a plan", "give me a timeline", "how should we roll this out", or "propose an approach" without ever mentioning risk. |
Premortem plan check
Plans drafted forward-only tend to describe the happy path, because generating steps and generating failure modes are different mental moves. Imagining the outcome as already having happened makes failure reasons easier to produce: in one study, "it failed — why?" yielded about 30% more identified reasons than "what might go wrong?" (Mitchell, Russo & Pennington 1989; single-study basis). Klein's premortem turns this into a working technique. Run that pass before the plan leaves your hands, so mitigations shape the plan instead of arriving as appended caveats.
Process
- Draft the plan as you normally would — goals, steps, sequencing, owners, dates as applicable.
- Before finalizing, switch frames: assume the plan was executed and failed outright. List the most plausible causes, as specific mechanisms ("the vendor slips delivery by two weeks"), not categories ("external risk").
- Rank the causes by likelihood and damage; keep the top two or three.
- Reshape the plan around them: add mitigations, pull risky or uncertain items earlier so failures surface while there is still time to react, and add checkpoints or fallbacks where a failure would otherwise be caught late.
- Present the reshaped plan, naming its likeliest failure modes and their mitigations inside the plan itself — a short risks section or inline notes — because a reader who executes the plan needs to know what to watch for.
What this looks like
- Product launch timeline: legal review is the likeliest slip, so it moves from week 6 to week 1 and the announcement date gets an explicit go/no-go gate.
- Research report plan: the key dataset may prove unusable, so access and quality get verified on day one, with a named fallback source before writing begins.
- Code migration: rollback is the step most likely to be untested, so the plan schedules a rollback drill before any production traffic moves.
Output rules
- Never narrate your own diligence ("I carefully considered the failure modes...", "as instructed, I..."). The premortem shows in the work product — the risks named, the sequencing chosen — not in self-description.
- Keep length proportionate to the task: a three-step plan warrants a sentence on its main risk, not a risk register.
- The failure-mode pass happens while you build the plan; only its results appear in the output — a plan whose shape reflects them, plus the top risks and mitigations where they matter.
Grounding: Klein 2007, "Performing a Project Premortem" (HBR); Mitchell, Russo & Pennington 1989 (prospective hindsight increases reasons identified; single study).
