Root Cause Analysis (RCA)

Author's Avatar

Author: Daniel Croft

Daniel Croft is an experienced continuous improvement manager with a Lean Six Sigma Black Belt and a Bachelor's degree in Business Management. With more than ten years of experience applying his skills across various industries, Daniel specializes in optimizing processes and improving efficiency. His approach combines practical experience with a deep understanding of business fundamentals to drive meaningful change.

Root cause analysis (RCA) is a range of tools and techniques used to establish the true root cause of a problem so that a solution can be implemented to address the root cause, rather than addressing the more visible symptom which often causes the problem to reappear elsewhere, therefore not solving the problem, but simply moving the issue to a different place in the process.

What is Root Cause Analysis?

Root Cause Analysis is a range of tools and techniques used to address a problem in a business, we define a problem as the difference between what is happening vs what should be happening (an abnormal occurrence) E.g., Product defects, late deliveries, processes not running at correct speed etc. The tools and techniques used in Root cause analysis aim to identify the root cause of the problem so that it can be addressed directly rather than treating symptoms.

Identifying a root cause

How to identify problems?

Sometimes it is obvious when there are problems in the workplace when key performance indicators (KPIs) are not being met, but often they may not be so obvious and may require some investigation to identify problems.

There are ways in which we can identify problems in the workplace by looking at existing workplace information and data such as reviewing customer complaints, speaking to those in the business conducting the processes or reviewing accessible data on defect rates etc. For instances where data is not readily available you may need to collect data measuring actual performance against the expected target performance or run trend data analysis.

Note: Collecting data in business is essential to understand a process baseline to provide a benchmark to improve against, if you don’t know the current process performance it is difficult to set a target for achievement or to identify when a problem is occurring.

Types of Root Causes

RCA presumes that a set of methods and actions are interrelated and that an action taken in one area triggers an action in another area. Therefore, with RCA we are looking for that initial action that is taken that triggers an issue elsewhere.

You will usually find three basic types of causes:

Human Causes – Someone did something wrong or did not do something that needed to be done. Human causes typically lead to the impact of a physical cause. E.g., An action not being taken such as safety checks or equipment calibration.

Physical Causes – A tangible, material failure of an item in some way. E.g., A produce defect.

Organisational Causes – A system or process that those in the organisation use or follow to make decisions causes a fault. E.g. Standard work instructions being followed leads to a process failure.

The tools and Techniques used in Root Cause Analysis

Within Root Cause Analysis there are a range of tools and techniques that are commonly used and recognised around the world. These can often follow the processes of A3 Problem Solving or 8 Disciplines in many multinational organisations and particularly in automotive organisations.

Ishikawa Diagram

An Ishikawa Diagram, also known by a range of other names such as Fishbone diagram cause of how it looks, Cause and Effect diagram or 6M. The Ishikawa diagram was developed during the 1960s as a way to measure quality control processes in the shipbuilding industry.

An Ishikawa diagram is a diagram that causes the causes of an event and often using within manufacturing and production to outline different steps in a process and identify where a quality control issue might arise.

RCA Example Fishbone analysis

5 Whys

The 5 Whys analysis, often referred to as Why-Why analysis is a useful tool based on the question of Why. The 5 Whys method is part of the Toyota Production System (TPS). Developed by Sakichi Toyoda who was a Japanese inventor and industrialist and to this day 5 Whys have become an integral part of the Lean Methodology.

5 whys is the basis of using the basic approach of asking why five times whenever a problem is found. By asking why 5 times the root cause of the problem, as well as the solution, become clear. When applying the 5 Whys technique, you want to get to the root cause of the problem and fix the source of the problem which is often quite unexpected. Often issues that can be considered human problems turn out to be technical or process problems.

5 Whys Analysis Tree

Finding the true root cause with 5 Why can help to eliminate the crucial root of the problem and avoid further iterations of failure.

Pareto Charts

