How to run a pre-mortem: forty-five minutes before you commit

A retrospective asks what went wrong after it has cost you. A pre-mortem asks the same question before anyone has committed, when the answer is still cheap. The method is one sentence: imagine the project has already failed, and write down why.

It works because of how the question is put. "What could go wrong?" invites reassurance; the people who want the project to start are in the room. "It is six months from now and this failed. What happened?" gives everyone permission to say what they already suspect.

When to run one

After the work is understood well enough to plan, and before it is promised. Earlier, and people can only guess. Later, and the answers arrive after the date has been given to a customer.

Not for everything. A two-week change inside one team does not need a meeting to imagine its failure. Run one when the work crosses teams, runs longer than a quarter, or cannot be undone, which is the same test that decides how much process a request needs.

Forty-five minutes, five steps

1. State the failure (2 minutes). "It is the end of March. The migration did not ship, or shipped and was rolled back." Make it specific to this work, and make it total.
2. Write alone (8 minutes). Everyone writes their own reasons for the failure, in silence. This is the step that matters: said aloud, the first reason anchors the rest, and the newest person in the room says nothing.
3. Read out, one each, in turn (15 minutes). No discussion, no defending. Group the duplicates as they come.
4. Pick the ones that would actually sink it (10 minutes). Usually three to five. A reason belongs on the list if it is both plausible and fatal. "People get busy" is plausible and not specific. "The vendor API has no bulk endpoint and we have 400,000 records" is both.
5. Decide what each one becomes (10 minutes). This is where most pre-mortems stop one step short.

What each reason becomes

A pre-mortem that ends with a list on a whiteboard has changed nothing. Each surviving reason turns into one of four things, and each of those has an owner.

• A risk, written as an event with its cost, with a severity and a mitigation. These go into a register that can block the commitment.
• A dependency on another team or a vendor, with the date it is needed by and someone on the other side who knows about it.
• An open question that can be answered before committing. If answering it takes more than a few days, that is a time-boxed discovery, not a risk to carry.
• A change to the scope or the date. Sometimes the honest result is that the work as described will not fit, and the thing to do is cut it or move it now.

One more outcome is legitimate: the pre-mortem finds a reason nobody can mitigate, and the decision is not to start. That is the method working. It is far cheaper than stopping the same project in month four.

The four ways a pre-mortem goes wrong

• Reasons are spoken instead of written. The most senior voice sets the list.
• The list is generic. "Scope creep, unclear requirements, lack of resources." If the same list would fit any project, nobody imagined this one. Ask for the specific version: which requirement, whose time.
• It is run after the commitment. Then every reason is an argument against a decision already made, and people stop offering them.
• Nothing is done with it. No risk is recorded, no dependency is confirmed, the plan is unchanged.

"We found nothing" is an answer

Sometimes forty-five minutes produce no fatal reason. Do not invent three to make the meeting look useful. Record that the question was asked and came up empty; a dimension that was looked at and found clear is different from one nobody looked at, and "no known risks" is a real answer when someone has checked.

If you use DeliverySheet

There is no pre-mortem screen, and the meeting is yours to run. The product is where its output lands. Planning a demand asks four things before it can be committed on the standard path: dependencies, decisions, capacity and risks. Dependencies, decisions and risks can each hold items or an explicit "none known", so an empty section says whether anyone looked; capacity needs a figure from the delivering team. A risk carries a severity and a mitigation, and an unresolved high or critical risk keeps the demand from reading as ready; committing anyway takes a recorded exception. An open question that needs more than a quick answer goes to a time-boxed discovery with its own question and date.