A premortem is the postmortem you run before the project: the team imagines the work has already failed and works out why, while there's still time to act. Gary Klein introduced the method, and research on prospective hindsight shows the failed-already framing finds about 30% more causes. This template runs it in four prompted steps: what might go wrong, the consequences, the mitigations, and what to do next.
One price difference separates them: the postmortem's lessons cost a real failure; the premortem's cost a meeting. The postmortem analyzes what happened, assigns systemic causes, and improves the next project. The premortem imagines the failure first, harvests the same causal insight, and improves this project, the one you can still save. The catch is honesty: a postmortem has evidence to keep it grounded, while a premortem only works if the team genuinely commits to the failure story instead of listing comfortable risks.
A premortem is a planning exercise where the team assumes the project has already failed and works backward to explain why, before work begins. Gary Klein described the method in Harvard Business Review in 2007. It inverts the postmortem: instead of learning from a real failure, you harvest the lessons from an imagined one while the plan can still change.
Tense. 'What could go wrong?' invites hedged, polite maybes. 'The project failed; what happened?' forces specific stories, and the research behind it, on prospective hindsight, found that imagining an event as already having occurred improves people's ability to identify its causes by roughly 30%. The same shift also licenses dissent: describing the failure is the assignment, so nobody looks negative doing it.
After the plan exists and before the work starts: the kickoff window. That's when the team knows enough to imagine specific failures and the plan is still cheap to change. Big launches, migrations, and anything with a hard date deserve one; a sprint-sized premortem can run in twenty minutes. Running one mid-project works too, before a major milestone, while course corrections are still affordable.
Timing, and what the lessons can still change. The postmortem happens after something real went wrong: you analyze, you learn, and the cost is already paid. The premortem happens before, on an imagined failure, so the lessons arrive while they can still change the plan. They use the same muscle, causal storytelling, which is why teams that run good postmortems pick up premortems quickly. Run both; they bracket the project.
A risk assessment is an ongoing, analytical document: risks logged with probability and impact scores, maintained through the project. A premortem is a one-session, imaginative exercise that exploits a psychological trick, and it surfaces the fears people would never type into a register. They feed each other: run the premortem to find the risks honestly, then carry the keepers into the risk register with owners.