Mark's Note: Today's post is the first contribution from Shrikant Kalegaonkar, a frequent commenter here on the blog, LinkedIn, and Twitter. We had a chance to meet in Austin last year and I appreciate his shared interests in Lean, statistical process control (ala Deming and Wheeler), and quality improvement. He initiated this piece and I ended up collaborating with him on it. I hope it sparks some healthy discussion…
By Shrikant Kalegaonkar and Mark Graban
Recently, Harvard Business Review shared a video from the site HBR Ascend called “The 5 Whys” where Eric Ries, author of the books The Lean Startup and The Startup Way, explains the use of the method. In it, he repeatedly, and incorrectly, suggests to the viewer that “behind every seemingly technical problem is actually a human problem waiting to be found.” Finding a human who failed to be singled out for blame won't find and fix the deficiencies in the process or system. What we need is to improve the design of the process or system within which humans work.
Asking “Why?” is a way to identify the cause of a failure. The more times we ask why, the more likely we are to discover deficiencies in the process or system of work, either with its design or with its operation. Fixing deficiencies in the process or system improves its performance.
Let's look at an example where the problem is that my car won't start. We could call this a “technical problem,” in Eric's language. Asking why the car won't start may lead to identifying the cause as a dead battery. I might typically fix this by either recharging the battery or replacing it. And if this gets my car running, I would move on and say “problem solved.”
However, let's say that my car fails to start again, and I discover that it's because my battery has died, as before. This repeated failure might lead me to ask, “Why did the battery die again?” I may discover that the alternator, which keeps the battery charged and provides additional electric power for my car's electrical systems when the engine is running, is not functioning.
At this point I may ask, “Why is the alternator not working?” and I might discover that the belt that drives the alternator is broken. Fixing the belt will fix the problem with my alternator not working which, in turn, would fix the problem with my battery not maintaining its charge.
Repairing or replacing failed components may correct a problem in the short or medium term, but it does not always prevent the problem from occurring again. Failures are costly and frustrating. They bring an abrupt halt to a routine and may damage other parts of the process or system. Thus, preventing failures is more desirable — repairing/replacing components before they fail.
To prevent failure, I need to dig deeper and ask, “Why did the alternator belt break?” I may find that it had worn out. I might ask, “Why was a worn out belt still in use?” and discover that the manufacturer's prescribed maintenance schedule was inadequate for my driving habits. This discovery points to the deficiency in the maintenance process I'm following. In other words, the design of the maintenance schedule is inadequate for my use case.
Changing the schedule is necessary to prevent such a failure from occurring in the future. This change to the maintenance process improves the performance of my car by preventing such failures in the future.
The practice of asking “Why?” multiple times to discover process or system related deficiencies were originated by Sakichi Toyoda and used within Toyota Motor Corporation. Toyota focuses on finding deficiencies in their production system and fixing them, thus improving the system in the process. It does not use The 5 Whys to find the human problem.
It's been suggested that investigators ask “Why?” five times to move past correcting the immediate problem (repeatedly) to preventing it from occurring again at all. The focus of the search is always on discovering process or system deficiencies. It is not intended to find the human behind the problem, be they line workers or managers.
Unfortunately, in many companies, investigators often end their investigations on “human error,” and recommend “retraining” as a remedy. This is both inadequate and ineffective as a means for preventing future recurrence of the problem. It seems to me that Eric fell into this trap by faulting a human in a management role, instead of finding and fixing the design issues with the process or system.
Don't want to miss a post or podcast? Subscribe to get notified about posts via email daily or weekly.