Talk:Root cause analysis

Miscellaneous discussion
The link below is broken - use  Mfhall (talk) 00:07, 9 September 2009 (UTC)

Stop being an add. 75.249.123.2 (talk) 23:26, 17 November 2008 (UTC)

The fact that this page is getting too close to the Apollo method is an effort to clarify and improve upon an otherwise poorly written page. Which by the way is a fundamental tenet of Wikipedia. As for a page being "general" I suppose that is acceptable to anyone who is only generally interested in knowing general information about a given subject. However, when I take the time to learn something new, I generally like to know everything there is to know. Human history is laden with simple minded attempts to explain the nature and structure of causes, ref:  for details. For a much more thoughtful discussion of all the RCA methods go to  ARCAMAN 18:30, 30 August 2008 (UTC)

This page is getting too close to the Apollo method of root cause analysis and does not represent the breadth of techniques available. For example, this piece:

General process for performing and documenting an RCA-based Corrective Action

Notice that RCA (in steps 3, 4 and 5) forms the most critical part of successful corrective action, because it directs the corrective action at the root of the problem. That is to say, it is effective solutions we seek, not root causes. Root causes are secondary to the goal of prevention, and are only revealed after we decide which solutions to implement. Define the problem. Gather data/evidence. Ask why and identify the causal relationships associated with the defined problem. Identify which causes if removed or changed will prevent recurrence. Identify effective solutions that prevent recurrence, are within your control, meet your goals and objectives and do not cause other problems. Implement the recommendations. Observe the recommended solutions to ensure effectiveness.

Previously, this was more general.

12.50.102.130 (talk) 15:17, 13 July 2008 (UTC)

The "Basic elements of root cause" at the end of this article should be completely removed from this discussion at it is represents only one of the methods in use today and there is no concurrence to these "elements" what-so-ever. Indeed this is only one of hundreds of categorical lists that attempt to use categorization of causes to determine the "Root Cause." See Ishikawa Fish Bone Diagram for a similar list. TapRoot and MORT also use similar lists. ARCAMAN 00:05, 10 June 2008 (UTC) —Preceding unsigned comment added by Deangano (talk • contribs)

It has been suggested that this page has too many embedded lists. I agree with this in some respects, but the introduction, which provides the principles of RCA, is a necessary list to communicate what RCA is. Since RCA is a stepwise process, telling a story with prose is totally inappropriate. As for the list of different types of root cause analysis, as stated in the introduction there is no universal consensus or standard. Myself and several other notable and accepted experts in the field tried to create a standard in 2005 and while there was good debate, in the end nothing ever came of it because of the significant differences in the practice of RCA. This is not unlike many things in science and just because there is no consensus on a particular topic, restricting it from Wikipedia does not serve the user at all. Indeed the article could be made to be more encyclopedic, but I think the emphasize for the encyclopedic style should be in the sub-pages that discuss the various RCA methods. These definitely need improvement. ARCAMAN 23:54, 9 June 2008 (UTC) —Preceding unsigned comment added by Deangano (talk • contribs)

Root Cause Analysis is an engineering term, and I suggest there should be a link in the Failure mode and effects analysis wiki.

If Root Cause Analysis is used in Psychology, could we have separate articles? --Graham Proud 01:45, 25 April 2006 (UTC)


 * Root cause analysis is not just an engineering term, as it is applied in a wide variety of fields. Root cause failure analysis (RCFA) might be more appropriate if a separate, engineering-oriented article is desired. Also, FMEA is more of a proactive risk analysis method applied in the design stage, and in my experience is not typically applied in a retroactive RCFA. --72.141.22.69 19:36, 29 July 2006 (UTC)

Root cause analysis is an engineering Term:

The engineering shall start from the incident management to provide an evidence of the issue. The responsibility of the service desk lies in provding the complete information of the issue with the evidence and the configuration items impacted.

Service desk shall monitor its life cycle on regular basis and update the problem management to reduce the down time of the services.

Later the problem management has to analyze the incident completely and shall start working with the evidence of the incident updating the problem log

