Project management ABC: R for Root Cause Analysis

Getting to the root of problems in projects

What is root cause analysis anyway?

Root cause analysis is a structured approach to identifying the root cause of a problem and not just its visible impact.

Let’s take a classic example:
Your project is repeatedly behind schedule. The superficial cause appears to be a late delivery of components. However, an RCA would dig deeper and ask, for example:

• Why were the components delivered too late?
• Why has the supplier planned too little capacity?
• Why was no risk assessment carried out before the order was placed?

This will take you from symptoms to causes. And only when you know these can you implement sustainable solutions to avoid similar problems in the future.

Root Cause Analysis in practice: A well-known example
The explosion of the Challenger space shuttle in 1986 is often used as a tragic example of RCA in engineering. Originally, the fault was blamed on “material failure” of the O-rings in the cold. However, the root cause analysis showed that management decisions and disregard of warnings from engineers were the actual cause.

An RCA therefore often uncovers not only technical, but also organizational and communicative causes.

Why is the RCA so important in project management?

1. Prevents recurring problems and thus saves time, money and nerves. Mastering RCA means you stop playing “firefighter” and become a strategic designer.
2. Increases quality sustainably, as an RCA aims for systematic improvement instead of hectic ad hoc repairs.
3. Strengthens team thinking, because the 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 Why method

The 5 Why method is the classic RCA tool. It was invented 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 reveal the causal chain of a problem step by step and thus get from the surface of the problem to the actual cause. The number five is not a law, sometimes three “whys” are enough, but sometimes 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 immediately preceding event. In other words, the first question is why the problem occurred. Then the question is asked about the previous answer.

Example from everyday project work:
Problem: Project progress delayed
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 comparison with the vacation plan
Why? Vacation plans are not entered into the PM tool
Cause: Lack of integration of HR data into project planning.

Our tip: Even if the method is very easy to implement, you should carry it out as a team and not alone at your desk. This way, the problem is viewed from different angles and you can identify the actual cause. Together, it is also easier to check whether an answer is really the cause or whether it only provides a partial explanation.

2. ishikawa diagram (fishbone or cause-effect diagram)

The Isikawa diagram is ideal for complex problems with several influencing factors. It visualizes relationships and causes in categories such as:

• People (e.g. lack of skills)
• Machine (e.g. software error)
• 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 article.

3. fault tree analysis (FTA)

Fault tree analysis is an analytical technique that originally comes from safety and risk engineering, but also provides valuable services in project management. FTA shows its strengths particularly in the case of technical or systemic problems. It works with logical gate visualizations (“AND”, “OR”) to identify which combinations of causes lead to a problem.

This is how the method works:

1. Start with the top event. This is the unwanted event that is to be analyzed (e.g. “The system has failed”).
2. Then identify all immediate causes.
3. Represent the causes with logical links. There are two options for the links:
   • AND means that all causes must occur simultaneously for the top event to happen.
   • OR means that one of the causes can already trigger the top event.
4. Dissect each cause further until you cannot analyze it any deeper or further analysis becomes uneconomical.

Example from a software project:
Top event: Web server has failed
Causes (OR link): Hardware defect OR system overload OR faulty update. The top event can therefore be triggered independently of each other by any of the three identified causes.
However, further analysis of the cause “system overload” reveals that the causes “suddenly high traffic” and “no load balancing activated” trigger the top event when they occur simultaneously (AND link). The FTA therefore shows that it is not just the high traffic that is the problem, but that the lack of scaling architecture is the actual weak point.

Our tip: The FTA is more complex to create. You should therefore use it primarily for critical risks or problems with security and compliance relevance.

Tips for selecting methods

Best Practices

• Define the problem clearly and measurably. “Project delay” is too unspecific. “Delivery A exceeds deadline by 3 days” would be better. To do this, substantiate the problem with facts, e.g. how long it has existed, who it affects, what consequences or symptoms the problem causes. This will give you a comprehensive picture of the problem and allow you to analyze the causes in more detail later.
• Involve the team. The best insights often come from operational employees, not from the project manager alone. Involving your team also speeds up the process of finding a solution and helps you to see the causes for which you may have been responsible.
• Separate cause and responsibility. An RCA is not an assignment of blame, but 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 found later and the right measures are taken based on them. Ideally, you should therefore document the results of the RCA in your project management system and immediately create the necessary measures.
• Derive corrective measures from the RCA and make sure you implement them. This sounds banal, but is often forgotten in everyday life. However, an analysis without measures is a waste of time.
• Also use root cause analyses for successes, not just problems. Such analyses can contribute to the successful implementation of future projects.

Typical errors with the RCA

• Stop too soon: The first cause is rarely the root, so it makes sense to keep asking questions or use an additional method to get to the bottom of the actual causes.
• No prioritization: Not every cause is equally critical. Analyze the risk and impact of the various causes.
• No sustainability: Documentation, lessons learned sessions and knowledge management are part of this.

Conclusion

Root Cause Analysis is a methodical approach to getting to the root of problems instead of just curing symptoms. Project managers who apply RCA consistently prevent recurring problems, improve their processes sustainably and strengthen their team through joint learning.

Learn more about the project and portfolio management software myPARM:

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