1. Home
  2. Smartpedia
  3. Premortem

What is a Premortem?

Smartpedia: A premortem is a predictive retrospective that identifies causes that will contribute to project failure.

Premortem – a predictive retrospective

In recent years, retrospectives have taken root in many organisations. A retrospective is a review in which projects or project phases, processes, workflows and tools used, as well as skills, relationships and experiences are reflected upon. It is a look from stakeholders at a near past. A premortem is a predictive retrospective. Unlike a regular retrospective, it does NOT take place after an event – a project, an iteration, a work step, a development or an event – but already at the beginning or in the course of the event. The aim is to identify possible causes for the delay or failure of projects. This is why it is often referred to as a premortem analysis, a premortem method or a management strategy.

The goal of a premortem

A premortem is the hypothetical opposite of a postmortem. In a medical autopsy – the postmortem – the aim is to determine the cause of a person’s death. In the premortem, the autopsy is at the beginning of a project, not at the end, so that the project can be improved instead of having to examine it in detail after the project has ended.

The crucial question is what went wrong, not what can go wrong. It is a consideration after an imagined project end, with the aim of finding plausible reasons for the failure of a project. The patient has already died, the project has hit the wall.

In some publications it can be read that the premortem analysis has a negative influence on the mood of those involved. In fact, this is not intended at any point, because the point is to identify possible blind spots early on. Ideally, this should even lift the mood, because the early identification of causes for failure provides the basis for possible countermeasures and thus for more success.

The origin of the idea

Gary Klein, an expert in the field of intuition and decision-making, is considered the inventor of the premortem method. In 2008, he published an article in the Harvard Business Review¹ in which he processed the findings of a study published in 1989 by Deborah J. Mitchell, Jay Russo and Nancy Pennington. Together, the three had found that imagining an event had already happened increased the ability to correctly identify the reasons for future events by 30%.

Klein recognised that people are reluctant to raise objections or concerns in the planning phase of a project because they fear pre-judgements such as low identification with the project or lack of teamwork. The “trick” of considering a project a failure makes it easier for participants to voice their concerns and thus make an important contribution to the actual success of the project.

The premortem procedure

A premortem can be divided into 5 parts:

  • Explanation of the method or the rules of the game and explicit mention of the goal: the identification of circumstances that lead to the failure of the project.
  • A look into the future by the facilitator or the project leader with the storyline that the project was an absolute flop and everything that could go wrong did go wrong.
  • The collection of causes that were essential for the failure of the project, e.g. by means of brainstorming session of doom, group work or individual work.
  • Visualising, grouping and ranking or prioritising the causes found according to severity and likelihood of occurrence.
  • Discussing probable causes within one’s own sphere of influence and looking for ways to eliminate these causes.

Advantages of a pre-mortem

A premortem has some key advantages:

  • The groupthink that leads to the Abilene Paradox is overcome.
  • A possible overestimation of oneself in the sense of “we can do it” becomes visible.
  • Things are addressed that are not usually discussed because there is no appropriate format for exchange.
  • Other perspectives – e.g. through the view of stakeholders or employees who are only indirectly affected by a project – are perceived.
  • The view of central points that are important for the success of a project or a development is sharpened. At the same time, this promotes cooperation in the team, which together tackles the cause of failure.

In addition, there are other benefits such as out-of-the-box thinking, early initiation of countermeasures or a stronger commitment to agreed goals.

Premortem versus risk management

What is the difference between premortem and risk management?

Risk management encompasses all aspects within an organisation, project or development, from systematic risk identification, analysis, assessment, prioritisation, to the definition of measures for risk avoidance, minimisation or toleration, and the definition of responsibilities as well as the monitoring of the success of the measures.

A premortem is about visualising reasons for failure in advance of a project or development. Risks could be identified, which then lead to measures for risk avoidance. However, aspects could also be identified that are not considered risks in the narrow sense, such as lack of user acceptance, changes in company policy such as changing boards of directors or low availability in local shops. Depending on the outcome or perspective, the premortem analysis may or may not be a risk management method.²

Premortem - a predictive retrospective
Impulse to discuss: Is a retrospective more of a premortem, a postmortem or possibly even both? Notes: [1] Harvard Business Review: Performing a Project Premortem. [2] Depending on the perspective, one could also speak of a method from business analysis, project management or for identifying impediments. In a way, chaos engineering also uses a similar approach. Murphy’s Law states that if something can go wrong, it will. It is based on an observation by Edward A. Murphy Jr. and contains various appeals that can also be useful in a premortem.

What does t2informatik do?

Was does t2informatik do? One click and you'll know it.

Here you will find additional information from the t2informatik Blog:

t2informatik Blog: Order clarification - first things first

Order clarification – first things first

t2informatik Blog: Change of project manager in an ongoing project

Change of project manager in an ongoing project