Is Five Why Analysis Too Simplistic for Complex Problems?

By Pascal Dennis (bio)

A common question, especially in industries that are just now learning the Lean Business System.

Problem solving is a kata - a set of core forms that we practice over & over, hopefully under the guidance of a capable sensei.

When practicing the problem solving kata, we pull in the tools we need including, Five Why, Ishikawa, Process Flow Diagrams, SIPOC etc.

It's a mistake to structure any problem solving discussion in either/or terms.

It's not Five Why OR Ishikawa OR Process Flow Diagram OR FMEA.

To paraphrase Hemingway, "it's all true." We pull in what we need.

Another common mistake is underestimating Five Why.

"Five Why is too simple for me. I want a more complex tool, because this is a complex problem. (And I am a very complex guy!)"

In consulting practice we've used Five Why to get to the root cause of complex design, supply chain and organizational problems.

Five Why is especially helpful when we've clearly defined a Direct Cause.

Often there are multiple causes, and we need to apply Five Why sequentially to get to the root cause of each.

A common failure mode is not understanding the three types of Root Causes - Inadequate Standard, Inadequate Adherence to Standard, Inadequate System.

These are derived from the splendid NASA and Loss Control literature & are invaluable because they point to actionable root causes.

In summary, problem solving is a kata and not unlike trying to hit a curve ball, shoot hoops, or hit a golf ball.

(All of which baffle me...)

You practice, practice, practice the core skills & movements.

Then, if you're very lucky, the day comes you can do it unconsciously.

Best regards,

Pascal

Easy on the people, hard on the process

By Al Norval

One of the basic tenants of Lean is “Respect for People”. There is much history behind it which I won’t go into in this blog; I’ll save that for another day.

Another basic foundation of Lean is that we “Solve problems according to the scientific method”. That is, we take problems to root cause and put in countermeasures against those root causes. The countermeasures form a hypothesis that says - if we do these things then the root cause will be eliminated and the problem will not re-appear. Then we run experiments and test the hypothesis and learn from the results.

Putting these two ideas together we see that in problem solving, we need to look at the processes in which people do their work. We believe that people are basically good; it’s the processes they use that are causing the problems. The people are merely executing the broken processes.

In problem solving we keep asking “why” to get to the root cause of a problem, and many times we see the root cause is actually a process problem. We need to be hard on the process to understand what is it about the process that is broken and is allowing these problems to appear. We also need to be hard on the process in designing countermeasures so we build robust processes where it’s easy for people to execute them.

Contrast the “5 why” process of getting to root cause with one that asks the “5 who’s” in trying to get to root cause. That type of questioning is hard on the people and doesn’t get to a true root cause. What it does do is violate the lean pillar of “Respect for People” and so does a great job of turning people off and undermining any engagement of people in improvement work.

To engage people in improvement work, we need to create an environment that is conducive to problem solving, one where we engage both the hearts and mind of people, one where the problem solving is “Easy on the people and hard on the process”.

Cheers