Decision Method
Premortem Analysis for Teams
Imagine your project has failed. Work backward to find the reasons before they happen. The most effective risk prevention technique available.
Last updated: April 2026
What is a Premortem Analysis?
A premortem is a technique developed by psychologist Gary Klein that flips traditional risk assessment on its head. Instead of asking "what might go wrong?", you start with the assumption that the project has already failed completely, and ask "what caused it?" This shift from possibility to certainty changes how the brain processes risk. People who imagine a failure as already having occurred are 30% better at identifying its causes than those asked to speculate about what could go wrong.
The reason premortems work is psychological, not analytical. Traditional risk brainstorming runs into two problems: optimism bias (teams underestimate risk because they are invested in the plan) and social pressure (nobody wants to be the person who "kills the vibe" by pointing out problems). The premortem eliminates both. By declaring that the project has already failed, optimism is irrelevant. And because everyone is asked to explain the failure, voicing concerns becomes the assignment, not the exception.
The output is a prioritized list of failure scenarios with probability and impact ratings, plus concrete mitigation actions assigned to specific people with deadlines. This makes premortems significantly more actionable than standard risk registers, which tend to list risks without ownership or timelines. The method is used in project management, product development, military planning, and healthcare safety. Gary Klein published the approach in his 2007 paper "Performing a Project Premortem" in Harvard Business Review.
When to Run a Premortem
- At the start of any significant project before resources are committed, when there is still time and budget to prevent failures
- Before major product launches or feature releases, where failure is costly and public
- When starting a new business initiative, partnership, or market entry with high uncertainty
- Before significant organizational changes like restructuring, mergers, or process overhauls
- Whenever a team feels overly confident about a plan and nobody has raised a single concern
- To identify project risks before they happen, while prevention is still cheaper than cure
Step-by-step guide
- 1
Set the stage
Describe the project, its goals, timeline, and what success looks like. Then announce the premise clearly: "Imagine it is 6 months from now. This project has failed completely. Not a small setback. Not a delay. A total failure. The product didn't launch. The partnership dissolved. The migration was rolled back. What happened?" The language matters. "Total failure" removes the escape hatch of "minor issue" and forces the team to think about catastrophic scenarios.
- 2
Brainstorm independently
Each team member silently writes down every possible reason the project could have failed. Give 5-10 minutes of quiet writing time. Cover all angles: people (key person leaves, team conflict), process (scope creep, unclear requirements), technology (integration fails, performance issues), market (competitor launches first, demand drops), timing (regulatory delay, dependency slips), and politics (sponsor loses interest, budget gets cut). No filtering. Even unlikely scenarios. The goal is volume.
- 3
Share and consolidate
Go around the room. Each person shares one failure reason per round. The facilitator captures everything on a shared board without judgment or discussion. Continue until all reasons are listed. Combine duplicates. Group similar items. A typical session with 6-8 people produces 15-25 unique failure reasons. The reasons that multiple people independently wrote down are often the most important.
- 4
Rate probability and impact
For each failure reason, the team rates probability (1-5: how likely is this?) and impact (1-5: how bad would it be if it happened?). Multiply P x I to get a risk score (1-25). Sort by highest score. The top 5-7 risks get the attention. Rating reveals something important: a low-probability/high-impact risk (like "key engineer leaves mid-project") might score higher than a high-probability/low-impact risk (like "timeline slips by 2 weeks"). Without scoring, teams focus on what feels likely and ignore what would be catastrophic.
- 5
Build the action plan
For the top 3-5 risks, define concrete mitigation actions. Not "monitor the risk" but "Sarah cross-trains Alex on the payment integration by March 15 so we have backup if either person is unavailable." Each action needs: who is responsible, what they will do, by when, and how you will know it worked. This turns abstract worries into a funded, assigned prevention plan. Schedule a follow-up premortem mid-project to catch new risks that emerged.
Pro tip: Have team members brainstorm independently for 5-10 minutes before anyone speaks. The silent writing phase is where the real value lives. Once someone says "scope creep" out loud, everyone anchors on process risks and stops thinking about people, market, or political risks. Independent brainstorming produces 3x more unique failure reasons than group discussion.
Pro tip: Encourage wild ideas. "The CEO gets arrested" sounds absurd, but it surfaces key-person dependency. "Our office burns down" surfaces disaster recovery gaps. Extreme scenarios often reveal real vulnerabilities that moderate-sounding risks hide.
Pro tip: Do not filter out low-probability items too quickly. Black swan events are individually unlikely but collectively common. A project with 20 risks at 5% probability each has a 64% chance that at least one will occur. The premortem should identify them; the scoring phase decides which ones get resources.
Pro tip: Schedule a mid-project follow-up premortem. Risks change as projects progress. The technology risk you mitigated in month one might be replaced by a market risk that wasn't visible at kickoff. A 30-minute refresh mid-project is worth more than a 2-hour session at the start that's never revisited.
Example
A team planning a new product launch identified these failure reasons:
| Failure Reason | P | I | Score |
|---|---|---|---|
| Supply chain delays | 4 | 4 | 16 |
| Wrong market timing | 3 | 5 | 15 |
| Resource conflicts | 4 | 3 | 12 |
| Budget underestimated | 3 | 4 | 12 |
| Competitor launches first | 2 | 5 | 10 |
| Key person leaves | 2 | 4 | 8 |
Worked Example
A product team at a 35-person B2B SaaS company is planning a Q4 launch of a new analytics dashboard. The PM ran a premortem during the kickoff meeting with 7 team members. She opened with: "It is March. The dashboard launch failed. Our biggest customer canceled because of it. What happened?"
| # | Failure Reason | P | I | Score | Category |
|---|---|---|---|---|---|
| 1 | Key engineer leaves during crunch | 2 | 5 | 10 | People |
| 2 | Data pipeline performance too slow | 4 | 4 | 16 | Technology |
| 3 | Scope keeps expanding after kickoff | 4 | 3 | 12 | Process |
| 4 | Competitor launches similar feature | 3 | 4 | 12 | Market |
| 5 | QA finds critical bugs 2 weeks before launch | 3 | 4 | 12 | Technology |
| 6 | Sales team oversells capabilities | 3 | 3 | 9 | People |
| 7 | Legal review delays API partnership | 2 | 4 | 8 | Process |
| 8 | Design changes requested by CEO | 3 | 2 | 6 | Politics |
The team identified 'Key engineer leaves during crunch' as the #1 risk (probability 2, impact 5, score 10). This surprised everyone because retention wasn't on the project risk radar. The CEO had assumed the team was stable. The premortem forced someone to say out loud what everyone privately worried about. The mitigation was concrete: cross-train two backup engineers on the critical path components before the project entered its intensive phase.
Premortem Analysis vs Risk Assessment Matrix
| Dimension | Premortem Analysis | Risk Assessment Matrix |
|---|---|---|
| Purpose | Discover risks you haven't thought of yet | Quantify and prioritize already-known risks |
| Starting point | "The project failed. What caused it?" | "What risks do we know about?" |
| Key strength | Removes optimism bias, surfaces hidden risks | Structured scoring, visual heatmap |
| Output | Prioritized failure list + action plan | 5x5 heatmap + mitigation assignments |
| Best used | At project kickoff, before resources committed | Throughout project lifecycle |
| Limitation | One-time exercise (snapshot, not continuous) | Only captures risks people already recognize |
Use the Premortem first to discover unknown risks through imagination, then use the Risk Matrix to quantify and prioritize the risks you found. Best used as a two-step workflow: Premortem generates the list, Risk Matrix scores and ranks it.
Common Mistakes
1 Turning it into a blame session for past projects
The premortem is forward-looking. It's about preventing failure in the current project, not assigning blame for past ones. If the conversation turns to "remember when the last migration failed because Dev Ops didn't..." redirect immediately. The prompt is "what WILL cause this project to fail," not "what DID cause the last project to fail."
2 Skipping the action plan step
Identifying risks without defining mitigations is just organized worrying. If the premortem ends with a list of 20 failure reasons and no assigned actions, the team will leave the meeting feeling anxious instead of prepared. The session is not complete until the top 3-5 risks each have an owner, an action, and a deadline.
3 Only including team leads
Team leads see strategic risks (budget, timeline, scope). Frontline team members see execution risks (technical debt, dependency issues, process gaps). Junior developers, QA engineers, and customer support staff often identify the most actionable failure reasons because they work closest to where things actually break. Include 6-10 people from diverse roles.
4 Running the premortem too late
A premortem at the kickoff meeting can prevent failures. A premortem after two months of development can only document risks that are already becoming real. Run it before committing resources, while changes are still cheap. If you discover a fundamental architecture risk in week 1, you can pivot. In week 12, you can only panic.
Try the free interactive tool
Use this method right now in your browser. No signup required, with PDF export.
Frequently asked questions
- A postmortem happens after a project ends (often after failure) to understand what went wrong. A premortem happens before the project starts: you imagine it has failed and identify causes in advance, while you can still prevent them.
- A standard risk assessment asks "what could go wrong?" A premortem reframes this as "the project failed, why?" This psychological shift increases failure identification by 30% because it removes optimism bias.
- Ideally 4-12 people from diverse roles. Include not just team leads but also frontline team members who see different risks. Too few perspectives limit coverage; too many slow down the process.
- Absolutely. The premortem identifies failure scenarios; the risk matrix quantifies them. Use the premortem output as input for your risk assessment matrix for a thorough, two-step approach.
- 4-8 people is ideal. Fewer than 4 limits the diversity of perspectives. More than 8 makes the brainstorming rounds slow and repetitive. Include people with different roles and viewpoints: the optimist, the skeptic, the technical expert, and someone from outside the project who brings fresh eyes.
Related from the blog
Related methods
Scenario Analysis
Think through best case, worst case, and realistic outcomes before you commit. Reduces surprises and prepares your team for different results.
SWOT Analysis
Systematically evaluate Strengths, Weaknesses, Opportunities, and Threats for each option. Gives you the full picture before you commit.
Impact/Effort Matrix
Rate each option by impact and effort to find quick wins and stop wasting resources on low-value work.