Root Cause Analysis in Project Management
By Dave Nielsen
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:
- Identify and define the problem
- Gather information about the problem
- Identify relationships between all the possible causes of the problem by asking the question “why” recursively
- Identify which causes would eliminate the problem if they were removed
- Identify solutions which will be the most effective at eliminating the problem, without causing problems. The solutions must be within your control
- Implement the solutions
- 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 th