Project Smart ~ Exploring trends and developments in project management today

Calendar icon
Adobe PDF icon

Root Cause Analysis

~ By Dave Nielsen

Word cloud for Root Cause Analysis

When mistakes are made during the course of your project, and mistakes will be made, its important not to repeat them. Before you can avoid repetition you have to determine what caused the problem in the first place and Root Cause Analysis is one of the best tools out there for getting to the root of the problem.


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 used properly, 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 seven 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 standardised fishbone diagram which categorises the different groups of causes.

Fishbone diagram with six groups of causes
Figure 1 - Fishbone diagram with six groups of causes.

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 six categories, you can have as many or as few as you like. Analyse 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 one 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.

You won't need to use Root Cause Analysis to resolve every project problem, you will be able to identify the causes for most and the ability to resolve them. Problems that defy your ability to solve, or problems you aren't familiar with will lend themselves to Root Cause Analysis. When the entire team agrees that the problem exists RCA has the advantage that you can use the collective expertise of the team to augment your own and the actions that are identified are identified by the entire team so support for their implementation is much more likely.

Root Cause Analysis is an analytical tool that can be used with other monitoring and controlling Quality Management processes. These processes are part of the project management best practices described in the PMBOK. These are taught in most PMP courses and other PMP exam preparation training products. If you haven't been certified as a PMP by the PMI and would like to learn more about certification, visit the three O Project Solutions website at:


Be the first to comment on this article.

Add a comment

(never displayed)

Enter the word five backwards.
Notify me of new comments via email.
Remember my form inputs on this computer.

Tracking a Risk

Dial showing three levels of risk management

Risk management is a vital part of project management. Learn four key steps to help you evaluate and mitigate any risks on your project.

Taming MS Project

Gantt chart and plan

Microsoft Project can become a huge overhead, even for seasoned project managers. This article contains some tips and tricks that will help you tame the tool.

10 Steps to Finding a Project Manager

Blond female job applicant handing over her CV to a smiling businessman

Hiring a good project manager means you can sit back and relax knowing that the project tasks are being taken care of in a professional, productive and profitable manner.

But What is Best for the Customer?

Four business people's hands holding puzzle pieces

Ideally our project management methodology in a box process works perfectly for everyone. But clients come in all types and sizes and one size doesn't fit all.

PROJECT SMART is the project management resource that helps managers at all levels improve their performance. We provide an important knowledge base for those involved in managing projects of all kinds. With weekly exclusive updates, we keep you in touch with the latest project management thinking.

WE ARE CONNECTED ~ Follow us on social media to get regular updates and opinion on what's happening in the world of project management.

Latest Comments

Joseph Marandus commented on…
How to Apply PRINCE2: Engaging Senior Management in Your Projects
- Tue 21 March 1:59pm

Janine Greene commented on…
The Role of the Project Manager
- Fri 17 March 1:30pm

Ben commented on…
The Role of the Project Manager
- Sun 12 March 12:30pm

Latest tweets

General Project Management • No Sponsor #projectsmart #pmot about 8 days ago

General Project Management • Re: Software Product Delivery Plan for an Agile project #projectsmart #pmot about 9 days ago

General Project Management • Re: How do you track who from your human resources have related… #projectsmart #pmot about 10 days ago