Featured Product
This Week in Quality Digest Live
Standards Features
Megan Wallin-Kerth
MasterControl’s Matt Lowe talks competition, data, and what quality does for a company
Using the CASCO Toolbox to repair and restore
Todd Hawkins
Good documentation is worth the effort you put into it
Rupa Mahanti
With data as the fuel of the digital economy, data governance is the much needed brake
Bryan Christiansen
Workplace policies that reduce accidents and enhance safety

More Features

Standards News
Creates one of the most comprehensive regulatory SaaS platforms for the industry
Yotrio and SunVilla to provide interactive, 3D-enabled assembly via BILT app
KCP25C grade with KENGold coating sets new standard for wear and productivity in steel turning
Takes action to mitigate risk of medical devices shortage
Standards, testing help autonomous vehicles drive safely
Offering production versatility and throughput with increased detection sensitivity and low energy consumption
New lines improve software capability and analysis
Automotive cybersecurity on Feb. 9, and AS9145 on Feb. 28

More News

Denise Robitaille


Four Things You Should Get From Root Cause Analysis

Why we do it

Published: Tuesday, November 10, 2009 - 05:00

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.

4. You should have created an architecture into which you can build your corrective action plan. Corrective action isn’t just one activity. It needs to be a plan, reflective of all aspects of the problem. If you’ve done a good root cause analysis, you’ll have identified not only the root cause, but the many different factors that need to be addressed to ensure that the problem doesn’t recur, that you don’t inadvertently create a new problem, and that your organization experiences some benefit from the action taken.


Your root cause analysis will let you see what processes may need to be modified, what documents and forms will have to be revised, who will require training, and a myriad of other considerations that go into a typical project plan.

Without root cause analysis, effective corrective action is impossible. Without corrective action, root cause analysis is a waste of time.


About The Author

Denise Robitaille’s picture

Denise Robitaille

Denise Robitaille is the author of thirteen books, including: ISO 9001:2015 Handbook for Small and Medium-Sized Businesses.

She is chair of PC302, the project committee responsible for the revision to ISO 19011, an active member of USTAG to ISO/TC 176 and technical expert on the working group that developed the current version of ISO 9004:2018. She has participated internationally in standards development for over 15 years. She is a globally recognized speaker and trainer. Denise is a Fellow of the American Society for Quality and an Exemplar Global certified lead assessor and an ASQ certified quality auditor.

As principal of Robitaille Associates, she has helped many companies achieve ISO 9001 registration and to improve their quality management systems. She has conducted training courses for thousands of individuals on such topics as auditing, corrective action, document control, root cause analysis, and implementing ISO 9001. Among Denise’s books are: 9 Keys to Successful Audits, The (Almost) Painless ISO 9001:2015 Transition and The Corrective Action Handbook. She is a frequent contributor to several quality periodicals.


Root Cause is not Problem Solving

Many speak of Root Cause as if its the end all be all of Problem solving but that is simply not the truth. 

Root cause (actually contributing causes, as there is generally never a single root cause but a string of contributing causes) is a tool that is used to solve problems when the current methodology is going to remain in place.  Contributing causes analysis should never I repeat NEVER be used as an initial tool to solve a problem.

First problems must be well stated and then classified as one of two types 

1) Unexpected results (a unexpected event has occurred in an otherwise effective process) 

  1a. Anomaly          1b. Chronic occurrence 

2) There is a Gap between the Current State and the Desired State 

To solve problem type # 1, Causation analysis will most likely be employed because the current business process is going to be maintained. Unless the current process has undetermined variation (explained in later)

To solve problem type # 2, its rare that Causation analysis will ever be employed as the conditions are known related to the expectation (desired state) and the (current state) and all that is needed is to fill in the gap between the two (usually creative thinking).  

Failure occurs when causation analysis (aka root cause analysis) is used improperly to search for the causes of failure for a process which is in the end, incapable or unstable due to variation.  The first thing to determine related to any business problem would be the capability and stability of the current process toward achieving the desired result.  Only after process capability and stability  the are determined, is an organization capable of making a good decision related to seeking out failure related cause analysis.

