How To Do Root Cause Analysis
This video is going to give you an introduction to what root cause analysis is, some of the methodologies and benefits from it, and some tools you can use to carry out a RCA.
I will also touch on some of the potential barriers to root cause analysis, why you need to think about human factors, and the 7 best practices to remember for RCA.
What is Root Cause Analysis?
Root cause analysis comes from underlying areas of concern, as opposed to the problem that we see above the surface. It's a very good method of identifying what the true root cause of a problem is and that problem can come from various areas.
It may be related to a health and safety incident, an environmental incident, or business process problem.
What is the Purpose of Root Cause Analysis?
The purpose of root cause analysis is to get to the underlying contributing factors, the true reasons why the error occurred.
Many companies and people see a quick fix as the root to solving a problem. However, history has shown us that often these problems reoccur, so using this type of methodology is a great way of getting to the true understanding of the problem.
A core competence necessary for delivering this type of insight, is the ability to identify first and foremost, the need to do a root cause analysis. Often people see and think they know what the problem is, and quickly close something down; complete an investigation, a non-conformance or a corrective action report - thinking they see exactly what the problem is.
Root cause analysis is a form of evaluation, and it can be done by various teams, and often should be led through a protocol. It's important that it involves heavy communication and engagement. And it's important that recommendations and support come from senior people in the organisation to understand the methodology and why it's been put in place.
Principles of Root Cause Analysis:
The main principles of root cause analysis is about aiming corrective actions at the root cause, being more effective than treating the symptoms of the problem.
To be effective, root cause analysis must be performed systematically, and conclusions must be backed up by evidence - Not looking at something with blinkers on in silo, and believing you understand that this was exactly what happened.
In some cases, it may be that you do understand, but more often than not, there's usually more than one root cause that's resulted in this problem. That's one of the reasons for using the term why and not how. We may understand how something occurred, that caused the problem, but we need to understand why those activities happened.
Process for Performing Root Cause Analysis:
Define what the problem is and ensure everyone in the team is clear on it.
Gather data and evidence from various locations as required.
Identify issues that contribute to the problem.
Find the root causes. Identify which causes to remove or change so that you can prevent repeated problems.
Develop solution recommendations that effectively prevent the repeating of the problem.
Implement the recommendations/changes following a change management protocol.
Observe the recommended solutions and changes to ensure you understand that they have worked.
Symptom vs Root-Cause Approach:
What you see quite quickly
"Errors are often result of worker carelessness"
"We need to train and motivate workers to be more careful"
"We don't have the time or resources to really get to the bottom of this problem"
"Let's just train people and re-emphasize what the problem is"
What are the contributing factors - not just relying upon that communication to humans.
"Errors are the results of defects in the system, people may only be part of the process"
"We need to find out why this is happening and implement mistake proof so it wouldn't happen again"
"If it's critical, we need to fix it for good or it will come back and ultimately burden us, cost us time, effort, and money"
There is a requirement that organisations understand the benefits of root cause analysis and why they would want to invest in it.
You also want to be able to present back to the organisation a return on that investment. Proper control, monitoring, and measurement of data will provide that.
Let's think about the root cause in terms of a weed, or something is very visible. The underlying causes are the roots which are below the surface. They're not that obvious to see and do require time and dedication to find them.
Please remember also, when we talk about a root, often it is more than one contributing factor that has resulted in the error or the problem that we see above the surface.
Cause Mapping of Root Cause Analysis
There's a methodology around root cause analysis which refers to the mapping of the cause.
The 'ROOT' refers to the causes beneath the surface. It is the system of causes that shows all the options for solutions.
Don't focus on one single cause. It can make you be blinkered and look at an area that may only contribute a certain percentage associated to the underlying issue.
A map helps us look at a wider spectrum, allows us to look at other contributing factors, even contributing factors that could have occurred some time ago.
The three basic steps of mapping:
Define what the problem is.
Why did it happen?
What will we do?
Root Cause Analysis Tools
There are a multitude of tools available to us for mapping the root cause. Most of these tools are simple tools and they're easy to use.
I'm going to discuss the following tools:
Fishbone / Ishikawa Diagram
Charts or graphs
Ultimately, you're going the next level down when asking questions, and you can understand how the root underneath the surface is starting to spread out. This concept is really simple and can be used as a fundamental tool for RCA.
Example of 5-Why's from the video:
The worker fell.
1. Why did the worker fall?
There was oil on the floor, so there was a slip.
2. Why was there oil on the floor? Not making assumptions, but why?
We may identify that there was a broken part.
3. Why was there a broken part?
We speak to other people and investigate it, and discover that the parts keep failing.
4. Why are the parts failing?
We then investigate further, and recognise that there needs to be changes in our procurement practices, because we've known about this problem, people have understood that they do keep failing and we don't have mechanisms in place to ultimately prevent the person from falling, so some containment measures to protect people.
That 5th Why that we have asked, identifies that we need to put a different methodology in our procurement practices, because we have not resolved any problems with the current supplier of the parts that fail.
Pareto charts is just another form of a chart that gives us some information that feeds into what some of those causes could be.
By using this type of methodology, it allows us to focus in some of the key areas that bring about greater errors in our system.
It may help us define and tackle the most fundamental areas, sometimes referred to as the golden nuggets, the areas where we would get the best bang for our buck.
Fishbone / Ishikawa Diagram:
The fishbone diagrams look at the cause and effect.
When we go down the location of the issue that this is caused by people, we make the assumption that it's because the people are not trained, and we have to provide them with training.
But when we ask the 5 Why's about the training, ultimately, we may find out that we are retraining people, but the errors have continued to occur. Why is that? Is the training effective? Are we communicating with the people that have been trained, that they understand what to do?
Are we then going further than that and thinking well, competence is not just about training, are we assessing the people using the training to see that they have the knowledge and skills to deliver what it is that's expected of them?
Charts and Diagrams for RCA:
This is just another method to allow us to have the data at hand to help investigate inside the root cause analysis.
Potential Barriers to Root Cause Analysis:
Prior to performing a root cause analysis, the team should anticipate any potential barriers. Management may be reluctant to support the team in what they're trying to do, they may want just a quick fix.
It's down to the team to try and educate management why this is important, what the benefit is and the long-term goal and return on investment.
Some of the contributing factors in the issues that are found in the organisation may actually be down to management and the culture of closing things down quickly and not investigating them. This can mean that it is a difficult subject to deal with, and it can be subjective.
It is important, how we communicate that information to top management.
Human Factors that affect Root Cause Analysis:
Most root causes can be traced back to decisions, actions, or inactions by one or more employees.
Some of these could be:
Competence of personnel
Hiring qualified personnel
Lack of or insufficient training
Adequacy of technology or tools
Appropriateness of organisation or departmental culture
Health of the organisation or departmental morale
Level or number of resources (budget/personnel)
Lack of processes or procedures that led the person or persons to make the decisions
Other influencing factors
Decision-making authority of the person or persons involved.
The 7 Best Practices for Root Cause Analysis:
Your root cause analysis is only as good as the info you collect.
Your knowledge (or lack of it) can get in the way of doing a root cause analysis and therefore it is important to practice this, even using case studies to allow you to do that.
You have to understand what happened, before you can understand why it happened.
Interviews are not about just asking questions, they're about finding out what happened. It’s important that the types of questions you ask individuals are open questions, and maybe taking them back a few steps.
You can't solve all human performance problems simply just with discipline, training, and procedures.
Often people can't see effective corrective actions, even if they can find the root cause.
All investigations do not need to be equal (bus some steps can't be skipped)
The 5 C's
Corrective Action (Reccomendation)
Criteria: What is it we're there to do? Is there a law or regulation? Is there a policy or procedure or a best practice that's expected of the individual?
Condition: The factual analysis of the process or the activity that exists. Do we actually believe it's being occurred as per the criteria?
Consequence: Why the issue is important and noteworthy from a compliance, financial, or operational standpoint.
Cause: The root cause which allowed the condition to not emulate the criteria.
Corrective action (Recommendation): Change that will address the root cause, allow the current condition to mirror best practice or other criteria and does not cost more in relation to its effect.
Putting corrective actions in place may not necessarily be a quick fix. It can often result in something that needs to occur over a period of time and again require multiple areas feeding into it, for it to be effective.
For corrective actions to work, and for you to demonstrate they work, there has to be a method of looking at the preventative side of it.
So, after the action has been taken, how effective is it and looking back at that maybe in six months or a year's time.
Data, of course will hope to educate you on that, but ultimately, you can use your internal audit process to see if the actions taken have been effective.
Summary of Root Cause Analysis:
Root Cause Analysis is a method to focus our efforts on the true “Causes” of escapes, so that we truly prevent their reoccurrence.
Root Cause Analysis helps us reduce errors and frustration, maintain customer satisfaction, and reduce costs significantly.
Each problem is an opportunity. It contains the information needed to eliminate the problem. But to identify the root cause, we have to ask “Why?” over and over, until we reach it.
Human Factors are often the main contributing factors.
Ask Yourself these Questions:
Are we really fixing the causes of the problems?
Are we asking why it happened and not what happened?
Have we considered all human factors