A risk technique that imagines a project has already failed and works backward to list the plausible causes, producing a risk register and matching mitigations before the work begins.
If this project has already failed a year from now, what were the reasons, and what can we do about them today?
A pre-mortem inverts the post-mortem. Instead of explaining a failure after it happens, the team imagines that the project has already failed, then works backwards to list the reasons why. The trick is the framing: assuming failure as a fact, rather than asking whether it might happen, gives people permission to voice doubts they would otherwise keep quiet.
The technique was introduced by the research psychologist Gary Klein, a leading figure in naturalistic decisionDecisionStrategyA recorded decision with context, rationale, and consequencesView reference →-making, in a 2007 Harvard Business Review article titled "Performing a Project Premortem". Klein drew on research into prospective hindsight, the finding that imagining an event has already occurred increases the ability to correctly identify reasons for it, in one study by around thirty percent. Daniel Kahneman later cited the pre-mortem approvingly in Thinking, Fast and Slow as a practical counter to the overconfidence and groupthink that infect team planning.
Its appeal is psychological as much as analytical. In a normal riskRiskComplianceA risk to the product or businessView reference → review, raising a concern can feel like disloyalty to a plan everyone has committed to. By stipulating that the project has failed, the pre-mortem makes naming problems the assigned taskTaskProduct SpecificationA unit of work within a story or epicView reference → rather than an act of dissent.
The session is short and has a fixed shape:
A worked example. A team is about to begin a six-month migration to a new billing platform. In the pre-mortem, one engineer writes that the project failed because the old system had undocumented edge cases that broke on import. A product manager writes that finance never had time to validate the migrated data, so trust collapsed at go-live. A designer writes that the cutover happened during the busiest sales month and support drowned. None of these is news exactly, but written as accomplished facts they carry weight, and the team leaves with three mitigations: a discovery spike on legacy edge cases, a finance validation gate before cutover, and a launch window moved out of peak season.
A pre-mortem is most valuable just after a plan is set and before significant resources are committed, on work that is large, irreversible, or politically charged. It is cheap, takes under an hour, and is at its best precisely when commitment and optimism are highest, which is when ordinary risk review is weakest.
It is less useful for small, reversible, or routine work, where the ceremony outweighs the benefit. It also fails when leadership treats it as a box to tick: if the surfaced risks are noted and then ignored, the team learns that candour is theatre and stops offering it. The value is entirely in whether the mitigations are actually owned and acted on.
The pre-mortem is a reflection framework in the team-process category. Its outputs map to three entity types:
riskinsightinitiativeBecause the risks and mitigations live in the graph rather than in a workshop document, they can be tracked through the life of the project. A mitigation links back to the risk it addresses and forward to the work that carries it out, so a pre-mortem becomes a live risk registerRisk RegisterProgram ManagementA register of project risksView reference → connected to delivery, not a memo that is filed and forgotten.
Imagining a failed platform migration
Before committing to a six-month migration to a new billing platform, the team runs a pre-mortem: they assume it is a year later and the project failed, then each person writes why. The framing as accomplished fact surfaces concerns people had been reluctant to voice, including that the legacy data was never fully mapped and that no rollback plan existed. The session produces a register of plausible failure modes with owners and mitigations, and the two highest-ranked, a data-mapping spike and a staged rollback, are added to the plan while there is still time to act.
Breaking the silence around a clean-looking launch
A launch plan looks suspiciously tidy and the room has gone quiet, so the lead runs a pre-mortem and asks everyone to explain a failure as though it had already happened. Stipulating failure as a fact converts dissent from a social risk into the expected contribution, and a junior engineer raises a load-testing gap that no one had wanted to be the one to flag. The doubt becomes a tracked mitigation rather than an unspoken worry, which is precisely the optimism-puncturing effect the technique is designed to produce.