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”
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)?