Pre-Mortem Analysis: How to Find Out Why a Project Will Fail Before It Starts

The launch approval meeting is going well. The plan has been reviewed, the director likes it and the schedule fits the quarter. Someone on the team has doubts about the integration but stays quiet: the project already seems decided.

Six months later, reviewing what went wrong, that person says: “I suspected this all along.” The pre-mortem moves that conversation to before the start, when the plan can still change.

What pre-mortem analysis is#

The Premortem was described by Gary Klein in a 2007 Harvard Business Review article. The analogy comes from medicine: an autopsy explains why the patient died, but it comes too late for the patient. The pre-mortem happens while the project can still be saved. Participants assume the project has just failed and generate plausible reasons for it (Klein, 2007).

It looks like a simple risk analysis, but it changes the question. “What could go wrong?” invites a defense of the plan. “It failed, why?” asks for an explanation. Klein highlights the social effect: the technique makes it safe to disagree for those who know the project well and worry about its weaknesses.

Root cause analysis investigates an observed problem, with evidence. A pre-mortem raises plausible failures, and none of them is a fact.

When to use it and when to avoid it#

How to run it#

The sequence below follows Klein’s description. The timings are a suggestion, for a session of a little over an hour:

Individual writing matters: it keeps the first opinions, usually from those with the most power, from shaping the whole list. And the word “failed” matters even more, as the studies below show.

Example: launching an app#

A chain of clinics is about to launch a scheduling app. The session starts from the sentence: “six months after launch, the app has failed. Few people use it, there was a security breach, costs overran, and those who installed it dropped out.” The list produced 31 reasons, which were grouped into these causes:

Prioritization takes impact, evidence and the ability to respond into account:

• Act before starting: high impact with strong evidence, or severe harm. This covers the peak-time calendar and the data leak.
• Test: high impact with incomplete evidence. This covers sign-up and the front desk.
• Record and monitor: the rest, with a defined signal.

Each priority risk becomes an item in the plan:

• Calendar down at peak. Signal: errors above 1% in the load test. Action: test at twice the expected peak before launch. Owner: tech lead. Contingency: phone booking stays active for 90 days.
• Data leak. Signal: critical findings in the security review. Action: external review before launch and minimal data at sign-up. Owner: security.
• Long sign-up. Signal: fewer than 60% finish sign-up in the test. Action: test with ten real patients and cut fields. Owner: product.

The plan changed in three places, and that’s what matters. The list alone doesn’t reduce any risk.

What the evidence shows#

There are few studies of the technique, and one review sums it up well: the academic literature is thin (Collins, n.d.).

• Where the 30% comes from. Klein cites Mitchell, Russo & Pennington (1989) to say that imagining an event as already having happened improves the ability to correctly identify reasons for future outcomes by 30%. According to Collins’s review, the study measured the number of reasons, not their quality. It’s a more modest finding than the famous sentence suggests.
• Certainty seems to be what counts. In that study’s first experiment, placing the event in the past or the future had little influence. What changed the explanations was whether the event was certain or uncertain. Hence the importance of saying “it failed”, not “it might fail”.
• Less confidence. Veinott, Klein & Wiggins (2010) compared ways of critiquing a plan with 178 college students. The pre-mortem reduced confidence in the plan the most. Note that the participants were students, and that lower confidence isn’t the same as a better decision.
• Higher-quality risks. Gallop, Willy & Bischoff (2016) assigned 101 experienced managers and engineers to brainstorming or pre-mortem groups. The pre-mortem groups identified more quality risks and proposed better changes. The comparison was with another technique, on a single historical case.

The prudent conclusion is that it’s worth doing: it’s cheap and has some support. Just don’t promise more than the studies back up.

How to use an LLM#

An LLM can widen the list with failure modes from other areas, such as security and data, and organize the result into a risk register. Run the human session first, because only those on the project know the specific failures, and the model’s list can anchor the group.

Run a pre-mortem of the project [project].
Goal and success criteria: [describe].
Current plan: [phases and dependencies].
Known constraints and risks: [describe].

Imagine that, [timeframe] from now, the project has failed in a
significant way. List plausible causes from the perspectives of
technology, product, users, security, data, operations, people and
business. For each one, propose early signals, preventive action, owner,
contingency plan and a test that could reduce the uncertainty.
Distinguish likely failure modes from remote possibilities.

Expected output: a risk register with warning signs and mitigation.

Before trusting the answer:

• Compare with the human list. The value lies in what the model adds, not in what it repeats.
• Cut the generic. If a risk would fit any project, it isn’t useful yet.
• Prioritize with your own data. Probabilities cited by the model are guesses.
• Sanitize the context. Plans, vendors and known security flaws shouldn’t go into public tools.

Combine it with other frameworks#

• 5 Whys: investigates problems that have already happened; the pre-mortem acts before execution.
• Scenario planning: explores changes in the environment; the pre-mortem assumes the plan failed.
• Force field analysis: maps the barriers to a change before it starts.
• Hypothesis testing: reduces the uncertainty of risks with little evidence.
• Critical path method: shows which dependencies can delay the deadline.

References#

1. Collins, J. The premortem. In Course notes on behavioural economics and corporate decision making, chapter 30. Link
2. Gallop, D., Willy, C. & Bischoff, J. (2016). How to catch a black swan: Measuring the benefits of the premortem technique for risk identification. Journal of Enterprise Transformation, 6(2), 87–106. DOI
3. Klein, G. (2007). Performing a Project Premortem. Harvard Business Review, September. Link
4. Mitchell, D. J., Russo, J. E. & Pennington, N. (1989). Back to the future: Temporal perspective in the explanation of events. Journal of Behavioral Decision Making, 2(1), 25–38. DOI
5. Veinott, B., Klein, G. & Wiggins, S. (2010). Evaluating the effectiveness of the PreMortem technique on plan confidence. Proceedings of ISCRAM, Seattle.