Premortem — Why It Should Be a Core Part of Your Digital Product

What Is a Postmortem?

Before explaining what a premortem is, let’s take a closer look at a postmortem.

In medical language, a postmortem describes the procedure after the patient's death, where doctors and pathologists try to understand the cause of demise. The detailed analysis of why something as complex as a human body has failed can be applied to multiple contexts.

For example, when you need to understand what exactly went wrong to be able to avoid it in the future.

Software development loves postmortems because they’re a great learning tool.

What Is a Premortem?

The main purpose of a premortem is to simulate failure before it happens.

More specifically, a premortem is a meeting that takes place before the first line of code is written. All team members involved in a project attend it:

• account manager
• development team
• moderator

Depending on the size of the project and the team, a premortem meeting lasts one to two hours.

We follow these steps:

#1. The scope of the project is explained so that each participant has a full picture of the situation and potential threats.

At nomtek, we do a premortem after the kick-off meeting, when the team already had a chance to familiarize themselves with the current state and plans for the future.

#2. The moderator announces that the project has failed — this is important. We are talking in the past tense: the project has ended. Participants must feel that the action has already happened.

#3. By using sticky notes or an agile retrospective tool, participants list the reasons why the project failed.

These reasons can be the obvious ones like exceeding the budget, the less obvious ones that all fell ill with COVID and the timeline crumbled, or the totally abstract ones like a falling meteorite. 

We throw out all ideas until we can move on to the next stages.

#4. Then we proceed as in a typical agile retro. We group similar cards and vote for the most important problems.

‍A good criterion is to vote on things that have the best chance of occurrence, and ones that we have an influence on. Sorry, we won't upvote the meteorite scenario ;)

#5. Here we discuss and come up with solutions. There are different techniques for how to carry out this step.

We simply give participants a moment to come up with specific actions and then post them simultaneously on the Slack channel where we can review the available solutions.

Experience tells us that sometimes the most unconventional ideas end up on the action point list, so it's important not to reveal solutions too early, so as not to disturb the creative phase.

The selected solutions must be actionable, precise, and measurable. We can select more than one way of mitigating the risk of a single problem.

#6. The developed action points are assigned to the appropriate people, and then we set a regular checkpoint to check the progress, e.g., in two weeks or at the beginning of a regular retrospective if it’s a repetitive activity.

A Practical Example of a Premortem

How does it work in practice? Let's take a hypothetical mobile application design where:

• The designs were made before the development team had a chance to give their input.
• The project timeline is extremely ambitious and contains a small margin of error.
• The application contains a demanding business part (e.g., AI elements) that hasn't yet been specified.

The team may have noticed the following reasons why the project failed:

• The designs covered only the “happy path.” Many hidden requirements emerged only when creating a detailed backlog and application behavior.
• Random events forced people related to the project (stakeholder, developers) to take time off. We were late with the release of the application for an important event.
• The AI part strongly influenced the shape of the project. It appeared so late that a large part of the already created application went to the trash and required changes, exceeding the budget.

What actions can be taken:

• Perform regular scoping sessions with developers and ask designers for input to find gaps in the requirements.
• Create a vacation calendar that helps assess the team's capacity in the future. Decide to scale the team in advance or reduce the scope to meet the deadline.
• Organize a workshop with a client and an AI expert where the team specifies the shape of the feature, what are the possible threats, and the influence on the already developed parts of the app. The outputs are the requirements backlog and a list of topics that need research.

Lessons Learned from Using Premortems in Commercial Projects

After using premortems in several projects, we collected feedback from participants one month after the meeting. In most cases, the technique brought noticeable results.

A premortem helped quickly address the greatest threats while urging the team to take action.

Taking that extra hour to organize a premortem is a sensible time investment, paying off by extinguishing fires before they occur. This technique has become our permanent step in the project life cycle, finding its place right after the project kick-off. 

The process itself is constantly evolving. We investigate whether the phase of coming up with problems and solutions can be carried out more effectively, e.g., to give more concrete results.

During the pandemic, it’s difficult to work together in workshops or discussions. To mitigate that, we collect feedback after each meeting and try to experiment.

For example, we impose strict timeboxing for solving each problem and moving to the next one or simply focus on the three most important issues.

You can use a premortem in virtually any company or private project. Before taking expensive actions, think about what can go wrong in a project and mitigate any problems long before they happen.