When is Root Cause Analysis not a Root Cause Analysis?

When you stop at the Cause and don’t do the Analysis!

I have heard this or similar too many times, “we performed the root cause analysis and found that we were missing a test case, we have added that case now.” or “we found the root cause was this line of code, we have fixed it now.”

I heard similar again today.

Whenever you have a reason to want to perform a Root Cause Analysis, remind yourself to be grateful – a leader I admire referred to incidents as learning gifts – we learn the most and the most effectively from failures.

At my first workplace, we designed and manufactured Flight Deck Instrumentation; you know that stuff you see in cockpits that pilots rely on to fly planes and get you to your destinations without issue. Well, I will often say I have never worked on anything since that could directly cost human lives if it fails. So, I am always grateful for these learning gifts as they will help the teams involved learn how to be better, annoy or frustrate our customers less, and delight them more. (And not harm them in any way)

Which leads me to the intentions you need to have when performing a Root Cause Analysis, a quick reminder;

• Our number one goal is to ensure we learn all we can to ensure we can prevent or at least catch future occurrences of any issues like this.
• An RCA is never about blame.
• We have the right people involved – Ensure you have folks representing each area of the product, service, or code involved in the issue.
• We are focused on prevention – Ideally, you are gathering to perform the analysis and have already found and resolved the specific issue(s) – now you are focused on analyzing to understand how to prevent similar problems from occurring or going unnoticed in the future.

You will also need someone skilled and experienced at running these types of discussions. The outcomes will depend on the skills, experience, and knowledge of those performing the analysis. An experienced facilitator will know how to get the best out of the participants and call for more or more in-depth SME help when required.

For example, the 5-whys technique is a popular technique to use in an RCA. However, it can easily fail to produce the desired results as;

• It is easy to stop at symptoms
• You can get stuck not knowing what would be another good ‘why’ question to ask
• Sometimes you follow the why questions down a path to a single root cause and are not open to multiple root causes.

So, the next time you have an issue or incident that you can learn from, set you and your team up for future success by;

• Enlisting the help of a skilled facilitator
• Getting the right people gathered together
• Remind everyone that is a no-blame discussion
• Ensure everyone is full of curiosity
• All are in learning mode

Then, see what you can discover together to prevent future problems and lead more productive and less interrupted (by issues) work lives.

A previous post with an example