Learn Easy Steps on When to Use Root Cause Analysis Techniques

Page content

Applications

A root cause analysis is a problem solving technique that probes the symptoms or manifestation of issues in depth, to gain understanding of the crux of the issue and the core reason(s) for the problem. It aims to resolve such core issues and make a permanent solution or a series of permanent fixes, rather than resort to quick fixes or fixing symptoms that occur if the core issue remains unsolved. The popular techniques to do so include 5-why, fishbone diagram, a decision tree, cause-and-analysis diagram, and others.

Most organizations use a root cause analysis as a reactive tool to solve problems after they occur. The application of this technique takes place after the project team or anyone else reports existence of issues, or the symptoms of issues start to manifest. This technique finds better use as a proactive tool to predict problems before they happen, when used as an analysis tool in decision-making process.

A root cause analysis finds common use in a variety of applications. Some of the popular applications are:

In occupational safety and health, for accident analysis
Production, for quality control
To check validity of procedures, and processes
Failure analysis in engineering and businesses
Change management, risk management, and systems analysis in business processes
To resolve customer complaints and returns.
In inventory management, to aid material review processes and dispose of non-conforming materials
For corrective action plans resulting from internal and customer audits

Situations

The application of a root cause analysis is an effective way to solve problems that occur. Problems with complex sub-issues and causes make identification of an apparent problem difficult. For instance, one can use this method to solve problems related to delays in processing orders or missing orders in a customer order process with a well-defined process for accepting, processing, and shipping customer orders. The problem could lie in any of the many sub-processes, or an apparent cause of delivery tracks which are unable to track the orders properly, may have a core issue of poor software capability.

Not all problems, however, make for good cases. Identifying the root cause for a direct cause and effect problem is unnecessary and very often counterproductive. For example, the most expedient thing to do when faced with a leaky pipe is to fix the pipe rather than waste time trying to identify the underlying causes such as high water pressure or faulty design that caused the pipe to leak. Of course, identifying the root cause might prevent the leak from reoccurring, but is not the most expedient or appropriate situation. If the leak persists, even after repair, then it may make for a case of using the root cause analysis.

At times, cost-benefit analysis plays a major role. If the cost to identify and fix the root cause is greater than letting things be, then managerial expediency may require accepting the problem and working around it. Assume the root cause of delivery staff missing orders is the lack of software functionality to list pending orders. If the cost of adding the functionality to the software is greater than a quick-fix of simply asking the staff to note down all orders in a slip and destroy the slip as delivery takes place, then the root cause may remain unresolved.

At other times, this method may be unnecessary regardless of the circumstances. For instance, trying to identify the root cause for destruction to a data center caused by hurricane is foolhardy.

Systems-based organizations using automated problem resolution support systems such as SolutionBuilder can easily identify such problems, whereas for others, determining when to use a root cause analysis depends on subjective managerial decision making. Many companies leave the process to the committee that regularly monitors operations. As a rule of thumb one-off situation with minimal impact on customers or operations rarely require such an analysis.

Root cause analysis methodologies serve to provide adequate depth and breadth of an analysis and take away insignificant data that places focus on the key factors and helps managers in their analysis and investigation. The best use of such tools is to aid analysis rather than substitute managerial foresight and work, for its effectiveness depends on the quality of input data. Using such tools without managerial assumptions and foresight could lead to discounting potentially important facts. Success also depends on the competence of the team to utilize the tool, such as the ability to challenge assumptions and delve into greater levels of the 5-Whys or the ability to extract the most relevant branch from the fishbone diagram. Use this approach as an organization performance model rather than as a be-all and end-all solution to solve the ills plaguing the system and organization.

References

Dr. Anthony Mark Doggett. “A Statistical Comparison of Three Root Cause Analysis Tools.” Journal of Industrial Technology. Volume 20, Number 2 - February 2004 to April 2004https://atmae.org/jit/Articles/doggett010504.pdf.retrieved June 08, 2011.
NASA. “Root Cause Analysis.”https://process.nasa.gov/documents/RootCauseAnalysis.pdf. Retrieved June 08, 2011.
University of Texas. “Root Cause Analysis for Beginners. ”https://webspace.utexas.edu/mae548/www/research/digital%20forensics/qp0704rooney.pdf. Retrieved June 08, 2011.

Learn more here on Bright Hub:

[Root Cause Analysis Diagrams and Forms](/tools/A root cause analysis delves into the heart of problems and issues and knowing when to use root cause analysis depends on the situation. This type of analysis serves its purpose best in situations where the problems recur and has multiple facets. Situations that do not impact operations or customers and problems with a direct cause-and-effect do not require a root cause analysis. Learn more about when to use this type of analysis here.)

Example of a Written Root Cause Analysis

Image Credit: flickr.com/facemePLS