1.3 Root Cause Analysis

Another method of problem solving is called Root Cause Analysis (RCA). This iterative (or repeating) procedure focuses on finding and correcting the root cause of the problem rather than focusing on the symptoms of the problem. By finding the cause of the problem at the root level you have a greater chance of removing or solving the problem rather than focusing on the symptoms being caused by the problem. For example, let’s imagine a scenario where you plug in every computer in your room and if you turn them all on you trip the electrical circuit breaker. In regular problem solving you would address the symptom, meaning you need the power back on so you simply go to the circuit breaker and switch the breaker back on. This works great until the next time you turn on all the computers and trip the breaker again. Far too many businesses focus on the symptom rather than the root cause. The computer locked up so reboot the computer. This does not solve the problem but treats the symptom.

Although you temporarily solve the problem you have not addressed the root cause. You are only addressing the symptoms. For example, a RCA would possibly require you to add a larger circuit breaker for that room that can handle a higher amp. Determining which application is causing the computer to lock up might require an update to that program. Problem solved!

Pre Step - Situational Analysis

The first step in performing a RCA is to conduct a situational analysis which identifies the problem, its severity and its causes. This analysis can also identify the individuals affected by the problem, the context in which the problem exists, any factors that will stop or produce a change.

The situational analysis acts as the guideline for conducting the RCA. It establishes the “picture” of what is going on (the current situation) and what needs to be fixed. This pre-requisite step sets the vision for the work to be completed.

Throughout the entire process make sure you consult with the customer or client who is experiencing the problem!

Step 1 – Identify Casual Factors by Gathering the Evidence

A casual factor is something that contributes to the problem but is not the root problem. In order to determine the casual factors, you will need to determine the sequence of events that lead to the root problem. For example, plug in computer one, plug in computer two, turn on printer, and the power breaker pops. You don’t really know the solution yet but you understand the casual factors that cause the problem.

Gather all of the artifacts or history of what is happening. Each of these items will help you identify the true problem that is occurring.

Step 2 - Identify the Root Cause (Problem)

Now that you have identified many casual factors, start asking yourself "Why"? One usually doesn’t see the root cause until you start to dig deep into what is going on. If you identify a problem, keep asking why until you get down to the root cause. This is very similar to the common problem-solving steps. You might think you know the root problem when in fact you are simply identifying casual factors.

You could possibly make the mistake of choosing a casual factor as the root cause. If you do so and the problem occurs again, you can immediately discern that you selected a casual factor instead of the root cause and return to step two asking "why". Also, be aware that you might identify more than one root cause thru this process.

One idea is to assist you in this step is to create a Problem Statement Document which can be a 1-page document describing the problem being addressed. There is no set format but items recommended to be included in this document may include:

  • Project Identifier (some unique code used to identify the problem. You can define this value.)
  • Description of Problem being investigated
  • Date(s) problem occurred
  • Owner or stakeholder assigned to handle this problem (NOTE: You could also list all stakeholders – those being affected by the problem.)
  • Where did the problem occur?
  • Actual impact of problem
    • Monetary cost
    • Reputation to organization
    • Revenue
    • Loss of business/customer
    • Etc.
  • Potential impact of problem (same as above)
  • Risk value (i.e. High, Medium, etc.)

This document provides a means of tracking the status of the problem and the current status of solving the problem. You might even want to include a current status in the document which could include:

  • Date
  • Current status
  • Currently assigned to

As stated earlier, there isn’t really a standard format for creating this document but the key is to just create it. It could be a Word file, Excel file, database record, etc.

By creating a problem statement document the problem can be more effectively tracked providing a history of how the problem was solved. This document could be used if the problem ever occurs again.

Step 3 – Identify Challenges (Analyze the Cause and Effect)

After you have identified the problem to be solved you need to determine what is causing the problem. A Cause and Effect Analysis (also called an Ishikawa or Fishbone diagram) allows you to build a model showing the problem and each of the likely causes. This can visually demonstrate the causes and the relationship to the problem along with providing you some direction as to what you should consider as possible causes rather than just the obvious one.

This step allows you to brainstorm to create a list of challenges affecting or causing the problem. No idea should be eliminated in the discovery process.

Start by writing down the problem to be solved on the left side of the page. This is similar to drawing a fish head on what will be the skeletal body of the fish. It is extremely important to make sure you define the problem correctly in the previous step 2.

Figure 1.1:

The "Effect", or problem box is drawn on the right side of the page. Then draw a straight line from the box (or the head) to the left of the page. We will draw a fishbone diagram to help solve the problem of the "Team is continuously missing deadlines". Now decide on some “Cause Categories” associated with the problem and write those above and below the straight line. In our sample, we have determined that the main causes are: People, Procedures, Environment, and Technology. Those categories are general topics that cause the problem. The next step is to draw lines from the straight line to the cause categories which will resemble bones of a fish.

Reviewing the cause categories allow you to generate a list of causes. For example, under the People categories we have determined that we need more team members and new company employees lack training. Under the Procedures category we have listed that the schedule was unrealistic. Continue listing the causes for each category. Just keep asking why on each of the categories until you get to the root of the problem.

Now that the problem has been documented, start asking "What caused the problem or what caused the effect?" In other words, determine the factors that contributed to or be a part of the problem.

You can use the final result to provide you with a list of all of the causes you should consider for the problem.

Step 4 – Solutions

The cause and effect diagram will provide a list of solutions. Any "cause" is a potential candidate for a solution. In fact, in order to solve the problem, you might need to solve a group of causes. The solution should minimize the risk of occurrence, be effective, be implementable, logically make sense to solve the problem (i.e. financially, etc.), and should not cause other problems.

The problem can be solved by controlling, altering, or eliminating any of the causes. One should be aware that there may be situations where solving one problem creates a new problem. Another problem is that there actually be more than one root cause. If so, you continue the problem-solving process until you have a stable environment … until the next problem occurs.

Step 5 – Final Report

Once the problem-solving process has been completed you need to assemble a final report. There is not standard format for this report. However, you will want to document how the problem was solved. You could call it a "Lessons Learned" document which can be used in the future if the problem occurs again.

Previous Next