#9 :: Imagine a failure {a.k.a premortem}



I’ve recently facilitated a route cause analysis for a feature that we have failed to deliver within our estimated range. Worth to mention that our estimations were adapted during our feature development, we scoped out a few functionalities but still we exceeded our maximum estimated delivery date.

The analysis surfaced a lot of issues that we didn’t consider throughout our development phase. We’ve got a lot of insights and we suggested actions that need to be considered for our new feature. Soon we are going to have our feature retrospective (a.k.a postmortem) as well, to gather even more data and get more insights on ways we could improve ourselves and our organization.

We all benefit from this analysis except our feature! Post-mortems and RCAs are really useful, we learn, we improve but not all of us! Psychologist Gary Klein described it in one of his article really nice:

A postmortem in a medical setting allows health professionals and the family to learn what caused a patient’s death. Everyone benefits except, of course, the patient.

In that article (referred in 99u’s post) Gary Klein introduced the concept of pre-mortem as a method that could be used in the planning phase of a project. As it is stated, pre-mortem can improve project’s chances for success and can help project teams to identify risks in a very beginning stage!

Based on my recent RCA experience, i’ve experimented with the pre-mortem concept for another feature team that i am coaching and had started a really challenging and complex feature. The steps i’ve used are described below

the case study

In that step it is important to “illustrate” an imaginary failed state of the current project/feature. Adding details, using pictures, creating a kind of “script” could help the team “live” that unwanted state.

The “script” in our case was a failed deployment of the very complex telecom feature we have developed for a very demanding telecom operator. The consequences for our operator and customer was a huge amount of call drops for a few hours. Our feature team has received an email from our customer’s head of sw deployment describing the impact of this failure, the urgency to find a workaround and remove our feature from operator’s network.

why this has happened

After describing the case study all team members need to take some time to think of possible causes that triggered this failure. Using sticky notes we’ve gathered all the causes and discussed on them. We then tried to group them in themes and we prioritised them based on their importance and their contribution in that imaginary failed state.

It was interesting to observe that feature team members were felt free to express all possible causes came in their minds and they were more open comparing to post-mortem or root cause analysis for failures that have actually happened!

how we could prevent this

The next step is a brainstorming session to find ways to prevent this imaginary failure and anticipate all possible causes. In our case we decided to work on the top themes, based on our ranking from the previous step. The outcome of our brainstorming was a concrete set of actions that we are following up weekly. In the meantime we are enhancing the rest of the themes with actions that need to be considered as well.

keep calm and carry on

you can close the pre-mortem session with a message just to relax all participants :-). It was just a simulation and we have done our best to prevent this happening in real life!


We have used almost two hours to gather causes, group them, prioritise them and find actions for the top themes. As facilitator you will need an hour to think of a failure scenario (ask your feature team, PdO e.t.c to get a few details) and prepare a “script”

personal reflections

The feedback i’ve received from all participants was really positive. This exercise trigger their creativity, as it is mentioned they were more open to express all their concerns,  and they had a feeling of doing their best to increase the chances of success. As facilitator and observer i really feel that most of the benefits as described in Klein’s article were gained

Although many project teams engage in prelaunch risk analysis, the premortem’s prospective hindsight approach offers benefits that other methods don’t. Indeed, the premortem doesn’t just help teams to identify potential problems early on. It also reduces the kind of damn-the-torpedoes attitude often assumed by people who are overinvested in a project. Moreover, in describing weaknesses that no one else has mentioned, team members feel valued for their intelligence and experience, and others learn from them. The exercise also sensitizes the team to pick up early signs of trouble once the project gets under way. In the end, a premortem may be the best way to circumvent any need for a painful postmortem.

Are you ready to imagine a failure? or a success (a.k.a future-spective)?


inspiring reading

avoid a failure with a premortem

performing a project premortem

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Managing organized complexity

DevOps is an -ism; SRE is the profession

I Manage Products

A product management blog by Jock Busuttil

Assess your Agility - BETA

A framework to evaluate and improve your organization's agility

Lean Adaptive Leadership

Transforming technology organisations using lean and adaptive principles.

Agile, Lean, Kanban, and System Thinking

Agile, Lean, Kanban, and System Thinking

Control Your Chaos

That Scrum Girl on everything Scrum, Agile and Lean

The Product Owner Framework - BETA

Evaluate your skills and identify areas for growth

Digital Business Transformation

Inviting you to explore the world of Digital Business

Agile For Startups

Tools and Techniques for Tech - Startups .

Escape The Local Optimum

jump out of any local optimums by iterating, evaluating, accepting, memorising and restarting

Software Process and Measurement

Software Process Improvement and Measurement - Oh My!

Dave Nicolette

Effective software development and delivery

Arialdo Martini

Random notes about software

Agile By Culture

Doing Agile means being Agile


Thoughts on software, code, philosophy and games

InnerActive Leadership

Partnering with you to find insights that lead to results!

Thoughts on Product Led, Analytics and Startups

Everything I find out about Product Led Growth, Analytics, Agile, Productivity, and startups.

quantum shifting

think bigger, go further

Benjamin Mitchell's Blog

Helping IT teams & their managers deliver great software solutions

Diary of a ScrumMaster

Finding a path to a new way of working

An Ethical Island

How to Teach Without a Lecture and other fun

Mike Cohn's Blog - Succeeding With Agile

jump out of any local optimums by iterating, evaluating, accepting, memorising and restarting

Jim Highsmith

jump out of any local optimums by iterating, evaluating, accepting, memorising and restarting

%d bloggers like this: