Conducting a Premortem

A premortem is a tool used in business for decades to help deliver stronger results. It drives teams to anticipate failure, then take steps to prevent it.

By applying premortems to significant decisions or tasks in our personal and professional lives, we can deliver better outcomes.

Overview: Premortem versus Postmortem

A decision postmortem looks back after the fact, to reflect on what worked and didn’t work as a way to enable future improvement.

A premortem is, in general terms, the opposite of a postmortem. It takes place at the beginning of a project, or decision. What makes a premortem powerful is the framing—you assume failure. With defeat solidly in mind, you take a hard look at what went wrong—and then develop strategies that could have prevented this outcome.


Decreases failure due to blind spots—no project leader/decision maker can see everything—and cognitive biases, including overconfidence

Enables us to measure the magnitude of threats we may already be worrying about

Enables all team members to share concerns and areas of potential weakness

Breaks up groupthink by applauding dissenting or questioning views

Heightens teamwork, as now everyone is fighting for the win together

Increases team productivity

Research has shown that we have a 30% chance of correctly identifying future outcomes when we imagine that an event has already occurred—as done in premortems.
1989 study conducted by Deborah J. Mitchell, of the Wharton School; Jay Russo, of Cornell; and Nancy Pennington, of the University of Colorado


How to Execute a Premortem

  1. Begin Early
    Shortly after a project or decision has been outlined, bring together everyone with a significant role to play.
    – Excluding key players will create blind spots.
    – Everyone should have a solid understanding of key details.
    – Do not wait until the project is too far along. Faced with a pending deadline, your team members are more likely to avoid hard truths in favor of acceleration and thus avoid important corrective actions.
  2. Dedicate the Time
    Plan for 1-2 hours.
    – Ensure all participants are fully involved, throughout the process.
    – Assign one person whose only role is to capture all notes.
  3. Collect all Crisis Scenarios
    Imagine that your project has failed, and then work to identify any factors that could have led to that failure. Consider this a brainstorm of doom. Every possible scenario that could have led to disaster, at any stage, should be included.
    – Because you are immersing yourself in this hypothetical scenario of imagined failure, team members will be less defensive or shy about calling out potential pitfalls.
    – Avoid creating solutions as you go, as this will distract you from the task at hand: identifying pitfalls.
  4. Rank Each Crisis Scenario
    Your aim is to create a list of the most impactful and likely-to-occur challenges.
    – First, in one column, rank each scenario according to how likely it is to happen, on a scale of 1-10.
    – Then, in a second column, rank each scenario according to its level of impact, again using the 1-10 scale.
    – Discard any scenarios that you have zero control over (i.e., a natural disaster).
    – Add up the results from the two columns.
    – Focus on the scenarios with the highest point totals.
  5. Create Solutions
    Either together as a group, or in small teams, create solutions with specific tactical steps for each top-crisis scenario.
    – Ensure that the scenario and the corrective steps are clear and detailed.
    – Often, smaller-issue scenarios will be resolved while you are working on the larger ones.
    – If you break into smaller teams, each team should have a leader.

Share this resource to your favorite platform!

View our other resources

  • Using a Weight-and-Rate Tool

    Often, we move to make a decision before really thinking about what matters most to us. This is where a weight-and-rate tool can help.

  • Conducting a Postmortem

    A decision postmortem looks back after the fact, to reflect on what worked and didn’t work as a way to enable future improvement.