Root Cause Analysis

Introduction

Good System Analysts never jump to a solution without making sure they fully understand the issues occurring and the cause of these issues.  This is to ensure that we don't solve the wrong problem and/or avoid applying the wrong solution.  Applying the appropriate technology to meet an organization’s challenges and opportunities distinguish the best analysts from the rest. The best organizations continuously strive for improved efficiency, management, and competitive advantage but only in a way that targets the real issues.  Whether solving problems or identifying opportunities, the key is always to identify the root cause(s).  To do this a root cause analysis process is followed.

Description

Before we explain how to perform a root cause analysis, we need to identify the 3 important components that we will identify when performing a root cause analysis:

• Symptoms are conditions that are produced by the problems or root cause, and are not the actual root cause we are trying to solve.  Symptoms are often things that we can observe (e.g. sales are stagnant; employees are unable to find documents they need to perform their job) but can't definitively say it's a problem or root cause.  More often than not, the cause of the problem and root cause are obscured by one or more symptoms. 
• Problems are caused by the root cause, and often cause the symptoms observed.  These tend to be more obvious or visible in our analysis.  A common and simple way to find the problem is to first identify a symptom and then ask why this symptom is happening.  Many times, the answer will lead you to the problem causing the symptom.  
• Root cause(s) is the underlying issue that is causing the identified problems, which cause the symptoms that we observe. The root cause is often less obvious and requires a thorough examination of the symptoms and problems to identify.  As you drill down to problems you can continue asking "why is this problem happening".  Once you reach a point that you can't ask why anymore, it's very possible you've found the root cause.

Figure 1.  Root Cause Analogy to a Tree

