Skip to content
Rabin Poudyal
Rabin Poudyal
← All models

Decision-making and strategy

Pre-mortem

Before you start, imagine the project has already failed and ask everyone to explain why.

Gary Klein, "Performing a Project Premortem", Harvard Business Review, September 2007. Klein built it on research into "prospective hindsight" by Deborah Mitchell, J. Edward Russo and Nancy Pennington (1989). Its finding was that treating an outcome as certain, rather than merely possible, changes the explanations people give for it.

A post-mortem explains a failure after the patient has died. A pre-mortem does it while there is still time to act. Once the plan is drafted, the team is told to imagine it is some months later and the project has failed badly. Each person writes down, alone, every reason they can think of. The leader collects the reasons round the table, and the plan is changed to deal with the worst of them.

Asking "what might go wrong?" invites hedged, polite answers. Saying "it went wrong; tell me why" makes the failure a fact to be explained, and people produce longer, more specific stories about facts than about possibilities. It also changes the social rules. Klein's point was that people on a team are often reluctant to speak up about a plan their leader likes; a pre-mortem makes doubt the assignment, so the person who sees the weak spot is helping rather than being disloyal.

The list is only worth what you do with it. A pre-mortem run after the decision is locked is theatre, and one run every week turns into a ritual where people write the same three risks. It also surfaces only the failures people can picture, so it is weak against the truly unexpected, and a vivid story can crowd out a dull but more likely one.

Example

In July 2004 the Federal Emergency Management Agency (FEMA) and Louisiana officials held a planning workshop built around a made-up catastrophic storm, "Hurricane Pam", striking 13 parishes in southeast Louisiana, New Orleans among them. Breakout groups took the disaster as given and worked through what would go wrong in search and rescue, sheltering, medical care, debris and pumping water out of areas enclosed by levees. Follow-up workshops ran in November 2004, July 2005 and August 2005. Then Hurricane Katrina struck at the end of August 2005. Testifying to the Senate in January 2006, FEMA's Wayne Fairley said the project "did not result in a catastrophic planning document per se, but rather a framework for developing such a plan." It was a scenario exercise rather than a pre-mortem in Klein's format, but it made the same move of treating the disaster as already done, and it shows the limit of the method: the failures had been named, and the fixes were still unfinished when the real storm came.

Where it applies

Run one before a launch, a migration or a hire, after the plan exists but before it is committed. For an AI feature, assume it caused a public embarrassment a month after release and list the prompts, users and data that did it; those become your first evaluation cases. Then assign each serious reason an owner and a date, or it was a meeting, not a pre-mortem.

Think about it

It is six months from now and your current project has failed: what is the most likely reason, and what are you doing about it this week?

Applied it to something real? Log it.

Test yourselfWhy does a pre-mortem say "the project failed" instead of asking "what could go wrong"?

Treating the failure as a fact makes people explain it with specific, concrete reasons, and it makes raising doubts the task rather than an act of disloyalty.

Related models

Sources and further reading