Safety – Root cause analysis examples
Root cause analysis examples
What is a root cause analysis?
Root cause analysis or 'RCA' is the processes of discovering the root or underlying causes of specific problems, issues or outcomes to identify appropriate solution and ultimately 'fix' the problem.
The idea and purpose behind root cause analysis is that delving into the root cause of an issues is a more effective way of properly treating a problem than simply treating the symptoms and issues as they arise.
For example, rather than simply replace your car tires when they keep on wearing down quickly, it would be advisable for a mechanic to check 'why' your car tires are wearing at a faster than normal rate so you (1) don't have to keep replacing your tires and so (2) the root cause doesn't create other undesirable issues due to suboptimal performance.
While the easier short term solution in the above root case analysis example might simply be to replace your tires, the better medium and long term solution is to discover the underlying problem and solve it.
Even so, many people, humans and companies suffer from a short term mindset, which leads to treating symptoms and leaving the root cause to persist.
In addition to requiring a slightly more long-term mindset, root cause analysis does require and involve some very intentional steps, techniques.
While solving a superficial symptom can be pretty straight forward, solving a root cause requires proven principles and methodologies with the goal of:
- Uncovering the root cause
- Understanding and analysing how this root cause can be fixed, and what we can learn from this root cause
- Applying and implementing what was learnt through the discovery process to the issue at hand and potentially other issues to in order to prevent future occurrences and improve performance
So what are the techniques and procedures involved with root cause analysis - and which example is most applicable for you?
Root cause analysis examples
The root cause analysis examples below are all generally applicable to root cause analyses across any industry which uses root cause analysis to uncover issues including construction, manufacturing and healthcare.
All of these industries have a deep focus on safety and quality, and on delivering projects with many moving pieces. Uncovering the root cause when one of these moving pieces goes wrong is critical to ensuring you deliver a better product or project next time.
All of these industries can use these examples and frameworks for guiding their root cause analyses.
5 Why's
One of the most common and well-known techniques of root cause analysis is the 5 whys. One of the reasons that the 5 whys approach has become widely adopted and accepted is that it is incredibly simple.
As you have probably gathered or already know, the process begins with asking why something happened, and then asking why 2-4 more times - or as many as it takes to get top the root cause.
An example of this 5 why root cause analysis may look like for a manufacturing company seeking to understand why customers have been giving products a low satisfaction or 'NPS' rating.
Start with the problem statement: Customers have been dissatisfied with the quality of products being shipped to them.
(1) Why are customer dissatisfied? Because the manufactured products were built to a specification which was different to what the customer expected and paid for.
(2) Why were products not manufactured to spec? Because an error occured when the specifications were written down by the lead manufacturer and sales person.
(3) Why was the wrong spec written down? Because the “start work” form requires the sales director’s approval before work can begin and slows the manufacturing process (or stops it when the director is out of the office).
(4) Why does the form contain an approval for the sales director? Because the sales director needs to be continually updated on sales for discussions with the CEO.
In this root cause analysis example, customers are recieiving low quality products because of a process issue at the sales and management level. Without a root cause analysis, the company may simply solve the problem by issuing new product and taking the revenue hit. But by performing a 5 why analysis, they were able to uncover a process issue which they can solve through better communication or dedicated tools.
The major strength of this root cause analysis example is that it is an incremental process which is very clear and easy to understand. The person conducting the analysis can peel back the layers on each why, uncovering possible issues throughout before hopefully coming to a conclusion after the 5th why which they can use to solve that root cause.
A good 5 whys analysis will also illustrate the relationship issues down the issue chain have with each other - and enable a person or team to de-couple some of those dependencies.
Fishbone diagram
Fishbone analysis is another root cause analysis example which is commonly used to uncover issues in manufacturing and other processes.
Called a fishbone diagram because the end result of the analysis is a diagram or mind-map which resembles a set of fishbones.
This is one of the strengths of the fishbone diagram over and above other root cause analysis examples; it provides a single worker with a framework for exploring potential issues down on 'paper', or provides a team with a strong and reliable brainstorming framework which everyone can participate and add value to.
The visual nature of the fishbone diagram can also be a weakness in this type of root cause analysis can become messy and unwieldy quite quickly - which makes it more difficult to narrow down the ultimate root cause.
Fishbone root cause analysis is very popular when the root cause is completely unknown. It opens up all the potential root causes associated with a specific issue from the outset of the analysis.
A good example of what this root cause analysis looks like in the construction industry. Let's assume a construction company experienced an incident because a safety hazard went unreported.
To uncover the root cause of this incident rather than simply rectifying the issue on the surface, the person or team would create the main 'fishbone' factors:
- Strategy
- Product/service
- People/process
- Tools/applications
- Technology/infrastructure
- Data/information
Now the brainstorming begins. In each of these main categories which could have led to the incident, think of as many possible causes which may be related to those categories.
For example, did a person see the hazard and not report it which may be due to safety culture, or was the person who saw the hazard unable to document it properly and report it to the right person - which could be related to tools and applications.
If it was decided that tools and applications were the problem, then the fishbone diagram would need to be expanded once again and new branches formed to uncover which tools or applications the person didn't have access to.
As you can see from this root cause analysis example, it is more brainstorm-y in nature, but can be really helpful in putting all of the potential causes on the table.
ICAM investigation
ICAM investigations or the 'incident cause analysis method' is a root cause analysis example which is predicated on discovering the root cause of incidents.
Created and implemented across many industries, the adoption of the ICAM investigation has seen a movement away from simply identifying incidents and judging based on whether they were intentional or unintentional to a more comprehensive analysis on all contributing factors.
In slight contrast to the above root cause analysis examples, an ICAM investigation is more focused on hypothesising and concluding what the contributing factors were.
The 5 whys does this in some ways by making progress through contributing factors, and the fishbone can draw attention to all factors, but the ICAM is very strong at uncovering and classifying contributing factors - which then enables teams to implement a number of fixes and improvements.
A specific root cause analysis example
The root cause analysis example below is an ICAM investigation, and it is a root cause analysis which was conducted to find the root cause behind how an employee broke their ankle from stepping into an exposed pit.
You can expand the example below to see the full analysis, but the most important part of this root cause analysis process is that the end result was a conclusion as to what the contributing factors behind the incident were.
On top of this, a reliable framework like this also 'forced' the investigators or workers to create a number of action steps for solving this contributing factors and solving the root cause.
Use this ICAM investigation framework for free.
Be proactive to prevent root cause analysis
While these root cause analysis examples are great and helpful for companies conducting these type of analyses, the goal for all companies in construction, manufacturing, healthcare etc. is to deliver products and projects with don't have any safety or quality issues which require a root cause analysis.
The main 'problem' with root cause analysis is that it is reactive.
A root cause analysis is conducted when something has gone wrong, to uncover the underlying problem causing that thing to go wrong.
Ideally, a company would create smart processes and procedures which don't lead to quality and safety issues. This is obviously almost impossible, as these industries are dynamic and always evolving. New developments and changes introduce new problems and new incidents and undesirable events which do need to be analysed.
Even so, many companies are far too reactive when it comes to safety, quality and other functions. They lean on the above root cause analysis examples instead of being proactive about these functions and seeking to continuously improve inputs, tools and processes.
In one of the root cause analysis examples above, a company could have prevented an incident/injury by giving site workers the tool they need to document hazards on site in real-time. Using a site safety app, the person could have easily pulled out their phone, filled out a hazard identification form, and the right person would have been instantly notified about the hazard.
Instead, the person forgot about the hazard or didn't have access to the right document, and the issue when undocumented.
While root cause analysis is useful and important, sometimes it is too late. So focus on perfecting your root cause analysis when it is required - and work hard to make sure it is used sparingly.
People in 80+ countries use this safety management system to improve their safety processes and outcomes.
See how you can easily streamline your systems and processes with Sitemate today
English (United States) 
English (Australia) 
English (UK) 
English (New Zealand) 
English (South Africa) 
German