An Overview of Root Cause Analysis


What is root cause analysis?

Quite simply, root cause analysis is a technique designed to unearth the real, often unknown reason why a business problem is happening, and then to propose a viable solution to fix it. BABOK explains that root cause analysis “can help identify the underlying cause of failures or difficulties in accomplishing business analysis work”[1] [emphasis added] and further clarifies that it is “used to ensure that the underlying reason for a defect is identified, rather than simply correcting the output (which may be a symptom of a deeper underlying problem).” One site defines it similarly as “finding the real cause of the problem and dealing with it rather than simply continuing to deal with the symptoms.” [2]  So the reasoning behind the technique is that if an organization has an unexamined problem, they are probably just treating the symptom—giving it a metaphorical aspirin, rather than eliminating the real cause of the headache.

An Overview of Root Cause AnalysisHere’s a simple, everyday example of employing this technique. Suppose a company manager notices his deadline-pressed, overloaded workers are leaving their remote headquarters each day to drive 20 minutes into town for lunch. Usually, the salaried workers are gone longer than their lunch hour. The manager decides to build an on-site cafeteria to encourage salaried workers to at least stay at headquarters and maybe even work through lunch at their desks. The manager reasons that an on-site eatery could glean as much an extra hour of work each day from workers—meaning hundreds of extra hours put in each week to benefit the company.

Those tasked with carrying out the manager’s directive then have two choices. They can address the superficial problem by hiring contractors, buying equipment, and building the onsite cafeteria. Or, they can request permission to do a bit of research first, compile the resulting data, and find out what might persuade workers to put in an extra hour each day. Why are workers leaving the office? Do they need a mental break in the pressured environment? Would an onsite gym serve them and their productivity better? Or perhaps a catered, free lunch would be both cheaper for the company and boost more morale among the workers. You never know answers like these until you gather existing data and then ask the right questions.

Enter the highly thorough business analysis technique of root cause analysis, which gets to the root of why things are really happening so that the true business need can be determined. This does not mean stating why management, or customers, or even the business analyst believes that something is happening, but researching the real, chartable reason why.

So how do you perform root cause analysis and get to the bottom of things?

First, define the problem. Ask: What is the problem that we’re facing? What are we currently doing to fix this? How often are we doing it? Who is it affecting? And so on. Gather all data documenting the problem, and quantify it to whatever extent you are able. (For example, 140 customer complaints, 81 returns, and so on.) A flowchart may be useful in documenting what is occurring.

One writer notes that there are three types of causes to most organizational problems—physical causes (something broke), human causes (human error), or organizational causes (a system or process is faulty)[3]. Be sure to consider each of these when gathering data to define your problem. (The applicable causes will make up part of the “bones” for your fishbone chart, explained below.) This data-gathering phase may well be the most time-consuming part of the root cause analysis process, but the accuracy of the research is essential, so there should be no shortcuts.

Then, together with the appropriate stakeholders, ask why the documented problem is occurring.

When that initial why question is answered, ask why that problem is occurring. Then ask why that one is occurring, and so on until you reach a “eureka” moment, or your conclusions start to become redundant. One writer notes that this phase of the process is asking “why the problem occurred, and then continuing to ask why . . . until we reach the fundamental process element that failed.”[4] (See a useful technique called “The Five Whys) Tools such as brainstorming and focus groups are likely to be useful in doing research during this “why” phase.

Additionally, a fishbone diagram (sometimes called a cause and effect diagram) is also likely to be useful in documenting why a problem is occurring. Vaguely resembling a fishbone, a fishbone diagram identifies multiple causes for a problem. When doing your brainstorming or research with stakeholders, the area you are examining is a “bone” on the diagram, and the problem within the area as well its “why” root are diagrammed off of it. An example is below:
fishbone diagram (sometimes called a cause and effect diagram)

