Pre-Mortem Analysis: How to Predict Failure Before It Happens (Kahneman’s Method)

Most organisations don’t suffer from bad luck — they suffer from bad foresight. Here’s the framework that changes that.

The Morning I Almost Greenlit a Project I Knew Would Fail

It was early — the kind of early that signals importance, when the coffee is still fresh and the PowerPoint is still convincing.

The project had everything: executive sponsorship, cross-functional buy-in, a timeline that looked ambitious but achievable if you squinted, and a team genuinely energised by the work. It was the kind of proposal that fills a room with the good kind of tension — the kind that feels like momentum.

I had questions. Not vague, background-noise questions. Specific ones. About the third-party dependency that had already caused delays on two adjacent projects. About the customer research that hadn’t actually involved customers. About the single engineer who held the technical understanding of the legacy system the entire launch depended on — and who was due to take her long-deferred sabbatical three weeks before the critical delivery window.

I knew these things. Other people in that room almost certainly knew some of these things.

And yet the energy in the room was celebratory. The VP was nodding. The timeline was already pencilled into the roadmap.

This is not a story about a heroic intervention. I’ve told that version in my Medium piece. This is the operational story — the story of what I started doing differently every single time after that, and the specific tools that made the difference.

This is the pre-mortem framework. The full version.

Part One: The Psychology You Need to Understand First

Before you run a pre-mortem, you need to understand what’s actually going wrong in your team’s thinking — because the pre-mortem isn’t magic. It’s a precise corrective tool for a specific cognitive failure. Use it without understanding the failure it’s correcting and you’ll get theatre, not insight.

The Hindsight Bias Problem

Daniel Kahneman, in Thinking, Fast and Slow, describes hindsight bias with a clarity that should make every business leader mildly uncomfortable:

Once we know how something turned out, our brains retroactively reconstruct the story to make the outcome feel inevitable. We “always knew” the project was too ambitious. We “saw the warning signs” with the difficult hire. The acquisition “obviously” wasn’t going to deliver the projected synergies.

The problem is not that humans do this — it’s a cognitive efficiency mechanism that generally serves us well. The problem is what it produces in organisational cultures:

1. It inflates confidence in future predictions. If our past failures always seemed unforeseeable in advance but obvious in retrospect, we conclude that we’re good at identifying risks in hindsight. We don’t update our planning processes — because the failure was “unforeseeable.” This is circular and catastrophic.

2. It creates accountability diffusion. Post-mortems conducted through the lens of hindsight bias produce findings like “the market conditions changed” and “the timeline was always aggressive given the dependencies.” These are descriptions, not diagnoses. Nobody learns anything. Nobody is responsible for anything specific.

3. It trains smart people to stop speaking up. If you’re in a meeting and you have a well-reasoned concern about a project, and you share it, and it’s either ignored or politely overridden by someone with more authority — and then the project fails, and the post-mortem concludes it was unforeseeable — what have you learned? You’ve learned that your judgment doesn’t materially affect outcomes. The rational response to that lesson is silence.

This is how organisations create the conditions for repeated, predictable failure.

The Planning Fallacy

Hindsight bias has a forward-looking cousin: the planning fallacy. Also documented by Kahneman (and Tversky), it describes our systematic tendency to underestimate the time, cost, and risks involved in completing a future task — even when we have direct experience with similar past tasks going over time and over budget.

You’ve lived this. Every project estimate you’ve given that turned out to be optimistic. Every timeline that slipped. Every budget that had to be revised upward.

The planning fallacy operates through what Kahneman calls the “inside view” — we plan based on the specifics of this project, this team, this context. We don’t naturally incorporate the base rate of how similar projects have gone historically. We believe, at some level, that this one is different.

The pre-mortem is, in part, a forced adoption of the “outside view.” It asks you to look at the project from the perspective of its completion — after it’s failed — and reason backward. This is the psychological mechanism that makes it work.

Why Teams Overestimate Readiness

There’s a third force at work, and it’s less discussed: organisational optimism bias.

Individual overconfidence is well-documented. Group overconfidence is worse. When a team of people who each individually overestimate their own competence gets together and collectively validates a plan, you get a compounding effect that can produce spectacular miscalculations.

Add to this the social dynamics of most planning meetings — where challenging the plan can signal lack of commitment, where the most senior voice tends to set the emotional tone, where dissenters are implicitly (and sometimes explicitly) penalised — and you have a system that is structurally designed to suppress the information it needs most.

The pre-mortem breaks this system. Temporarily. Deliberately. With a very specific kind of structured permission.

Before running the framework: if you’re not sure whether you’re dealing with a planning problem or a decision-making paralysis problem, that distinction matters. The two require different interventions.

Part Two: The Pre-Mortem Framework in Full

This is the version I use. It’s been refined through repeated application across product launches, compliance projects, hiring decisions, strategic pivots, and technology implementations. It works. But it requires fidelity to the process — the individual steps matter, and the order matters.

• Total time: 90 minutes for a medium-complexity project. Allow up to 2 hours for high-stakes decisions.
• Minimum viable group size: 4 people. Maximum effective: 12. Above 12, split into groups and synthesise.
• Facilitation: Ideally someone who is not the project lead and is not the most senior person in the room. An external facilitator is valuable for high-stakes decisions precisely because they have no stake in the outcome.

Phase 1: Preparation (Before the Session)

Send participants a single-page brief 24–48 hours before the session. Include:

• A clear description of the project/decision being pre-mortemed
• The specific “failure scenario” framing you’ll use
• The instruction: “Come with your honest concerns, your quiet doubts, and your half-formed worries. This is the time for them.”

Do not send detailed planning documents. You want people thinking about the project holistically, not locked into the current plan’s framing.

Why the advance notice matters: The pre-mortem’s best insights often come from the things people have been privately worried about for weeks. The 24-hour notice gives those concerns time to surface fully before the session.

Phase 2: Setting the Scene (5–7 minutes)

Open the session with precision. The exact framing matters.

What not to say: “Let’s think about what might go wrong with this project.”

This activates defensive optimism. “Might go wrong” implies it probably won’t. People will offer token concerns and then reassure themselves.

What to say: “It is [specific future date — e.g., October 15th]. [Project Name] has failed. Completely. The launch was a disaster / the audit failed / the hire didn’t work out. We are doing a retrospective. The project is over. I need to understand what happened.”

Use past tense. State the failure definitively. The psychological shift from “might fail” to “has failed” is the engine of the entire exercise.

Add: “There are no wrong answers here. In this room, for the next 90 minutes, pessimism is the job.”

Phase 3: Individual Silent Reflection (10–12 minutes)

Everyone writes their failure reasons individually, privately, in silence.

This step is non-negotiable and widely skipped. Do not skip it.

Group brainstorming — the default — produces anchoring, social conformity, and status-driven filtering. When the project lead speaks first, everyone’s thinking shifts toward their frame. When the VP nods at one item, it becomes more real than the items that didn’t get the nod.

Silent individual writing before group sharing equalises the room in a way that no facilitation technique can replicate.

Prompt: “Write down at least five specific reasons why [Project Name] failed. Be as specific as you can. What went wrong? Whose assumptions were incorrect? What dependencies broke down? What was overlooked? What was known but not acted on?”

Push for specificity. “The timeline was unrealistic” is a start. “The timeline assumed the third-party API integration would be complete by Week 4, but that integration had already slipped twice on Project Atlas and there was no evidence the vendor’s delivery pace had changed” is useful.

Phase 4: Round-Robin Sharing (20–25 minutes)

Go around the room. One reason per person per turn. No commentary, no discussion, no dismissal.

The facilitator’s only job here: capture everything, keep the pace moving, enforce the “no dismissal” rule.

The no-dismissal rule in practice: This means that when someone says “I think the CEO will lose interest and deprioritise this after Q1,” and the room’s instinct is to protect the project’s political legitimacy, the facilitator writes it down and moves on. The evaluation of that risk comes later.

