事前驗屍法：團隊引導指南

For me, the pre-mortem method is the most underrated meeting in everyday project work. We all run retrospectives, and most teams now hold postmortems after incidents. Both share the same catch, though: they happen once the damage is done. A pre-mortem flips the order. Before the project starts, the team acts as if it has already failed and then looks for the reasons why.

It sounds like a game, yet it is one of the cheapest tools against blind spots that I know. In this guide you get a complete 60-minute agenda, an opening script to read aloud, prompts for the moment the room goes quiet, a template for the follow-up and the typical mistakes that make the method fail in practice.

In short

In a pre-mortem, a team imagines that its planned project has already failed and collects the most likely causes, first in silence and then together. Because failure is taken as a given, people voice concerns they would keep to themselves in a normal risk review. The biggest pitfall is the missing follow-up: without owners, dates and early warning signs, it stays a pleasant chat.

What you will learn in this article

• Why looking back from an imagined future surfaces more risks
• A practical 60-minute agenda with timings and an opening script
• Prompts that get a stalled session moving again
• How to turn causes into actions with owners and early warning signs
• Which mistakes turn a pre-mortem into a box-ticking exercise

What is the pre-mortem method?

Psychologist Gary Klein popularised the term in 2007 in a short piece for the Harvard Business Review. The idea: before a project kicks off, the team meets and gets a single instruction. We are a few months in the future, and the project has failed spectacularly. Now everyone writes down why it happened.

The name is a play on the post-mortem, the medical examination after death. There you ask what the patient died of. In a pre-mortem the patient is still alive, and that is exactly why you can still help. In software teams you mostly know the postmortem as the review after an incident. The pre-mortem is its counterpart for the planning phase.

Notice how this differs from a classic risk analysis. There, the question is usually “What could go wrong?”. That invites cautious, abstract answers (“The schedule is ambitious”). In a pre-mortem the failure has already happened. So the question becomes “What went wrong?”, and suddenly people tell stories with concrete causes.

Why the shift in perspective works

Klein draws on research into so-called prospective hindsight, looking back from an imagined future. A frequently cited 1989 study by Mitchell, Russo and Pennington suggests that people come up with more explanations for an event when they treat it as having already happened rather than as merely possible (overview on Wikipedia). Our minds are simply better at telling stories about the past than at reasoning about probabilities.

The second effect is social, and in teams I consider it even more important. Nobody wants to be the one slowing things down in a planning meeting. Anyone who voices doubts can easily come across as disloyal to the plan, to the manager or to the colleague who designed the architecture. In a pre-mortem, doubting is the assignment. Whoever finds the best reason for failure has done the exercise best. That brings knowledge to the table which would otherwise only surface in hallway conversations.

The method also counters the excessive optimism that Daniel Kahneman describes at length in “Thinking, Fast and Slow”. Teams that have just agreed on a plan almost always underestimate duration and risk. Kahneman explicitly names the pre-mortem there as a remedy, because it briefly lifts the group pressure towards agreement.

When a pre-mortem is worth it

Not every task deserves a full hour of doom and gloom. I would use the pre-mortem method whenever failure would be expensive and the team can still influence the plan. A few examples for orientation:

The best moment is shortly after the plan is set but before the first big decisions are put into action. Run the pre-mortem too early and there is nothing to doubt yet. Hold it too late and the key decisions are already made, so the session only produces frustration.

Preparation: what to settle before the session

Preparation takes half an hour at most, yet it decides whether anything useful comes out at the end. Settle these points beforehand:

• Participants: everyone who will deliver the project or is strongly affected by it. Five to ten people work well. Deliberately invite someone from operations or support, because they know the spots where plans tear in reality.
• Facilitation: ideally someone who is not responsible for the plan. If you as team lead designed the plan yourself, hand over facilitation or at least say openly that today you are only listening.
• The scenario: pick a specific date and a specific failure, for example “It is 31 March, the migration has been called off and we are back on the old system”. The more tangible the picture, the more concrete the answers.
• Materials: on site, sticky notes and a wall; remotely, a whiteboard with two empty areas: “Reasons for failure” and “Actions”.
• Context up front: send the current plan round a day before so that nobody has to start reading during the session.

Running the pre-mortem method in 60 minutes

The following agenda is a variant that sticks to Klein’s core idea and adds a clear voting step and an action round. Timings are guidelines for seven to eight people. With larger groups, the sharing round is what grows the most.

The agenda at a glance: from the scenario through silent writing to actions with owners.

1. Set the frame (5 minutes): briefly explain what this is about and what will happen with the results. Stress that the focus is the plan, not people.
2. Read the scenario (2 minutes): read the failure scenario aloud, ideally word for word and without softening it. You will find a suggestion in the next section.
3. Write silently (8 minutes): everyone writes down, on their own, every reason why the project failed. One note per reason. No talking, no questions.
4. Share in turns (15 minutes): each person names exactly one reason per round until all notes are on the wall. Whoever’s turn it is reads aloud. Everyone else listens and does not discuss yet.
5. Cluster (8 minutes): group similar reasons together and give each cluster a short name.
6. Vote (5 minutes): everyone distributes three dots across the clusters they consider most likely and most damaging.
7. Actions for the top 3 (15 minutes): for each of the three strongest clusters, agree on a countermeasure, an early warning sign, an owner and a due date.
8. Wrap up (2 minutes): summarise briefly when you will review the actions again, and thank everyone for their openness.

Silent writing is the most important step, and at the same time the one facilitators most like to cut short. Keep it anyway. As soon as people start by talking, the loudest or most senior voices set the direction, and quieter colleagues end up writing down only what has already been said.

Opening script to read aloud

The opening sets the tone. You can use this text as it is and adapt it to your project:

Imagine it is 31 March. We are sitting in this room again, and the project has failed. Not slightly late, but properly failed: we pulled the plug. You now have eight minutes to write down what happened. Each reason on its own note. There are no wrong answers, and nobody has to justify their reasons. The more uncomfortable, the more valuable.

The sentence “The more uncomfortable, the more valuable” is not a detail. It explicitly gives permission to write down political or personal reasons too, such as “We did not dare to say no to the business side”.

Prompts for when the session stalls

Sometimes, after three minutes, only the usual technical suspects come up. Targeted prompts from areas nobody is thinking about can help. I would not hand them out in advance but drop them into the room when needed:

• Technology: which assumption about a system turned out to be wrong? Which dependency was documented worse than expected?
• Interfaces: which other team did not deliver on time, and why did we notice too late?
• People: who dropped out in the middle of the project, and what knowledge only that person had?
• Decisions: which decision did we postpone until it was too late?
• Stakeholders: whose expectations did we misjudge?
• Operations: what happened in the first week after go-live that we had not tested?
• Communication: what did some of us know early on but never said out loud?

The last question is the most honest one and usually the most productive. It only works, however, in a team where speaking openly carries no penalty. I describe how to build that foundation in detail in my guide to psychological safety in teams.

Follow-up: turning reasons into actions

Many pre-mortems end with an impressive wall of sticky notes, and then nothing happens. To prevent that, each of the top clusters gets a row in a simple table. The most important part is the early warning sign: an observable event that tells you the feared scenario is becoming reality.

Early warning signs have a big advantage over plain actions. You can check them in two minutes in the sprint review or the weekly: “Has any of our signs occurred?” That turns a one-off exercise into a small, ongoing risk radar.

Also schedule a date right away to look at the list again, for example after a third of the project’s duration. And once the project is finished, a look back in the retrospective pays off: which reasons from the pre-mortem actually occurred, which did we prevent, and what did we miss entirely?

Facilitating a pre-mortem remotely

Distributed teams can use the pre-mortem method just as well, sometimes even better. The silent phase almost runs itself remotely, because everyone is sitting at their own screen anyway. A few adjustments still help:

• Have people write their notes hidden at first during the silent phase, if your whiteboard supports it. Otherwise everyone reads along with the first entries and writes similar reasons.
• Cameras on is more helpful here than in many other meetings, because hesitation and nodding are important signals.
• In the sharing round, call names in a fixed order instead of waiting for people to speak up.
• With more than eight people, plan 75 minutes and take a short break after clustering.

For teams across several time zones, the silent phase can even run asynchronously: the scenario goes out the day before, everyone adds their reasons by a fixed time, and the joint session starts straight with clustering. You lose some spontaneity, but you often get more thorough answers.

Common pre-mortem mistakes

The pre-mortem method is simple but very sensitive in a few places. These are the five spots where I would be especially careful.

The manager defends the plan

As soon as the most powerful person in the room answers a reason with “We already thought of that”, the exercise is over. Everyone realises that criticism is not welcome after all. As a team lead, your most important job on that day is to listen, say thank you and ask questions. Justifying yourself is off limits.

The scenario is too soft

“Imagine things did not go all that well” produces answers like “We were a bit slower”. Only a clear failure with a date forces real causes. Dare to paint the picture drastically.

Discussion before collection

If every reason is commented on immediately, the session never reaches the uncomfortable points. Collect first, then cluster, then discuss. This order is the heart of the format.

No follow-up

A pre-mortem without owners and dates costs more than none at all. The team has invested an hour, laid its concerns open and then sees nothing happen. Next time, nobody will honestly write down what they think.

The pre-mortem turns into a tribunal

Reasons such as “Colleague X modelled the database wrong” target people. Reword them together until they describe the situation, for example “The data model was decided without a review with operations”. It is the same attitude as in the feedback guide: concrete behaviour and impact instead of judgements about people.

My take

I consider the pre-mortem method one of the tools with the best effort-to-benefit ratio, especially in technical teams. Developers often see risks very early but do not raise them, because the deadline has already been communicated or because they do not want to be seen as naysayers. The format gives them a legitimate stage for it.

Two limitations belong to the picture, though. First, a pre-mortem only finds risks that somebody in the room at least suspects. It does not uncover truly unknown problems, which is why it replaces neither tests nor load tests nor architecture reviews. Second, the method can backfire if used too often. Rehearsing failure before every little thing creates paralysis instead of clarity. One pre-mortem per larger project is enough.

What I like best about the pre-mortem method: it is a good litmus test for team culture. If the silent phase only produces reasons like “unclear requirements” and “not enough time”, the trust needed for uncomfortable truths is usually missing. That is a valuable signal that goes beyond the individual project.

FAQ

How long does a pre-mortem take?

For five to eight people, 60 minutes is enough for the pre-mortem method. With larger groups, or remotely with many participants, plan 75 to 90 minutes so that the action round does not get squeezed.

Who should facilitate a pre-mortem?

Ideally someone who does not own the plan, for example a Scrum Master, an agile coach or a manager from a neighbouring team. That way nobody in the room feels personally attacked when weaknesses of the plan come up.

What is the difference between a pre-mortem and a post-mortem?

A post-mortem looks back after an event, such as an incident or the end of a project. A pre-mortem takes place before the start and uses imagined hindsight to find risks while the plan can still be changed.

Can you combine a pre-mortem with Scrum?

Yes. It fits well before a new release, a larger epic or at the start of quarterly planning. The actions become backlog items, and you check the early warning signs in the sprint review.

Your next step

Pick the next project in your team where failure would really hurt and block an hour for it. Write the scenario with a specific date, use the opening script from this article and schedule the date for reviewing the actions right now. That is all you need to get started.

And now I am curious: have you ever run a pre-mortem, and which reason on the wall surprised you the most? Let me know in the comments.

Sources

• Klein, G. (2007): Performing a Project Premortem. Harvard Business Review, September 2007
• Atlassian Team Playbook: Pre-mortem (agenda, variants for distributed teams)
• Wikipedia: Pre-mortem (origin, link to Mitchell, Russo and Pennington 1989)
• Kahneman, D. (2011): Thinking, Fast and Slow. Farrar, Straus and Giroux

This post was created with AI assistance.

Originally published on sascha-ms.de. On my site you will also find interactive tools like the AWS service finder and the Lambda cost calculator, printable cheat sheets and more articles on serverless, AI in everyday development and leading tech teams: sascha-ms.de/en