There have been a couple of great columns in recent weeks in Quality Digest Daily dealing either directly or indirectly with the subject of root cause analysis. Mike Micklewright gave us his spin on medical consequences of inadequate root cause analysis and Dirk Dusharme illustrated the pitfalls of gathering data and then not using it to do root cause analysis.

Emphasis on effective root cause analysis has gotten increased attention in several sectors. Registrars, for example, are requiring more substantial evidence of root cause analysis as part of responses to their requests for corrective action. All of this is good news. Except, my personal experience is that, although people understand that they’re required to do root cause analysis, they don’t comprehend three issues:

1. What root cause analysis is
2. How to conduct effective root cause analysis
3. What the results of root cause analysis should yield

Let’s start by reviewing what root cause analysis is. It’s an in-depth investigation into the cause of an identified problem. It asks why something happened. It should also investigate how something could have gone wrong, which will help to identify contributing factors and interim breakdowns.

There are two important things to remember at the outset. Root cause analysis is focused on cause and the ultimate intent is to use the information to develop a corrective action plan. This perception is relevant to the next two issues people need to know.

People don’t know how to do root cause analysis. They still treat it like it’s a haphazard activity. Organizations fail to train individuals in good investigative techniques. They perpetuate a culture of blame: “Let’s find out who screwed up.” And they simply don’t treat root cause analysis like a controlled process.

Apart from the 5 Whys there are many other tools that can be used. There are flowcharts, brainstorming, fishbone diagrams, Pareto charts, design of experiment—just to name a few. Several tools should be used in concert to achieve the most productive results. For example, use brainstorming or the 5 Whys to conjecture what could have gone wrong, then organize the results in a fishbone diagram that will direct you to the areas where you’ll find the evidence you need to objectively conclude what the root cause of the problem really is. Organizations have to stop assigning people to do root cause analysis without giving them the necessary training and tools.

Finally, individuals need to understand what the expected outcome of this process is. It’s great to say that we’re going to conduct root cause analysis. Do people have any idea what they’re supposed to do when they figure out the cause?

You should get four things from root cause analysis

1. You should uncover the root cause or causes of the problem. That’s the primary output of this process.

2. You should identify weaknesses or other contributing factors which, in and of themselves, are not necessarily nonconformances. They may be the outcome of shortsighted decisions to curtail activities so that efficiency or cost savings is perceived. You may have, for example, decided to wait until the first point of use to test components. The time savings experienced at the receiving process could result in costly delays and scheduling snafus that dwarf any savings that had been anticipated. It wasn’t a bad idea at the time, but it may have contributed to late deliveries.

3. You should better understand the process surrounding the problem, as well as supporting processes. If you don’t, you haven’t done a thorough root cause analysis. Without that heightened comprehension of the process, you can’t understand interrelations, interdependencies, or other factors that are reliant on the outcome of seemingly unrelated processes. This takes me to the final outcome.