How to Run a Pre-Mortem Workshop

Every project debrief uncovers the same uncomfortable truth: the warning signs were there all along — someone just didn't feel safe saying them out loud. The pre-mortem is how you change that, before it's too late to act.

The method is simple in concept and surprisingly difficult to facilitate well. This guide covers the full picture: the psychology behind why it works, how to assemble the right room, a five-phase agenda you can run in 90 minutes, and — the part most guides skip — how to ensure the outputs survive contact with Monday morning.

What a pre-mortem is and why the cognitive mechanism matters

The pre-mortem was developed by research psychologist Gary Klein and introduced to a broad management audience via Harvard Business Review in 2007. The premise inverts the traditional post-mortem: instead of analysing failure after it happens, you ask the team to imagine, before a project launches, that it has already failed badly. Then you work backwards to explain why.

This isn't just a reframe for its own sake. The mechanism is a cognitive phenomenon called prospective hindsight. Humans are considerably better at explaining past events than predicting future ones, because we treat past events as fixed and search more thoroughly for causes. Klein's research found that mentally simulating a failure as already occurred increases the ability to correctly identify reasons for that outcome by approximately 30% compared to standard forward-looking risk assessment — a finding documented in the original HBR piece.

The second mechanism is social. In conventional planning meetings, especially ones where a senior leader is visibly invested in a plan, people suppress doubts to avoid appearing disloyal or obstructive. The pre-mortem reframes pessimism as the task itself. Voicing concerns isn't dissent; it's the deliverable.

McKinsey's research on large capital projects consistently identifies optimism bias — the systematic underestimation of cost and timeline — as a primary driver of project failure. A pre-mortem is a direct structural intervention against that bias.

Gary Klein describes a product team that ran a pre-mortem before launching a new software platform. Within minutes, a junior engineer surfaced a dependency on a third-party API that no one had stress-tested. The assumption was that the API was stable; prospective hindsight surfaced it as a single point of failure. The team built a fallback before launch. The API failed in week two. Without the pre-mortem, that failure would have been a crisis instead of a managed incident.

When to schedule a pre-mortem

Timing matters more than most facilitator guides acknowledge. The optimal window is after a plan is detailed enough to critique, but before resources are fully committed and sunk-cost psychology takes hold. In practice: after a project charter or business case is approved, but before formal kick-off or budget release.

Run it too early and you get abstract worries about hypothetical problems. Run it too late and participants are psychologically invested in the plan succeeding; they'll rate risks as low-likelihood not because they believe it, but because admitting otherwise feels like attacking their own work.

Pre-mortems are also worth running at phase gates in longer programmes — at the transition from discovery to delivery, for example, or before a major go/no-go decision. In those contexts they function as a stress-test of assumptions accumulated during the previous phase, which is a different and valuable use.

Certain project characteristics make a pre-mortem especially worth the time: tight deadlines with little schedule slack, first-time team compositions with no shared working history, high external dependencies, politically sensitive launches, and any initiative built on an assumption that has never been tested in practice. If two or more of those apply, the pre-mortem earns its 90 minutes.

Building the right room

The participant list is a facilitation decision, not an admin task.

The most effective rooms have 6 to 12 participants drawn from three groups. First, the core project team — the people who know the plan in detail and will be accountable for delivery. Second, adjacent stakeholders who will be affected by the project but are not running it; they see risk surfaces the core team is too close to notice. Third, at least one genuine outsider: a colleague from a different function, a recently onboarded team member, or a customer proxy. The outsider's lack of familiarity with the plan is a feature, not a limitation. They ask the questions the core team stopped asking months ago.

The citizen advisory panel example is instructive here. A UK government digital service team preparing to launch a citizen-facing web portal ran their pre-mortem with developers, a policy lead, a content designer, and two members of a citizen advisory panel. The two citizen representatives surfaced the single highest-priority risk identified in the session: the portal assumed all users had a valid email address, but the target demographic — older benefit claimants — had significantly lower email adoption rates. That risk was not on any technical risk register. No one on the core team had thought to look for it.

Research on diverse teams and decision quality consistently shows that cross-functional groups identify a wider range of failure modes than homogeneous ones. A room of engineers surfaces technical risks well. Add a finance analyst and budget risks appear. Add a customer success manager and adoption risks appear. The failure space expands with the diversity of the room.

Hierarchy is the enemy of honest pre-mortems. If the project sponsor is in the room and visibly attached to the plan, junior participants will self-censor. The facilitation response is one of two things: brief senior attendees explicitly in advance to reward dissent rather than signal discomfort with it, or structure the session so the sponsor only joins for the synthesis phase, after the failure identification is complete. Some facilitators remove the sponsor entirely from the ideation phase. I've done this and it works. The sponsor reviews the output, not the process.

An agenda in five phases

A 90-minute pre-mortem for a team of 8 runs like this:

• Minutes 0-10: Briefing. Share the plan — a summary is fine, not every slide. Then set the imaginative frame explicitly: "It is now 12 months from today. This project has failed badly. The launch went wrong, stakeholders are unhappy, and we're trying to understand how we got here." Specificity in the scenario produces specificity in the outputs. Atlassian's facilitator guide recommends concrete framing: not just "the project failed" but "it is the launch date, the system is down, the CEO is on the phone".
• Minutes 10-18: Silent generation. Individuals write their failure causes independently, one per sticky note or card. No discussion. No sharing yet.
• Minutes 18-45: Round-robin harvest. Each person shares one item at a time, rotating until all unique items are on the board. The facilitator clusters as they go.
• Minutes 45-65: Prioritisation. The group dot-votes or scores items by a combination of severity and likelihood. Surface the top 5 to 8.
• Minutes 65-90: Ownership assignment. Each prioritised risk is assigned to a named individual with a specific mitigation action and a follow-up date.