(image from https://www.slideshare.net/oeconsulting/root-cause-analysis-by-operational-excellence-consulting Links to an external site.)

It is critical to be able to identify the root cause so that we can find a solution to address the root cause. In the example above, we can treat a fever with fever-reducing medication. This will work for a few hours and can be repeated. However, without treating the infection that is causing the fever, the fever will continue to persist, as well as the symptoms, and the infection itself could get worse and cause additional problems and symptoms. The idea is similar to pulling weeds - if you don't remove the weed with its roots intact, the weed will regrow.

Process

When meeting with your client, you will ask many questions and the client will share a lot of information with you, particularly during the first few weeks of the project. Keep detailed notes of your questions, your client's responses, and general information your client shares with your team. If your client provides a response or information that doesn't completely clarify the situation or the point being addressed, ask more questions. Once you have collected a lot of information from your client and feel like your team is ready to work towards uncovering the root cause, we suggest you perform the following steps:

1. Hold a brainstorming session where you lay out all of the information that you have collected from your client using the notes taken during all of your client meetings. It may be helpful to reserve a conference room that has a whiteboard where you can add all the information for your team to see.
2. Review the information as a group and begin to identify the symptoms. It may be helpful to draw circles around the symptoms with a specific color marker.
3. Once you feel comfortable that you have separated the symptoms, begin asking the question "why is this symptom happening?" and see if the answer to that points you to a specific problem or even another symptom.   Review the remaining notes on the whiteboard and determine problems that may be causing the symptoms identified. A problem may cause a single symptom, or it may cause multiple symptoms. In addition, a single symptom may be caused by multiple problems. This process creates the problem chain.
   • If you have symptoms that lack a cause, evaluate whether you should gather more information from the client to identify the problem, or whether that symptom is outside of the scope of your project.
   • If you have problems that are not associated with any symptoms, brainstorm with your team whether any information has been missed or whether you should gather additional information from the client to understand the symptoms caused by the problem.
4. Finally, review the sets of problems that cause groups of symptoms (the problem chain), and identify with your team the underlying cause (root cause) of the problem chain.  Again, you drill into each problem by asking "why is this problem happening?" to get closer to the root cause of that problem.  Once you feel like there's no need to ask "why" anymore, it's possible you've landed on the root cause that you need to build a solution around.
5. The final step is to transfer the results of your analysis into the root cause template provided for the class. Do not use the template as a guide for your analysis - it's very important that you brainstorm and analyze the information you have collected from your client in a more organic process, and then transfer the results of this analysis into the template to organize your ideas for your client and for class.

Every problem produces a set of symptoms.  Your team should try to describe in detail the points of pain. This includes but is not limited to who is experiencing the difficulty, what the experience is, when it happens and how it impacts the rest of the organization or the entire firm.  Your job is to organize all this information into a problem chain that leads to the root cause.  Asking “why” after each symptom is described will enable you to logically create your problem chain. 

Example - Understanding Declining Profits

Using the root cause analysis process clearly distinguishes symptoms from actual problems and opportunities. In so doing, information specialists are able to recognize if the root cause is an IT problem and if it is, begin solving it with the systems process approach.

For example, an online firm that sells nutritional supplements is concerned about declining profits.  That’s the first “point of pain” illustrated as a symptom in Figure 1 below. A marketing manager argues they are losing customers to a competitor who posts great savings opportunities on Groupon. In an attempt to learn the real problem, the marketing manager asks the web site hosting company to research web traffic for several days when she knows there has been a Groupon offering by a competitor.  Web traffic metrics indicate that daily site usage this year is 20% higher than last year. The user traffic research also indicates that registered customers are buying about the same amount as they always have. The traffic metric that disturbs the marketing manager is that non-registered, first-time users rarely click all the way through to a purchase. (This is symptom 2 below.)  The web traffic graphs for each page on the company website indicate a couple of places where first time users often leave the site. Both frequent exit spots are before the posted prices pages, so price sensitivity is not the root cause - website confusion is the likely root cause.

Figure 2.  Problem Chain Example

Example - ASTA, former MIS 374 project

Here is an example:  Advanced System Technology Associates (ASTA) provides consulting services and software for factory automation. Their workforce consists mainly of engineers with a broad spectrum of technical expertise relating to their diverse factory automation systems that they manufacture and market around the world from offices in Austin and Dallas. The project request was to automate their paper-based “Skills Inventory System.”
They wanted to be able to quickly identify employees possessing the required knowledge and skills demanded by business opportunities as they emerged. Like most industrial marketing organizations, they respond to requests for proposals (RFPs) submitted by other firms. To be competitive, they need to respond quickly with proposals that show their relevant expertise and experience.

Figure 3 shows a high-level view of problems with the current skills set process.  The consultants interviewed key stakeholders during the first week of the project.  The stakeholders included three project managers in different company areas and Yolanda, the HR director.  The HR director was in charge of the manila folders that composed the current “skill set” data storage system.

The ASTA root Cause Analysis (Figure 5) shows how the team initially reported the results of their early interviews. Their recommendation was to create an automated Skills Inventory System, and they included two other recommendations based on their interviews with project managers. One was a market intelligence system to provide information for project managers about market trends and competitor activities to improve ASTA's ability to predict demand. Another was a warning to upper management that some ASTA employees seldom updated their skill set folders.  Even if the team created an easy-to-use, web-based Skills Inventory System the firm may need to create incentives or clearer rules about employees keeping their files updated.

Figure 3.  System Overview Graphic of Existing Skills Inventory System for ASTA

Summary of Potential Solutions

With the root cause identified, you and your team are ready to propose possible solutions that address the root cause(s) identified. Each root cause must be addressed by at least one solution, and it may be possible that a single solution addresses all root causes identified.  Some root causes may be addressed with non-IT related solutions, while others would benefit from an IT solution. You are not expected to implement non-IT solutions if they are outside of the scope of our class (e.g. HR related solutions). All of the MIS 374 clients would benefit from an IT-related solution, so be sure to include at least one that you will implement as a team.

Objectives, Performance Criteria, & Constraints

The final section of the root cause analysis is a recommendation for a project solution(s) with proposed objectives, measurable performance criteria, and constraints. Discussing these options with your team early in the development process builds trust between all interested parties and gives your team a chance to make an informed decision about the best solution.  System objectives take into account: accuracy, timeliness, completeness, and relevance. Using broad, general terms identify the new system’s objectives. This is a first attempt at defining your project scope at a high level. 

The next step is identifying the performance criteria of the new system.  These are the stated, measurable goals the system must meet. Collaborating with your team, establish quantifiable performance criteria and document all measurements.

All the while, keep in mind that there will be internal and external constraints impacting your objectives and performance criteria and therefore your new system. What is the budget for the new system?  How does it impact the hardware and software requirements? What is the personnel situation?  Who can/will maintain the system after development ends and the system is in production? What are the system security risks and how does this impact the budget? How committed is the client?  How committed are you, the developers?

System constraints are many and varied.  Reality and honesty regarding scope, schedule and resources go a long way in distinguishing a successful system from an unsuccessful one.  The triple constraints of scope, schedule, and resources illustrate the inter-related nature of IT projects, as shown in Figure 4.  It is often possible to achieve two of these targets fairly easily, but adding the third can make or break project success.

Figure 4.  Triple Constraints of Projects

Benefits

Going through the logical process of identifying symptoms of the problem and creating a problem chain leading to a root cause ensures that you are solving a problem and not wasting time treating a symptom that is a false lead—like the marketing manager in the example who thought advertising by competitors was the problem when poor website navigation was the root cause.  

Tips for Completeness

• Be careful not to jump too quickly to solutions. For example, a team was working on building a website for the display and sale of items for an artist who did original works, as well as cards and T-shirts. The team identified symptoms for the artist’s web site as difficulties faced by Judy Paul, the artist, or her customers. It is tempting to list some of their underlying problems, like “lack of a shopping cart” as a symptom.  But that’s a possible solution, not a symptom. If you jump to design decisions—like “Judy.Paul.com needs a shopping cart”—your team might decide that a quick add-on for a shopping cart is all Judy Paul needs.  When they considered all the points of pain in the list of symptoms, it was obvious there were more reasons for lower sales than just the lack of a shopping cart.
• Be aware that technology is not the answer to every problem. Sometimes organizational problems surface as part of a root cause analysis. So also be aware of how organizational issues can impact the technology solution you are providing. Non- IT issues can sabotage your technological success! Information technology specialists must always ask themselves, “Is this a problem I should try to solve?” If not, is it a problem that you need to bring to the attention of management? For example, some employees may be unwilling to follow perfectly good procedures correctly because they do not understand the system or there is too little time to perform the prescribed tasks or even some reason unrelated to technology.  When technology is not the answer to a problem you discover, work with your clients to encourage an organizational solution.  For example, the ASTA team identified what they called a Human Resource Problem and suggested a solution in their root cause analysis. The client’s’ project goal was a Skills Inventory System that employees had to update quarterly, but the employee response was poor to management requests for these updates. Along with the web-based Skills Inventory System, the ASTA project team also recommended that ASTA HR provide a solution ensuring quarterly firm-wide updating of the Skills Inventory System, otherwise their system development work would have limited value to the managers relying on the system data.

Figure 5.  Example Root Cause Analysis

Note that Objectives and Performance Criteria have not been provided for two potential solutions: a Market Intelligence System and Human Resource Improvements. Our class schedule constraint eliminates the Market Intelligence System for this semester. The Human Resource issues are best approached by ASTA management

FAQs

Q1. What is the difference between a Problem Chain and Root Cause Analysis? Answer: MIS professionals use both terms to refer to a process of looking at complaints (or symptoms) and investigating what the real cause (root cause) is before recommending solutions. In MIS 374 we identify the “problem chain” as part of a Root Cause Analysis.  Some organizations include the same sections of a Root Cause Analysis that we do and call it Problem Chain Analysis. Others have different sections and different names, e.g. “Investigation Summary” for a summary of the steps that led to eliminating possible underlying problems as the root cause of the complaints.  MIS 374 exercises, exam questions, and project requirements will require all the parts discussed here. 

Q2.  Do we have to have three solutions like the ASTA Example?  Answer:  No.  Your team may have a problem that you can manage within your schedule constraint and just suggest one solution.

Q3.  What if we don’t know the constraints?  Answer:  For the Latinitas case you have very little information, so guess what they might be for your Root Cause Analysis class exercise.  For Group Project 1, read the case for constraints.  For your client project, ask your client about constraints.

Pro Tips

• Start with your symptoms and keep asking why until it leads you to the underlying problem and root cause. 
• Each symptom should have at least one corresponding problem in the problem chain.
• Every solution’s objective should address the problems in the problem chain.
• Performance criteria must be measurable and quantifiable
• Symptoms, problems, objectives, and constraints should match the specific situation.

 

FYI: Other methods of Root Cause Analysis you could encounter

• 5 Whys Method – The simpler form of analysis is one that is done usually with management on a whiteboard. To do this, you would write the problem at the center of the board and make sure that all understand what the problem is.  You then ask “Why” that’s a problem and the answers are written as offshoots to for a bubble diagram.  Ideally, you will reach the root cause before asking why 5 times. While the 5 Whys is a powerful tool for engineers or tech-savvy individuals to help get to the true causes of problems, it has been criticized by the former managing director of global purchasing for Toyota, as being too basic a tool to analyze root causes to the depth that is needed to ensure that they are fixed.  Still, a simpler form of root cause like this could be more effective for clients overwhelmed by the more in-depth process used above and it can be helpful to use the 5 why rule as a way of drilling into a symptom in your brainstorming session in order to get down to the root cause.
• Fishbone Technique – This is also a method used that graphically displays the problem and unwraps the problem to find true root causes. If you do a web search for “Fishbone Diagram” you’ll see what this looks like.  Essentially a horizontal line is drawn across the board to the left or right of your problem.  As you answer the question “Why” you draw diagonal lines off the horizontal line to potential causes.  You can continue to draw further lines and drill down further.  The end result is a shape that some think looks like a fish skeleton, hence the name “fishbone”.

Key take-away – No matter what method you use, use one so you can be sure you’re solving the right problem

---

Resources 

Template: Root Cause Analysis Template Download Root Cause Analysis Template

Root Cause Analysis Examples: House of Songs Download House of Songs (Wordpress) Asset Mapping Download Asset Mapping (Custom)