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.
Here’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:
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 (www.xmind.net) 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 ModernAnalyst.com, 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 http://www.ModernAnalyst.com
[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] http://www.systems-thinking.org/rca/rootca.htm. Accessed November 27, 2011.
[3] http://www.mindtools.com/pages/article/newTMC_80.htm. Accessed November 27, 2011.
[4] http://www.au.af.mil/au/awc/awcgate/nasa/root_cause_analysis.pdf. Accessed November 27, 2011.
[5] http://www.au.af.mil/au/awc/awcgate/nasa/root_cause_analysis.pdf. Accessed November 27, 2011.