Then, the life cycle of root cause analysis shall provide the detailed information of the errors.

This helps the problem management to raise an RFC (Request for change) if required.

--unsigned

Root Cause Analysis is not just an engineering term. While the most formal techniques are generally used by engineers, the term root cause and attempts to identify root causes has been around for over 100 years in fields other than engineering. In fact, the earliest reference I can find is from November 1905 and was in the medical journal The Lancet. It doesn't look like engineers used the term (at least in any professional journals) until some time in the 1970s.

Also, I was looking through the revision history and was surprised to see what I thought were relevent links removed as spam. Granted, there's no need for 6 Taproot links, but in looking at the guidelines for external links (External links) I don't see why a single link there or to the page from the REASON people or a variety of others would be removed. Since Wikipedia is supposed to be a work of reference, isn't it appropriate on the "Root Cause Analysis" page to identify the generally recognized and widely used methods for analyzing root causes? Please excuse my ignorance, but if I'm misunderstanding, then what then DOES belong on the links for this page?

--Prainog 13:02, 15 October 2006 (UTC)

I believe the term RCA has multiple uses. It is more than the engineering term, and although there is an engineering application foundation for RCA to the best of my knowledge, RCA can be used in any endeavor when negative outcomes ("failures") occur. My objection here is to the haphazard mixing of the terms RCA and Failure Modes and Effects (including criticality) Analysis (FMEA/FMECA). Here the link is very tenuous, and we're definitely talking engineering analysis. My concern is that many printed references incorrectly state things like FMEAs identify root causes. This is simply not the case;there is no automatic connection between FMEA and the failures causes and a root cause of the failure. Many failures dealt with in industrial practice may have a root cause, but the cost of using it is prohibitively expensive. The user is advised to have great caution reading anything connecting the two. JK August (talk) 05:55, 29 April 2014 (UTC)

I agree but most editors would disagree.

68.143.40.146 22:14, 17 October 2006 (UTC)


 * I appreciate the support, but which are you agreeing with that you think most wouldn't - that root cause analysis isn't strictly an engineering term or that the page should have references to the common methods for RCA?


 * --Prainog 01:13, 20 October 2006 (UTC)

I would like to translate this article about the RCA into german. RCA is not described in the german version of wikipedia. Are there concerns?

I notice that this page has no discussion and the article has no mention of software problem root cause analysis for help desks. I notice that this is quite popular when one does a google search. Anybody have any ideas for an addition?

24.183.226.168 04:00, 30 January 2007 (UTC)

I believe I started this wiki many years ago when there was no information on the subject of RCA available in Wikipedia at all. I wrote the first draft off the top of my head, with no references. My goal was to learn how Wikipedia worked and provide source material to draw in others. Nearly eight years later, I can see I accomplished one goal; I failed on the second. Others have taken and developed this subject making many corrections. However, although current interest is largely software, the origins of RCA are in studies and development of what is now called NASA in the study of rocket launch failures in the late 1950s and early 1960s. Many methods have come along that have not been well-published. They reflect different trains of RCA thought. My contributions reflect nuclear use of RCA following the accident at Three Mile Island in the 1980s. I intend to make periodic contributions again to support my second, unattained goal -- learning how Wikipedia works. I was so frustrated making insertions and changes on the first go around in 2008 that I basically quit editing. Kudos to everyone here who drew me back. JK August (talk) 05:43, 29 April 2014 (UTC)

There is no reference or citation for the importance of RCA. Has there been no scholarly work on differential outcomes for organizations that good or bad RCA systems? I'm looking, but have not found anything. Normhowe (talk) 15:30, 30 December 2020 (UTC)

5 "schools"
The article listed 5 "schools" of root cause analysis that have their bases in safety, production, process, failure and systems. A 6th was added without changing the prior text to mention a 6th, so I removed it pending cleanup. I don't disagree with the addition made by Dalechadwick but it didn't make sense to leave the article describing that there's 5 broadly-defined schools and listing 6. So it isn't lost in the history, the removed text was:

