Failures are a natural event in the life cycle of a product, but they’re especially painful when a whole project ends up unsuccessful.
When a digital product fails, the team usually performs an inspection called a postmortem. The team gathers, analyzes what went wrong, tries to draw conclusions, and creates a note. The learnings from that failure help the company adjust the processes so as not to repeat the same mistake.
But what if we could look into the future before the project failed? At nomtek, we use a premortem — an attempt to predict and mitigate problems before they happen.
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.
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:
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.
How does it work in practice? Let's take a hypothetical mobile application design where:
The team may have noticed the following reasons why the project failed:
What actions can be taken:
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.