Premortem Technique: 7 Steps Before a Launch
Every launch review asks the same question in the same tone: are we ready? The room says yes, because the person who would say no is the one who built it.
Code: Pre-Mortem-Skill, GPL-3.0 licensed.
A premortem inverts the question. The project has already failed, six months from now, and the job is to explain how. That single grammatical shift pulls out objections that a status meeting never surfaces, and it costs one hour.
Why the usual risk review misses
Asking “what could go wrong” produces a list of things that are already on the risk register. Everyone names the same three items, the meeting moves on, and the failure that kills the project is not on the list because nobody imagines it aloud.
Gary Klein’s version, published in Harvard Business Review, works because it removes the social cost of pessimism. Nobody is criticising the plan. The plan is already dead, and the group is reconstructing the autopsy.
The premortem technique in seven steps
The protocol we run is short enough to finish in one sitting and structured enough that it does not collapse into a complaint session.
- Check the input. What is the plan, who is it for, what does success look like, and when does it land. Without a named decision and a date, the exercise produces generic worry.
- Set the frame. Pick a horizon: three months for a launch, twelve for a hire. Say the sentence out loud: it failed, and here is why.
- Generate failures. Aim for specific, grounded reasons. At least two have to be boring: the timeline slipped, the team lost interest, the budget moved. Boring failures kill more projects than dramatic ones.
- Score them. Likelihood and impact from one to five. The numbers give the room something concrete to argue with instead of a vague sense of unease.
- Expand the top few. For each serious failure, write the story, the assumption underneath it, the early warning sign, and the cheapest mitigation that fits in the coming week.
- Synthesise. Which failure is most likely, which is most dangerous, and what assumption is doing the most work without evidence.
- Ask for one commitment. A single action with a day attached. No date, no action.
Step seven is where most risk workshops die. A list of risks is entertainment until someone changes a deadline because of it.
What the numbers are for
Likelihood and impact scores are not a model. They are a way to make disagreement visible.
Two people who both rate a failure as a three will argue about something else. Two people who rate it a one and a five have found the conversation worth having, and the gap usually means one of them knows something the other does not.
The scoring also stops the loudest voice from setting the agenda. A risk rated five by five out loud and two by two in private is a risk with a communication problem.
The failure mode of premortems
The exercise has its own ways to fail.
It fails when the plan is still vague. “We want to grow in Europe” cannot fail in a specific way, because there is nothing to fail. It fails when the horizon is left open, because “eventually” makes every cause plausible. It fails when the same person generates and evaluates the failures, since the evaluation quietly filters out the embarrassing ones.
And it fails when the output is a document nobody opens again. The mitigations need owners and dates or the hour was theatre.
Where it fits in a project
We run one before a launch, before a pricing change, before a senior hire, and before a rewrite of something that already works. Those four cover most of the decisions where being wrong is expensive and reversible.
It is a poor fit for an idea that has no shape yet, or for a decision already made. Running a premortem on a signed contract produces a list of regrets, not actions.
For the delivery side of the same discipline, see IT consulting and business automation, where most of the failure reasons come from. Once a feature passes the premortem, the build itself often lands in PHP AI inference, where a new dependency is the next place things break.
Background: Gary Klein, Performing a Project Premortem, Harvard Business Review.