# Pre-Mortem A pre-mortem assumes the project has already failed and asks the team to explain why, while the plan can still change. **The question.** If this plan has already failed, why did it fail, and what would we change in it now? Also known as: Also written premortem. Klein's application of prospective hindsight to a plan that has not yet run. ## When to use it - A plan has just been approved and the kickoff is about to turn into cheerleading, with known doubts left unsaid. - A risk register exists and lists only generic items, such as "resource constraints," that would fit any project. - The decision is expensive to reverse, such as a cutover, a launch, or a bid, and the team still has weeks to change the plan. - You need dissent from people who will not contradict the sponsor in an ordinary review. ## When to avoid it - There is no plan yet. Imagining failure of an undefined effort produces a list of fears, not changes. Write the plan first. - The decision is small and reversible. A ten-minute conversation about what could go wrong is enough. - The group cannot speak candidly, even under the cover of a hypothetical failure. The exercise will reproduce the silence it was meant to break, and you need a different channel. - You need scenarios for how the outside world could develop. Pre-mortem asks why our plan failed. Scenario planning asks what worlds we might have to operate in. ## Overview A pre-mortem asks a team to treat a plan as if it has already failed, and to explain why, while there is still time to change the plan. The past tense is what makes doubts speakable. People write alone, then read reasons around the room, and the output that matters is a change to dates, scope, owners, or gates, not a longer risk register. It is not a forecast and not a substitute for a plan. Prospective hindsight helps people name more causes. It does not tell you which ones will happen. Rank the reasons by damage and plausibility, keep the rare vivid ones as watch-outs, and run the exercise early enough that the plan can still move. ## The working steps ### Assume failure After a briefing on the actual plan, the facilitator states that it is twelve months later, or whatever horizon fits, and the project has failed. The past tense is the point. "What might go wrong" invites politeness. "What did go wrong" asks for a cause. ### List reasons Each person writes privately for a few minutes, including the reasons they would not offer in a normal review. Then, going around the room, each reads one unused reason. The project manager goes first. Keep going until the new reasons run out. ### Rank Cluster duplicates, then rate the remaining reasons by how much damage they would do and how plausible they are given what the team knows. The ranking is a choice about attention, not a forecast. ### Change the plan For the top reasons, add a preventive change, an owner, and a trigger that would show the failure is starting. If nothing in the plan changes, the session was a conversation. ## What it is not - A risk workshop with the same register and the same people speaking in the same order. If the format still rewards agreeing with the plan, it is not a pre-mortem. - A prediction that the project will fail. The method borrows the feeling of a postmortem to improve a live plan. It does not assign a probability. ## The steps 1. **Brief the real plan.** Give everyone the same account of scope, dates, owners, and constraints. A pre-mortem on a plan people have not seen produces generic fears. What comes out is a shared starting document, even if it is only a few pages. 2. **Set the failure and the horizon.** State that the project has already failed, at a date far enough out that the failure would be visible. Keep the statement short. Do not list causes. The room has to invent them. 3. **Write, then go around.** Silent writing first, a few minutes. Then each person, starting with the project manager, reads one reason that has not been said. Capture them in the person's words. Stop when a full round adds nothing new. 4. **Cluster and rank.** Merge duplicates. Score the rest for damage and plausibility, quickly, with the people who know the work. Mark the few that would kill the project on their own. 5. **Put changes into the plan.** For each top reason, add a preventive action, an owner, and a trigger. Drop or delay parts of the plan that the reasons have made indefensible. Take the revised plan back to the sponsor, not only the list of fears. ## In practice A manufacturer had board approval for a $14 million ERP cutover in nine months. The risk register listed data quality, training, and vendor performance, each rated medium. The consultant ran a 45-minute pre-mortem with the core team, including two people from plant 3 who had been silent in the kickoff. Written independently, then read aloud, the leading reasons were specific. Master data was still 18 percent incomplete, and the incompleteness was concentrated in plant 3's spare-part records. Plant 3 would not freeze its SKU list because a seasonal promotion was still being designed. Cutover was planned for the same weekend as month-end close. None of those three had been on the register. The plan changed. Cutover moved eight weeks, past close. Plant 3 froze a SKU list of 1,140 items, with a named owner for the remaining 18 percent of records and a weekly completeness count reported to the sponsor. The promotion was designed against that frozen list. Two of the silent concerns, the data gap and the close-weekend collision, would have shown up first as a failed go-live. ## What you leave with - A list of failure reasons in the team's words, clustered, with the duplicates marked. - A short ranking of the reasons that would kill the project. - Specific changes to dates, scope, owners, or gates, each tied to a reason. - Triggers that would show a top reason is starting to come true. ## Failure points ### What might go wrong The facilitator softens the prompt to keep the room comfortable. People offer the same generic risks that are already in the register, and the past-tense advantage is lost. ### The sponsor speaks first Once the most senior person has named a cause, the rest of the room confirms it. Independent writing, and the project manager going first among the readers, are what prevent that. ### A list with no change to the plan The reasons are recorded, thanked, and filed. The dates, scope, and owners stay as they were, so the session becomes another round of documented anxiety. ### Ranking by eloquence The most vivid story wins, even if it is rare. Score damage and plausibility separately, and keep the vivid rare item as a watch-out rather than the main redesign. ### Running it too late The contract is signed, the cutover weekend is booked, and the only remaining moves are cosmetic. A pre-mortem needs enough time left that a date or a scope line can still move. The failures above are usually [Framing](https://usefulconsultingframeworks.com/your-edge/#framing): the wrong problem was chosen before this framework was applied. ## Origin Gary Klein, a psychologist known for research on how experts make decisions under pressure, published "Performing a Project Premortem" in Harvard Business Review in September 2007. The article is short, four pages, and is the usual citation in consulting work. Klein built the exercise on prospective hindsight, a finding from Deborah J. Mitchell, J. Edward Russo, and Nancy Pennington (1989) that imagining an event has already occurred helps people name more of the reasons that could produce it. Klein's point was practical. People who have doubts about a plan often stay quiet in a kickoff, and a postmortem comes too late to help the project. In the method, the leader tells the team that the project has failed spectacularly, people write reasons independently, then each person reads a reason the group has not yet heard, starting with the project manager. After the session, the manager looks for ways to strengthen the plan. The exercise is public and carries no trademark. Klein's firm has taught it, and many later writers have added scoring and templates. This note follows the 2007 article and the obvious working steps around it. ## Further reading - [Performing a Project Premortem](https://hbr.org/2007/09/performing-a-project-premortem). Gary Klein, Harvard Business Review, September 2007. The original four-page article, including the prospective-hindsight citation and two short cases. Paywalled after a preview. - [Analyzing Failure Beforehand](https://www.nytimes.com/2007/09/22/business/media/22offline.html). A New York Times write-up of the same HBR article, useful as a free short account of the exercise. Dated 22 September 2007. ## Related frameworks - [Scenario Planning](https://usefulconsultingframeworks.com/frameworks/scenario-planning/): Builds a few internally consistent pictures of how the outside world could develop. Use it when the uncertainty is environmental. Use a pre-mortem when the uncertainty is whether this plan would survive. - [Kepner-Tregoe](https://usefulconsultingframeworks.com/frameworks/kepner-tregoe/): Potential problem analysis lists what could go wrong with a chosen course, then sets prevention and triggers. Use it for a structured pass after the pre-mortem has surfaced the reasons people would not say in a normal review. - [Six Thinking Hats](https://usefulconsultingframeworks.com/frameworks/six-thinking-hats/): Gives a group a timed caution stance. Use it for a meeting that needs several stances. Use a pre-mortem when the missing stance is candor about a plan that already has momentum. - [Playing to Win](https://usefulconsultingframeworks.com/frameworks/playing-to-win/): Tests a strategy with "what would have to be true." A pre-mortem asks the inverse about a committed plan. Use Playing to Win while choices are still open, and a pre-mortem once a plan exists. Last updated October 20, 2026.