''clinical interventions. RCA has emerged as a key tool in healthcare cqi and qi. Often coupled with, compared to, evidence-based practices.''

I'm wondering if there's some reference that discusses the 5 or if it's simply based on someone's interpretation of the field. The inclusion of the medical field seems like a legitimate addition to the list, or if that's too narrow, what about "service-based"? While the consequences of unwanted outcomes are steeper than most other service industries, the medical field is still a service industry. --Prainog 01:16, 29 March 2007 (UTC)

Causal factor tree analysis
Is causal factor tree analysis in any way different from fault tree analysis? -- Karada 15:05, 16 May 2007 (UTC)

A fault tree analysis is an inductive method (top down) used to evaluate faults or failure events. FTA can be used as a Hazard Analysis tool to show what COULD happen and it can also be used as a probablistic risk assement tool as well. A causal factor tree would only be used after an event occured but a Fault Tree can be applicable in both scenarios. —Preceding unsigned comment added by 192.35.35.34 (talk) 23:24, 5 January 2011 (UTC)

THEORY OF TROUBLE SHOOTING
I AM PASTING HERE CONTENT OF MY RESEARCH FOR GENERAL COMMENTS. ONCE I GET PERMISION FOR UPLOADING FILES, I SHALL UPLOAD COMPLETE RESEARCH WITH SKETCHES THERE IN)

Troubleshooter123 (talk) 15:50, 11 July 2008 (UTC)

Barrier Analysis Loop Link
The "barrier analysis" link in the body leads back to this same article. If it is a separate technique, it should have an article of its own; if not, the link should be removed here. I am inclined to think the former is the case. —Preceding unsigned comment added by 170.170.59.138 (talk) 23:09, 28 December 2008 (UTC)

Broken links
The link to the reference 4 "The Management Oversight and Risk Tree (MORT)". International Crisis Management Association. Retrieved 1 October 2014 is broken. Ppso (talk) 11:54, 14 June 2017 (UTC)

Yes a number of issues
It does look as though the entry here is obsolete but also not very informative. In the examples the tone is not encyclopedic but the sub topic could be greatly shortened to something like:


 * Problem -- My car won't run
 * Why #1 -- The engine won't start
 * Why #2 -- There is no gasoline for the engine
 * Why #3 -- Because the gas tank was not filled
 * Why #4 -- Because gasoline could not be purchased
 * Why #5 -- Because I'm unemployed
 * Why #6 -- Because there are no jobs I'm qualified for
 * Why #7 -- Because automation handles the tasks I was trained for now

The root cause of a problem consists of drilling down through as many "whys" as it takes to reach the bedrock cause, though at any step along the way a corrective action can be taken. Why 6 in my example can be corrected by re-training. Why #3 can be corrected by borrowing gasoline. Why #4 can be corrected by borrowing money. And so it goes.

Point being that RCA is performed to identify the root case but also to identify possible solutions that could have been taken at any step where the cause and contributing factors are identified.

I think that the examples section might benefit from a simpler format, basically a bullet-point series of examples which convey the methodology of RCA better. SoftwareThing (talk) 18:35, 23 July 2018 (UTC)

From a General Problem-Solving Strategy to RCA
This article was difficult to read. It included a lot of material describing a general problem-solving strategy, and it was difficult to see what pertained to RCA per se.

I have significantly edited it with a more Wikipedia tone, refocusing it on RCA and deleting almost everything related to corrective actions. I have also restructured the plan and added new sections. Hopefully, the article is now easier to read and clearer.

Section "Application domains" still needs more work. I have already added some material for two application domains that I know well (IT and telecoms), but the other application domains really need to be developed further.

I have also added several references, but more references are needed.

I meant to add a new section explaining various techniques for performing RCA (e.g., interviews of technicians in manufacturing, automated deductions based on monitoring data, case bases, and dependency graphs in IT), but it is getting late and I need to stop for now. We may also want to elaborate a bit on the data mining and case-based reasoning techniques that are used for automating RCA.

J.P. Martin-Flatin (talk) 02:33, 23 March 2019 (UTC)