The other day browsing through my twitter account I read a tweet from Mark Graban about a problem-solving tip for 5 Whys: “it’s not always magically five whys to get to a possible root cause”. That tweet and some of the subsequent conversation reminds me of an experience I had recently.
One activity that we have been doing a lot lately is root cause analysis. Our quality program requires the completion of a root cause analysis to support all corrective and preventive actions proposed. After our most recent third-party audit, we decided to complete an analysis for all the observations reported, including some issues we identified as a group but not pointed out by the auditor. When the Quality team recruited me to facilitate the sessions, I was happy to help.
My only doubt was which tool to use, the Five Whys or Fish Bone. I decided to do both, which immediately raised up questions from my fellow managers, why both? Are we are doing the same analysis twice? Which one is more effective? Honestly, I did not know the answer to any of those questions but I proposed the group to start doing both for a couple of non-compliances and then after we all have a feel of it, decide which way to go.
Practice makes perfection, after a couple of exercises I was able to tell that it was better to do the Fish Bone to identify all possible causes, and then the 5 whys to find each possible cause’s root. That worked for me in the past, and with this experience I validated it. The whole team agrees and this analysis method becomes our new standard for root cause analysis.
The team members were representative of all departments so the discussions were sometimes intense but always productive. Through brainstorming and a bit of group discussion, we were able to choose the most probable cause(s) from the fishbone based on criticality and impact on quality, cost, and delivery. For that cause or causes we completed the five whys and just like Mark’s tweet; sometimes with two or three whys we find the root cause but in some of them we went as far as six or seven whys before we hit the root.
After we identified the origin for each cause or causes we create and implement the corrective actions. We also set a date in the future to meet just to check that all corrective actions were completed and verify if there is any other incident after their completion. The most important part about doing a root cause analysis is to check if we really identify the root cause of the problem. If it happens again probably we did not, which means that we have to sit down and put more efforts this time to find the real root cause.
Is good to learn to do things on our own but is even better when we can validate with other people experiences that what we are doing is good. Thank you for the lesson Mark!