Pre-Mortem vs Post-Mortem: Same Question, Asked at the Two Useful Moments
A pre-mortem runs before a project starts: the team assumes it has already failed and lists the reasons, so the plan can change. A post-mortem runs after the project ends or fails and asks what went wrong, so the next project can change. Same question, asked at the two points where the answer is still useful.
Pre-mortem vs post-mortem at a glance
| Pre-mortem | Post-mortem | |
|---|---|---|
| When it runs | Once the plan is set, before the work or money is committed | After the project ships, ends or fails |
| Starting point | The failure is imagined | The failure (or the result) is real |
| The question | It failed. Why? | It failed, or it ended. What happened and why? |
| Evidence | Experience and imagination; no outcome data yet | Timelines, numbers, logs, what people saw |
| Who it helps | This project | The next project |
| What goes wrong with it | The causes are guesses, and the room guesses alike | Hindsight makes everything look obvious, and blame shuts people up |
| What comes out | Changes to the plan, owners, early warning signals | Lessons, process changes, follow-up actions with owners |
Where the two words come from
Post-mortem is Latin for “after death.” In medicine it is the examination that finds the cause of death. Engineering and project teams borrowed the word for the review that follows an outage, a failed launch or the end of a project. Software operations teams pushed the blameless version: John Allspaw wrote about it for Etsy’s engineering team in 2012, and Google’s Site Reliability Engineering book gives it a chapter, “Postmortem Culture: Learning from Failure.”
Pre-mortem comes from Gary Klein, who described it in “Performing a Project Premortem,” Harvard Business Review, September 2007, as “the hypothetical opposite of a postmortem.” The team is told the project has already failed and each person writes down why. Klein grounded it in 1989 research on prospective hindsight: imagining that an outcome has already happened makes people better at naming its causes. The business premortem guide covers the method in full. In medicine and forensics, premortem simply means before death, the same sense as antemortem.
When to run a pre-mortem
Run one before any decision that is expensive to undo:
- a hire, especially the first one in a new role
- a price change or a move to retainers
- a new offer, a launch, or a new market
- a client big enough to carry the quarter
- a migration to a new system, platform or supplier
Run it once the plan is concrete enough to fail in a specific way. “Grow next year” cannot fail in a specific way. “Move every retainer client to the new pricing in January” can. The pre-mortem template gives you the page to fill in.
When to run a post-mortem
Run one after:
- an outage, a missed delivery, or a refund wave
- a lost client, especially one you thought was safe
- a launch or quarter that missed its number
- a result that beat the plan for reasons nobody can name
Run it soon enough that people still remember, with the data in front of you, and keep it blameless. The goal is the cause, not the culprit. A post-mortem that ends with a name instead of a change has taught people to hide the next problem.
How the two work together
The pre-mortem and the post-mortem are most useful as one loop.
- Before the decision, run the pre-mortem. Keep the list of causes and give each unfixed cause a tripwire: the early signal that says it is starting.
- During the project, watch the tripwires. A tripwire that fires is a reason to act early, or to run a fresh pre-mortem on the new situation.
- After the project, run the post-mortem with the pre-mortem list on the table. Sort what actually went wrong into two piles: causes you predicted, and causes nobody predicted.
- Feed the second pile forward. Predicted causes that still happened mean the fix did not hold. Unpredicted causes are your team’s blind spot. Add them to the question list for the next pre-mortem.
Over a few projects, that comparison tells you how well your team predicts its own failures, which is worth more than any single list.
Questions for each
Pre-mortem
- It is six months from now and this failed. What happened?
- What did we assume that turned out to be false?
- What was the first sign, and who would have seen it?
- Who in the room had doubts and did not say them?
Post-mortem
- What did we expect to happen, and what actually happened?
- Where did the gap first show up, and when did we notice?
- Was this cause on the pre-mortem list? If it was, why did the fix not hold?
- What changes now, who owns it, and by when?
The cause neither one catches
Both exercises run inside the team’s own frame. A pre-mortem can only list the causes someone in the room can imagine. A post-mortem explains the failure that happened, not the one that is building underneath the next plan. Causes that live in the business itself, such as revenue that depends on a few clients or an owner the business cannot run without, are older than any single project and easy for the people inside it to miss.
That is the gap a premortem analysis of the business is built for: twelve adversarial perspectives that do not share your frame, run against the business and not only the plan. For a free first look at one structural cause, the Revenue Fragility Index shows how much of your revenue has to be won again every year.