I’ll never forget the day I realized how powerful root cause problem solving can be. I was at a supplier training conference and when the trainer came into the room, he walked over to a table with a huge stack of papers on it. He stated that these papers were all of the corrective action reports that us suppliers had submitted. Suppliers were responsible for filling out these reports whenever we sent a serious defect to the customer and it was designed to explain what the root cause of the problem was and what the countermeasure would be implemented to prevent a reoccurrence. Although I was surprised at the amount of quality issues represented in the stack, the staggering fact that the trainer informed us that 90% of them were repeat issues.
After that week of training, I came to realize that my company was not properly solving problems and I needed to learn this technique. I’d like to share some of the key points that I learned in that class and over my years of practice.
First of all, it’s not a punishment.
Have you ever seen a situation where the expectation to do a 5 Why analysis has been issued either by a customer or a manager and it’s viewed as a penance for passing a defect or some other negative situation. Then, a person or a group of people will go sit down and try to come up with a 5 Why that flows so that they can mark the task complete. An Ishikawa diagram (aka Fishbone diagram) is used and then whichever potential cause sounds the most convincing is chosen and everyone tries to force the 5 Why to support it as if they are solving a crossword puzzle. Finally, someone is assigned to implement a countermeasure for the fifth why, everyone sighs with relief, and case closed. The document is filled out and the penance is paid.
I will admit that this is better than nothing, but it’s not world class problem solving. Root Cause analysis is used in combination with the PDCA cycle to explore all possibilities, go deep into the cause and truly solve the problem with absolute thoroughness. It’s not a punishment and it shouldn’t be viewed as “work”. It should be done because root cause problem solving provides a critical component to becoming an organization that is driven to be successful on all levels.
What does it mean to “Get to the Root Cause”?
Some people may be unfamiliar with 5 Why Root Cause Analysis altogether so I’ll explain it. When trying to solve a problem, simply ask: Why did that happen. After you determine that answer, ask why that happened, and so on, until you ask why enough times that you can’t answer it anymore. At this point, you should have discovered the root cause. Here is an example of a simple 5 why:
Problem: My lawn looks bad.
Why #1:Why does my lawn look bad? Answer: Because the grass is yellow.
Why #2:Why is the grass yellow? Answer: Because it’s dying.
Why #3: Why is it dying? Answer: Because it’s not getting enough nutrients.
Why #4: Why isn’t it getting enough nutrients? Answer: Because I’m not fertilizing it.
Why #5: Why am I not fertilizing it? I don’t know what fertilizer I need.
At this point, you would want to determine a countermeasure based on your 5th why (your root cause). For this example, you would want to take a soil sample to get analyzed so you can purchase the correct fertilizer and apply it according to the recommendations.
Now, you have reached the P portion of PDCA (which is Plan). The next steps are to follow through with Do, Check and Act.
Here are some guidelines to doing a 5 Why analysis correctly:
- Before getting started, be aware that this is energy used effectively. Yes, it can take a lot of initial effort, time, resources etc., but it’s actually spent wisely over the long term because if done properly, the problem will not reoccur. You could probably skip the complex and arduous task of analyzing the root cause with this much tenacity by doing the first thing that comes to mind, but this is likely to only be a band aid for the symptom and it will occur again. This will result in a perpetual cycle until the true root cause is found and countermeasure and it will be far more costly in the long run.
- Five is not a set in stone number. It’s not the guaranteed magic number. It does usually force you to push deeper than most feel comfortable, in most cases. Think about it like this. It might be something that takes asking why seven or eight times or maybe three is adequate. The key point is to not just accept the first answer to the question: Why did XX happen, because it’s probably a symptom of a deeper cause, so you have to keep asking why until you get out of the symptom level and into the root cause level.
- Take time to do it right. Don’t think you need to gather everyone to have one meeting and finish it by the end of the meeting. All possibilities in the brainstorming activity should be investigated and validated as true or not. This quite possibly will require team members to seek out more information and report back. There’s nothing wrong with this. I’d advise to not let this turn into an excessive break in the problem solving process, especially in more urgent matters.
- Brainstorm with a group. Unless you’re a one person business, take advantage of the different points of views of the team. Always include the person that is the closest to the problem, this is usually an employee from the floor. I don’t know how many times I’ve seen a group of managers or engineers argue about a theoretical cause while ignoring the fact that the person that was physically present during the problem probably knows exactly what happened.
- Don’t punish employees for telling the truth. Many times they will have information, but with-hold it in fear of getting in trouble for not doing or saying something earlier. This is why Lean can only truly exist if a “blame free environment” is created. (more on this topic in future posts).
- Look at things from different perspectives. Examine every detail. Don’t assume that something is happening correctly, verify that it is. Think about the cause of the problem form outside of the proverbial box. After all, the solution is unknown at this point, so the cause could be absolutely anywhere, even in the most likely of places.
- Use the 4 M’s to help kickstart brainstorming. You can generally categorize problems that occur in manufacturing under Man, Method, Material or Machine. It is sometimes helpful to ask, “how can a person be part of creating this problem?” Or, “How can the method be part of creating this problem?” Don’t get to hung up on what M to categorize it under, the important part is to surface the potential cause.
- Get out of the office. The Japanese term Genchi Genbutsu means to go to the place where the work is done. Ask questions. Observe the work for a while. Look at data that is relevant to tracking down clues. You may have to ask for some additional data to temporarily be collected if needed. Say for instance if a potential cause of a defect is that the robot breaks down and causes the defect. Check the robot down time. If downtime is not a metric that is recorded, ask for it to be recorded to see if it is an issue.
- Always consider that there can be multiple causes for the same issue and branch out. See the illustration. As you ask why something happened, you may decide there are three or four different possible answers. Write them all down and investigate. Rule out the ones that you find out are not a potential and ask why for the remaining ones. Keep repeating this process until you can’t do it anymore. This technique will quite literally result in something that looks like a “root” system of a plant.
- Be very honest. Don’t sugarcoat and don’t try to pick the easiest path, be truthful and take the right path. Just because it’s easier, doesn’t mean it’s the best thing to do. You shouldn’t let personal feelings block you from getting to the truth. Let the be highlighted and use it as a learning experience, not an opportunity to point blame in a direction, but always make sure you are acknowledging the factual truth.
- Try to recreate the problem. Nothing beats a good old fashioned, “I saw it with my own eyes”. I’ll take that over an, “I’ll betcha it happened this way” any day of the week.
So to summarize and clarify, if you want to solve a problem, don’t just get your salary staff together and say, “we’re obligated to do a 5 Why, so let’s get this out of the way”. Recognize that this short term expenditure of resources will be a long term gain via total elimination of the problem. Let the solution for your problem be the true goal and ask “Why” enough times to expose the truth. Utilize pure and honest techniques to do it and utilize employee knowledge to uncover the truth by putting in the leg work and working hard at solving the problem.
As a final note, this type of activity ties into another of my strong beliefs which is that “Servant Leadership” read this article, means that Leaders have the obligation to solve problems with employees by empowering them and working alongside of them to fix issues, rather than blame them for them.