Project Management ABC: R for Root Cause Analysis

Tackling Project Problems at Their Root

What exactly is root cause analysis?

Root cause analysis is a structured approach to identifying the root cause of a problem, rather than just its visible effects.

Let's take a classic example:
Your project has repeatedly fallen behind schedule. The apparent cause seems to be a delayed delivery of components. An RCA, however, would dig deeper and ask, for example:

• Why were the components delivered late?
• Why did the supplier plan for insufficient capacity?
• Why wasn't a risk assessment conducted before the order was placed?

This is how you move from symptoms to causes. And only once you understand the causes can you implement lasting solutions to prevent similar problems in the future.

Root Cause Analysis in Practice: A Well-Known Example
The 1986 explosion of the space shuttle Challenger is often cited in engineering as a tragic example of RCA. Initially, the fault was attributed to “material failure” of the O-rings in cold temperatures. However, the root cause analysis revealed that management decisions and a disregard for warnings from engineers were the actual causes.

An RCA therefore often uncovers not only technical causes, but also organizational and communication-related ones.

Why is RCA so important in project management?

1. It prevents recurring problems, thereby saving time, money, and stress. Those who master RCA stop playing “firefighter” and become strategic planners.
2. It sustainably improves quality, as RCA focuses on systematic improvement rather than frantic ad-hoc fixes.
3. Strengthens teamwork, because an RCA should not be used to find someone to blame, but is a neutral method for learning together.
4. Supports lessons learned.

Typical Methods of Root Cause Analysis

1. The 5 Whys Method

The 5 Whys method is the classic among RCA tools. It was developed by Sakichi Toyoda as part of the well-known Toyota Production System. The core of the method is to ask “Why?” five times in order to gradually uncover the causal chain of a problem and thus move from the surface of the problem to its root cause. The number five is not a rule; sometimes three “Whys” are enough, while other times seven are needed.
The method is very easy to implement and is therefore often used in workshops. First, the problem is precisely defined. Then, the question “Why?” is asked about the event that immediately preceded it. In other words, the first question asks why the problem occurred. The next question is then asked about the previous answer.

Example from everyday project work:
Problem: Project progress is behind schedule
Why? Task A was not completed as planned
Why? Employee X did not have enough time to complete the tasks
Why? Employee X’s vacation was not taken into account in resource planning
Why? There was no synchronization with the vacation schedule
Why? Vacation schedules are not entered into the PM tool
Cause: Lack of integration of HR data into project planning.

Our tip: Even though this method is very easy to implement, you should carry it out as a team rather than alone at your desk. This way, the problem is examined from different perspectives, and you can identify the actual cause. Working together also makes it easier to determine whether an answer is truly the root cause or whether it merely provides a partial explanation.

2. Ishikawa Diagram (Fishbone Diagram or Cause-and-Effect Diagram)

The Ishikawa diagram is ideal for complex problems with multiple contributing factors. It visualizes relationships and causes in categories such as:

• Human (e.g., lack of skills)
• Machine (e.g., software errors)
• Method (e.g., inefficient processes)
• Material (e.g., supply bottlenecks)
• Environment (e.g., company policy)
• Measurement (e.g., incorrect KPIs)

You can find a detailed explanation of the Ishikawa diagram in this post.

3. Fault Tree Analysis (FTA)

Fault Tree Analysis (FTA) is an analytical technique that originated in the fields of safety and risk engineering but is also highly valuable in project management. FTA is particularly effective when dealing with technical or systemic problems. It uses logical gate diagrams (“AND,” “OR”) to identify which combinations of causes lead to a problem.

Here's how the method works:

1. Start with the top event. This is the undesirable event to be analyzed (e.g., “The system has failed”).
2. Next, identify all immediate causes.
3. Represent the causes using logical relationships. There are two options for these relationships:
   • AND means that all causes must occur simultaneously for the top event to happen.
   • OR means that even one of the causes is sufficient to trigger the top event.
4. Break down each cause further until you can no longer analyze it any deeper or further analysis becomes uneconomical.

Example from a software project:
Top Event: Web server is down
Causes (OR relationship): Hardware failure OR system overload OR faulty update. The top event can therefore be triggered independently by any of the three identified causes.
However, upon further analysis of the cause “system overload,” it becomes apparent that the causes “sudden high traffic” and “no load balancing enabled” trigger the top event when they occur simultaneously (AND operator). Here, the FTA shows that it is not just the high traffic that is the problem, but rather the lack of a scalable architecture that represents the actual vulnerability.

Our tip: The FTA is more time-consuming to prepare. Therefore, you should use it primarily for critical risks or issues related to security and compliance.

Tips for Choosing a Method

Best Practices

• Define the problem clearly and in measurable terms. “Project delay” is too vague. A better example would be “Delivery A is 3 days past the deadline.” Back up the problem with facts, such as how long it has existed, who it affects, and what consequences or symptoms the problem causes. This will give you a comprehensive picture of the problem and allow you to analyze the root causes more precisely later on.
• Involve the team. The best insights often come from front-line employees, not just the project manager. Involving your team also speeds up the process of finding solutions and helps you identify causes for which you yourself may have been responsible.
• Distinguish between cause and responsibility. An RCA is not about assigning blame; it is a tool for continuous improvement. If you use it to assign blame, the team may be reluctant to participate in the future.
• Document the results. Lessons learned are only useful if they can be retrieved later and if the appropriate actions are taken based on them. Ideally, you should therefore document the results of the RCA in your project management system and create the necessary actions there right away.
• Use the RCA to identify corrective actions and make sure to implement them. That may sound obvious, but it’s often overlooked in day-to-day work. However, an analysis without follow-up actions is a waste of time.
• Use root cause analyses even when things go well, not just when problems arise. Such analyses can help ensure the successful implementation of future projects.

Common Mistakes in RCA

• Stopping too soon: The first cause is rarely the root cause, so it makes sense to ask further questions or use an additional method to get to the bottom of the actual causes.
• Failure to Prioritize: Not every cause is equally critical. Analyze the risk and impact of the various causes.
• Lack of sustainability: Documentation, lessons-learned sessions, and knowledge management are all part of the process.

Conclusion

Root Cause Analysis is a methodical approach to tackling problems at their root rather than merely treating symptoms. Project managers who consistently apply RCA prevent recurring problems, improve their processes in a sustainable way, and strengthen their team through collaborative learning.

Learn more about the myPARM project and portfolio management software:

Would you like to get to know myPARM in a demo? Then make an appointment with us right away!