Continue the round-robin until every reason has been shared. This typically takes 3–4 complete rounds for a complex project.

Common facilitation trap: The first round surfaces the “safe” concerns — timeline, budget, resourcing. The second and third rounds are where the real intelligence emerges: assumptions that haven’t been validated, dependencies that haven’t been stress-tested, cultural dynamics that have been actively suppressed.

Don’t let the session end after the first round.

Phase 5: Clustering and Pattern Recognition (15 minutes)

Move everything visible — whiteboard, digital board, or printed sheet on the table — and group the failure scenarios into clusters.

Common clusters I consistently see: assumption risks (things the team believes to be true but hasn’t validated), dependency risks (things outside the team’s control that the project relies on), people and culture risks (dynamics within or between teams that could undermine execution), process risks (steps or systems that are insufficiently robust), and external risks (market, regulatory, competitive, or environmental factors).

Name the clusters yourself initially, then invite the group to challenge or refine the naming. The naming matters — it creates the frame for action planning.

Phase 6: Risk Ranking Matrix (15 minutes)

For each cluster, score two dimensions on a 1–5 scale:

Scoring guidance: Immediate action applies to scores of 12 or above — this risk needs a mitigation plan, an owner, and a deadline before the end of this session. Monitor with owner applies to scores of 6–11 — named owner and specific review date. Log and review applies to scores below 6 — documented in the pre-mortem record, reviewed at the next project checkpoint.

The precise scores don’t matter. The relative ranking does. You’re not doing actuarial risk modelling — you’re achieving structured consensus about which risks are serious enough to act on before the project moves forward.

Phase 7: Action Planning (20 minutes)

For each “immediate action” risk: four questions, answered before the session ends.

• What is the specific mitigation? Not “address the customer assumption risk.” “Conduct 10 structured customer discovery interviews using the JTBD framework before the end of sprint 4.”
• Who owns it? One person. Not “the product team.” One name.
• What is the deadline? A specific date. Not “before launch.” October 14th.
• How will progress be visible? Where will this appear so it can’t be quietly dropped? Sprint review? Leadership update? Pre-mortem follow-up session?

Vague action items are how pre-mortems die. They produce a satisfying document, a sense of having been thorough, and then absolutely no change in how the project runs.

Phase 8: Documentation and Distribution (48 hours after the session)

The pre-mortem output is a living document, not a filed record.

What the document should contain: the full failure scenario list (unedited — the unvarnished version), the risk ranking matrix, the action items with owners and deadlines, and a review schedule.

What the document should do: It should appear in the next project planning meeting. The action items should have been actioned or escalated. The risk rankings should be referenced in project updates.

If the pre-mortem document never appears again after the session, the session was valuable but insufficient. The pre-mortem’s ROI is entirely downstream of the actions it produces.

Part Three: Three Extended Case Studies

The following case studies are the full operational versions of examples I reference in condensed form in my Medium article. That article provides the strategic and psychological framing. This is the gritty detail — the politics, the resistance, the specific turning points.

Case Study 1: The Product Launch That Nearly Launched to Nobody

The context: A mid-sized software company, a product team of eight, and a B2B SaaS product that had been in development for 14 months. The team had done everything “right” by their organisation’s standards: extensive internal research, multiple iterations of the product, strong internal demo performance, positive feedback from the sales team.

The VP of Product wanted to launch in Q2. The engineering lead was confident the build was solid. The commercial team was already in conversations with potential enterprise clients.

The pre-mortem was requested — reluctantly — by the Head of Product Operations, who had a quiet, persistent concern she couldn’t quite articulate.

The session: The failure scenario: “It is November 30th. We launched in Q2. The product has been live for four months. We have acquired exactly six customers, three of whom signed up because of pre-existing relationships with our sales team. We are not on track to hit Year 1 targets. What went wrong?”

The first round surfaced expected concerns: the pricing model, the sales cycle length, the competitive landscape.

