Post-mortems are honest and useless in equal measure: everyone learns exactly why the project failed, at the precise moment the lesson stops being applicable.
A pre-mortem flips the timing. Before the sprint (or launch, or migration) starts, you ask the team to imagine it already failed — then write down why. Psychologist Gary Klein, who popularized the technique, found it surfaces risks that polite planning sessions miss, because “the project failed” gives everyone permission to say the uncomfortable thing.
Here’s the template we use. It runs async in about 20 minutes of everyone’s time, no meeting required.
Setup (2 minutes, one person)
Create a ticket or whiteboard frame titled: “It’s [end date]. [Project] failed badly. What happened?” Everyone answers the six questions below in writing, before reading anyone else’s answers. Written-first matters — it stops the loudest voice from anchoring the room.
The six questions
1. What’s the failure story? One paragraph, past tense: “We shipped three weeks late because…” Force specificity. Vague doom (“it didn’t go well”) can’t be acted on; a story can.
2. What did we assume that turned out to be wrong? Every plan rests on assumptions nobody wrote down. The API stays stable. Design lands on time. The migration is reversible. Name them now, while naming them is free.
3. Where did we depend on one person? If the failure story starts with “when X got sick / left / got pulled onto the fire…”, you’ve found a bus-factor problem to fix before it fixes you.
4. What did we know at kickoff but never said? This is the money question. Someone on the team already suspects the timeline is fantasy or the scope is doubled. “The project failed” is cover to say it.
5. Which external thing broke? The third-party service, the other team’s deliverable, the approval you’re waiting on. You can’t control these, but you can decide today what happens when they slip: buffer, fallback, or scope cut.
6. What would have warned us earlier? For each failure story: what signal, in week one, would have told us we were headed here? That signal becomes a check — a thing you actually look at mid-sprint, not a vibe.
Triaging the answers (10 minutes, async)
Collect the failure stories and sort them into three buckets:
- Fix now — cheap to address today (write down the assumption, add the fallback, spread the knowledge). Do these immediately; they’re the whole point.
- Watch — real risks you can’t remove. For each, name the early-warning signal from question 6 and where it lives: a board column, a CI check, a weekly glance at a metric. A risk without a visible signal is just worry.
- Accept — write down that you accepted it, and why. Accepted risks don’t ambush you; they arrive as expected guests.
Keep it alive
A pre-mortem that lives in a doc is a post-mortem waiting to happen. Put the watch-list signals where the work is — on the board, next to the tasks they threaten. When the signal trips, the failure story is already written and waiting, and the response is a decision you made weeks ago with a clear head.
Twenty minutes, six questions, zero meetings. The cheapest risk management a small team can buy.
👉 Keep your risks next to the work — Kahoona is free to start
Related: Async retro template: five questions · Sprint review without a meeting