View source for Root cause analysis

{{Short description|Method of identifying the fundamental causes of faults or problems}}
{{Multiple issues|
}}

In [[Science|science]] and [[Reliability engineering|reliability engineering]], '''root cause analysis''' ('''RCA''') is a method of [[Problem solving|problem solving]] used for identifying the root causes of faults or problems.<ref>See {{Harvnb|Wilson|Dell|Anderson|1993|pages=8–17}}.</ref> It is widely used in IT operations, manufacturing, telecommunications, [[Process control|industrial process control]], [[Accident analysis|accident analysis]] (e.g., in aviation,<ref>See {{Harvnb|IATA|2016}} and {{Harvnb|Sofema|2017}}.</ref> [[Engineering:Rail transport|rail transport]], or nuclear plants), [[Medicine:Medical diagnosis|medical diagnosis]], the healthcare industry (e.g., for [[Social:Epidemiology|epidemiology]]). Root cause analysis is a form of inductive inference (first create a theory, or ''root'', based on empirical evidence, or ''causes'') and deductive inference (test the theory, i.e., the underlying causal mechanisms, with empirical data).

RCA can be decomposed into four steps:
# Identify and describe the problem clearly
# Establish a timeline from the normal situation until the problem occurrence
# Distinguish between the root cause and other causal factors (e.g., via [[Event correlation|event correlation]])
# Establish a [[Causal graph|causal graph]] between the root cause and the problem.

RCA generally serves as input to a remediation process whereby [[Corrective and preventive action|corrective actions]] are taken to prevent the problem from recurring. The name of this process varies between application domains. According to ISO/IEC 31010, RCA may include these techniques: [[Five whys|five whys]], [[Failure mode and effects analysis|failure mode and effects analysis]] (FMEA), [[Fault tree analysis|fault tree analysis]], [[Ishikawa diagram]]s, and [[Pareto analysis]].

==Definitions==
There are essentially two ways of repairing faults and solving problems in science and engineering.

===Reactive management===
Reactive management consists of reacting quickly after the problem occurs, by treating the symptoms. This type of management is implemented by reactive systems,<ref>See {{Harvnb|Manna|Pnueli|1995}}.</ref><ref>See {{Harvnb|Lewerentz|Lindner|1995}}.</ref> self-adaptive systems,<ref>See {{Harvnb|Babaoglu|Jelasity|Montresor|Fetzer|2005}}.</ref> [[Physics:Self-organization|self-organized systems]], and [[Complex adaptive system|complex adaptive system]]s. The goal here is to react quickly and alleviate the effects of the problem as soon as possible.

===Proactive management===
Proactive management, conversely, consists of preventing problems from occurring. Many techniques can be used for this purpose, ranging from good practices in design to analyzing in detail problems that have already occurred and taking actions to make sure they never recur. Speed is not as important here as the [[Accuracy and precision|accuracy and precision]] of the diagnosis. The focus is on addressing the real cause of the problem rather than its effects.

Root cause analysis is often used in proactive management to identify the root cause of a problem, that is, the factor that was the leading cause. It is customary to refer to the "root cause" in singular form, but one or several factors may constitute the ''root cause(s)'' of the problem under study.

A factor is considered the "root cause" of a problem if removing it prevents the problem from recurring. Conversely, a "causal factor" is a contributing action that affects an incident/event's outcome but is not the root cause. Although removing a causal factor can benefit an outcome, it does not prevent its recurrence with certainty.

