Finding the Root Cause

Root Cause Analysis (RCA) is typically associated with operational activities, but there is no reason that the practices that make this tool so effective in getting at the root cause of operational problems can’t be used to determine the cause of a project problem. The Root Cause Analysis method, when properly used, gives the project manager the ability to diagnose a problem that negatively impacted the project and remove it when it is first noticed. Lessons Learned is a similar tool, but is not designed to address one specific problem, nor is it designed to be used on the spot. RCA is one of a family of tools I’ll call "continuous improvement” tools because their purpose is to improve project performance and they can be used over and over.

Root Cause Analysis should be used when the project manager notices a problem in the project. The problem could be due to any cause but RCA relies on early detection to work. Don’t wait until the problem is too large to ignore, perform the root cause analysis immediately upon noticing the problem. The problem could be work running behind schedule, a larger than normal number of defects in a product under test, or features missing from the deliverable. There are only two criteria a problem must meet to lend itself to resolution by RCA: it is detected early enough to solve, and it has a negative impact on project performance.

There is a general process that is the backbone of RCA and that process consists of 7 steps:

1. Identify and define the problem

2. Gather information about the problem

3. Identify relationships between all the possible causes of the problem by asking the question "why” recursively

4. Identify which causes would eliminate the problem if they were removed

5. Identify solutions which will be the most effective at eliminating the problem, without causing problems. The solutions must be within your control

6. Implement the solutions

7. Observe the effect of the solutions and repeat RCA if necessary

Recursively asking "why” when identifying the relationships between the various possible causes is at the core of RCA. Let me show you an example of how this might work on a software project. The problem is that you have missed the deadline for one of your iterations. All the software was ready except for one module which was the responsibility of one programmer. Start by stating the problem: the delivery date for module x was missed – why? Because the programmer delivered it late – why? Because they couldn’t complete the work in the time allowed – why? Because the estimate wasn’t accurate, or because the programmer lacks experience, or because the programmer didn’t have access to the tools they needed, etc. Once you’ve asked "why” as often as possible and the causes are traced back to every possible cause, you can go ahead with identifying the solution.

There are many tools available to the project manager embarking on an RCA exercise. Many, such as Pareto analysis, Barrier analysis, and Bayesian inference rely on statistics observed over time that the project manager simply won’t have. Kepner-Tregoe also offer a unique approach to problem solving. They’ve been using this unique approach for over 50 years so it does get results if used properly. Using the Kepner-Tregoe approach requires proper training which is beyond the scope of this article. If you’d like to explore using their approach, I’d recommend taking their course so that you’ll become proficient with their methods. The method I will use in this article is based on the Ishikawa or fishbone diagram.

This method requires you to conduct a workshop or brainstorming session. Collect all the information you can about the problem on your own. The method lends itself well to input from various SMEs (Subject Matter Experts) so identify project team members who are experienced enough in the area that the problem arose from to provide information and reserve their time for the workshop. Communicate all the information you have been able to uncover to the SMEs in advance of the workshop. The brainstorming session begins with a fishbone diagram on a whiteboard. The fishbone starts with the body of the fish, aligned with the causes of the problem and ends at the head with the problem statement. The various causes of the problem flow into the backbone which leads to the fish head, or cause. Start out with a standardized fishbone diagram which categorizes the different groups of causes as in the example below:

Figure 1

The categories used in this example are only suggestions. Choose the categories that make the most sense for your project. The number of categories is also a suggestion. There is no necessity to have 6 categories, you can have as many or as few as you like. Analyze the project environment and choose the categories that best suit the problem.

Ask your team of SMEs to jot down in a few words the causes they believe responsible for the problem in each of the categories on the diagram, then have them go to the whiteboard and paste them in the appropriate category. Take a few minutes to review the notes to detect duplicates, or causes that are similar. Eliminate duplicates and determine with the team whether the similar causes could be combined. Now go through the causes 1 at a time and asking the question "why” trace it back to the source. The idea here is to go from symptom to source and asking "why” until there is no answer is the best way to do this. Record the sub-causes and root causes on the diagram. Complete this exercise for each of the causes on the diagram until you’ve explored them all. Now look for duplicates in the root causes. The more apparent causes the root cause is responsible for, the more effective elimination of that root cause will be at removing the problem. There is no rule that dictates you must identify only one root cause with this exercise, but you shouldn’t come out of it with so many that elimination of them is impossible.

The next step is to identify the actions that would eliminate each of the root causes. There are two basic criteria that an action must meet: it must solve the problem and it must be possible for the team to perform. Ask the team to suggest actions in the areas they are most familiar with and control. You should take ownership of any Management related actions. Compare each action against these criteria and eliminate any that don’t meet both. Team members should be prepared to explain why they believe an action does not meet the criteria. The team should also agree with a decision to remove an action from the list of candidates.

This exercise may reduce the list to the point where all of the actions would be feasible in which case your exercise is over. If not, ask the team to rank each action against each of the criteria, using a scoring system that assigns a score for feasibility and effectiveness at correcting the problem. You can use a cardinal or ordinal system and you can either average scores or pick the score that receives the most votes. This will identify the actions that will have the greatest chance of eliminating the problem and you can select one or several to implement, depending on the need and your resources.

The final step is to implement the identified actions and observe their effectiveness at removing the problem. You may have to repeat this exercise in order to identify the real root cause and eliminate it, so don’t throw away any of your artifacts, such as the sticky notes, until you have verified that your problem is solved.