When you ask people about the Lean Startup methodology, one of the first things you'll often hear is advocacy for a root cause problem solving method called “the 5 whys.”
As I mentioned yesterday, I'm currently attending Eric Ries' “Lean Startup Conference,” yesterday and today, so I hope you'll say hi if you're there.
For a bit of background, Eric wrote this blog post about the Five Whys, crediting Taiichi Ohno, one of the creators of the Toyota Production System. Listen to my podcast with Eric sharing his reflections on Ohno.
Eric wrote:
“When something goes wrong, we tend to see it as a crisis and seek to blame. A better way is to see it as a learning opportunity. Not in the existential sense of general self-improvement. Instead, we can use the technique of asking why five times to get to the root cause of the problem.”
He's on the right track that blaming an individual for a systemic error (a machine producing a defect, the wrong medication being given to a patient, or a server going down) generally isn't helpful. Most (>90%) problems are caused by the system, as Dr. W. Edwards Deming taught us and Toyota reinforces today.
Toyota's corporate website has an article about the Five Whys, saying in part:
“…according to Taiichi Ohno, pioneer of the Toyota Production System in the 1950s, “Having no problems is the biggest problem of all.” Ohno saw a problem not as a negative, but, in fact, as “a kaizen (continuous improvement) opportunity in disguise.” Whenever one cropped up, he encouraged his staff to explore problems first-hand until the root causes were found. “Observe the production floor without preconceptions,” he would advise. “Ask ‘why' five times about every matter.”
Yes, having “no problems is a problem.” That's a very common Toyota-ism.
Eric also wrote this helpful HBR piece that says:
“… behind every supposedly technical problem is actually a human problem.”
This is usually the case in healthcare and the “Just Culture” methodology and framework helps us figure out when a problem was caused by the system and when it's appropriate to consider punishing an individual.
I think this Just Culture method would be helpful in startups and other settings too. What's “just” and fair for those doing the work? Blaming an individual for a problem that a colleague would have likely also made is not fair and just. It's not “just” to future patients to hamper problem solving (which hampers the prevention of future problems) by “naming, blaming, and shaming” as people say in healthcare.
Once we start asking “why?” instead of “who?”, we might ask why the number is usually expressed as five… the five whys?
Yes, Taiichi Ohno wrote about the five whys as a way to get beyond the surface and closer to a root cause…
I think the key is we ask “why?” more than once. It's not always five whys that gets us to something that seems like a potential root cause. Asking once or twice might not get deep enough.
Maybe it should have been called “The Many Whys” approach instead of “The Five Whys” since people tend to take things quite literally?
Listen to Mark read this post (subscribe to the podcast series):
There's no magic about the number five. I've seen some people write that five is somehow a “magic number.” No, that's not really the case. Ask why more than once, probably more than twice… it might take four, or maybe five, or maybe six whys.
One reason the necessary number of whys varies is that it's dependent upon the way we frame a problem.
Properly defining a problem is really the first step in this Toyota problem solving process (read more about this).
In a hospital setting, where I work most often, we might frame a problem in different ways, at different levels.
We might start by stating a problem vaguely as something like: “It's too noisy in the hospital inpatient units at night.”
A more specific and quantifiable problem statement might point to the need to reduce the number of complaints or to improve patient survey scores (it's important to know the scale of the problem so we can know if we've eliminated it or at least made things a little better).
If we ask “Why is it too noisy at night?” there might be MULTIPLE reasons why. Again, the Five Whys process is usually not simple and linear. We might need to list different causes in something called a “Fishbone Diagram” (aka an “Ishikawa Diagram“), something not mentioned in Eric's book. There's not always a single magical root cause to problems in complex systems.
Let's look at an example that Eric used in his book:
The implication here is that the root cause of the problem is:
- Manager doesn't believe in training new engineers
But in that 5th statement is actually another why question and answer. It could have been stated as:
5. Why wasn't he trained? Because his manager doesn't believe in training new engineers.
6. Why doesn't the manager believe in training? He and his team are too busy.
So that's actually a sixth why. Should we have stopped after five? Probably not.
We could keep going.
7. Why are they too busy? Meetings are too long.
8. Why are meetings too long? They don't have agendas and things get off topic.
Are we done yet?
The problem could have also been framed at a higher level. The first why question could have been:
- Why have we lost a bunch of customers this month? Because a feature for customers got disabled.
- Why was the feature disabled? Because the new release went badly.
So we might, in this case, be up to 9 or 10 whys.
The exact number of whys doesn't matter. Solving the problem matters. Don't be too prescriptive or stuck on the number.
What matters is the thought process… not just the whys but the entire thought process, as I blogged about yesterday. Identify problems. Don't blame individuals. Understand the problem and clarify it. Brainstorm potential causes. Brainstorm countermeasures that might help. TEST those countermeasures and reflect upon or improve your causal analysis.
When should we stop asking why? I was taught to stop when we've reached a point where we can no longer develop countermeasures. If we starting pointing at factors like “quarterly financial pressures” or “society” or “our education system,” we've probably exhausted the usefulness of asking why…
What are your thoughts? Do you use “The Many Whys” method in healthcare, manufacturing, startups or another setting?
What do you think? Please scroll down (or click) to post a comment. Or please share the post with your thoughts on LinkedIn – and follow me or connect with me there.
Did you like this post? Make sure you don't miss a post or podcast — Subscribe to get notified about posts via email daily or weekly.
Check out my latest book, The Mistakes That Make Us: Cultivating a Culture of Learning and Innovation:
Totally agree Mark. I think people can get caught up in the technicality of it all. Its not meant to be so regimented and its not meant to lock you into one way of thinking. Lean thinking is also agile thinking, being fluid to new concepts and ideas. Asking “5 Whys” and only 5 Whys, is really limiting your ability to accurately root cause and countermeasure issues. If it really takes 3 whys, you might spin your wheels trying to get to 5, frustrating everyone in the process thus losing credibility. If it takes you 7 whys and you stop at 5, you may not be getting to the real root cause and thus not utilizing the tool for what its meant. Good read. Cheers.
Disagree. I think 5 is a good guideline and rule of thumb for how deep you need to go. The problem of excessively literal applications of rules should be solved elsewhere.
David Keith Butler, MD: Great read!
Bob Rush: I’ve had 5 why’s lead to another round of 5 why’s. Sometimes we get lucky and it takes less than 5 as well.
Susan McDermott: I’ve always thought about the “5” in 5 Whys as ensuring that you dig to a truly actionable level. The focus needs to shift from the symptoms to the cause. When there are many branches to the answers, I usually switch to a different tool – like the Ishikawa or a fault tree analysis. Those approaches can also get you beyond the high level policy excuses.
Maybe as continuous improvement or lean geeks, we get so stuck on the beauty of standard work (The number should be 5) that we fail to realize the beauty of using a 5-Why approach. I agree with what you’ve shared. In an effort to engage over 500 team members on a daily focus of problem solving, we’ve been working to implement and use 5-Why’s for the past 3 years. We rolled it out through the lean champions and then horizontally throughout the organization. Results varied and problems were identified and countermeasures implemented. Yet the biggest gain was from the new level of awareness, reflection and collaboration for approaching problems across functions and without blame. It’s far from perfect and I’m sure some of my academic and engineering friends would be horrified at our lack of expertise. But we found a mechanism to keep pointing towards the process instead of people, while “learning by doing” together. Many of the problems shouldn’t have been a 5-Why at all. Others should have been a Fish Bone. Others probably needed the 8D approach. With that said, we’ve seen a stronger culture and organization focused on getting better. And to collaborate with the post, we had some 3, 5, 7, 8 and branched off other 5-Why’s to boot :-)
Nice post and very relevant for us.
Thanks for adding your thoughts, Rick!
Part of the iterative nature of 5 whys, problem solving, etc. is learning by doing and getting better over time!
Sometimes, the 5 will get you where you want to go. I prefer the Theory of Constraints analysis (reality tree) as it brings in the peripheral necessary factors that feed into the causalities. By starting with the problem as an effect, you dig down to the root cause – but recognize the interconnectedness of other data/players/operations.
Good input from Art Smalley, a former Toyota guy:
I have seen “5 Why” used effectively, and also not so effectively. One team had an agenda to do more training, and somehow the 5 why’s always led to “lack of training.”
Another issue is that some “why” questions have multiple answers, and each answer needs its own subsequent “why” – that can get rather cumbersome. In such cases, perhaps a fish bone is a good alternative.
Like every problem solving tool, it is powerful when applied correctly, and problematic when either misused or when the situation calls for an alternative tool.
Thanks for your comment, Jonathon. I’ve seen the “whys” analysis done in a tree structure… or, you’re right, it can be helpful to do a fishbone before digging deeper into causal analysis.