Pareto charts are a great tool to use in Root Cause Analysis when you have data available to support the identification of root causes. Pareto Charts are based on the Pareto principle (80/20) rule that 20% of cases represent 80% of the effects. This is extremely useful in root cause analysis as it helps direct you towards the main causes of the problem and treat the right categories of problems. #

Like in the example below where the problem is customer complaints of a call centre’s service the Pareto shows that 80% of the complaints come from either customer service not being helpful, or too long on hold. Directing the project team to focus on those areas of the problem allowing for resolving 80% of the issues with only 20% of the effort.

Example of Pareto chart for customer complaints
Example of Pareto chart for customer complaints

The Root Cause Analysis Process

The Root Cause Analysis process follows a process similar to the 8D process to provide a structured and clear method for identifying, containing, correcting and preventing problems.

Define the team

The first step is to define the team which is a vital step and requires the inclusion of key individuals depending on the nature of the problem. Multi-skilling and flexibility are critical for a team to achieve business improvement.

These teams can often include:

  • Facilitator
  • An employee from the place where the issue occurred
  • Team leader
  • A process expert
  • A challenger
  • Supplier or customer (if impacted for involved).

Additional people can also be drafted as required to support the root causes analysis and support solution identification.

Clarify the problem

Once a project team has been pulled together it is important to ensure the project team has a good understanding of the problem, where possible supported by data. This stage should include the data collection, analysis and interpretation of data which is shared among the project team to create a common baseline for the issues.

At this point, it is commonplace to use Histograms and Pareto charts to display the data.

Interim containment actions

The next step is interim containment actions which should be taken before the root causes is identified and solutions are implemented. Often the problems identified impact products and services that go to the customers so it is vital to protect the customers and as a result the organisation’s reputation.

These should only be temporary actions and not long-term fixes to the problem as containment actions can often be very expensive in both time and actual costs.

Examples of short-term containment actions could include:

  • 100% inspection of the product or service before progressing further in the process.
  • Implementing additional machine checks
  • Outsourcing manufacturing to other production lines.

These actions should only be used until permanent corrective actions have been implemented and proven, they should then be removed.

Root Cause Analysis

Once the problem has been contained it is time to use the Root Cause analysis tools such as the Ishikawa Diagram and the 5 Whys analysis to get to the root cause of the problem.

The Ishikawa diagram should be completed with the project team with the focus on what the problem is that was defined in an earlier step, using the power of group think to identify potential causes and listing them on the Ishikawa diagram. The ideas generated should then be prioritised by the project team and explored to identify the root cause by using the 5 Whys analysis and verifying the hypothesis with data collection and analysis.

Permanent Countermeasures – Corrective actions

Once the root cause is verified, it is time to identify suitable permanent countermeasures to the root cause identified to remove the problem from the process. Solutions to the problem are always unique to the business and the problem identified which makes selecting the right project team critical.

These solutions are generated with group think, then voted on by the project team and verified with testing and trials to verify the solutions solve the problem permanently. This would include reviewing data to check that the solution has worked, collecting customer feedback if this impacts the customer and tacking and reviewing key performance measures.

Preventative Actions

Once the permanent countermeasures have been put in place, it is important to ensure that they are sustained. This step is to ensure that standard operating procedures (SOPs), work instructions etc are updated to reflect the change. Training has been updated as well as any associated training skills matrixes, engineering drawings and operating systems are also updated.

Having updated all documentation, the personnel impacted by the change should also be made aware of the changes, updating relevant management, customers, and suppliers as well as operators.

Furthermore, audits and checks can be carried out after this to ensure the sustainment of the changes is continued.

Recognise Team Contributions

Finally, every good project closes with recognition of the team’s involvement, support and success. This can be done using a range of methods, such as displaying the success of the project on notice boards, formal presentations to management and acknowledging the value and significance of the team’s results from the project.

Conclusion

In conclusion Root cause analysis is a vital process that organisations can use to solve workplace problems using the standardised RCA process with a supportive problem-solving team and using tools and techniques such as Fishbone Diagram, 5Whys and Pareto data analysis.

Author