What Is the Purpose of Running a Premortem?

The purpose of a premortem is to surface the reasons a project will fail while there is still time to act on them. The team assumes the project has already failed, then writes down why. Stating failure as fact rather than possibility makes people specific about problems they would otherwise soften.

This is for engineering leads and project owners deciding whether the exercise justifies ninety minutes of the team’s time. It covers where the technique came from, how to run one, who to invite, when in the project to hold it, and what separates the output from a postmortem.

What is the purpose of running a premortem?

A premortem exists to convert vague unease into named, specific risks that someone can act on before the plan hardens. It does three things a normal risk discussion does badly.

It changes what people can retrieve. Asked what might go wrong, engineers produce categories: integration risk, unclear requirements, dependency on another team. Asked why the project failed, the same engineers produce events: the payments team never got the schema change in time, the migration script was tested on a copy that had no production nulls in it. Only the second kind can be assigned to anyone.

It lowers the social cost of dissent. In a normal planning meeting, raising a serious objection is a bet against the plan and, by implication, against the person who wrote it. In a premortem, pessimism is the assignment. Nobody is being difficult; everyone is answering the question they were given.

It produces mitigations while they are still cheap. A risk identified in the design week costs a conversation. The same risk identified in cutover week costs a weekend.

A premortem is not a risk workshop with better branding. The difference is grammatical. A risk workshop asks what could go wrong; a premortem asserts that it did, and asks the team to explain themselves.

What it does not do is tell you whether to proceed. It assumes the project is going ahead and asks how it dies. That constraint is the point, and it is also why the exercise occasionally produces an answer the sponsor did not order.

What is the Gary Klein premortem technique?

The premortem was described by Gary Klein, a research psychologist who studies how experts make decisions under pressure, in a 2007 Harvard Business Review article. The mechanism behind it is prospective hindsight: research on judgement found that people asked to explain an event that has already happened generate more reasons, and more concrete ones, than people asked to predict what might happen. Klein’s contribution was to turn that finding into a meeting.

A working version of the session:

1. Brief the plan. Ten minutes. Everyone must be attacking the same version of the plan, including the dates and the assumptions underneath them. Circulate the document beforehand and assume half the room skimmed it.
2. State the failure. One minute, out loud, with a date. “It is the fourteenth of March. We cut over last weekend, we rolled back on Monday morning, and the migration is being replanned from scratch.” Vague failure produces vague reasons, so pick a specific form of disaster and a specific date.
3. Write in silence. Ten minutes. Everyone lists reasons independently, on their own, before anyone speaks. This step is not a formality. Skip it and the first confident voice sets the range of acceptable answers for the rest of the room.
4. Read round the room. Twenty to thirty minutes. Each person reads out one reason, going round until the lists are exhausted. One at a time, no debating, no ranking yet. The facilitator writes them down in the words the author used, not a tidied paraphrase.
5. Cluster and choose. Ten minutes. Group duplicates, then have the room pick the handful that are both plausible and expensive. Ten to fifteen distinct failure modes is a normal harvest; three or four are worth immediate work.
6. Assign, before anyone leaves. Each chosen failure mode gets a named person and one next action. Doing this in the room takes ten minutes. Doing it afterwards takes three weeks and usually does not happen.

Klein’s framing is that the exercise legitimises doubt. That framing matters more than the process detail. Run all six steps with a room that believes the decision is already made and you will get a polite list of things that are somebody else’s fault.

When should a premortem be held?

Hold a premortem once there is a plan concrete enough to attack, and before the commitments in it become expensive to unwind. Run it late enough that there is something real to shoot at, early enough that the plan can still change in response.

For engineering work, the usable moments are fairly narrow:

• After the technical design or RFC is drafted, before the estimate goes to stakeholders as a date
• Before a migration or cutover plan is signed off, while the rollback path is still being written
• At the start of a rewrite, when the scope is still a proposal rather than a headcount plan
• Before a launch that involves teams outside your own, once their dependencies are known

The common mistake is holding it at kickoff, alongside everything else. At kickoff there is usually a goal and not yet a plan, so the exercise produces generic anxiety. Give it a slot a week or two after the kickoff has established what the project actually is, when there is a design to argue with.

There is also a point after which it stops being useful. Once the dates are external commitments and the team has been assembled around them, a premortem becomes a documentation exercise in which everyone lists the reasons they will later cite. That is not worthless, but do not confuse it with a chance to change anything.

Who should be involved in a premortem?

Invite the people who will have to make the plan work, plus at least one person who has reason to doubt it. Seniority is the wrong selection criterion; proximity to the failure is the right one.

A good room for an engineering premortem:

• The people doing the build, not only the leads. The engineer who will write the migration script knows things about the data that the design doc does not record.
• The plan’s author, present and answering questions, but not facilitating. Authors defend. Facilitators cannot.
• Downstream teams. On-call, support, QA and data are the people who inherit the consequences of a bad launch, and they are usually the last to be asked.
• One informed skeptic. Someone who argued against this approach and lost. They arrive with a list already written.
• One outsider. A person with no history on the project asks the questions everybody else stopped asking eight months ago.

