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

1. 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.
2. Generate failure stories independently first — list as many distinct ways it died as you can before discussing any. Quantity beats polish here.
3. Cover the categories: technical, people/team, scope/timeline, external/market, dependencies, assumptions that turned out false, and "the boring thing nobody owned."
4. For each failure, write the one-line obituary: "It failed because ___."
5. Score each on likelihood x impact. Focus on high-impact, plausible failures, not exotic ones.
6. For the top risks, name the earliest warning sign — what would you observe in week 2 or 4 that this is happening?
7. Convert each top risk into a mitigation or a tripwire: prevent it, or define the signal that triggers a course-correction.
8. 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.