By Mike Loughrin, CEO for Transformance Advisors
At some point, the pain of a recurring issue will lead someone to scream “we need to find the root cause!”
Examples are everywhere:
- Why do 20% of the flights from Denver to Dallas land before a gate is ready?
- Why do the safety audit scores show no improvement over last year?
- Why do some blue jeans wear out sooner than expected?
- Why does another hospital have better outcomes for their patients?
The challenge for investigators, searching for a root cause, is how the issues appear to be random. In many cases, there have been multiple attempts to address the situation. It’s common to hear “we already tried that and it didn’t work.”
It’s time to get to “the source of the problem.” It’s time to recognize how “focusing on the underlying causes of problems is more effective than simply treating the symptoms.”
Where It Fits
In most cases, root cause analysis is not a stand-alone improvement project.
It is just an assignment, to one person or a small team, to “find the root cause” for something which needs to be addressed – as part of a larger project.
A few examples:
- Six Sigma projects use Define Measure Analyze Improve and Control or DMAIC; root cause analysis is needed during the Analyze step
- Value Stream Mapping projects will need to find the root cause of waste before you can design a future state value stream map
- Problem Solving projects have a specific step for root cause analysis – it comes before you can identify and select countermeasures
A challenge I have found, in learning about root cause analysis, is how too many sources spend 80% of their effort on forming a team and running a project. I just want to “find the root cause.”
For our purpose, root cause analysis is taking an issue, which needs to be addressed, and finding the root cause of the issue. Then, you pass the root cause to the project team so they can design and implement a solution which does not suffer from the recurring issue at hand.
Of course, there is always the obvious notion where you can have numerous root causes. That may be the case and you can ponder it all you want. Nothing really changes in what you need to do.
An Effective Approach
Let’s go with the scenario where an issue has been identified and you have been assigned the mission to “find the root cause.”
Your step by step approach should be:
- Confirm you have the right people available
- Articulate the specific issue you are addressing
- Review the information you have and go get more data
- Peel back the onion to reveal the truth
- Find the root cause – easier said than done
- Craft a root cause statement of fact
Let’s look closer at each step.
Right People Available
The team working on your six sigma project, value stream mapping project, or problem solving project may have all the talent you need.
But many times, you will will need to add more horsepower to get at the root cause of a challenging issue.
A few examples:
- Time to crunch more data on what has been happening for the last 90 days – get someone from IT who can download the detailed transactions
- The flow of customer orders appears random and out of sync with common sense – add the customer service person for that specific customer
- Materials from a supplier meet your specifications, but do not work as expected – get someone from the supplier who can help find answers
- The results from a software program are not making sense – add someone with greater knowledge of your systems
You get the picture, the team working on the “big” project may not be the same team needed for working on the root cause of one issue.
Articulate the Issue
Similar to how the team for your “bigger” project might not be correct, the project charter and other documentation will not be precise enough for your mission to find the root cause of one issue.
You need to focus:
- Who is involved?
- What is the issue?
- Where does it happen?
- When does it happen?
- Why is it important?
For most projects, data has been collected and has helped identify the need to dig deeper.
It’s now time to dig even deeper and get more data.
The common tools you will need include:
- Check sheets
- Fish bone diagrams
- Run charts
- Affinity diagrams
- Data dumps from IT systems
- Mapping techniques
Reveal the Truth
It’s time to peel back the onion to find the fault which ignites the fire.
You need to analyze the data and ask why more times than you can count. The key is the need to find the “thing” which starts the sequence of errors which lead to the issue you want to stop. Think of the “thing” as the first domino to tumble.
The common tools you will need include:
- 5 whys
- Scatter diagrams
- Fault tree analysis
- Pareto analysis
- Statistical analysis
- Control charts
- Failure mode and effects analysis
Find the Root Cause
The hardest part of root cause analysis is knowing if you have reached your destination. When can you stop digging?
You will reach the root cause when you have something you can change which will make the issue go away and not happen again. It must be something which is actionable. Claiming Maria forgot to do something is not actionable.
Typical findings which indicate you have arrived include:
- Documentation errors, usage, or simply not available
- Training gaps, effectiveness, or lack of relevance
- Measurements driving the wrong behavior, or just not in place
- Cultural issues leading to carelessness or foolishness
A partner in crime will often be a faulty assumption – teamed up with documentation, training, measurements, or cultural issues.
Consider assumptions such as:
- Outsourcing work instructions to the low cost bidder will save money
- Everyone should understand directions written in English
- A 60-minute presentation on overcoming objections will lead to increased sales
- Rewarding purchasing, for saving money, should drive people to buy high quality materials
- Measuring customer call duration will encourage people to quickly provide correct answers
- A 15-minute video on fork lift safety should be all anyone needs
- People will be fine, learning on Friday afternoon, that overtime is required on Saturday
- Executive bonuses will encourage everyone to work harder and faster
Working past the assumptions, you will find the root cause is, most likely, a “system” cause and not a “human” cause.
Statement of Fact
Once you find the root cause, you are ready for the last step. It’s time to craft your root cause statement of fact.
This statement needs to be clear and concise – one or two sentences. This is not the time for a 50-page manifesto.
Test your statement:
- Verify your thinking using the first domino test – does the root cause start the sequence of errors which leads to the issue you are attempting to resolve?
- Confirm your statement is actionable – can something be done to eliminate the root cause?
Your assignment for finding the root cause is complete when you can return a statement which allows the project team to move to their next step:
- Six sigma teams can move from Analyze to Improve
- Value stream mapping teams can move to creating a future state map
- Problem solving teams can move to identifying countermeasures
- Other types of project teams can move to their solution design step
Most of the time, root cause analysis is not a stand-alone improvement project. It is just an assignment to “find the root cause” for something which needs to be addressed – as part of a larger project.
You start with your assignment and end with the delivery of a concise statement of fact on what is causing the issue. What is the first domino which tips over and causes all the others to fall?
You will generally find the root cause to be associated with documentation, training, measurements, or cultural issues. A partner in crime, with these four suspects, are “assumptions” which, often in hindsight, are not valid.
Root Cause Analysis explained with examples and methods by Tableau.