Cap the room at around ten. Beyond that the round robin runs long and people stop contributing. If the project spans more organisations than that, run two sessions and merge the outputs rather than staging a large meeting in which nobody speaks twice.

One practical note on hierarchy. The silent writing step exists mostly to protect the room from its most senior member. If the principal engineer speaks first and calls the schema migration the main risk, you will get six variations on schema migration and nothing about the third-party rate limit that will actually take you down.

Turning premortem output into risks someone owns

Convert every surviving failure mode into a risk with an owner, a trigger and a next action, then file it where the team already looks. A premortem that ends in a shared document nobody owns is a well-facilitated complaint.

Each failure mode gets one of three dispositions, and the disposition is recorded:

• Mitigate. There is work to do, so it becomes a ticket in the same backlog as everything else, with the failure mode written in the description. Tickets created out of a premortem and parked in a separate document do not get done.
• Monitor. You are not acting yet, so name the signal that means you should, and the person watching for it. “If the vendor sandbox is still unavailable by the twentieth, we descope the integration” is a monitor. “Keep an eye on the vendor” is not.
• Accept. You have decided to carry the risk. Write down that you accepted it, who accepted it, and why. This is the entry that matters most six months later, and it is the one teams skip.

Phrase the entries as events with causes and consequences rather than as topics, and keep them somewhere with a review rhythm attached, whether that is a RAID log or a risk register you actually reopen or the project’s own board. One option for the write-up step, if the session already runs in Slack or Microsoft Teams, is Projan: it presses each proposed mitigation for a named owner and a date before it exports the surviving ones to Jira or Linear as tickets.

Set a date to reread the list. Most premortem output has a shelf life of about a fortnight in the team’s memory and considerably longer in reality.

How is a premortem different from a postmortem?

A premortem imagines a failure that has not happened to prevent it; a postmortem examines one that has, to stop it recurring. Same muscle, opposite direction, and the input quality is completely different.

	Premortem	Postmortem
When	Before the work, once a plan exists	After an incident or a delivery
The failure	Hypothetical, asserted as fact for the exercise	Real, with evidence
Main input	The team’s experience and instinct	Logs, timelines, the incident record
Facilitated by	Anyone except the plan’s author	Anyone not on the responding team
Output	Risks with owners and mitigations	Contributing factors and action items
Fails when	Held too late to change anything	Held too late to remember anything
Biggest threat to it	Optimism about the plan	Blame directed at people

The two are not substitutes and the postmortem is not the more serious of the pair. A postmortem has better data; a premortem has better timing. Teams that run blameless postmortems already have most of what a premortem needs, because the cultural work of separating a bad outcome from a bad person is the same in both directions.

One thing does transfer cleanly. Recurring themes in your postmortems make excellent seed material for the next premortem, particularly the ones about coordination between teams, which almost never appear in anyone’s independent list.

Where premortems go wrong

Five failure modes account for most of the premortems that produce nothing usable.

1. Held after the dates were promised. Nothing can change, so the room performs the exercise instead of doing it.
2. Facilitated by the person who wrote the plan. Every reason gets answered rather than recorded, and the room learns to stop offering them.
3. Discussion before silent writing. The list converges on the first two ideas mentioned. You will not notice this happening.
4. Reasons written as categories. “Poor communication” cannot be assigned or mitigated. “The mobile team finds out about the API change from the release notes” can be, by one named person, this week.
5. No owner attached in the room. The output goes into a document that is opened once more, at the postmortem, by someone looking for evidence.

None of these are cultural problems, which makes premortems unusually easy to improve. Get the timing right, hand facilitation to someone with no stake in the plan, and refuse to end the meeting without names against the top four items.

Frequently asked questions

When should you conduct a premortem, and is one enough? One is enough for a project measured in weeks. Anything running longer than a quarter deserves a second session at each phase boundary, because the failure modes change once code exists. A rewrite has different risks at design time and at cutover time. Repeat the exercise when the plan changes materially, not on a calendar.

How long should a premortem take? Sixty to ninety minutes for a substantial project, including the plan briefing at the start. The silent writing takes ten minutes, the round robin twenty to thirty depending on group size, and clustering the rest. If you cannot spare ninety minutes, run a shorter version on one phase rather than a rushed version on everything.

Can a premortem be run asynchronously? The writing step works well asynchronously, since it is silent and individual anyway. Post the plan and the failure statement, give people two days to submit reasons privately, then meet to cluster and assign. The part that does not survive going async is the discussion, where one person’s reason reminds someone else of a worse one.

What if the premortem suggests the project should not go ahead? That is a legitimate result, though a rare one, and it needs escalating rather than absorbing. Write up the failure modes the team could not mitigate and send them to whoever authorised the work, with the specific conditions that would make the plan viable. A premortem does not have authority to cancel anything. It produces evidence for the person who does.

A premortem is cheap, and its cost is almost entirely in the discipline of running it at a point where the answers can still change the plan. Ask for reasons the project failed rather than risks it faces, write them down in the words people used, and leave the room with four of them owned.