A Root Cause Analysis (RCA, Ishikawa diagram or fish bone) is a problem solving technique that gets to the root causes of problems. The workshop has an action plan as output to deal with the real (root) causes and make sure the problem doesn’t occur again.
You can do the root cause analysis on different moments in time: during right after the incidents or even later.
During the incident
When an incident takes place, there will be no time to do a root cause analysis. The focus is to get up & running as soon as possible. Afterwards the problem can be studied with a root cause analysis to solve the root causes and make sure it doesn’t happen again.
Right after the incident
The ideal situation for doing a Root Cause Analysis is immediately when the incident is solved.
The reason for this is that the incident is still fresh in people’s mind. Everybody is thinking of the same and there is no (better: less) room for interpretation and assumptions.
To make sure everybody is on the same track, some best practices are to prepare the problem statement in advance and to agree to it in group when the workshop starts. This approach will save you lots of group effort (time) because the discussion is held up front with the necessary contributors, and the focus is clear and set when the group effort is needed.
It is also easier to agree to the problem to investigate with a smaller group.
When the workshop starts you can recapitulate the problem you are about to investigate and see if everyone present agrees that his is this problem to make sure there is no room for interpretation and assumptions.
After some time
Due to time and other restrictions it is not always possible to facilitate a Root Cause Analysis workshop right after the facts and more time is needed.
An example of this could be a postponed workshop for a software release evaluation X that is held after release X+1 went to production.
The challenge for this workshop is to get everyone looking in the same direction. We want to evaluate software release X, but in the meanwhile another software version (X+1) is already released. The risk here is that during the evaluation of X, participants are confused and will discuss or mix-up incident details with the evaluation of release X+1.
How can you deal with this?
- Think carefully about the added value of doing the workshop for release X after release X+1.
- Address the issue to the participants. You know it’s rather late to make the evaluation, but the added value is high enough to put in the effort (and take the risk).
- Tell the story again: what happened? What were the conditions? Who was involved? If needed, create a time line.
- On workshop start, make an in and out of scope board. Put topics on Post-Its to set them explicitly in or out of scope. When in doubt during the workshop, you can refer back to this board. “In scope is the release X and out of scope is release X+1, some more?”
- Don’t make assumptions: when in doubt, don’t assign root causes.
Pingback: Five why are you doing a RCA workshop? « No Rules Just Words – Lean stories from the trenches·
Pingback: Work fascinates me, I can watch it for hours. « No Rules Just Words – Lean stories from the trenches·
Pingback: Training for Performance Management | No Rules Just Words - Stories from the trenches of work·