The second round produced something more uncomfortable. Three separate team members, in three separate turns, independently identified the same thing: they had no validated evidence that the target buyer experienced the problem as urgent. They had evidence the problem existed. They had no evidence the problem ranked in the buyer’s top-three pain points — which, in enterprise B2B, is effectively the threshold for budget allocation.

One engineer added: “We’ve done user research with product people who already love the concept. We haven’t done research with the finance or operations leaders who will actually approve the purchase.”

The fourth round — the round most teams don’t reach — produced the most useful insight: a salesperson noted that in every conversation he’d had with prospective clients, the most common response was “this is interesting, we’ll keep an eye on it.” Not “this solves a problem we’re actively trying to solve.” Interesting.

The turning point: The VP of Product, who had been quiet for most of the session, said something genuinely brave: “I think we’ve been building for the user who would love this, not the buyer who would fund it. Those might be different people.”

They were different people.

What happened: The launch was delayed by six weeks — not to do more building, but to do the research that should have preceded the building. Twenty-two structured interviews with economic buyers (VP Operations, CFO, COO) across the target segment revealed that the problem the product solved ranked, on average, sixth in the list of operational priorities for the target buyer. The existing workflow workarounds were “good enough.” However, two of the twenty-two interviews revealed a related but distinct problem that did rank in the top three — one the product, with a modest pivot, was well-positioned to address.

The outcome: The product launched six weeks late, repositioned around the validated urgent problem. In Year 1, it hit 71% of original targets. That sounds like underperformance until you consider: the original launch would likely have hit single-digit percentages of targets, and the team would have spent 18 months trying to diagnose why.

The pre-mortem is one diagnostic tool in a broader set. If you’re assessing where your career sits right now — not just a single project — the Mid-Career Experience Audit works through a similar structured examination, applied to your professional situation rather than a specific plan.

The lesson: The pre-mortem didn’t surface information nobody had. The salesperson’s observation about “interesting, we’ll keep an eye on it” had been in his head for months. The pre-mortem created the conditions under which those observations could be treated as strategic intelligence rather than background noise. It didn’t change the quality of information the team had. It changed the quality of attention they paid to it.

Case Study 2: The “Bulletproof” Compliance Project That Nearly Broke

The context: A financial services organisation. Regulatory deadline approaching. A compliance programme that had been running for 18 months, led by a team of experienced professionals who had navigated similar programmes before.

The collective confidence in the team was high. Warranted, even — these were genuinely expert people. But expertise, paradoxically, is one of the most reliable producers of overconfidence. When you’ve done something many times and it’s gone well, you stop actively questioning your assumptions.

The phrase I heard in the first planning meeting: “The process is watertight.”

The session: The failure scenario: “The audit has failed. The regulator has identified critical gaps. We are facing enforcement action and reputational damage. What went wrong?”

The first round was defensive. The second round started surfacing the edges. A process analyst noted she wasn’t entirely sure how a specific legacy workflow had been adapted to meet the new requirement — she’d been told it had been handled, but she hadn’t seen the documentation.

A senior compliance officer admitted that one element of the programme relied on the institutional knowledge of a colleague who had been in the role for twelve years and who was the only person who fully understood how two critical systems interacted.

A junior team member — the only person in the room who had been with the organisation for less than two years — said something that caused a visible shift in the room: “I’ve been trying to document the end-to-end process for onboarding, and I keep hitting steps where the answer is ‘ask [name].’ There are at least seven of those steps. I don’t know what we do if [name] isn’t available.”

The third round produced something nobody had named at all: Legal, Operations, and IT had materially different understandings of what “audit-ready” meant in practical terms. None of them was wrong. They had simply never compared definitions.

The risk ranking — three highest-scoring risks:

• Tribal knowledge concentration (Likelihood: 4, Impact: 5, Score: 20) — The twelve-year employee was due to begin long-deferred annual leave during the final four weeks before the audit.
• Cross-functional definition misalignment (Likelihood: 5, Impact: 4, Score: 20) — Legal, Operations, and IT had never jointly reviewed their understanding of “audit-ready.”
• Undocumented legacy processes (Likelihood: 4, Impact: 4, Score: 16) — At least four process steps relied on institutional knowledge that had never been formally documented.

