A data center migration I helped run early in my career was approved on a plan that everyone in the room believed in. We had a Gantt chart, a rollback procedure, a bridge call scheduled, and a lead engineer who answered every question with a confident number. The project sailed through sign-off in forty minutes. Six weeks later it failed on a dependency nobody had mentioned: a licensing server that lived in the old environment and that three other systems silently phoned home to. When we cut it over, those three systems went dark in the middle of a business morning. The rollback took most of a day. The dependency was not exotic. At least two people in that approval meeting knew about it. Neither said a word, because the meeting was built to confirm the plan, not to attack it.

That morning taught me something I have used in every operations role since, and later in fractional COO work: the time to find the flaw that kills your plan is before you commit to it, and the usual way we run planning meetings almost guarantees we won’t.

The meeting rewards confidence, so the doubts stay home

Watch what actually happens when a team reviews a plan. Someone presents. The leader asks, “Any concerns?” There is a pause. The people who have concerns do a fast private calculation: raising a problem means slowing the room down, looking negative in front of the person who built the plan, and being wrong in public if the concern turns out to be nothing. So the half-formed worry stays in their head. The plan gets approved with its fatal flaw intact, carried quietly by the two or three people who could have named it.

This is not a courage problem you can fix by telling people to speak up. It is a design problem. The format itself punishes dissent and rewards the appearance of alignment. If you want the doubts, you have to build a meeting that makes voicing them the safe, expected, low-cost move. That is exactly what a premortem does.

Flip the question from “could” to “did”

The premortem comes from research psychologist Gary Klein, who laid it out in a 2007 Harvard Business Review piece called “Performing a Project Premortem.” The move is deceptively small. Instead of asking the team what might go wrong, you tell them the project has already failed, completely, and ask them to explain why.

You say it plainly: “It is nine months from now. This project shipped and it was a disaster. Take five minutes and write down every reason it failed.” Then you go around the room and collect them.

The reason this works is not motivational, it is cognitive. It rests on a finding from a 1989 study by Deborah Mitchell, Jay Russo, and Nancy Pennington, published in the Journal of Behavioral Decision Making under the title “Back to the future: Temporal perspective in the explanation of events.” They found that imagining an event as a certainty that has already happened, rather than a possibility that might happen, increased people’s ability to generate correct reasons for the outcome by about 30 percent. Klein named the mechanism prospective hindsight. Our brains are far better at explaining a concrete past than at forecasting an abstract future, so you borrow that strength by pretending the future is already behind you.

“Any concerns?” asks people to speculate, which feels like disloyalty. “Why did it fail?” asks them to explain, which feels like competence. Same information, completely different social cost to say it out loud.

Kahneman kept it in his toolkit for a reason

The technique has a serious endorsement behind it. Daniel Kahneman, the Nobel laureate who spent a career documenting how badly humans judge probability, singled out the premortem in his book Thinking, Fast and Slow as one of the few practical tools he actively recommended. His argument was that once a group has tilted toward a decision, doubts get suppressed and overconfidence compounds; the premortem legitimizes doubt by making the search for problems the explicit purpose of the exercise, and it unlocks the knowledge of people who had quietly concluded the plan was shaky but saw no acceptable way to say so.

That last part is the piece managers underrate. The information you need is almost always already in the room. The licensing server that took down my migration was not a secret. The premortem is not a tool for generating new intelligence. It is a tool for extracting intelligence that your normal meeting format keeps locked up.

Running one on a Tuesday afternoon

You do not need a facilitator or a template to run this. Klein’s version takes twenty to thirty minutes, and I have run it in less. Here is the shape I use before any change big enough to hurt if it goes wrong.

Get the people who actually do the work in a room, not just the leads. The licensing-server knowledge lived two levels below the person presenting the plan. Then:

1. State the failure as a fact. “It is launch day plus ninety. This was a clear failure. We are doing the post-incident review right now.” Say it with a straight face. The certainty is the active ingredient; do not soften it into “imagine if it didn’t go well.”

2. Everyone writes silently first. Two to five minutes, independently, on paper or in a doc. Silent writing before discussion matters because it stops the most senior or loudest voice from anchoring the room. You want the quiet engineer’s list uncontaminated by the VP’s list.

3. Go around and collect one reason each, round robin. One item per person per turn, no debate yet, until the lists are empty. Round-robin collection means the junior person’s concern gets read into the record with the same weight as everyone else’s. That is the whole point.

4. Then, and only then, discuss and act. Group the failures. Pick the two or three that are both plausible and severe. For each, change something concrete in the plan: add a dependency scan, move a checkpoint earlier, assign an owner, build a real rollback test rather than a rollback paragraph.

That fourth step is where most premortems quietly fail. Surfacing the risk feels productive enough that people stop before they act on it. A list of twelve ways the project could die, filed and forgotten, changes nothing. The deliverable is not the list. It is the edits you make to the plan because of the list.

What it catches, and what it won’t

I want to be straight about the limits, because a technique oversold is a technique that gets abandoned after it disappoints once.

The premortem is strong against the failures people can see but won’t say: the known dependency, the deadline nobody believes, the vendor with a history of slipping, the team that is already underwater. It is good at converting private doubt into a plan change. It pairs naturally with the discipline of trusting your team’s track record over its estimates, because the reasons people generate in a premortem are usually grounded in what has actually gone wrong before.

It is weak against failures nobody in the room has the knowledge to imagine. A premortem on a brand-new product in a market you have never served will miss the things you don’t know you don’t know. It also will not save a plan that is being pushed through for political reasons, where the decision was made before the meeting and the premortem is theater. And it is not a substitute for the dull, reliable controls that catch routine error: the checklist for the work your team knows cold, the design that makes the common mistake physically hard to make. Those handle the failures of execution. The premortem handles the failures of judgment, the ones hiding inside a plan everyone has already agreed to like.

There is one more honest limit. A premortem can surface a reason to kill the project, and some managers do not actually want that answer, especially when they have already spent real money or political capital getting the thing approved. If you are going to run one, you have to be willing to act on it, even when acting means walking back something you championed. Pretending to want the bad news while quietly ignoring it is worse than never asking; it teaches your team that dissent is decorative. If you catch yourself reluctant to hear the answer because of what you have already invested, that reluctance is its own warning sign, and the sunk cost sitting behind it is a separate trap worth naming out loud.

Try it on the next decision that scares you a little

You do not have to reorganize how your team plans. Pick the next initiative that matters enough that failure would actually hurt, and spend thirty minutes before you commit asking the room to explain why it died. The first time I ran one properly, after that migration, we caught two things in twenty-five minutes that the normal review had missed twice. One of them would have cost us a weekend.

The plan you are most confident in is the one that most needs this, because confidence is exactly what stops people from telling you what they already suspect. Assume it already failed. Then sit quietly and let your team tell you why.