Pre-Mortem

When to use

Project kickoff, before commitment. New initiative, migration, launch, anything where failure modes are still hypothetical and there's time to act on them. Run it after Remember the Future — paint the win first, then surface the threats. Skip it mid-project; failures aren't hypothetical at month four and a regular retro is the right tool. Skip it on a team in conflict; the fear column becomes a vehicle for the conflict and the project gets buried.

How it runs

1. Set anonymity before anyone writes

   Tell the team the failure-mode column is anonymous, and use tooling that hides authorship. This step is non-negotiable. Without it, the senior people's fears anchor the room and the juniors write thin agreement — the format collapses to a sanitised risk register.

2. Stage-set: 'imagine the project failed'

   Walk the team to the future date. 'It's six months from now. The project shipped late, missed scope, or didn't ship at all. Customers are unhappy. The CEO has questions. Why?' The framing matters — past tense, specific date, concrete failure. Vague framing produces vague failure modes.

3. Silent independent write, ten minutes

   Each person writes their own failure modes, alone. No discussion. Klein's original demands silent independent writing because group writing produces the safest possible list, not the real one. Specificity rule: 'we didn't ship' is a wish in reverse; 'we missed the November deadline because the API contract slipped in week three' is the artefact.

4. Cluster, then vote on the top three threats

   Group duplicate failure modes — duplicates are the strongest signal. Vote (anonymously, dot-vote style) on the top three threats most worth acting on. Voting prioritises; clustering reveals shared concern.

5. Assign owners and follow-up dates — this is the step nobody does

   For each top threat, name an owner and a date. 'Auth migration risk — Priya owns the API-contract review by end of week three.' Without owners and dates, the fears collected in the meeting evaporate before week one. This is the step that separates pre-mortem from theatre.

Why it works

Forward-looking risk planning produces optimistic lists; failure-imagination produces realistic ones. The cognitive shift — from 'what could go wrong?' to 'why did it fail?' — pulls past-tense specificity out of the team that future-tense speculation cannot. Anonymity is the format's signal-to-noise ratio: with it, juniors name the real risks the senior person doesn't see; without it, the list is the senior person's risks restated. The act-on-the-output step is the difference between a pre-mortem and a fear-collection exercise.

Variations

• Two-column variant: top threats in one column, top success factors in the other. Cleaner integration with Remember the Future.
• Async pre-mortem: silent write spread over 24 hours via a private form, facilitator clusters, live meeting only for the prioritisation and ownership step. Strongest format for distributed teams.
• Time-boxed mini version (30 mins): drop the voting; surface the top one or two failure modes only. Useful for smaller projects where the full hour is overkill.
• Pair with Remember the Future in a single workshop. Order matters: paint the win first, name the threats second.

Facilitator notes

Police anonymity ruthlessly. If the tool you're using accidentally shows authorship — Miro stickies with names, Slack threads, anything — the format is broken. Switch tools mid-meeting if you have to. Read the failure modes flat; don't editorialise. The senior person on the project should not lead the cluster step or the prioritisation step; their interpretation will set the room's reading. Their job is to listen.

Pitfalls

• Skipping anonymity. The senior person's fears anchor the room; juniors write polite versions of the same.
• Vague failure modes. 'We didn't ship' is a wish in reverse — useless. Push for the why, the when, the specific.
• Stopping at 'discuss findings.' The act-on-the-output step is what makes the exercise worth running.
• Running it mid-project. By then failures are real, not hypothetical, and a retro is the right format.

Remote tips

Use a tool with explicit anonymous mode (Miro hidden voting, Mural with anonymous stickies, FunRetro, Parabol). Open the silent-write phase 24 hours before the live session — failure modes written in 90 seconds are always thinner than failure modes written overnight. Don't use a Google Doc; even with auth turned off, names leak.

Example outputs

• Failure mode: 'We missed the November launch by six weeks because the auth migration depended on a platform-team release freeze nobody checked for. The dependency was discovered in week eleven, three weeks before launch.'
• Failure mode: 'We shipped on time but with the wrong scope. The team built feature X assuming the customer wanted real-time updates; they wanted accurate updates. Discovered in beta testing.'
• Failure mode: 'Two key engineers left in week eight. We had no second-on-call for the database layer. Recovery cost six weeks.'
• Owner-and-date output: 'Auth-migration dependency — Priya owns the platform-team alignment check, due Friday week one.'

FAQ

Pre-mortem or Remember the Future?

Run both. They're siblings — pre-mortem imagines failure, Remember the Future imagines success. Either alone is half the picture. Order matters: Remember the Future first to paint the win, pre-mortem second to surface the threats. Strongest pre-project facilitation pattern in the catalogue.

Pre-mortem or Hopes/Fears?

Same shape, different register. Hopes/Fears is the gentler-named cousin. Pick Hopes/Fears for cross-functional kickoffs where 'mortem' lands wrong (legal, compliance, exec stakeholders); pick Pre-mortem for engineering-led projects where the directness is welcome. Pre-mortem is more rigorous on anonymity and ownership; Hopes/Fears more flexible on the hopes side.

Do I really need anonymity?

Yes. Klein's original implies it; commercial pages soften it to 'encourage' silent writing. Without enforced anonymity, juniors write the safe failure modes and the real ones never appear. The senior person doesn't need to be in the room as an author for the format to work — they need to be in the room as a listener.

Related activities

Recommended use cases