Pre-mortem for leaders
Most project risks are known by someone on the team long before they appear in a report — they are simply not said out loud in time. A pre-mortem makes saying them the task itself: the team imagines the project has already failed, explains why, and turns those explanations into a risk register and decisions while there is still time to act.
A scene from project life
A project team meets to confirm a launch plan. The dates are tight but plausible, the sponsor is confident, and the plan on the screen has no empty spaces. The leader asks the usual question: does anyone see a problem? Two people have doubts. One depends on a supplier whose answers have slowed down. Another knows that a key specialist is shared with a second project that peaks in the same week.
Neither doubt is raised. The first sounds disloyal while everyone is being optimistic. The second was mentioned once before and answered with reassurance, so repeating it feels like arguing. The meeting closes with agreement, the risk register stays short and tidy, and the two known risks continue their work undisturbed.
Six weeks later, both arrive on schedule. The supplier delivers late, the shared specialist is pulled away, and the team holds a long, honest meeting about what went wrong. Everything said in that meeting was available at the start. What was missing was not knowledge. It was a format in which saying the difficult thing early counted as good work rather than as spoiling the mood.
The method, in substance
A pre-mortem reverses the order of that story. Instead of asking whether the project might fail, the team takes failure as a fact and works backwards. The leader sets a concrete future date — the launch, the delivery, the end of the quarter — and states the premise plainly: we are meeting after that date, and the project has failed. Not struggled, not slipped a little: failed. Each participant's task is to explain how it happened.
The premise matters because it changes what honesty costs. Predicting failure in advance can sound like doubt about colleagues or about the plan. Explaining a failure that is treated as already real is a different job: it is analysis, and everyone in the room is doing it together. Risks that politeness, optimism, and hierarchy usually hide become the material the meeting was called to produce.
The output is not a mood and not a list of complaints. Each named cause is rewritten as a risk in standard form: an event that may damage the project, stated clearly enough to be watched. The team then weighs each risk on the probability-by-impact matrix — how likely it is, and how much damage it would do if it happened — and enters the serious ones into the risk register with an owner, early indicators, and a prepared response: avoid, transfer, reduce, or accept, chosen deliberately rather than by default.
That is also where the pre-mortem joins decision work. Decisions in a project are collective information work: knowledge is distributed across people and levels, and the known failure mode is a discussion built only from what everyone already shares, while the one fact that would change the decision stays in somebody's head. A pre-mortem is a structured way to surface that unique knowledge before the decision closes — and to record what it changed: a date moved, a resource protected, a first step made reversible, a review point set.
How to use it in a team
Run the pre-mortem before a major commitment: a launch, a signed date, a budget, a promise to a sponsor. Allow about an hour. The leader states the future date and the premise, and states the working position explicitly: in this room, I am OK and you are OK — every contribution is treated as information about the project, not as a verdict on a person, and no one will be punished in this meeting for naming a hard fact early.
First, everyone writes silently, alone, for ten to fifteen minutes: the causes of the failure, each on its own line, as concretely as possible. Silence is not a courtesy; it is the mechanism. Writing before speaking stops the first confident voice from setting the boundaries of what others remember and dare to say.
Then the causes are collected round by round, one at a time, without debate, until the lists are exhausted. Only after collection does the team group duplicates, discuss evidence, and test which causes describe real risks and which describe general anxiety. Each surviving risk is scored for probability and impact, given an owner and early indicators, and entered into the risk register with a response and a date to review it.
Close by converting the strongest findings into decisions, in the room: what changes in the plan today, what is watched, what trigger would reopen the decision, and when the team will look again. If the pre-mortem changes nothing — no date, no owner, no response, no decision — it was a conversation, not a method. The register and the decision log are what make it work.
Where the method stops
A pre-mortem does not predict the future, and it does not replace a living risk register. New risks appear as the work changes, suppliers change, and people change; a register written once and never reviewed is decoration. The method also cannot manufacture honesty where honesty is genuinely unsafe. If a leader has previously punished bad news, one well-run meeting will not undo that record; the team will write safe causes and keep the real ones. The position has to be practised between meetings, not only declared inside one.
It also has a boundary with crisis. A risk is an event that may still be answered in advance; a crisis is a failure already unfolding, where the project's success itself is in question and the first job is to stabilise, then decide. Running a pre-mortem in the middle of a crisis wastes the hour the crisis needs. Use it while there is still a future to change.
Finally, a pre-mortem cannot settle a decision that belongs elsewhere. If the real choice sits with a sponsor who is not in the room, the team's output is an input to that decision — a register and a recommendation — and it should be contracted as such, not mistaken for the decision itself.
One step this week
Take the nearest milestone your team has already agreed. Book thirty minutes before the commitment becomes final, set the date after that milestone, and open with one sentence: we have failed — what happened? Collect the answers in silence first, score the three strongest causes for probability and impact, and give each an owner and a review date. That single page is the start of a risk register that tells the truth.