i

Description

Un grand voilier à quatre mâts échoué au large d'une plage, avec quelques promeneurs sur le sable.

Source

Fred Kruger · original page

Licence

PD Public domain

Original photo, unretouched. The background is a version of it stylised by the site.

The pre-mortem

Rather than asking “what could go wrong?”, we announce that it went wrong and look for the causes. The question changes, and so do the answers.

In brief

• What: a meeting of about an hour, before launch, where the team assumes the project has failed and each person writes down, individually, the reasons for the failure.
• Why it works: presenting failure as a given (rather than a possibility) produces more concrete causes, and it becomes allowed, even expected, to voice one's doubts.
• Deliverable: a ranked list of risks, preventive actions, warning signals to monitor and, sometimes, a modified plan.
• To remember: it is a planning method, not a steering one; it reduces overconfidence, it does not eliminate it.

On this page

1. Definition
2. The principle: why it works
3. How to do it: the step-by-step procedure
4. Examples
   1. Prospective hindsight, in the laboratory 1989
   2. Replacing the billing system: a typical pre-mortem Illustrative example
5. When to use it, when to avoid it
   1. Use it
   2. Avoid it or adapt it
6. Limits and criticisms
7. With AI
   1. Detect
   2. Fix
   3. Mitigate
   4. Prompts to use
   5. Precautions
8. Sources and verification
9. See also
   1. Biases this method fights
   2. Complementary methods

Definition#

Fictitious illustration

Illustration inspired by the person

The pre-mortem (premortem) is a project review technique proposed by the psychologist Gary Klein. It was presented to the general public in the article “Performing a Project Premortem,” published in the September 2007 Harvard Business Review. Its name is a play on the autopsy (post-mortem): we do not look for why a project died, we do it before it is born.

The instruction is simple. The team has a plan, and it is judged ready. The facilitator says: “We are one year from now. The project has failed, totally and humiliatingly. Write down the reasons for this failure.” Everyone writes in silence, then the causes are shared and dealt with.

The scientific basis Klein invokes is a study by Deborah Mitchell, Jay Russo and Nancy Pennington (1989) on prospective hindsight: mentally placing oneself in the future by considering that an event has already occurred.

The principle: why it works#

A project that has just been decided is surrounded by three forces that stifle doubt:

• Optimism: we plan as if everything were going to go well (see unrealistic optimism and the planning fallacy).
• Group pressure: once the decision is made, voicing a doubt looks like defeatism or disloyalty (see groupthink and authority bias).
• Commitment: the more we have invested, the more we defend the plan (see sunk costs).

The pre-mortem reverses these three forces. By stating failure as a fact, it changes the mental task: it is no longer about defending the plan or guessing whether a risk is “likely,” but about explaining an event, which the brain does well and with more concrete detail. And because the exercise is requested by the project manager, pointing out a weakness becomes a contribution rather than a criticism.

Daniel Kahneman took up the idea in Thinking, Fast and Slow (2011): he sees it as a way of containing overconfidence and groupthink, without claiming that it eliminates them.

How to do it: the step-by-step procedure#

Duration: 45 to 90 minutes depending on the size of the project. Participants: the project team, plus two or three people who did not design it (operations, support, an internal client, someone from another department). Timing: when the plan is precise enough to be criticized, but before irreversible commitments (signed contract, team formed, milestones promised).

1. Prepare. A participant summarizes the plan in ten minutes: objective, scope, schedule, budget, assumptions. The facilitator must not be the sponsor, nor the person who wrote the plan.
2. Set the instruction. “We are at the planned end date (or a year later). The project has clearly failed. You know it.” You must say “has failed,” not “could fail.” Stress that there is no debate about probability.
3. Write alone, in silence. Each person notes down, for 5 to 10 minutes, every reason that comes to mind, including the most improbable or most awkward ones (the sponsor, the client, the technology, the schedule, oneself). Silence prevents the first person to speak from framing the others (see authority bias).
4. Share in a round table. Each person gives one reason at a time, until the lists are exhausted; the facilitator takes notes without commenting or defending. We look for diversity, not consensus. There is no discussion yet.
5. Group and score. The causes are grouped by theme, then each person votes, for example with three stickers, for those they judge most serious and most plausible.
6. Address the top ones. For the five to ten selected causes: what action prevents the cause? what signal would allow it to be spotted early? who takes charge, by when? Some change the plan (added milestone, preliminary trial, stop criterion), others call for monitoring.
7. Keep and reopen. The list is archived with the plan. It is reread at each milestone review: a cause that materializes without having been monitored is a follow-up failure, not a surprise.

