Premortem Workshop Agenda and Facilitation in 45 Minutes

Picture your project six months from now. It failed. Everyone in the room already knows why. They just haven't been allowed to say it out loud until now.

That is the premise of a premortem, and it explains why the exercise works when it works. People on a project usually know where the weak joints are: the vendor nobody trusts, the deadline that assumes nothing slips, the stakeholder who nodded through the kickoff and hasn't replied to an email since. What stops them from saying so is social cost. A well-run premortem removes that cost for 45 minutes. A badly run one adds to it.

This post covers the short version I run most often, the exact wording of the question, and the three situations where I'd tell you not to bother. The premortem method page has the full method reference. The earlier post How to Run a Pre-Mortem Workshop has templates and a longer facilitation script. I won't repeat either here.

What a premortem is and where it comes from

Gary Klein described the technique in a short 2007 Harvard Business Review piece, Performing a Project Premortem. The logic is simple. A postmortem tells you why the patient died, which helps everyone except the patient. A premortem runs the same analysis before the project starts by asking the team to assume it has already failed.

The mechanism is prospective hindsight. Klein cites a 1989 study by Deborah Mitchell, J. Edward Russo and Nancy Pennington which found that imagining an event had already happened increased people's ability to correctly identify reasons for future outcomes by about 30% (HBR). Klein later returned to the idea in a short Edge.org piece on the premortem.

The cognitive trick is half the value. The other half is permission. In a normal planning meeting, the person who raises doubts about a plan everyone has signed off on looks like a pessimist, or like they're attacking the colleague who wrote it. In a premortem, finding fault is the assignment. The quiet engineer who has worried about a single-supplier dependency for three weeks now has a sanctioned slot to write it down.

The 45-minute agenda

Klein's version is brief, and I've found 45 minutes is the right container. Longer and it drifts into a general planning debate. Shorter and you skip the mitigation step, which is the only part that changes anything.

• Minutes 0-5: Framing. Restate the plan in two or three sentences, explain the rules (silent writing first, no rebuttals during sharing), and read the question out exactly as written.
• Minutes 5-15: Silent individual writing. One failure reason per sticky note or per line in a shared doc. No talking.
• Minutes 15-30: Round-robin sharing and clustering. Each person reads one item per round until everything is on the wall. Group similar items into themes as you go.
• Minutes 30-40: Prioritise. A dot vote or a quick discussion to pick the handful of clusters that would hurt most.
• Minutes 40-45: Owners. Each priority cluster gets a named person and a next action with a date.

This is close to the structure in Atlassian's premortem play, which also has people write separately before anything is read aloud. Timebox hard. Premortems go wrong the moment someone challenges a note during sharing ("that won't happen, we've already signed the contract") and the room turns into a defence of the plan. Debate brings back exactly the social pressure the silent step was designed to remove. Park every objection until prioritisation.

I keep this as a saved template in Workshop Weaver with the timings fixed, so the only prep for a new session is a two-sentence plan summary and the invite list. The invite list is the harder of the two, as you'll see below.

The question that makes it work

Klein's original framing runs like this: "Imagine that it is a year from now. We implemented the plan as it now exists. The outcome was a disaster. Please take 5 to 10 minutes to write a brief history of that disaster."

Every phrase in that does work. "As it now exists" stops people from writing about the better plan they'd have preferred. "The outcome was a disaster" is stated as fact. Nobody in the room is predicting failure. They're explaining something that already happened, which is a far easier thing to say in front of your manager. "A brief history" asks for a story with causes and a sequence.

For most projects I shorten the horizon to six months, because a year is too distant for a quarterly roadmap to feel real. I say: "It is six months later and the project has failed. Tell me why." Then I stop talking. Do not soften it with "might have" or "let's imagine some things that could possibly go wrong." A hedged question gets hedged answers.

Weak and strong versions of the question

"What could go wrong?" produces a list everyone has seen before: scope creep, resourcing, communication. Those words are true of every project and actionable for none.

"It failed, tell me why" produces causal chains. On a website relaunch I facilitated, one note read: "Legal review took three weeks because nobody booked it, so content froze late, so QA got four days instead of ten, so we shipped with broken forms." That single note contains an owner, a date and a mitigation waiting to be written. The strong question gets you notes like that. The weak one gets you "timeline risk."

Silent writing and clustering

The silent writing step is the biggest single difference between a premortem and an ordinary risk meeting. Brainstorming research going back to Diehl and Stroebe's work on production blocking finds that people who generate ideas alone and then pool them come up with more and better ideas than the same people talking together (American Psychological Association). In open discussion, people wait their turn, forget their point, and edit themselves based on how the first few answers landed. The first answer usually comes from the most senior person, and the room anchors on it. The same dynamic wrecks prioritisation, which I covered in How to Use Dot Voting Without Getting Groupthink.