What happened: Two weeks were spent in knowledge transfer sessions with the twelve-year employee, producing documented process maps. A joint “audit readiness definition” workshop was held with Legal, Operations, and IT — three hours that uncovered four substantive gaps where different teams believed another team “owned” a specific requirement, with the result that nobody was actively managing it. The undocumented legacy processes were formally mapped — a two-week exercise that revealed three of the four processes had been performed slightly differently by different staff members for years, with no one aware of the inconsistency.

The audit: Passed. One minor observation, which had been identified in the pre-mortem risk ranking and monitored but not fully resolved before the deadline.

The lesson: Expert teams don’t fail because of incompetence. They fail because expertise creates the comfortable illusion that the plan doesn’t need to be interrogated. The most dangerous phrase in any planning meeting is “the process is watertight.” It means nobody has pressure-tested it recently.

Case Study 3: The Leadership Hire That Almost Went Wrong for All the Right Reasons

This one is the hardest to write. Not because the outcome was bad — it wasn’t. But because the pre-mortem in this case surfaced something that I had to look directly at in myself.

The context: A senior leadership hire. Strategy Director. We had a strong field of candidates and a clear finalist. She was, by any conventional measure, excellent: broad strategic experience, strong commercial instincts, impressive track record in scaling functions, exceptional interpersonal presence. Every person who interviewed her came out of the conversation positive. Several came out evangelical.

Including me. I had found her thinking genuinely impressive. I had, by the third interview, largely stopped critically evaluating her and started imagining the future she was describing. That, I later realised, was the halo effect in real time.

The session: The pre-mortem prompt: “It is 18 months from now. [Name] has left the organisation. The relationship was unsuccessful. We’re doing a retrospective. What went wrong?”

This is an adapted version of the standard pre-mortem. It’s harder to run for a hiring decision because people have a personal relationship with the candidate by this point. The first round was thin — vague concerns about onboarding and cultural integration.

The second round was more honest. Several people noted that she had asked disproportionately detailed questions about headcount approval thresholds and budget authority during the interview process. In isolation, this seemed like diligence. Collectively — once four people named it independently — it started to feel like a pattern.

One interviewer said something that crystallised it: “When I think about the organisation she’s come from versus ours, I think she’s used to operating with a level of autonomy that we don’t currently have at that level. I’m not sure she knows that. I’m not sure we’ve told her.”

Another: “Our decision-making culture is consensus-heavy. She’s built her career in fast-moving environments where the senior person’s call is final. Those are genuinely different operating models.”

And then the moment that required the most courage from a colleague: “I think some of us have been won over by her energy and we’ve stopped evaluating the role fit. We’re in ‘how do we land this hire’ mode rather than ‘is this the right hire’ mode.”

He was talking about me. He knew it. I knew it. He said it anyway.

What happened: We didn’t withdraw the offer. But we restructured the role description to make the decision-making model explicit. We had a direct conversation with her about the cultural difference — not “our culture is collaborative” (meaningless) but “here is how a major budget decision actually gets made in this organisation.” We built a formal 90-day alignment process with explicit milestones for understanding the culture, identifying key stakeholders, and aligning on decision-making norms before she began pushing strategic initiatives.

The outcome: She’s been in the role for two years. The first six months were harder than they would have been with a candidate from a similar cultural background. There were moments of friction around decision pace and authority boundaries. But she adapted — partly because the expectations had been set explicitly rather than discovered through failure, and partly because the 90-day process gave both sides the tools to have direct conversations when tensions surfaced.

The lesson: The halo effect is not a character flaw. It is a cognitive mechanism. It is particularly powerful in hiring because the interview process is social, emotional, and reciprocal. The pre-mortem doesn’t eliminate the halo effect. But it creates a specific moment in which the team is required to think critically about a decision they are emotionally committed to. That moment is often sufficient to surface the things they knew but weren’t saying.

