Skip to content
Log in
← Glossary

project pre-mortem

Also called: pre-mortem, premortem

A planning session where the team imagines the launch date has passed and the project has failed, and each person writes down why. The reasons go straight into the risk register with owners and triggers, so the exercise changes the plan rather than the mood.

A pre-mortem is a short planning session in which the team imagines that the project's deadline has passed and the project has failed, and then explains why. Instead of asking "what might go wrong?", it states the failure as a fact: "It is two weeks after launch. It went badly. What happened?" People find it easier to give reasons for something that "already happened" than to forecast trouble, and nobody looks like a pessimist for naming one.

The format matters more than the length. Half an hour is enough: set the scene, then everyone writes their reasons alone for a few minutes before anyone speaks, so the most senior or loudest person does not set the list. Then read the reasons out one per person per round, merge duplicates, and look for the ones nobody has written down before.

The session is only useful if it changes the plan. Every new reason becomes a register row written as cause, event and consequence, with an owner, a trigger and a next action. A pre-mortem that ends with a good conversation and no new rows has changed the mood, not the project.

Run it once the plan exists but before the big commitments are made, and again when the situation changes a lot. It is especially good at surfacing risks that feel too ordinary to mention (outages, people's other jobs, holidays) and quality failures that only show up when real users arrive.

Example

Klasna's physics team runs a 30-minute pre-mortem on a call in December: "It's 2 March 2027. The physics launch failed. Write down why." Five minutes of silent writing produce reasons such as:

  • "Lessons kept being cut by outages and alerts in the evening, and families gave up."
  • "Evening slots were full by mid-February; new families waited and booked elsewhere."
  • "Tutors found mistakes in the practice sets in February."
  • "The diagnostic test didn't work well on phones."

The first two were missing from the team's 40-line list. Each becomes a register row; for example: because vetted tutors teach at school by day, evening slots may be full by mid-February, so new families would wait over a week for a first lesson and some would not book: possible (50 %), owner Roman, trigger "fewer than 100 free evening slots a week confirmed by 15 January", next action "ask each tutor for February evening slots in writing this week". The practice-set reason turns into a sample check: a second tutor solves the first ten tasks of every topic as soon as it is drafted.

The phone reason is the one the team underweighted: in February only 35 % of tests started on phones were completed, against 64.71 % on computers, and phones were 67.92 % of all starts. A pre-mortem reason is a hypothesis; it pays off only when it gets an owner and a check date.

Common mistakes

  • Discussing before writing. If people speak first, the first confident voice sets the list; write alone, then share.
  • Ending without register rows. Every new reason needs an owner, a trigger and a next action, or nothing changes.
  • Running it too late. A pre-mortem a week before launch finds risks you can no longer afford to address.
  • Turning it into blame. It imagines a failure of the plan, not of a person; reasons about people become reasons about information and process.
  • Collecting only dramatic causes. The ordinary ones (connections, evenings, phones) are often the ones that actually happen.

Learn it in the course