The Pre-Mortem: Why Assuming Failure Produces More Honest Planning

You have signed off on the reorg. Three departments fold into two, a layer of management comes out, two teams that have never reported to the same person now will, and the new structure goes live at the start of next quarter. The deck is polished, the leadership team is aligned, and the rollout plan has dates against every step. Near the end of the meeting someone asks the ritual question: what could go wrong? A couple of safe risks get named. People might be unsettled for a while. The handover of one product line is a bit tight. Someone writes them on a risk log and the meeting moves on.

Six months later the reorg is judged a mess. Two senior people you needed have left, a key customer relationship fell through the gap between the two merged teams, and the manager you put over both of them spends every day refereeing instead of leading. None of this was unforeseeable. Half the room had a private worry along these lines on the day you approved it. The worries just never made it onto the table, because the question you asked could not pull them out.

The evidence

The problem is built into the question. “What could go wrong?” asks people to challenge a plan that has already been blessed, in a room full of the people who blessed it, at the exact moment when saying so feels like disloyalty. So you get the safe answers, the ones nobody can be blamed for raising, and the real ones stay in people’s heads.

Change the question and you change what comes back. Instead of asking whether the plan might fail, you state that it has failed. It is a year from now, the reorg did not work, and the task is to explain why. This is the pre-mortem, and the effect it leans on is well documented. Imagining that an event has already happened and explaining it produces substantially more reasons, and more specific reasons, than predicting the same event as a possibility. The increase runs to roughly a third more causes generated, and it holds up as one of the steadier findings in the work on how people reason about events across time. The label for it is prospective hindsight: you are looking back at a future that is being treated as settled fact.

That sounds like a small wording change, and it does far more than the wording suggests. When you ask people to predict a failure, they are pushing against the plan’s own internal logic. The plan already hangs together. It has been argued for, costed, and rationalised, and everyone in the room helped build that story. To name a risk, you have to fight the coherence of the thing. But when the failure is stated as already true, that resistance falls away, because you are explaining a fact rather than arguing the plan might be wrong. Explaining a fact is something the mind does fluently, reaching for cause after cause without having to defend each one.

How it works

Two things shift at once, and they reinforce each other.

The first is cognitive. Forward planning runs on a part of your thinking that is built for narrative and motivation. It wants the plan to cohere, because a coherent plan is one you can commit to and rally people around. That same machinery is terrible at spotting how the plan breaks, because spotting breaks is the opposite of building a story you can believe in. Explaining a past event runs on different equipment entirely, the part that is good at reconstructing how something came apart. The pre-mortem works where willpower and “be more careful” do not, because instead of asking you to be less optimistic it hands the question to the instrument that is actually good at finding faults.

The second is social, and in a reorg it is the heavier of the two. When a group has committed to a decision, several pressures line up to keep doubts quiet: the wish to look aligned, the cost of being the person who is always negative, and the steep gradient that stops a junior voice from contradicting a senior one. The same observation carries a completely different charge depending on the frame. “I don’t think the merged team has enough management bandwidth” is dissent, and raising it marks you as a problem. “The merged team didn’t have enough management bandwidth and the manager burned out by month three” is analysis, offered into a shared exercise where naming the failure is the whole point. You have changed the job from criticising a plan to explaining an outcome, without making anyone braver, and the second job is one people will do honestly.

Once a person is explaining a failure they have been told already happened, the reasons come out without having to be defended, and that is why they say what they were holding back.

How to use it

Run it at the moment the plan feels most solid, which is exactly when your instinct says you can skip it. The reorg that still has open questions invites scrutiny on its own. The one that looks bulletproof is where optimism is strongest and the pressure against doubt is highest, so that is where this earns its keep. The discomfort of opening up a plan everyone already agreed to is precisely the signal that the moment has arrived.

Have people write before they talk. State the failure plainly, give everyone a few quiet minutes, and have each person privately write the reasons the reorg fell apart a year out. The writing-first step matters because it stops the room anchoring on the first thing said and losing every failure mode that does not resemble it. If the most senior person speaks first, you will get variations on their one concern. If everyone writes alone, you get the customer relationship that slipped through the seam, the two people who left because nobody told them where they stood, and the manager drowning in conflict, all at once instead of one at a time. Insist on concrete scenarios. “The integration of the two teams went badly” tells you nothing. “The two teams kept their old tools and the handover of the enterprise accounts had no owner for the first two months” is something you can act on.

Then do the part that separates this from a worry session. A list of failure scenarios with nothing done about them is just structured anxiety dressed up as rigour. Take each scenario and sort it on two axes: how likely it is, and whether you can do anything about it now. The likely and preventable ones become things you change before launch, so you assign an owner to the enterprise accounts today and confirm where the two senior people stand this week. The likely but unpreventable ones become contingency plans you have ready rather than surprises you absorb. The unlikely ones you note and watch. What you walk out with is a shorter list of removable failures and a few prepared responses rather than a darker mood about the reorg, and that list is the entire return on the exercise.

Why it matters

Most planning rests on an unstated assumption: that the way to reach success is to picture it. Set the goal, map the steps, line up the team behind the vision. That produces plans that are coherent and motivating and blind in a particular direction, because the same focus that makes a plan compelling is the focus that cannot see the conditions under which it breaks. A reorg is the sharpest version of this. It is sold internally on a story of a cleaner structure and clearer ownership, and the story has to be confident to win approval, which means the confidence is doing real work right up until it walks you into the failure nobody felt safe naming.

The pre-mortem does not replace any of that, and it is not an argument for pessimism. The teams that build it into how they decide are not gloomier than the teams that do not. They have simply put a moment of honest doubt at the one point where doubt is most useful and most suppressed, and they let people speak in the mode where speaking is cheap. A few minutes spent assuming the thing already failed, asked before you commit rather than discovered after, is about the cheapest insurance a serious decision ever gets.