By Mike Loughrin, CEO of 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 steam 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 steam 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 to 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. The key is the need to dig 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
- Value stream mapping
Reveal the Truth
It’s time to peep 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.
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 in knowing if and when 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 are close or 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:
- We assumed outsourcing work instructions to the low cost bidder would solve our problems
- We assumed everyone would understand directions written in English
- We assumed a 15-minute video on fork lift safety would be all anyone needs
- We assumed a 60-minute presentation on overcoming objections would lead to increased sales
- We assumed measuring customer call duration would encourage people to quickly provide correct answers
- We assumed that rewarding purchasing, for saving money, would drive people to buy high quality materials
- We assumed people would be fine, with learning on Friday afternoon, that overtime was required on Saturday
- We assumed executive bonuses would 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
It’s time to craft your root cause statement of fact. This statement needs to be clear and concise – one or two sentences.
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 an answer which allows the project team to move to their next step:
- Six sigma teams can move from Analyze to Improve
- Value steam 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 is “assumptions” which, often in hindsight, are not valid.
Don’t miss future editions of the Transformance Communiqué, the newsletter designed for those serious about crafting sustainable organizations.click here to create your own account.
Root Cause Analysis Washington State Department of Enterprise Services