A great way to look at the proactive/reactive picture is to consider the [https://www.cheminst.ca/wp-content/uploads/2019/04/509-Application-of-Bowtie-CSChE2017.pdf Bowtie Risk Assessment] model.  In the center of the model is the event or accident.  To the left, are the anticipated hazards and the line of defenses put in place to prevent those hazards from causing events.  The line of defense is the regulatory requirements, applicable procedures, physical barriers, and cyber barriers that are in place to manage operations and prevent events.  A great way to use root cause analysis is to proactively evaluate the effectiveness of those defenses by comparing actual performance against applicable requirements, identifying performance gaps, and then closing the gaps to strengthen those defenses. If an event occurs, then we are on the right side of the model, the reactive side where the emphasis is on identifying the root causes and mitigating the damage.

===Example===
Imagine an investigation into a machine that stopped because it was overloaded and the fuse blew.<ref>See {{Harvnb|Ohno|1988}}.</ref> Investigation shows that the machine was overloaded because it had a bearing that was not being sufficiently lubricated. The investigation proceeds further and finds that the automatic lubrication mechanism had a pump that was not pumping sufficiently, hence the lack of lubrication. Investigation of the pump shows that it has a worn shaft. Investigation of why the shaft was worn discovers that there is not an adequate mechanism to prevent metal scrap getting into the pump. This enabled scrap to get into the pump and damage it.

The apparent root cause of the problem is that metal scrap can contaminate the lubrication system. Fixing this problem ought to prevent the whole sequence of events from recurring. The ''real'' root cause could be a design issue if there is no filter to prevent the metal scrap getting into the system. Or if it has a filter that was blocked due to a lack of routine inspection, then the ''real'' root cause is a maintenance issue.

Compare this with an investigation that does not find the root cause: replacing the fuse, the bearing, or the lubrication pump will probably allow the machine to go back into operation for a while. However there is a risk that the problem will simply recur until the root cause is dealt with.<!-- This entire section could be condensed into a comment under the Examples (which should be titled "Example", since only one is present) sub-heading. Additionally, the explanation of CBA omits necessary discussion about the importance of time period selection and constraints. -->

The above does not include cost/benefit analysis: does the cost of replacing one or more machines exceed the cost of downtime until the fuse is replaced? This situation is sometimes referred to as ''the cure being worse than the disease''.<ref>{{cite news
    |newspaper=The New York Times
    |url=https://www.nytimes.com/1927/11/05/archives/the-cure-worse-than-the-disease.html
    |title=The Cure Worse Than the Disease |date=5 November 1927}}</ref><ref>{{cite news |newspaper=The New York Times
|url=https://www.nytimes.com/2000/12/07/nyregion/dredging-river-s-pcb-s-could-be-a-cure-worse-than-the-disease-ge-insists.html
|title=Dredging River's PCB's Could Be a Cure Worse Than the disease, G. E. insists
|author=Andrew C. Revkin  |date=7 December 2000}}</ref>

As an unrelated example of the conclusions that can be drawn in the absence of the cost/benefit analysis, consider the tradeoff between some claimed benefits of population decline: In the short term there will be fewer payers into pension/retirement systems; whereas halting the population decline will require higher taxes to cover the cost of building more schools. This can help explain the problem of the cure being worse than the disease.<ref>{{cite news |newspaper=The New York Times
   |url=https://archive.nytimes.com/www.nytimes.com/cfr/international/20040501faessay_v83n3_longman.html
   |title=The Global Baby Bust
   |author=Phillip Longman  |date=9 June 2004}}</ref>

Costs to consider go beyond finances when considering the personnel who operate the machinery. Ultimately, the goal is to prevent downtime; but more so prevent catastrophic injuries. Prevention begins with being proactive.

==General principles==
[[File:Root Cause Analysis Tree Diagram.jpg|thumb|upright=1.5|Example of a root cause analysis method]]

Despite the different approaches among the various schools of root cause analysis and the specifics of each application domain, RCA generally follows the same four steps:

# '''Identification and description:''' Effective [[Problem statement|problem statement]]s and event descriptions (as failures, for example) are helpful and usually required to ensure the execution of appropriate root cause analyses. Problem statements are the North Star of the RCA as it keeps the team focused on what they are investigating and prevents them from going astray. 
# '''Gathering, organizing and analyzing information:''' Most RCAs begin with a fact finding session to gather available information such as witness statements, the chronology of events and applicable requirements for the evolutions that were taking place at the time of the event.  The information can be used to establish a sequence of events or [[Timeline|timeline]] for the event, and to identify the line of the defenses that should have prevented the event (i.e. the administrative requirements, and physical and cyber barriers). Available databases should also be queried and analyzed (such as corrective action program and safety program databases), and data analysis tools such as Pareto charts, process maps, fault trees, and other tools that provide us with insights into performance gaps. Any number of data analysis tools can be brought to bear, including data analysis tools from Lean Six Sigma, statistical analysis tools, and others such as [[Hierarchical clustering|hierarchical clustering]] and [[Data mining|data-mining]] solutions (such as [[Graph theory|graph-theory-based]] data mining). Another consists in comparing the situation under investigation with past situations stored in case libraries, using [[Case-based reasoning|case-based reasoning]] tools and can include change analysis, comparative timeline analysis and task analysis.
# '''Analysis of Defenses:''' After identifying the defenses in place that should have prevented the event or accident, it is highly recommended to conduct an analysis of defenses (traditionally called [[Philosophy:Barrier analysis#:~:text=Barrier Analysis is a rapid,supporting activities can be developed.|Barrier Analysis]]) in every case including non-RCA investigations. One method is to list the defenses on chart or a virtual white board. Then, for each defense, look at the information and data that was gathered for evidence of the effectiveness of that defense.  We are actually looking for deficiencies or gaps in performance where the administrative requirements were not met, or where the physical or cyber barriers were bypassed.  These initial gaps in performance are merely symptoms of deeper-seated causes. We use these symptomatic performance gaps to develop lines of inquiry questions as outlined below, to pursue the symptoms back to their points of origin (i.e. the root causes) using cause-and-effect analysis. 
# '''Generating focused, unbiased lines of inquiry questions:''' After gathering available information, organizing it into charts with timelines and other data, after analyzing available data, and after conducting an analysis of our defenses, we use those insights to generate great questions. These questions will become our lines of inquiry for cause-and-effect analysis. The questions must be unbiased, and to prevent any bias from the RCA team from tainting the investigation, questions should be tied to a specific defense, or to a specific insight from our data analysis (e.g., [[Pareto chart]]s, process maps, [[Fault tree analysis|fault trees]], [[Control chart|control chart]]s) and other tools that provide us with insights into performance gaps. There should not be any curiosity questions, questions that reflect "confirmation bias" (i.e. asking a leading question so they answer what the RCA team thinks are the causes), or questions that are accusatory in nature that will cause those helping the investigation to close down and withdraw. 
# '''Cause-and-Effect Analysis:''' Once we have developed a robust set of lines of inquiry questions from the factual evidence collected, the applicable requirements, and an analysis of the available data, we can take those questions to the organization's subject matter experts.  This begins the process of cause-and-effect analysis. Once we pose a question to the affected organization, we use their answer to pose a follow-up [[Socratic questioning|Socratic questions]]. Socratic questions keep the investigation flowing down to the next deeper causal factors until the organization runs out of answers, or the last causal factor is beyond the organization's control.  There are many skills involved in conducting an effective cause-and-effect analysis, including facilitation skills, communication skills, and Socratic questioning.  When conducted properly, this will take the RCA down to the deepest-seated root causes. A word of caution: [[Ishikawa diagram|Ishikawa]] or the Fishbone Diagram, and the [[Five whys|5-Whys]] methods, are not rigorous enough for conducting a root cause analysis.  The Fishbone is from the 1940s and the 5-Whys is from the 1930, and there are much more advanced methods available.  Look for methods that were developed in this century (the year 2000 and later), as they are more likely to account for the new dynamics of the modern sociotechnical work environments.
# '''Charting the Results of the RCA:''' The best way to chart the results of an RCA investigation is to start populating the final chart from the start.  This process has become much easier with the advent of virtual white boards. In a single [https://zapier.com/blog/best-online-whiteboard/ virtual white board], we can display the timelines, the lines of defenses, the data analysis, the lines of inquiry questions, the cause-and-effect analysis, the root causes, and the corrective action plan.
# '''Corrective Actions to Prevent Recurrence:''' From a management perspective, the RCA effort is not complete without a comprehensive corrective action plan to address the root causes, the contributing factors, and the "Extent of the Causes." The corrective action plan should be developed by the issue owners and does not require participation by the RCA team, although the team is an excellent source of guidance for the issue owners.  The Extent of Cause reviews are conducted to determine the extent of the damage or impact that the root causes and contributing factors had on humans, equipment, or facilities. Extent of Cause reviews are an Achilles heel in the vast majority of organizations and a primary reason why RCAs and corrective action plans fail to prevent recurrence. Also, care must be taken to avoid corrective action plans that simply add more administrative requirements and more training to the organization.  To avoid this, use the [[Hierarchy of hazard controls|Hierarchy of Hazard Controls]] and [https://asq.org/quality-resources/mistake-proofing Lean Mistake Proofing] as guidelines for developing effective corrective actions that have a much higher likelihood of preventing recurrence.  
# '''Effectiveness Reviews:''' After a pre-determined period after the implementation of the corrective action plan, an effectiveness review is scheduled to evaluate the [https://info.degrandson.com/blog/effectiveness-corrective-action-1 effectiveness of those corrective actions]. This requires specifying a set of metrics or indicators that will be monitored prior to and after the corrective actions are implemented, so we can measure their impact.  If the desired results are not achieved, which in most cases is a significant reduction in the magnitude or frequency of the event or problem, then the RCA must be reopened as it was not effective.

To be effective, root cause analysis must be performed systematically. The process enables the chance to not miss any other important details. A team effort is typically required, and ideally all persons involved should arrive at the same conclusion. In aircraft accident analyses, for example, the conclusions of the investigation and the root causes that are identified must be backed up by documented evidence.<ref>See {{Harvnb|IATA|2016}}.</ref>

===Transition to corrective actions===
The goal of RCA is to identify the root cause of the problem with the intent to stop the problem from recurring or worsening. The next step is to trigger long-term corrective actions to address the root cause identified during RCA, and make sure that the problem does not resurface. Correcting a problem is not formally part of RCA, however; these are different steps in a problem-solving process known as [[Fault management|fault management]] in IT and telecommunications, repair in engineering, remediation in aviation, [[Engineering:Environmental remediation|environmental remediation]] in [[Earth:Ecology|ecology]], [[Chemistry:Therapy|therapy]] in [[Medicine:Medicine|medicine]], etc.

==Application domains==

Root cause analysis is used in many application domains. RCA is specifically called out in the United States Code of Federal Regulations in many of the Titles. For example:

# [https://www.ecfr.gov/current/title-10 TITLE 10 - ENERGY] >>> 10CFR Part 50, Appendix B, Criterion XVI, "Corrective Actions" (also adopted by NQA-1)
#* “Measures shall be established to assure that conditions adverse to quality such as failures, malfunctions, deficiencies, defective material and equipment, and non-conformances are promptly identified and corrected.
#* In the case of significant conditions adverse to quality, the measures shall assure that the cause of the condition is determined, and corrective action taken to prevent recurrence.”
# [https://www.ecfr.gov/current/title-14 TITLE 14 - AERONAUTICS AND SPACE] >>> 14 CFR Chapter III, Subchapter C, Part 437, Subpart C, §437.73   Anomaly recording, reporting and implementation of corrective actions.
## A permittee must record each anomaly that affects a safety-critical system, subsystem, process, facility, or support equipment.
## A permittee must identify all root causes of each anomaly and implement all corrective actions for each anomaly.
# [https://www.ecfr.gov/current/title-21 TITLE 21 - FOOD AND DRUG] >>> 21 CFR Subpart J: 21CFR820.100(a) – Corr./Preventive Action: (A) Each manufacturer shall establish and maintain procedures for implementing corrective and preventive action.  The procedures shall include requirements for:
## Investigating the cause of nonconformities relating to product, processes, and the quality system;
## Identifying the action(s) needed to correct and prevent recurrence of non- conforming product and other quality problems;
## Verifying or validating the corrective and preventive action to ensure that such action is effective and does not adversely affect the finished device;
# [https://www.ecfr.gov/current/title-42 TITLE 42 - PUBLIC HEALTH] >>> 42 CFR PART 488, SURVEY, CERTIFICATION, AND ENFORCEMENT PROCEDURES > Subpart E—Survey and Certification of Long-Term Care Facilities
## §488.61   Special procedures for approval and re-approval of organ transplant programs.
## ...Root Cause Analysis for patient deaths and graft failures, including factors the program has identified as likely causal or contributing factors for patient deaths and graft failures;

===Manufacturing and industrial process control===
The example above illustrates how RCA can be used in manufacturing. RCA is also routinely used in [[Process control|industrial process control]], e.g. to control the production of chemicals ([[Quality control|quality control]]).

RCA is also used for [[Engineering:Failure analysis|failure analysis]] in [[Engineering:Engineering|engineering]] and maintenance.

===IT and telecommunications===
Root cause analysis is frequently used in IT and telecommunications to detect the root causes of serious problems. For example, in the [[ITIL]] service management framework, the goal of [[Software:Incident management|incident management]] is to resume a faulty IT service as soon as possible (reactive management), whereas problem management deals with solving recurring problems for good by addressing their root causes (proactive management).

Another example is the [[Computer security incident management|computer security incident management process]], where root-cause analysis is often used to investigate security breaches.<ref>See {{Harvnb|Abubakar|Bagheri Zadeh|Janicke|Howley|2016}}</ref>

RCA is also used in conjunction with [[Business activity monitoring|business activity monitoring]] and [[Complex event processing|complex event processing]] to analyze faults in [[Finance:Business process|business process]]es.

Its use in the IT industry cannot always be compared to its use in safety critical industries, since in normality the use of RCA in IT industry is ''not'' supported by pre-existing fault trees or other design specs. Instead a mixture of debugging, event based detection and monitoring systems (where the services are individually modelled) is normally supporting the analysis. Training and supporting tools like simulation or different in-depth runbooks for all expected scenarios do not exist, instead they are created after the fact based on issues seen as 'worthy'.
As a result the analysis is often limited to those things that have monitoring/observation interfaces and not the actual planned/seen function with focus on verification of inputs and outputs. Hence, the saying "there is no root cause" has become common in the IT industry.

===Health and safety===
In the domains of health and safety, RCA is routinely used in [[Medicine:Medicine|medicine]] (diagnosis) and [[Social:Epidemiology|epidemiology]] (e.g., to identify the source of an infectious disease), where causal inference methods often require both clinical and statistical expertise to make sense of the complexities of the processes.<ref>{{Cite journal|last1=Landsittel|first1=Douglas|last2=Srivastava|first2=Avantika|last3=Kropf|first3=Kristin|date=2020|title=A Narrative Review of Methods for Causal Inference and Associated Educational Resources|url=https://dx.doi.org/10.1097%2FQMH.0000000000000276|journal=Quality Management in Health Care |volume=29|issue=4|pages=260–269|doi=10.1097/QMH.0000000000000276|pmid=32991545|s2cid=222146291|issn=1063-8628|url-access=subscription}}</ref>

RCA is used in [[Environmental science|environmental science]] (e.g., to analyze environmental disasters), accident analysis (aviation and rail industry), and [[Social:Occupational safety and health|occupational safety and health]].<ref>See {{Harvnb|OSHA|2019}}.</ref> In the manufacture of medical devices,<ref>{{Cite journal |publisher=Office of Regulatory Affairs |date=26 December 2019 |title=Corrective and Preventive Actions (CAPA) |url=https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/inspection-guides/corrective-and-preventive-actions-capa |journal=FDA }}</ref> pharmaceuticals,<ref>{{Cite web |publisher=US-FDA |title=CURRENT GOOD MANUFACTURING PRACTICE FOR FINISHED PHARMACEUTICALS|url=https://www.ecfr.gov/|access-date=28 December 2020|website=Electronic Code of Federal Regulations (eCFR) }}</ref> food,<ref>{{Cite web |publisher=US-FDA |title=Current Good Manufacturing Practice, Hazard Analysis, and Risk-Based Preventive Controls for Human Food |url=https://www.ecfr.gov/ |access-date=28 December 2020 |website=Electronic Code of Federal Regulations (eCFR) }}</ref> and dietary supplements,<ref>{{Cite web |publisher=US-FDA |title=Current Good Manufacturing Practice in Manufacturing, Packaging, Labeling, or Holding Operations for Dietary Supplements |url=https://www.ecfr.gov/|access-date=28 December 2020|website=Electronic Code of Federal Regulations (eCFR) }}</ref> root cause analysis is a regulatory requirement.

===Systems analysis===
RCA is also used in [[Social:Change management|change management]], [[Risk management|risk management]], and [[Systems analysis|systems analysis]].

==Challenges==
Without delving in the idiosyncrasies of specific problems, several general conditions can make RCA more difficult than it may appear at first sight.

First, important information is often missing because it is generally not possible, in practice, to monitor everything and store all monitoring data for a long time.

Second, gathering data and evidence, and classifying them along a timeline of events to the final problem, can be nontrivial. In telecommunications, for instance, distributed monitoring systems typically manage between a million and a billion events per day. Finding a few relevant events in such a mass of irrelevant events is asking to find the proverbial needle in a haystack.

Third, there may be more than one root cause for a given problem, and this multiplicity can make the causal graph very difficult to establish.

Fourth, causal graphs often have many levels, and root-cause analysis terminates at a level that is "root" to the eyes of the investigator. Looking again at the example above in industrial process control, a deeper investigation could reveal that the maintenance procedures at the plant included periodic inspection of the lubrication subsystem every two years, while the current lubrication subsystem vendor's product specified a 6-month period. Switching vendors may have been due to management's desire to save money, and a failure to consult with engineering staff on the implication of the change on maintenance procedures. Thus, while the "root cause" shown above may have prevented the quoted recurrence, it would not have prevented other {{snd}} perhaps more severe{{snd}} failures affecting other machines.

==See also==
{{Div col}}
* {{Annotated link|A3 problem solving}}
* {{Annotated link|Eight disciplines problem solving}}
* {{Annotated link|Factor analysis}}
* {{Annotated link|Failure mode and effects analysis}}
* {{Annotated link|Fault tree analysis}}
* {{Annotated link|For Want of a Nail}}
* {{Annotated link|Forensic engineering}}
* {{Annotated link|Ishikawa diagram}}
* {{Annotated link|Issue-based information system}}
* {{Annotated link|Issue tree}}
* {{Annotated link|Multiple regression}}
* {{Annotated link|Multivariate linear regression}}
* {{Annotated link|Orthogonal defect classification}}
* {{Annotated link|Root Cause Analysis Solver Engine}}
* {{Annotated link|Structural fix}}
{{Div col end}}

==Notes==
{{Reflist}}

==References==
* {{Cite conference
 | first1 = Aisha
 | last1 = Abubakar
 | first2 = Pooneh
 | last2 = Bagheri Zadeh
 | first3 = Helge
 | last3 = Janicke
 | first4 = Richard
 | last4 = Howley
 | article = Root cause analysis (RCA) as a preliminary tool into the investigation of identity theft
 | title = Proc. 2016 International Conference On Cyber Security And Protection Of Digital Services (Cyber Security)
 | year = 2016
}}
* {{Cite conference
 | editor1-last = Babaoglu |editor1-first= O.
 | editor2-last = Jelasity |editor2-first= M.
 | editor3-last = Montresor |editor3-first= A.
 | editor4-last = Fetzer |editor4-first= C.
 | editor5-last = Leonardi |editor5-first= S.
 | editor6-last = van Moorsel |editor6-first= A.
 | editor7-last = van Steen |editor7-first= M.
 | title = Self-star Properties in Complex Information Systems; Conceptual and Practical Foundations
 | publisher = Springer
 | series = LNCS
 | volume = 3460
 | year = 2005
}}
* {{Cite web
 | author = IATA
 | url = http://www.iata.org/training/courses/Pages/root-cause-analysis-talp37.aspx
 | title = Root Cause Analysis for Civil Aviation Authorities and Air Navigation Service Providers
 | access-date = 17 November 2017
 | date= 8 April 2016
 | website = International Air Transport Association
 | quote = Key steps to conducting an effective root cause analysis, which tools to use for root cause identification, and how to develop effective corrective actions plans.
 | archive-url = https://web.archive.org/web/20160408135838/http://www.iata.org/training/courses/Pages/root-cause-analysis-talp37.aspx
 | archive-date= 8 April 2016
}}
* {{Cite conference
 | editor1-first = Claus |editor1-last=Lewerentz
 | editor2-first = Thomas |editor2-last=Lindner
 | title = Formal Development of Reactive Systems; Case Study Production Cell
 | series = LNCS
 | volume = 891
 | publisher = Springer
 | year = 1995
}}
* {{Cite book
 | last1 = Manna
 | first1 = Zohar
 | last2 = Pnueli
 | first2 = Amir
 | title = Temporal Verification of Reactive Systems: Safety
 | year = 1995
 | publisher = Springer
 | isbn = 978-0387944593
}}
* {{Cite book
 | last = Ohno
 | first = Taiichi
 | title = Toyota Production System: Beyond Large-Scale Production
 | page = 17
 | year = 1988
 | location = Portland, Oregon
 | publisher = Productivity Press
 | isbn = 0-915299-14-3
}}
* {{Cite web
 | author1 = OSHA
 | author2 = EPA
 | title = FactSheet: The Importance of Root Cause Analysis During Incident Investigation
 | url = https://www.osha.gov/Publications/OSHA3895.pdf
 | website = Occupational Safety and Health Administration
 | access-date = 22 March 2019
 | ref = {{sfnref|OSHA|2019}}
}}
* {{Cite web
 | author = Sofema
 | url = https://sassofia.com/course/root-cause-analysis-safety-management-practitioners-business-area-owners-2-days/
 | title = Root Cause Analysis for Safety Management Practitioners & Business Area Owners
 | access-date = 17 November 2017
 | date = 17 November 2017
 | website = Sofema Aviation Services
 | quote = Identify best practice techniques and behaviours to perform effective Root Cause Analysis (RCA)
 | archive-url = https://web.archive.org/web/20171117220831/https://sassofia.com/course/root-cause-analysis-safety-management-practitioners-business-area-owners-2-days/
 | archive-date = 17 November 2017
}}
* {{Cite book
 | last1 = Wilson
 | first1 = Paul F.
 | last2 = Dell
 | first2 = Larry D.
 | last3 = Anderson
 | first3 = Gaylord F.
 | title = Root Cause Analysis: A Tool for Total Quality Management
 | date = 1993
 | publisher = ASQ Quality Press
 | location = Milwaukee, Wisconsin
 | isbn = 0-87389-163-5
}}

== External links ==
* [https://www.psmap.io/ Problem Solving Map (PSMap) RCA software]
* [https://bluedragon1-ips.com/ BlueDragon Integrated Problem-solving System (IPS)]
* [https://blog.pandorafms.org/root-cause-analysis/ "Root Cause Analysis and Monitoring Tools: A Perfect Match" by Irene Carrasco]
* [https://www.realitycharting.com/apollo-root-cause-analysis-problem-solving-methodology/ "Apollo Root Cause Analysis"]
* [https://www.thinkreliability.com/cause-mapping/ "Cause Mapping a visual explanation"]
* [https://www.sologic.com/en-us/about/root-cause-analysis/ "Sologic Root Cause Analysis Method"]
* [https://www.taproot.com/about/root-cause-analysis-fundamentals/ "Fundamentals of Root Cause Analysis"]
* [https://www.standards.doe.gov/standards-documents/1000/1004-std-1992 "DOE Root Cause Analysis Document"]

{{Six Sigma Tools|state=collapsed}}

{{DEFAULTSORT:Root Cause Analysis}}
[[Category:Quality control tools]]
[[Category:Problem solving]]

{{Sourceattribution|Root cause analysis|1}}