“Pre-Mortem Analysis: How to Run One”

What is a pre-mortem analysis?

A pre-mortem analysis is a structured risk-identification exercise run before a project starts or before a major decision, in which the team imagines the work has already failed and generates the reasons. The term was popularised by psychologist Gary Klein in a 2007 Harvard Business Review article, building on research into prospective hindsight.

The mechanism is simple. Asking “what might go wrong?” invites hedging, politics, and optimism. Asking “why did it fail?” turns the same people into analysts explaining an event. The certainty of the premise does the psychological work.

One honest caveat before you cite the famous statistic: the 1989 study by Mitchell, Russo, and Pennington found that imagining an event as already having happened increased the number of reasons people generated by about 30%. It did not measure whether those reasons were correct. A pre-mortem reliably widens the list. It does not guarantee the list is right, which is why the ranking step matters so much.

What do you need before the session?

Five things, and none of them is software.

1. A plan specific enough to criticise. One page: objective, scope, timeline, budget, key dependencies, and the assumptions the plan rests on. If the plan is vague, the failure reasons will be vague too.
2. Six to ten people who know the work. Include one or two outsiders — someone from support, finance, or another delivery team. They see risks the core team has normalised.
3. A facilitator who is not the project manager. The PM needs to listen and take notes, not defend. If no one else can facilitate, use a strict script and a timer.
4. A capture surface. Sticky notes and a wall, or one shared document with a column per person. Anonymity helps; authorship should not be visible during the readout.
5. A hard stop. Sixty minutes. Sessions that run to ninety minutes stop generating and start relitigating the plan.

> Important note: Do not run a pre-mortem before the plan exists. Without a plan, the exercise produces generic fears about “communication” and “resourcing” that cannot be acted on. With a plan, it produces specific, testable failure stories.

What is the exact agenda?

The timings below assume a 55-minute session with eight people. Adjust the writing time, not the structure.

Two rules protect the first half. No rebuttal during the readout. If someone says “that would never happen”, the facilitator writes it down and moves on. Quantity before quality. Ask for at least five items per person; the fifth is usually the honest one.

What is the exact script?

Words matter here, because the exercise only works if people accept the premise. Use this, or something close to it.

> “We are twelve months from now. This project has failed. Not a small slip — it was cancelled after spending most of the budget, and the client is unhappy. You are writing the post-mortem. In silence, list every reason you can think of for that failure, especially the ones you would not normally raise in a planning meeting. Five minutes, one reason per line. Do not discuss yet.”

Then stop talking. When someone asks “but how do I know why it failed?”, answer once: “Make it up. What is the most plausible story?” and withdraw. The moment the group starts debating whether failure is possible, the exercise collapses back into a normal risk review.

For the readout, go around the room and take one item per person per round. Start with the facilitator, not the most senior person, to avoid anchoring. Read anonymous notes yourself if the group is politically sensitive.

Who should be in the room?

People who can change the plan, plus people who will feel the consequences. That usually means the project manager, the delivery leads, a technical or operational specialist, and one outsider with no stake in the plan’s approval.

Keep the group between six and ten. Below six, the range of experience is too narrow. Above ten, the readout takes longer than the insight is worth, and the quieter half stops contributing. For large programmes, run two sessions by sub-team and compare the lists: the differences usually reveal where the organisation is siloed.

There is one exception to the “invite the sponsor” instinct. A sponsor who reacts to every risk with “that is not going to happen” will suppress the room. Brief them beforehand, or ask them to observe without speaking until the voting stage.

How do you run it remotely?

Better than most in-person meetings, if you protect the silent writing. Use a shared board with one column per person, or a form that collects responses anonymously before anyone can read them.

• Write first, talk second. Give a full five minutes with cameras optional and microphones muted.
• Collect before revealing. Paste all notes into one board, shuffled, so the first answer does not anchor the rest.
• Cluster live but slowly. Name themes with the group rather than pre-sorting them into a facilitator’s taxonomy.
• Vote in silence. A poll or a dot-vote column, three votes each, no discussion until the result is visible.
• Assign owners verbally. An action without a named owner and a date is a wish.

Remote sessions often surface more candid risks, because typing feels less exposed than speaking. They also drift; the timer is doing real work.

How do you turn the output into action?

Cluster, rank, then convert the top themes into risk register entries with four fields. The brainstorm is cheap; the triage is the part that changes the plan.

Cluster. Forty-five sticky notes usually collapse into six or seven themes: data quality, vendor dependency, staffing, decision rights, adoption, timeline assumptions, and scope. Name them in the team’s language, not in risk-taxonomy language.

Rank. Three votes per person, cumulative allowed. Take the top three to five. Everything else goes into the register as unranked, which is not the same as discarded.

Convert. For each top theme, write:

