In my last blog post, I reviewed the 5 why problem-solving method. In this blog post, we will continue this discussion so if you have not seen Part 1, I suggest you read that post first and then come back here.
A Beginner’s Struggle
Here is an example of the difficulty’s newcomers have with the five why approach. This blog author explains his struggle. Mike Cohn shares his frustration with using the five why approach to find the root cause of his flat tire. Mr. Cohn attempts to use the five why method without any guidance on how to ask productive whys. At the end, he gives up, saying, “sometimes root cause analysis isn't worth it.”
Mike’s difficulty is typical of the five why rookie experience. It is no wonder. There are sparse instructions on how to use the five why approach. Only those tenacious enough to practice refine their skills.
Take Small Steps
Often the five why analysis goes wrong when the team takes a giant step with weak cause and effect relationship. This often occurs when team are sure of themselves and are eager to take action. Small incremental “why” responses help guide the team toward a strong root cause. Here is a real life example of a giant step setting the team off in the wrong direction:
PROBLEM: Production is using work instructions that are out of date.
1 - WHY? Operators do not have the ability to view online documents.
In this case, the team who made this five why had their mind made up early on. They really wanted to get the production computers onto the company network, so production operators could view their work instructions online. In their five why, the team skipped over explaining why management allows operators to use out of date work instructions. Many readers already recognize that the problem statement indicates an out of control condition where production builds with obsolete documents. This is not a document automation problem. This is a process control issue. The team did not question why obsolete documents were in use.
The team got their network drops, to address the “root cause” but it took several more years to get the process in control and have production operators regularly follow their work instructions.
Go and See
When using the five why approach, it is tempting to answer a “why” question with a belief, not a fact. Working this way might seem satisfying because you can go through the whys quickly. The problem then becomes that your results are suspect. Go back to Mike Cohn’s example. That is exactly what he does in his third why. Gemba walk.
“Because my gym, which was pretty much the only place I'd driven to the day before, is re-paving its parking lot.”
You see that the remainder of his five why is not rooted in fact. Subsequently, his root cause is not actionable.
“Because it rains.”
Successful five why practitioners go to the place where thing happen. Their terminology for this is Gemba walk. When in doubt, go and see. Observe, ask questions, and gain insight.
Are We Done Yet?
So how do we know when we have identified to the root cause? You will have reached the root cause when asking "why" produces no more useful responses. Let me illustrate with an example where by the 5th why, the team discovers that the design engineers cannot collaborate effectively:
This is a real-life example:
PROBLEM: Engineers cannot efficiently collaborate on SolidWorks design.
1 - WHY? No one has access to entire library of CAD designs or visibility of what others are working on.
2 - WHY? Engineers store CAD locally on their own computers, share via email.
3 - WHY? No shared CAD database that allows for collaboration and file management.
4 - WHY? Current engineering workgroup tools are not optimized for version control and document management.
5 - WHY? Our engineering workflow was not designed for multiple engineers to work from the same files.
6 - WHY? Epec previously only required one design engineer, who also happened to work on-site with production.
Notice that the 6th why describes what may be another problem in another part of the process but following this line of inquiry will not fix the problem described in the problem statement. The team went on to provide countermeasures for the root cause identified in the 5th why.
Root causes are underlying, are reasonably identifiable, can be controlled by management, and allow for generation of recommendations. Are you at the end? “If the most recent response were corrected, is it likely the problem would recur?” If the answer is yes, it is likely this is a contributing factor, not a root cause.
Knowing when to stop asking why mostly depends on three questions:
- How relevant are the questions and answers to the original problem you are investigating?
- Did you find a root cause that helps you control or avoid the problem?
- Are the questions and answers useful?
Parting Thoughts
The "five" in the Five Why Method is just a "rule of thumb." In some instances, you may need to go on and ask "why?" a few more times before you get to the root of the problem. At other times, you may identify the root cause before you ask your fifth "why?"
Some teams - especially in manufacturing - do not bother to focus on finding the reason why the problem occurred, they search for the root cause of why the problem was not detected after it occurred. While this is often a valid part of a comprehensive improvement program, it’s not sufficient enough to merely improve detection methods. It is usually far more productive to focus on eliminating the cause of a problem, rather than focus on containment.
When you try to determine root cause through the five why method, remember to use these four rules:
- Focus on actionable answers
- Select answers that are in the team’s control
- Take small steps
- When in doubt, go and see
When you think that you found the root cause of your problem, ask these three questions:
- How relevant are the questions and answers to the original problem you are investigating?
- Did you find a root cause that helps you control or avoid the problem?
- Are the questions and answers useful?
Good luck, problem-solver!
