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.
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:
I think the point that Ries tries to make, is that the explicit design of systems are usually the result of management decisions. In that sense, one can argue that behind every technical problem is a human problem.
Whether an error-prone system is always “designed” is very debatable however. Many obvious or complicated systems have simply grown into complex or chaotic systems over time. They weren’t designed that way.
In the end, most people try to do a good job, including management. Therefore I adhere to your conclusion: what is causing the problem? Not who is causing it.
Further reading/ sorces:
– Out of the crisis, page 314-315 (W. Edwards Deming)
– https://management.curiouscatblog.net/2013/04/24/94-belongs-to-the-system/
– http://blog.leansystems.org/2013/09/dr-w-edwards-deming-people-work-in.html
– https://en.m.wikipedia.org/wiki/Cynefin_framework (pronounced ku-ni-vin)
Thanks for the comment. I agree that system design is management and they are human. I still think it’s better to refer to “system problems” instead of a breakdown of “human problems” and “technical problems.”
Good point about the system not being “designed.” That’s sadly often true in healthcare. But, senior management is still responsible, even when they work as part of a system (a board, investors, regulations, etc.).
I agree that most people mean well…. even ineffective executives.
Shrinkant’s reply on Linkedin:
[…] You can read the full post on Mark Graban’s Lean Blog. Please click on the link — https://www.leanblog.org/2018/01/not-fixing-systems-not-blaming-workers/ […]
We can probably also change the view on this as “human factor” is a cause, but not a root cause. When we encounter a “human failure” as the answer to a “why” question, another “why” can be asked. The answer may well be “because we did not design a system/process that prevent human failture come into play”. This essentially drove many process automation and product redesign.
Right, we can keep asking why. As Eric says (and I’ve written about), it’s not always FIVE whys. We keep asking why until we find addressable causes and stop asking why before we reach a point where we are blaming society or human nature.
In Eric’s example, if the manager didn’t value training, we could ask why. Or the CEO of that organization could ask how they ended up hiring a manager who doesn’t value training… if that is indeed the issue.