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.”
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.
“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?
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?