The silent generation phase is the most commonly skipped and the most consequential. Research on nominal group technique — structured independent idea generation before group discussion — consistently shows it produces more ideas and more diverse ideas than open group brainstorming, because it prevents the first vocal participant from anchoring the room. When you skip it, you get a risk list that reflects the most senior or most confident voice in the room, not the full failure space the group collectively perceives.

An optional extension worth adding when time allows: after the failure exercise, run a "pre-parade" with a smaller group. The frame flips — "the project exceeded all expectations, customers love it, and we're trying to understand what specifically made it succeed." This surfaces hidden strengths and unstated assumptions about what good looks like. It also prevents the session from leaving participants with a purely defensive posture about a project they're about to spend months delivering.

Turning surfaced risks into owned actions

The most common failure mode of a pre-mortem is producing a rich risk list that then lives in a shared document and is never revisited. This is the leading reason participants dismiss the exercise as performative. It's also entirely preventable.

Every prioritised risk must leave the room with a named owner, a specific mitigation action, and a date to report back. Not "monitor this" — that is not an action. A specific mitigation means: "Build a fallback API integration by [date], owned by [name]." "Conduct a stakeholder alignment meeting with [person] before [date], owned by [name]."

Ownership should follow the logic of proximity to the failure mode. A technical risk belongs to a technical lead. A stakeholder communication risk belongs to the comms or change lead. When ownership defaults to the most senior person in the room, accountability diffuses and actions stall. The facilitator's job is to resist that default.

The most durable outputs happen when pre-mortem findings are fed directly into existing project governance artefacts: the RAID log (Risks, Assumptions, Issues, Dependencies), the project brief, or the team charter. A European fintech product team did exactly this before launching a new payments feature: their facilitator required every risk to be entered into the project RAID log before participants left the room, using a shared screen. Each item had an owner and a mitigation due date. At the next weekly stand-up, the RAID log was the first agenda item. Three of the top five risks surfaced in the pre-mortem were realised during the project. Because they already had owners and plans, none became a critical incident.

Facilitation mistakes worth avoiding

Beyond skipping silent generation and failing to assign ownership, there are two failure modes that are harder to see until you've made them.

The first is allowing the session to slide into solution mode during the failure-identification phase. As soon as someone says "we could fix that by..." the group's attention shifts from finding problems to defending solutions. The failure space stops expanding. The facilitator's job is to interrupt this explicitly: "We're not solving yet. We're still looking for what could go wrong."

The second is the false-comfort pre-mortem: a session where risks are diligently listed but rated low-likelihood by group consensus to avoid discomfort. This is hard to detect because it looks like a functioning session. The tell is a risk list where every item scores 2 out of 5 on likelihood. Counter it by asking participants to rate risks individually before the group shares ratings, or by naming the dynamic directly: "Our job right now is to make this list as alarming as possible. Probability calibration comes later."

Underlying both of these is psychological safety. Amy Edmondson's research at Harvard Business School — studying hospital nursing units and later business teams — found that units with higher psychological safety reported significantly more errors, but had better outcomes, because errors were caught and corrected rather than concealed. The parallel for pre-mortems is exact: a room where people feel safe voicing uncomfortable concerns produces a more honest and therefore more useful risk list.

Pairing the pre-mortem with scenario planning and three horizons

A pre-mortem examines one failure scenario in depth. That depth is its strength and its limit. For projects operating under genuine strategic uncertainty — where the future itself is contested — pairing the pre-mortem with scenario planning extends its reach considerably.

The sequencing that works: use scenario planning first to identify the key uncertainties driving divergent futures, typically producing 2 to 4 plausible scenarios. Then run a pre-mortem for each high-stakes scenario. The risks that appear across multiple scenarios are your highest-priority items, because they are robust to uncertainty. The risks that appear in only one scenario are contingent and can be monitored accordingly.

The Three Horizons framework adds another dimension. Pre-mortems applied across Horizon 1 (optimise current operations), Horizon 2 (build emerging capabilities), and Horizon 3 (transformative bets) produce qualitatively different risk profiles. Horizon 1 risks tend to be operational and near-term. Horizon 2 risks tend to involve capability gaps and transition costs. Horizon 3 risks tend to involve assumption failures about what the future will actually demand. Tagging risks by horizon during the pre-mortem is a small facilitator move that adds strategic depth to the output without extending the session time.

Workshop Weaver supports all three of these methods, with templates and facilitation guides designed to work together rather than in isolation. If you're running a pre-mortem as part of a larger planning cycle, the scenario planning and three-horizons resources there are worth pairing with this guide.

Running your first one

Identify one upcoming project — a product launch, a strategy pivot, a new team formation — and commit to scheduling a 90-minute pre-mortem before the kick-off. The five phases in sequence: brief the plan and set the failure frame, generate risks silently, harvest by round-robin, prioritise by vote, assign ownership with dates.

The pre-mortem is not a pessimism exercise. It is the most optimistic thing a team can do: surface the problems you can still fix, while there is still time to fix them. The warning signs are almost always there. The method is simply how you get them into the open before the debrief.