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 the symptoms of the problem. Finding the cause of the problem at the root level gives you a greater chance of removing or solving the problem as opposed to just 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. In another example, when a computer locks up, you 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, an 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 an RCA is to conduct a situational analysis that 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, and 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 prerequisite 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 Causal Factors by Gathering the Evidence

A causal factor is something that contributes to the problem but is not the root problem. In order to determine the causal factors, you will need to determine the sequence of events that led 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 causal 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 causal factors, start asking yourself, "Why?" You usually don'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 causal factors.

You could possibly make the mistake of choosing a causal factor as the root cause. If you do so and the problem occurs again, you can immediately discern that you selected a causal 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 through this process.

One idea to assist you in this step is to create a Problem Statement Document, which can be a one-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 or customers

    • Etc.

  • Potential impact of problem (same as above)

  • Risk value (e.g., high, medium, low, and so on)

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, and so on.

The problem can be more effectively tracked, providing a history of how the problem was solved, by creating a problem statement document. 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 while providing you some direction as to what you should consider as possible causes rather than just the obvious ones.

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.

Figure 1.1: Fishbone Diagram

Draw the "effect," or problem box, 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 "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 the following: 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 the bones of a fish.

Reviewing the cause categories allows 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 are 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 (e.g., financially), 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 can 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 no standard format for this report. However, you will want to document how the problem was solved. You could call it a "Lessons Learned" document that can be used in the future if the problem occurs again.

Previous Next