Reading anonymously helps. Collect the notes, shuffle them and read them out yourself, or use a shared board with authorship hidden.

Clustering turns a wall of 40 fears into five or six themes. Typical ones are external dependencies, staffing, timeline assumptions, unclear decision rights and adoption. Name the clusters with the group, in their words.

Your job during clustering is neutrality. Resist the urge to fold an odd note into a safer category. If someone writes "the CFO kills this in the Q3 budget review," do not file it under "stakeholder alignment." It is its own cluster. Outliers are often the cause nobody else considered, and they are the first thing a nervous facilitator smooths away.

Turning causes into mitigations with owners

A premortem that ends with a list of causes is half done. Klein's method finishes with the team going back to the plan and changing it based on what surfaced. In practice, every priority cluster leaves the room with four things written next to it:

• The cause, in one sentence
• An early warning sign you could spot before it's too late
• An owner: one named person
• An action and a date

Not every cluster gets fixed, so triage. Causes within the team's control get a fix. Partly controllable ones get a monitoring plan, meaning a leading indicator someone checks every two weeks. Causes outside anyone's reach, like a regulator's timetable, get documented as accepted risks and sent upward so nobody is surprised later.

On the website relaunch, "legal review not booked" got an owner and a booking confirmed by Friday. "Marketing campaign dates assume we ship two weeks early" got a monitoring plan: the PM checks the burn-up weekly and alerts marketing at week six if the gap is still there. That's the line between a premortem and a venting session. Send the owner list out within a few days, or watch it quietly die.

When it turns into a blame session: leadership in the room

The format depends on people naming causes they would normally keep to themselves. Status differences in the room are one of the strongest suppressors of that kind of candour, which sits at the core of Amy Edmondson's research on psychological safety. Put the sponsor who championed the plan in the circle and watch what happens to the list.

The pattern I see most: when a senior leader joins a premortem for their own initiative, the causes drift outward. "Market conditions changed." "A competitor launched first." "IT didn't deliver." The internal decisions that are politically risky to name, like the leader's timeline or the underfunded team, quietly vanish. Sometimes the opposite happens. Someone with a grievance uses the anonymous wall to write "Sarah's vendor choice sank us," and the session becomes a trial.

Two fixes work. Run it without the sponsor and give them an anonymised summary of themes afterwards. Or bring in a facilitator from outside the reporting line who can hold the group to naming decisions without naming people. I also set a rule at the start: write about decisions and conditions, never individuals. "The vendor was selected without a second bid" is a cause. "Sarah picked the wrong vendor" is a grievance. For more on how hierarchy shapes what gets said, read The Org Chart Is in the Room Whether You Invite It Or Not.

When not to run it: no mandate to change the plan

A premortem makes an implicit promise that what people say can still change the plan. Klein places it at the point where a plan is nearly final and has not yet been set in motion. Run it after the budget is signed, the vendor contracted and the launch date announced, and you've asked people to be candid about things they can't touch.

I watched this happen to a team asked to premortem a reorg that had already been announced company-wide. Roles were fixed, contracts drafted, the messaging sent. The team produced a sharp list of failure causes, and almost none of them were actionable. People left more frustrated than they arrived. The next time that team was asked for honest input, they gave polite answers.

Before you agree to run one, ask the sponsor directly which parts of the plan can still change. If the answer is "none," decline. Or run a narrower session on implementation risk and say plainly that the plan itself is off the table.

When not to run it: as a substitute for a risk register

A premortem is a snapshot of what a team can imagine on one afternoon. A risk register is a system, with likelihood, impact, owner and status tracked and reviewed for the life of the project. PMI's guidance on risk management treats risk identification as a continuous process with regular reviews, which a single 45-minute session cannot provide.

The failure mode is predictable. A team runs a good premortem at kickoff, feels responsible, and never looks at risk again. At the midpoint the plan changes, a new dependency appears, a key engineer leaves, and the issues that end up sinking the project are ones that didn't exist when the premortem ran.

Treat the premortem as the best input your register will ever get. Enter every prioritised cluster as a register item. Rerun a short premortem at major milestones or whenever the plan changes substantially. The register carries the list between sessions.

Before your next launch

A premortem has preconditions. You need 45 focused minutes, one precisely worded question delivered without hedging, and a culture where naming a cause does not end a career. Miss any of those and the exercise produces either a generic worry list or an accusation.

For the deeper method reference, go to the premortem method page. For templates and full facilitation scripts, use How to Run a Pre-Mortem Workshop.

Then do this: before your next big launch, block 45 minutes on the calendar. Leave the senior sponsor off the invite list if their presence will change what people write. And do not close the session until every priority cluster has a named owner, an action and a date. Otherwise you've just held a very well-organized complaint session.