How to run a pre-mortem
It finds the reasons. It loses the count.
Klein’s 2007 exercise, as he actually wrote it — and the one step that discards how many people independently arrived at the same doubt.
What Klein actually described
One page of the Harvard Business Review, September 2007, under the title “Performing a Project Premortem”. It opens on the problem rather than the method: projects fail at a spectacular rate, and one reason is that too many people are reluctant to speak up about their reservations during the planning phase.
The mechanism is a grammatical trick with evidence behind it. Work published in 1989 by Deborah Mitchell, Jay Russo and Nancy Pennington found that prospective hindsight — imagining that an event has already happened — increases the ability to correctly identify reasons for future outcomes by 30%. So a pre-mortem does not ask what could go wrong. It asserts that everything already did, and asks what happened.
That is the entire difference between a pre-mortem and the risk review most teams already run, and it is why the pre-mortem gets better answers. Asking a room what might go wrong invites a defence of the plan. Telling a room the plan is dead removes anything to defend.
How to run one
Brief the plan first
A pre-mortem begins after the team has been briefed on the plan, not instead of that briefing. People cannot generate specific failure modes for something they have only heard the summary of, and a pre-mortem run on a vague plan returns vague doubts.
Declare it dead
The leader tells everyone the project has failed spectacularly. Not that it might, not that it is at risk — that it is over and it went badly. The past tense is the working part; softening it back to a conditional gives up the 30%.
Write alone, for a few minutes
Everyone in the room independently writes down every reason they can think of for the failure. Klein is explicit about which reasons matter most: especially the kinds of things they ordinarily wouldn’t mention, for fear of being impolitic.
This step is doing almost all of the work. It is also the step most teams shorten when the meeting runs long, which is the same as skipping the exercise.
Klein’s own account of what this step is worth: on a project to put air-campaign algorithms in front of military planners, a team member who had been silent through the entire kickoff volunteered that one of the algorithms would not fit on the laptops being used in the field, and would take hours to run where users needed answers quickly. The developers had already built a shortcut and had been reluctant to mention it. It was substituted, and the project went on to succeed.
Read them out, one each
The leader asks each team member — starting with the project manager — to read one reason from their list. Everyone states a different reason until all have been recorded, so the room goes round rather than one person emptying their page.
The plan owner takes the list away
After the session the project manager reviews the list and looks for ways to strengthen the plan. In Klein’s own example the fix was immediate: a senior executive said the failure was caused by there being no time to prepare a business case before a corporate review, and nobody had mentioned a single time constraint in the entire ninety-minute kickoff that preceded it.
What the read-out costs you
Klein already knew the hard part was people not saying things, which is why the write-down is private. But the write-down is private and the record is not. Two things happen in that one sentence about reading the list aloud, and they are worth separating.
The first is ordinary and everyone has felt it. You read your reason out, in your own voice, in front of the people it is about — and the round starts with the project manager, whose plan it is. The thing you wrote down when nobody was looking is not always the thing you read out when they are.
The second is structural and nearly invisible. Everyone states a different reason until all have been recorded, which means the list is deduplicated as it is built. If seven of nine people independently wrote “the timeline”, the timeline appears on that list exactly once — indistinguishable from the reason one person wrote and nobody else was thinking.
That is the strongest signal the room produced and the format discards it. Seven people arriving at the same doubt separately, before hearing anyone else say it, is not a longer list. It is a different kind of fact, and the one you would want most before committing a quarter to the plan.
Written alone, on nine pages
9 written
Recorded on the list
4 recorded
Run both. They answer different questions.
A pre-mortem is generative, and Daylight is not. A room riffing on how a project died produces failure modes nobody had on their own, and no anonymous form will ever do that. If you can only run one thing before a kickoff, run the pre-mortem.
Daylight does the other half. Everyone answers three numbers privately — how good the thing is today, how good it has to be by the date, and the odds it lands — and adds up to five reasons in their own words. Nothing opens until five people have answered. Nothing recorded could say who gave which answer: no name, no account, no timestamp and no order, so there is nothing to sort the answers back into people.
What comes back is the thing the read-out deletes. Not a list of reasons — a count of how many people held each one, and three spreads showing whether the room is looking at the same project at all.
Source: Gary Klein, “Performing a Project Premortem”, Harvard Business Review, September 2007, p. 18. The prospective-hindsight finding is Mitchell, Russo & Pennington, 1989.