Deliverables: the ranked list of causes, the actions with an owner and a date, the warning signals, and the possible decision to modify the plan or not to launch it.

Examples#

When to use it, when to avoid it#

Use it#

• Before the launch of a project, a migration, an overhaul, a major go-live.
• Before a firm commitment: contract, budget, a date promised to a client.
• When the plan seems “obvious” or reaches unanimity: this is often a sign that no one dares voice their doubts.
• For a decision that is hard to undo (choice of architecture, of vendor).

Avoid it or adapt it#

• Too early: without a precise plan, the causes remain vague (“lack of resources”). Better to wait for a first version.
• Too late: when everything is already committed and nothing can change, the exercise becomes a complaint.
• If the manager or sponsor does not play along: if they react to each cause with a justification, participants fall silent. The manager must listen and take notes.
• For a routine and reversible task: the method is disproportionate.
• If you are trying to estimate a figure (duration, budget): prefer reference class forecasting; the pre-mortem finds causes, it does not give a figure.

Limits and criticisms#

• Little direct evidence. The gain in the quantity of reasons is established in the laboratory; the effect on the success of real projects is mainly reported by practitioners, without a solid comparative trial.
• List effect. Many causes are produced, but nothing forces anyone to act. Without an owner or a date, the list ends up in a drawer.
• Imagination limited to the group's experience. Causes that no participant knows about will not come out: hence the value of inviting people from outside the project.
• Discouragement. A poorly run pre-mortem can demoralize the team or provide a pretext for inaction. It must end on actions, not on fear.
• “Fashionable” causes. The reasons cited also reflect the recent failures each person has in mind (see the availability heuristic).
• It does not replace outside advice. It complements the devil's advocate and the outside view; it does not replace them.

With AI#

Prompts to use#

1. Complete the list of failure causes. Run AFTER the round table, not before: otherwise the AI steers the participants.

Here is a project plan: [objective, scope, schedule, budget, team, dependencies, assumptions].
We are at the planned end date, and the project has clearly failed.
Here is the list of causes already found by the team: [list].
1. Propose the failure causes the team did NOT mention, classifying them: technical, organization, client or sponsor, data, vendors, schedule, people.
2. For each cause, indicate which element of the plan makes it plausible, quoting it.
3. Flag the plan's assumptions for which no verification is planned.
Do not invent any fact about the company: if information is missing, ask the question.

2. Turn the causes into an action plan. For the end of the meeting, from the voted causes.

Here are the failure causes selected by the team, in priority order: [list].
For each, propose: a concrete preventive action, an early observable warning signal, the person or role who must answer for it, and a criterion that would say “we must stop or correct.”
End with a table (cause, action, signal, owner, deadline to be set) and flag the causes that have no realistic action.

Precautions#

• Never submit the plan before the individual writing: you would anchor the team on the tool's causes.
• Generated lists are plausible by construction: they do not prove that the risks exist in your case. Sort them with people who know the field.
• Do not paste a confidential plan, or client or personal data, into an unauthorized tool.

Sources and verification#

• Klein, G. (2007), “Performing a Project Premortem,” Harvard Business Review, September 2007 — the method.
• 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 — prospective hindsight.
• Kahneman, D. (2011), Thinking, Fast and Slow, Farrar, Straus and Giroux — the pre-mortem presented as a remedy for overconfidence (chapter “The Engine of Capitalism”).
• Klein, G. (2003), The Power of Intuition, Currency/Doubleday — presentation of Klein's approach.

See also#