• The cause, in one sentence
• An early warning sign someone could actually observe
• One named owner
• One action with a date

Triage. Causes inside the team’s control get a fix. Partly controllable causes get a monitoring plan with a leading indicator. Causes outside anyone’s control get documented as accepted and escalated, so nobody is surprised later.

Worked example: the numbers behind the hour

Eight people at a loaded cost of $65 an hour spend one hour in the session, plus 45 minutes of facilitator prep: 8 × $65 + $49 = $569.

Now suppose the exercise surfaces one dependency that would otherwise have been discovered in week 9: a vendor’s data feed arrives two weeks later than the plan assumes. Catching it in week 1 allows the team to resequence testing, avoiding a three-day slip for a five-person team at $700 a day: 5 × 3 × $700 = $10,500.

That is a return of roughly 18 to 1 on the meeting cost alone. The comparison is deliberately generous — not every session finds a $10,500 problem — but the asymmetry is the point. An hour is cheap; a late discovery is not.

Worked example: a cutover pre-mortem

Suppose a 900-person manufacturer is eight weeks from an ERP cutover. The plan has 180 tasks, a three-day freeze window, and a training programme for 400 users. The pre-mortem produces 31 causes, clustered into six themes.

The vote puts “migration data does not reconcile and we cut over anyway” first, with 14 of 24 votes. The team converts it:

• Cause: master data cleansed in the test environment is not cleansed in production.
• Warning sign: reconciliation mismatch above 0.5% in the second dry run.
• Owner: data migration lead.
• Action: two full dry runs, plus a go/no-go gate requiring 99.5% record match, by week 6.

The second theme is “key users are unavailable during the freeze because month-end close overlaps”. The action is a one-week shift of the freeze window, agreed with finance in week 2 rather than week 7.

Neither action is exotic. That is the normal output of a good pre-mortem: not brilliant strategy, but three or four obvious-in-hindsight adjustments made early enough to matter. The dry runs cost about 40 hours of combined effort, or 40 × $65 = $2,600 — a small price against a cutover that has to be repeated.

What are the common failure modes?

It becomes a blame session. The prompt invites systemic causes, not personal ones. If someone names a colleague, reframe: “what process made that likely?”

The senior person speaks first. Anchoring kills diversity. Silent writing and anonymous readout exist to prevent this.

The list is long and nothing happens. Without voting and owners, the output is a wall of paper. Book the triage inside the same session.

It substitutes for a risk register. A pre-mortem is one afternoon of imagination; a register is a living system with review dates. Feed the register, do not replace it.

It runs only at kickoff. Plans change. A pre-mortem from month one is stale by month five, and the risks that sink projects often did not exist when it ran.

It ends on fear. Close with commitments, not with a recital of everything that could go wrong. Teams leave either energised or demoralised, and the difference is the last ten minutes.

When should you run another one?

Run a short version at any point where the plan’s assumptions change materially: a major milestone, a scope change above roughly 15% of budget or effort, a change of sponsor, a key person leaving, or four to six weeks before a go-live or launch.

The rerun can be 25 minutes: restate what changed, silent writing on “why did the next phase fail?”, then update the top three register entries. The point is not ceremony. It is to catch the risks that the original session could not have known about.

How is it different from a retrospective?

A retrospective looks back at work already done; a pre-mortem looks forward at work not yet started; a post-mortem explains a failure after it happens. The link above covers the full comparison, including when each format earns its meeting.

The practical difference is the mood. A retrospective asks “what should we change next sprint?” A pre-mortem asks “what would kill this plan?” Both are blameless. Only one is useful before the first commit.

Where Doitify fits

A pre-mortem produces a list; the list needs a home. Doitify keeps risks and constraints, tasks and sub-tasks, owners and due dates, milestones, dependencies, and project documents in the same workspace as the plan, so an action agreed in the session becomes a tracked task with an owner rather than a line in a document nobody opens.

Doitify is our product, so treat that as a description rather than a recommendation. The exercise works on a whiteboard and a shared doc. What a tool adds is the follow-through: the warning sign that gets checked, the owner who gets reminded, and the risk that stays visible at the next milestone review.

Conclusion

A pre-mortem analysis is a small, cheap intervention with an unusually good hit rate, provided you run it as a decision tool rather than a ritual. Get the plan on one page, put the right eight people in the room, say the words exactly as written, and protect the silence.

Then spend your energy where it counts: rank the themes, name an owner for each, and set a date. A session that ends with three tracked actions is worth more than a brilliant brainstorm that ends with a document. And when the plan changes — because it will — run the short version again before the next commitment, not after the next failure.

If this post on pre-mortem analysis was helpful, you might also enjoy Project Reporting: The Complete Guide (Types, Templates, Best Practices) and How to Create a Gantt Chart (Step-by-Step).