Learn it → Apply it → Save as Skill
Asking "what might go wrong?" rarely produces honest answers, because admitting a plan could fail feels disloyal while everyone is still excited about it. Pre-Mortem Analysis changes the question. It asks you to imagine the plan has already failed completely, then work backward to explain why, while there is still time to fix it.
The Dr. Wallace’s Favorite Mental Models series is designed to turn useful ways of thinking into reusable tools. Each model gives you a fast visual overview, deeper interactive learning, practical application exercises and an AI-ready Markdown skill you can save for future use.
Instead of merely reading about mental models, you can gradually build your own AI skills library: a collection of portable reasoning skills that can help ChatGPT, Claude, Grok and other AI assistants apply the mental models you value.
When you ask people whether a plan might fail, most stay polite and vague. When you ask them to assume it already failed and explain why, the same people suddenly produce specific, concrete, often uncomfortable reasons. That shift from "might" to "did" is the entire mechanism behind the pre-mortem.
Illustrative, not exact: bar heights represent the relative size of the effect reported in each study, not a precise measurement scale. Both studies measured the number of reasons people generated, not real project outcomes.
The pre-mortem is most useful at the moment a plan has taken shape but hasn't yet been funded, staffed or shipped, while changing course still costs almost nothing.
A pre-mortem doesn't ask whether a plan is good. It asks what a believable failure story would say, so you can fix the plot before it happens.
Set a specific future date and state, with full certainty, that the project failed completely. Not "might fail." Failed.
Each person involved writes down, independently and silently, every plausible reason the failure happened before anyone speaks.
Pool every reason into one list, remove duplicates, and rank each by how likely it is and how much damage it would do.
For the highest-ranked reasons, build a concrete countermeasure into the plan now, while changing it still costs almost nothing.
Open a use case to see what the model changes.
Before the kickoff meeting ends, imagine it's the deadline and the project has missed it badly. The reasons people name, usually about dependencies, staffing or scope, are worth building countermeasures for now, not discovering in week ten.
A launch review that only asks "are we ready?" invites a reassuring yes. Asking the team to imagine the launch failed and explain why surfaces the quieter worries, like an unresolved edge case, that a status update would have glossed over.
Imagine it's one year later and the hire clearly didn't work out. The specific reasons that come to mind, a skills gap, a culture mismatch, unclear scope, are exactly the questions worth resolving in the interview process itself.
Imagine the feature shipped and caused a visible, embarrassing failure. Naming the specific failure mode, a bad edge case, an overconfident output, a missing fallback, turns a vague worry about "AI risk" into a concrete fix you can build before launch.
Big, hard-to-reverse bets are exactly where optimism is most costly. Imagining the acquisition failed and explaining why, badly, forces out integration and cultural risks that a purely financial model won't surface.
Imagine it's contract renewal time and the relationship has clearly soured. The reasons, missed SLAs, a pricing trap, a single point of failure, point directly at the clauses worth negotiating before signing, not after.
This is an illustrative example designed to teach the method.
Expand for where the method came from and how solid the evidence actually is.
Cognitive psychologist Gary Klein described and named the technique in his September 2007 Harvard Business Review article, "Performing a Project Premortem." He framed it as the opposite of a post-mortem: instead of explaining a failure after it happens, a team explains an imagined failure before committing to the plan.
It is the specific psychological effect the pre-mortem relies on: people who imagine an outcome has already occurred generate more, and more concrete, reasons for it than people asked to predict whether it might occur. The effect was first documented by Deborah Mitchell, J. Edward Russo and Nancy Pennington in "Back to the Future: Temporal Perspective in the Explanation of Events," Journal of Behavioral Decision Making, 1989, which found roughly 30% more reasons generated under the certain-hindsight framing than under open-ended foresight.
Reasonably strong for the specific mechanism, more limited for real-world outcomes. The 1989 study and a 2002 replication by Russo and Paul Shoemaker (finding about 25% more reasons) both measured how many explanations people could generate, not whether premortems actually improve real project success rates. Large randomized studies tracking that second question are limited, so the technique's track record rests more on this reasoning-generation evidence and wide practitioner adoption than on controlled outcome trials.
No. A risk register and SWOT analysis both typically ask people to speculate about possible future problems, which tends to produce generic, hedged answers. A pre-mortem is a specific technique for feeding a standard risk process: by assuming failure as certain rather than possible, it is designed to produce sharper, more specific inputs for that same risk register, not to replace it.
Reverting to open-ended possibility language quietly removes the certainty framing that makes the technique work, and the answers slide back into vague, hedged generalities.
Having people call out reasons out loud lets the first or most senior voice anchor everyone else, which is the groupthink problem the technique is meant to avoid.
A pre-mortem run after the budget is spent and the team is hired can still surface real risks, but fixing them is now expensive instead of nearly free.
Generating a long, honest list of failure reasons and then filing it away without ranking it or assigning a countermeasure wastes the exercise's entire value.
Running the exercise ritually, to be seen as diligent, without any real intention of changing the plan based on what comes up, trains people to stop taking it seriously.
Plans change after the pre-mortem is run; a reason that didn't apply at kickoff can become the dominant risk by the midpoint, and the exercise is rarely revisited to check.
the decision is small, cheap and easily reversed. A pre-mortem costs real time and attention that a quickly correctable choice doesn't need.
a way to quietly blame whoever raises the most failure reasons, or to relitigate a decision the group has already made and funded. That turns a useful exercise into a trap people learn to avoid.
the risk is narrow and technical, such as a specific engineering failure mode or a financial model's sensitivity to one input. A pre-mortem surfaces where to look; it doesn't replace the specialized analysis once you're looking there.
This browser tool structures your thinking. It does not send your information anywhere or perform AI analysis.
Save as Skill converts the model into portable Markdown instructions that teach an AI when and how to run a Pre-Mortem Analysis, what questions to ask, what evidence to seek, what mistakes to avoid and how to structure its analysis.
Save the skills you find useful and organize them into your own reusable library. The Markdown is intentionally model-neutral, so it can be used wherever an AI system accepts uploaded files, project knowledge, custom instructions or reusable text context. Platform capabilities differ, so this is a portable skill file rather than a claim of one-click installation.
A normal risk review usually asks an open question, "what could go wrong?", which lets people stay comfortably vague. A pre-mortem forces a specific framing, assume with certainty that it already failed, which research shows produces more concrete, specific answers than the open-ended version.
Not typically, when it's run well. The exercise is scoped tightly: imagine failure, name reasons, fix the worst ones, then proceed. Teams that run it as a genuine planning step rather than a debate about whether to proceed usually come out more confident, because known risks now have owners.
It works solo, but a group surfaces a wider range of failure reasons because different people notice different blind spots. The independent, silent writing step matters most in a group, where it prevents one voice from anchoring everyone else's answers.
The list only has value if it changes the plan. The highest-ranked reasons need a named owner and a concrete action, and the list is worth a short second look partway through the project, since the risks that mattered at kickoff aren't always the ones that matter later.