On this page
A pre-mortem is a facilitated meeting where participants imagine a project has already failed, then identify what went wrong to surface risks in advance. The session takes about 30 minutes, involves small teams for open dialogue, and produces a ranked list of failure scenarios that becomes the foundation for mitigation planning.
- A pre-mortem differs from a post-mortem (analysis after failure) and risk assessment (systematic identification of known categories); it surfaces unexpected failure modes through imaginative group thinking.
- Assemble 5 to 8 people with direct knowledge of the project, including at least one skeptic, and ensure psychological safety so participants voice concerns without fear of dismissal.
- The core technique is asking the team to imagine the project has failed, then spend 10 minutes silently writing down what went wrong before discussing as a group.
- Prioritize risks using a matrix that maps likelihood against impact, then assign each identified risk to an owner with a concrete mitigation step.
- Convert the prioritized list into a risk register and schedule regular reviews to update it as the project evolves and new information emerges.
A pre-mortem is a meeting held before a project begins where the team imagines it has failed, then works backward to identify what caused the failure. The goal is to surface risks that formal risk assessments often miss: the unexpected combinations, the overlooked dependencies, the assumptions no one thought to question. Unlike a post-mortem, which analyzes what actually went wrong after the fact, a pre-mortem is preventive. Unlike a risk assessment, which works through known categories systematically, a pre-mortem uses imaginative group thinking to uncover failure modes the team might not have considered.
The technique is simple enough to run in a single meeting and produces a concrete output: a prioritized list of risks with assigned owners and mitigation steps. It works because it removes the social friction that normally prevents people from voicing concerns early. When you ask "What could go wrong?" in a planning meeting, people hesitate; they worry about sounding negative or undermining confidence. When you ask "Imagine it's six months from now and the project failed completely, what happened?" the psychological frame shifts. You are not predicting doom; you are running a thought experiment. The permission to imagine failure frees people to speak.
What a pre-mortem is and what you need before starting
A pre-mortem is a structured meeting held before a project launches where participants imagine the project has failed, then identify the causes. The output is a list of potential failure modes, ranked by likelihood and impact, with assigned owners and preliminary mitigation steps. The whole session takes about 30 minutes. You need three things to run one: a defined project with a clear scope and timeline, a team with direct knowledge of how the work will be executed, and a facilitator who can keep the group focused and ensure all voices are heard. If the project is still in early conceptual stages and the scope is undefined, a pre-mortem will produce vague results. Wait until you have enough clarity to imagine concrete failure scenarios. If the team has not yet been assembled or does not know how they will work together, a pre-mortem will be less valuable; run it after the core team is in place.
How a pre-mortem differs from a post-mortem and risk assessment
A post-mortem is a retrospective analysis conducted after a project ends or fails. It examines what actually happened, why it happened, and what to learn for the future. A pre-mortem is prospective; it happens before the work begins and uses imagination rather than data. A post-mortem is investigative; a pre-mortem is generative.
A risk assessment is a systematic process that works through known categories of risk, technical, financial, organizational, market, and asks whether each category poses a threat. It is thorough and methodical. A pre-mortem is less systematic and more imaginative. It asks the team to think freely about failure without being constrained by categories. As a result, a pre-mortem often surfaces risks that a checklist-based assessment would miss: unusual combinations of events, second-order effects, and assumptions that no one thought to question. The two are complementary. A risk assessment ensures you have covered the known territory; a pre-mortem helps you find blind spots.
Assemble the right participants
Use a small team for the most open dialogue. Include anyone with direct knowledge of how the project will be executed: the project lead, the technical lead or leads, someone from the business or customer side, and someone from operations or support. Deliberately include at least one person who is skeptical about the project or who has a track record of raising concerns. That person's voice matters most in a pre-mortem; they will think of failure modes others overlook. Avoid including people who are not directly involved in the work or who have only a passing interest; they will either be silent or will ask questions that derail the group. If the project spans multiple teams or disciplines, you may need to run separate pre-mortems for each, then synthesize the results. Typically use small teams for the most open dialogue.
Set the frame and context
Begin by explaining what a pre-mortem is and why you are running one. Say something like: "We are going to imagine that it is six months from now and our project has failed. We are not saying it will fail; we are running a thought experiment. Your job is to imagine what went wrong and to be as specific as you can. We want to hear every concern, even ones that seem unlikely or that you are not sure about. There is no such thing as a bad answer here. We are not trying to be positive or to convince anyone the project will succeed; we are trying to find risks we can plan for now."
Emphasize psychological safety explicitly. Tell the team that concerns raised in this meeting will not be held against anyone, that voicing a risk is not the same as opposing the project, and that the goal is to make the project more likely to succeed by identifying problems early. Then briefly recap the project: what it aims to do, who it serves, what success looks like, and what the timeline is. Make sure everyone in the room has the same basic understanding. If there are significant disagreements about the project's scope or goals, surface them now; a pre-mortem will not work if the team does not share a common vision of what they are trying to build.
Conduct the brainstorming phase
The brainstorming phase has two parts: silent individual ideation, then group discussion. This structure ensures that all voices are heard and that the group is not dominated by the loudest person.
Prompt the team to imagine the project has failed
Ask the team to close their eyes for a moment and imagine that it is six months in the future. The project has failed. It did not deliver what was promised, or it was cancelled, or it caused unexpected harm, or it cost far more than budgeted. Tell them: "You are not responsible for the failure, but you were part of the team. What happened? What went wrong?" Then open their eyes and ask them to write down their answers. The shift from present tense to past tense is crucial. When you ask "What could go wrong?" people think in possibilities and hedges. When you ask "What went wrong?" people think in concrete scenarios and specific causes. The imaginative distance, the permission to pretend, makes it safe to voice concerns that would sound like criticism or doubt in a normal planning meeting.
Capture all failure scenarios without filtering
Give the team 10 minutes to silently write down their answers on a shared document or on sticky notes. Tell them to write as many scenarios as they can think of. Emphasize that you want quantity, not quality; that spelling and grammar do not matter; and that they should not filter their ideas or worry about whether a scenario is realistic. If someone thinks of something that seems far-fetched, they should write it down anyway. The goal at this stage is to generate a comprehensive list, not to evaluate feasibility.
While the team is writing, stay quiet. Do not offer suggestions or examples; let them think. If someone finishes early, ask them to keep writing and to think about second-order effects: if X happens, what else might break? After 10 minutes, collect all the responses. Read them aloud without commentary. Do not dismiss any scenario or ask someone to justify what they wrote. The purpose of reading them aloud is to give the group a shared sense of all the risks that were surfaced and to prevent any idea from being lost.
Prioritize and analyze the identified risks
Once you have a raw list of failure scenarios, the next step is to move from quantity to quality. You will group overlapping risks, score each one by likelihood and impact, and assign ownership. This is where the pre-mortem output becomes actionable.
Group and consolidate overlapping risks
Read through the list and look for scenarios that are really the same risk described in different words. For example, "the team lacks the skills to build the feature" and "we hire people who do not understand the technology" are both about capability gaps. Group them together and give the group a single name: "Technical skill shortage." The goal is to reduce the list to distinct, non-redundant failure modes so that you are not tracking the same risk multiple times. Ask the team for input on grouping; they will often see connections you miss. Once you have consolidated the list, you will have identified the key risks for the project.
Score each risk by likelihood and impact
Use a risk management matrix to rank each risk. The matrix has two dimensions: likelihood (how probable is this risk?) and impact (how bad would it be if it occurred?). For each risk, ask the team: "If this happened, how much damage would it do to the project?" Rate impact on a scale of low, medium, or high. Then ask: "How likely is this to happen?" Rate likelihood on the same scale. A risk with high impact and high likelihood is a priority; a risk with low impact and low likelihood can be monitored but does not need immediate mitigation. A risk with high impact and low likelihood is worth planning for because the downside is severe. A risk with low impact and high likelihood is less critical but may be easy to prevent.
Plot each risk on the matrix. This creates a visual ranking that makes it obvious where to focus. The risks in the top right (high likelihood, high impact) are your immediate priorities. The risks in the bottom left (low likelihood, low impact) are worth noting but do not require action now.
Assign ownership and mitigation steps
For each high-priority risk, assign an owner: a single person responsible for monitoring that risk and leading mitigation efforts. The owner does not have to solve the problem alone; they are the point person who ensures the risk is tracked and addressed. Then, for each risk, identify a preliminary mitigation step. This is not a detailed plan; it is a concrete action or decision that reduces the likelihood or impact of the risk. For example, if the risk is "the timeline is too aggressive," a mitigation step might be "conduct a detailed estimation exercise in the next two weeks and adjust the timeline if needed." If the risk is "key team member leaves," a mitigation step might be "document critical processes and cross-train a backup." The mitigation step should be specific enough that the owner knows what to do, and it should be something that can be started before the project launches.
Document and act on the results
A pre-mortem that produces a list and then disappears is a wasted meeting. The output must become a living reference that guides the project through its execution.
Create a risk register from the prioritized list
Copy the prioritized risks into a risk register. A risk register is a document that lists every identified risk with the information needed to manage it. For each risk, include a description, a likelihood and impact rating, a score, an owner, a planned response, and a status. Each risk should have a description, a likelihood and impact rating, a score, an owner, a planned response, and a status. The planned response is the mitigation step you identified in the pre-mortem. The status starts as "open" or "not yet started." As the project progresses, the owner will update the status to "in progress," "mitigated," or "occurred." The risk register becomes the single source of truth for project risks. It is not a one-time artifact; it is a working document that evolves as the project evolves.
Schedule reviews and update the register
Schedule regular reviews of the risk register, typically at the same cadence as your project status meetings. Monthly is common for projects that run several months; weekly for shorter, higher-risk projects. At each review, ask the risk owner to report on the status of their assigned risks. Have they taken the mitigation steps they planned? Has the likelihood or impact changed based on new information? Have any of the risks occurred? Are there new risks that have emerged that should be added to the register? As the project progresses, some risks will be mitigated and can be closed. Others may become more or less likely as circumstances change. New risks will emerge that were not visible at the start. The register should reflect the current state of risk at any point in time. This discipline, regular review and update, is what transforms a pre-mortem from a one-time exercise into a risk management practice.
Recognize when the pre-mortem is working
A productive pre-mortem produces a diverse list of failure scenarios that span multiple categories: technical risks, people risks, market risks, organizational risks, and external risks. If the list is dominated by one category, the team may be stuck in a particular frame and not thinking broadly. Prompt them to consider other dimensions: "We have heard a lot about technical challenges. What about people or organizational risks?" A working pre-mortem also surfaces at least one or two scenarios that surprise the group or that no one had thought of before. If every risk on the list is something the team already knew about, the pre-mortem has not added much value. A third sign that the pre-mortem is working is that the team is engaged and contributing. If only one or two people are talking, or if people seem reluctant to voice concerns, the psychological safety frame did not land. Stop and reset: remind the team that this is a thought experiment, not a prediction, and that all concerns are welcome. Finally, a working pre-mortem produces risks that are specific and actionable. "The project might fail" is not actionable. "The API we depend on might not be ready in time" is specific and suggests concrete mitigation steps.
Avoid common execution failures
Pre-mortems fail most often when the facilitator does not maintain psychological safety. If the project sponsor or a senior leader is in the room and responds to concerns with defensiveness or dismissal, people will stop speaking. Protect the space. If someone raises a risk and another person immediately argues against it or tries to solve it, the group will shift into debate mode and stop generating ideas. Save the evaluation and problem-solving for after the brainstorming phase. Another common failure is running a pre-mortem with the wrong participants. If the people in the room do not have direct knowledge of how the work will be done, they will generate abstract risks that are not useful. Make sure the team includes people who will actually execute the project. A third failure mode is treating the pre-mortem as a one-time event rather than the start of an ongoing risk management practice. If the risks are identified in the meeting and then never reviewed again, they will be forgotten and the project will be blindsided by problems that were already surfaced. Commit to regular reviews of the risk register from the start. Finally, pre-mortems fail when the team is too optimistic or too cautious. If everyone is convinced the project will succeed, they will not imagine failure scenarios. If everyone is convinced the project will fail, they will list catastrophic risks that are not realistic and the ranking will be meaningless. The facilitator's job is to keep the team in the middle: serious about risk, but not paralyzed by it.
Do this automatically
Running a pre-mortem requires assembling the right participants, setting clear context, and conducting structured brainstorming across multiple sessions, a process that demands hours of coordination, facilitation, and synthesis from project leadership. Software can automate the scheduling of participants, capture and organize the failure scenarios identified during brainstorming, and generate a prioritized risk report without requiring manual compilation across email threads and documents. IMBeacon.ai runs this kind of analysis end to end and cites every figure back to its original source, across as many subjects as you need, with Mimir attaching a citation to every figure. It will not make the decision for you. It gathers and cites the evidence; the judgment stays yours, and deliberately so. Every plan includes it, including the free one.
Start your first report and run it on something you already know well.
This article is general information and research commentary. It is not professional advice, and it does not account for your particular circumstances.