BABOK notes that a fishbone diagram not only identifies the “underlying causes of an ob¬served problem [but] the relationships that exist between those causes.” (Other diagrams, such as data flow diagrams, may be useful during this phase as well, particularly if your group is more comfortable with the technique but fishbone diagrams are most commonly referenced for root cause analysis.) Many online software tools, such as XMind ( will create fishbone diagrams. For more about using fishbone diagrams in root cause analysis, see "What is a fishbone diagram?"

The data in your why phase should lead you to the root of the problem. In our sample diagram, it appears to be pointing to the need to hire more staff, or take a retreat or long work weekend to address some underlying issues within the company.

Finally, gather all of your data and present it to appropriate stakeholders and management. Once you present your findings, management is likely to have one bottom line question—what is the cost to remove the root cause versus implementing (or continuing to implement) an ad hoc fix? An analyst will need to get an estimate on the cost of removing the root cause as well as continuing to implement the ad hoc fix, in so far as these are available, and present them to management with their findings. Be sure to also include any risks associated with implementing the root cause solution versus treating the symptom.

So is root cause analysis right for your project or business process right now? It depends on your time and needs. Consider that time is a risk that is almost invariably associated with any root cause analysis process. Getting to the bottom of something is time-consuming. And the greater the project or business need, and the more system or stakeholders involved, the more time one can expect this technique to consume. As BABOK notes, “If there is a strict deadline to deliver the solution. . . . root cause analysis of the problems can take more time and resources than are available.” Even so, root cause analysis has strong advantages. As one site succinctly puts it, “Root Cause is the factor that, when you fix it, the problem goes away and doesn’t come back.” [5] In this economic climate, getting rid of a workaround or continual fix to a symptom may be a great solution for a company as well as its personnel.

Author: Morgan Masters is Business Analyst and Staff Writer at, the premier community and resource portal for business analysts. Business analysis resources such as articles, blogs, templates, forums, books, along with a thriving business analyst community can be found at

[1] A Guide to the Business Analyst’s Body of Knowledge® (BABOK® Guide), Version 2.0, International Institute of Business Analysis, Toronto, Ontario, Canada, ©2005, 2006, 2008, 2009.
[2] Accessed November 27, 2011.
[3] Accessed November 27, 2011.
[4] Accessed November 27, 2011.
[5] Accessed November 27, 2011.

Like this article:
  15 members liked this article


Tony Markos posted on Friday, September 7, 2012 7:47 AM

Very good article. Root cause analysis forces one to look closer at the business at hand, avoid the temptation to prematurely jump into solutions.

Just a note on Data Flow Diagrams and how specifically they help in Root Cause Analysis. Often, even senior level operations managers do not have an adequate understanding of what the inputs into the processes under their control are. And without such an understanding, problems whose root is process related will remain indeterminate. DFD's uniquely actually guide BA's through a rigorous input (and output) discovery. This is a major advantage of DFD's over sequence-based (i.e., non-input-putput based) flow charting techniques.

zarfman posted on Wednesday, September 12, 2012 7:29 PM

Zarfman here:

With regard to Root Cause analysis, time is a very important factor.

How much time has passed before the problem was discovered?

How much time passes before the problem solution is determined and implemented?

How much time has passed before one knows if the proposed solution worked?

If too much time passes severe legal sanctions may apply, the company may fail, etc.

One can also ask, are there dependencies that affect to root cause?

It's easy to say lets do a root cause analysis, but, actually solving the problem is another matter.

Accordingly, I agree with ajmarkos and his comment regarding lack of knowledge and indeterminate solutions.

Travis Barker MPA GCPM posted on Monday, November 5, 2012 3:17 AM
Thanks for writing the article.

It was very informative. I agree with youir points that management is usually left without the resources, support, or time necessary to focus on the cause of the problem. The emphasis is instead on the symptoms.

The symptoms effect short term profits, which are immediately apparent to stakeholders; whereas the roots of the problems affect long term profits, which requires patience and tolerance of the risks that surface while waiting.

Financial sustainability of financial weak corporations requires focus on short term benefits whereas competitive sustainability of innovative & strong corporations requires focus on the effective utilization long term advantages.

Thanks again.

Travis Barker, MPA GCPM
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC