Root Cause Analysis

Root cause analysis is determining the real or root cause of an issue for a product or process that you or your company may face. There are a number of tools and techniques that a Business Analyst can use to help determine the root cause of an issue.

  1. Describe the issue or opportunity. It is important to describe the situation in easy-to-understand terms. Try and break down issues into smaller individual issues where possible. Prioritize the issues and see if some are linked to internal or external factors. Determine if this was a one-time or recurring issue.
  2. Collect information. Gather as much information about the situation as you can. Involve stakeholders whenever possible to give input to the situation. Sometimes it is the simple things that made a big difference.
  3. Use Diagrams: Using a cause-and-effect diagram also known as a Fishbone or Ishikawa diagram can help to determine the root cause of an issue. This diagram works well with the next step.
  4. Use the 5 Whys. A simple technique for identifying possible causes where a group of people will brainstorm an issue by first asking why something happened and then continuing to ask why for each answer. On average it may take you 5 why’s before you can discover the root cause.

Example problem: We have an unknown error message in our software.
Why did we get an error message? A. There was a bug in the software.
Why was there a bug in the software? A. There was a mistake in the code.
Why was there a mistake in the code? A. The mistake was missed during the testing phase.
Why was the mistake missed during the testing phase? A. There wasn’t a test case written to test that function.
Why wasn’t there a test case written for that function? A. There wasn’t a requirement to test that function.

From the example above you can see how asking why multiple times can help drill down to possible solutions to a problem. In this example, a solution could be to create a test case for that function that traces back to a requirement for that particular feature so that the testing team can test that function for bugs.

  1. Recreate the issue: Test to see if you can recreate the original problem. If you can recreate the issue in a test environment it may help to identify the root cause of the problem.
  2. Determine the best cause. Out of the possible causes, there should be one cause that stands out. If so, select this as your root cause and start to determine the solutions to prevent this issue from happening again.
  3. Determine solution. Identify all possible solutions and pick one solution that seems to be the best for the issue identified. Involve stakeholders in this process. Gather their feedback to see on selecting the best solution.
  4. Test the solution. Test the solution in a test environment where you recreated the issue if you were able to recreate the problem. This can often cost much less than testing in production. Make sure you create a test plan. This type of testing is very important and should be included in your SDLC. If you are unable to determine a solution you may have to redo the 5 Whys technique or try and break down the issue into smaller testable and solvable parts.
  5. Get signoff. You may want to get formal approval that this is the solution you have selected is the one you will go with. You do not want to be in a situation where you verbally agree that this is a possible solution and then you implement it and the solution doesn’t work and then people start playing the blame game. Get documented consensus that everyone agrees with the solution and also document any reasons why people would not agree with the solution. This information can be used to update project documentation.
  6. Take Action (Corrective and Preventive Action). Make sure you apply this solution and retrofit it to existing projects as required. Also, check for similar areas that where this type of issue is possible. It is better to deal with risk now than an issue later.
    I.e., Your team found a bug in their Auto Insurance billing system so it would be a good idea to check if your home insurance billing system has a similar bug.

Root cause analysis could be the difference between a one-time fix, repetitive support, and preventative maintenance. Take some time now to determine what issues you may face and it could save you time and money in the future.

By Morgan

CBAP and PMI-ACP with over 20 years of Project management and Business Analysis experience.