Part Four: Templates and Tools

The following are the exact templates I use. Each is formatted as a standalone, copy-pasteable resource. Adapt the bracketed fields to your context.

Template 1: Pre-Mortem Briefing

Send 24–48 hours before the session

Template 2: Session Facilitation Script

Read this verbatim, or close to it

Template 3: Risk Ranking Matrix

Complete during Phase 6 of the session

L = Likelihood, I = Impact

Category options: Assumption risk / Dependency risk / People & culture risk / Process risk / External risk / Knowledge / Technology

Action levels: Score 12+ → Immediate action required before project proceeds | Score 6–11 → Named owner + specific review date | Score 1–5 → Logged, reviewed at next project checkpoint

Template 4: Failure Scenario Prompts

Use these when the room runs dry — typically in rounds 3 and 4

Template 5: Action Item Format

Complete one of these for every high-priority risk

Part Five: The Hard Truth About Organisational Blind Spots

Most operational guides leave this part out. I’m including it because without it, the framework above is incomplete.

The pre-mortem is a powerful tool. It is not sufficient on its own. For it to surface the real concerns rather than the safe ones — for it to produce action rather than theatre — several conditions need to be true about your organisation first.

1. Psychological safety is a prerequisite, not an outcome. The pre-mortem creates temporary structural protection for dissent. It does not create underlying safety. If your culture actively punishes people who raise inconvenient concerns — and most cultures do, more than their leaders recognise — the pre-mortem will produce a sanitised conversation. The pre-mortem is most valuable in organisations that have already done some work on psychological safety. It is most needed in organisations that haven’t.

2. The most important person in the room must participate last. If you are the most senior person in a pre-mortem session and you speak first, you contaminate the process. Your assessment of the failure scenarios becomes the frame through which everyone else evaluates their own contributions. The most powerful thing a senior leader can do in a pre-mortem: write your reasons privately, stay quiet during round-robin, and speak toward the end. This requires ego subordination that is structurally counter to most senior leadership roles. Do it anyway.

3. Most failures persist because they benefit someone. This is the most cynical insight I have, and I believe it completely. Projects that everyone knows will fail continue because they provide cover for a decision that’s already been made. The pre-mortem surfaces these dynamics. It cannot resolve them. Resolving them requires something the pre-mortem cannot provide: the institutional will to act on what you’ve found, even when acting is costly.

4. Normalising dissent is a long-term project. The first time you run a pre-mortem in an organisation that hasn’t run one before, it will feel uncomfortable. The fifth time, the culture will have shifted enough that people come prepared to be honest. The tenth time, honesty will feel like the norm rather than the exception. The ROI of the pre-mortem is not the single session. It is the cultural change that comes from making structured dissent a repeatable, normalised practice.

A Final Word

I started this guide with a meeting where I stayed silent.

I’ve run hundreds of pre-mortems since then. Some of them produced dramatic course corrections. Some confirmed that the plan was sound and the team’s confidence was justified. Some surfaced information that was uncomfortable and went unacted upon — because the will wasn’t there, or the power dynamics were too entrenched, or the deadline was too close.

I can’t promise you that the pre-mortem will always produce the outcome it should. Organisations are human systems, and human systems are imperfect.

What I can tell you is this: the pre-mortem will always produce better information than planning without one. Whether your organisation acts on that information is a separate question. But you will not be able to say, afterward, that you didn’t know.

That’s something. In my experience, over time, it becomes quite a lot.

For the leadership-focused strategic frame — including a sharper narrative breakdown of the three case studies and the psychological principles behind why most leaders avoid this — read the companion piece on Medium. Both posts are designed to deepen each other. Start here for the tools; go there for the thinking.

→ Read the companion article on Medium

Over to you:

What’s the highest-stakes project your organisation is currently running — and when did you last create a structured space for someone to say it might fail?

Leave a comment below. I read them all.