opelpleple Pre-Mortem
Assume it's six months from now and the project failed. The question isn't "could it fail?" — it's "it failed; now, why?" That framing unlocks risks people won't admit while they're still hopeful.
When to use
- Finalizing a plan, launch, migration, or roadmap before committing.
- High-stakes, hard-to-reverse decisions (hire, vendor lock-in, public launch).
- The team is confident and aligned — exactly when blind spots hide.
- Right before a go/no-go gate.
When NOT to use
- Early ideation where you're still generating, not committing.
- Trivial or easily reversible decisions (don't pre-mortem a font choice).
- The team is already demoralized — this can tip into doom; reframe toward mitigation fast.
- You have no plan yet — there's nothing concrete to fail.
The method
- Set the scene out loud: "It's [date, ~6 months out]. The project shipped but failed / never shipped. It's a clear, undeniable failure." Make it vivid and concrete.
- Generate failure stories independently first — list as many distinct ways it died as you can before discussing any. Quantity beats polish here.
- Cover the categories: technical, people/team, scope/timeline, external/market, dependencies, assumptions that turned out false, and "the boring thing nobody owned."
- For each failure, write the one-line obituary: "It failed because ___."
- Score each on likelihood x impact. Focus on high-impact, plausible failures, not exotic ones.
- For the top risks, name the earliest warning sign — what would you observe in week 2 or 4 that this is happening?
- Convert each top risk into a mitigation or a tripwire: prevent it, or define the signal that triggers a course-correction.
- Output: ranked risks, leading indicators, and concrete pre-commitments (what you'll do now, what you'll watch for).
What good looks like
- At least one risk surfaces that nobody had said aloud before.
- Risks are specific ("the third-party API rate limit kills our import at scale"), not generic ("scope creep").
- Each top risk has an early warning sign and an owner.
- The plan changes as a result — a mitigation added, scope trimmed, or a tripwire set.
Anti-patterns
- Vague risks ("communication issues") that can't be watched for or prevented.
- Listing only risks you already planned to handle (theater, not discovery).
- Stopping at the scary list with no mitigations or tripwires.
- Pre-mortem as veto — using it to kill a project rather than de-risk it.
- Only technical risks; the killers are often people, ownership, and false assumptions.
Example
Plan: "Launch the new billing system on the 1st." Pre-mortem (it's the 1st of next quarter; the launch failed):
- "It failed because customers were double-charged during the cutover." (High impact, medium likelihood.) Early sign: mismatched totals in the dry-run reconciliation. Tripwire: any reconciliation delta > $0 in staging blocks launch.
- "It failed because the old system's edge-case discounts weren't migrated and finance found out in week 3." Early sign: discount count differs between systems. Mitigation: diff discount records before cutover; assign an owner.
- "It failed because nobody owned customer comms and support drowned." Sign: no comms draft exists 1 week out. Mitigation: assign comms owner today. Result: launch gated on zero reconciliation delta, a discount diff added to the checklist, and a named comms owner.