If the process is initially determined to be froth with variability, then there is no way to ever determine any factual causation, because the variability simply can never be repeated accurately, which means the causes can never be determined accurately.  Its better, and less expensive to the organization, in those cases, to simply re-engineer the process so its capable of achieving the desired state continually.   

A case in point would be a manufacturing process which provides chronic results related to a wide variety of acceptance characteristics, where most controls are open to adjustment by both the operator as well as other external sources.  The variation possibilities are endless with this process therefore “root cause” analysis would never result in any reliable resolution.  This process, in its current state, is neither stable nor capable due to the indeterminate amount of variation inherent in its design. Spending any time attempting to determine causation will simply be time (and business assets) spent in vain.  Believe it or not this scenario is quite common in manufacturing. The argument often given in this case is that determination the cause of failure, assist in avoiding the same mistakes when the process is redefined, however the combinations of all variation and its related causes, would all need to be considered in order for that statement to ever be accurate .  Why should an organization waste its resources if they are fairly sure the end result will be the re-engineering of the process?  

Next would be considering a process which runs continually at three sigma and which experiences a hiccup for some unforeseen reason (Anomaly).  For this situation, causation analysis is warranted because the process is both stable and capable and should be maintained and the causes of the anomaly identified.

It’s important to remove the perception that all things occur because of a single or “root cause”, which is usually only true related to machinery malfunction. Process which are generally well behaved, tend to experience a sequence of causes or events which result in failure.  Causation analysis can be a very beneficial tool when applied correctly, however when applied incorrectly, it can be a disruptive nightmare. The trick is knowing when to properly apply causation analysis tools.

Right on!

I couldn't have said it better....'Organizations have to stop assigning people to do root cause analysis without giving them the necessary training and tools.' It's also beneficial if people are knowledgeable of the process for which they are conducting a RCA. Nice article!
Sandra Gauvin

#4 Separates the Alchemists from the Firefighters

Of all the things we (humanity) can improve on, I believe it is the development of solutions that don't create even bigger problems - something I am fond of calling "Cane Toadyism" after the less-than-successful Australian pest control strategy.

Being able to truly transmute a broken process into one that not only performs to expectations but is also self-sustaining in its effectiveness improvements and currency is something that any quality professional worth their salt aims for: in other words, we should be working to gradually make our positions obsolete - not easy for a species with an innate aversion to change and an inherant instinct for self-preservation.

Be the change you want to see in this world.
Mahatma Gandhi

Root Cause Analysis

Dr. Richard Cook suggests regarding complex systems that:

Post-accident attribution accident to a ‘root cause’ is fundamentally wrong.
Because overt failure requires multiple faults, there is no isolated ‘cause’ of an accident.
There are multiple contributors to accidents. Each of these is necessary insufficient in
itself to create an accident. Only jointly are these causes sufficient to create an accident.
Indeed, it is the linking of these causes together that creates the circumstances required
for the accident. Thus, no isolation of the ‘root cause’ of an accident is possible. The
evaluations based on such reasoning as ‘root cause’ do not reflect a technical
understanding of the nature of failure but rather the social, cultural need to blame
specific, localized forces or events for outcomes.1

The complete "treatise" is available at:

Dr Richard Cook's assessment of Root Cause

I would agree initiall with Dr. Cook that "root cause" is not something which can be determined upon a process.  It can be determined upon finite objects such as machines but not processes in all cases as most process failures are attributable to a chain of events (causis) which lead to the eventual failure.  I would disagree that the use of "root cause" is related to a social, cultural need to blame.  I would think that causation analysis (or problem solving for that matter) is more related to the elimination of pain or discomfort.

The problem I discoverd after decades of following the normal school of fish is that to often folks attempt to use causation analysis (aka root cause analysis) to solve each and every problem they encournter, especially for process which have undetermined variation (process adjustments are outside the control of the processs owner) or the process is simply unstable or incapable.  Performing causation analysis in these conditions is futile.