Find the Root Cause Instead of the Person to Blame

Posted on May 3, 2006  Comments (5)

When encountering a problem or defect the inclination of many is to find a person to blame. W. Edwards Deming believed that the system was responsible for 93% of the problems and over time he increased that number to at least 97%. Why did he see it that way, while so many others first inclination is to blame someone?

As I see it the issue has to do with what is the effective way to improve. Often if you ask why do we have this problem or defect, people will point to some error by someone. So you can blame that person (there are reasons this is not a very accurate way to view the situation often but even without accepting that premise the blaming a person strategy is not wise). The reason the blaming a person is a bad idea is that your organization will improve much more effectively if you keep asking why.

Why did they make that error? Why did the process let them make that error? When you follow the why chain a couple more steps you can find root causes that will allow you to find a much more effective solution. You can then pilot (PDSA) an improvement strategy that doesn’t just amount to “Do a better job Joe” or “that is it Joe we are replacing you with Mary.” Neither of those strategies turns out to be very effective.

But investigating a bit more to find a root cause can result in finding solutions that improve the performance of all the workers. What kinds of things? You can apply poka yoke (mistake proofing) concepts. You can institute standard practices so that everyone is using the best methods – not whatever methods they have developed over time. You can rearrange the process to simplify the steps and eliminate chances for errors. These improvement, and many more, are sustainable and can be built upon over time.

In addition, the psychology effects of seeing people as the source of errors and defect instead of seeing people as the source of improvements to process weaknesses are powerful. If you find yourself thinking a problem or defect is the fault of a person try asking why a couple more times and see if you can find a system improvement that would eliminate or mitigate such problems in the future. That is a much more effective improvement strategy.

I always have had a bias toward finding system improvements but over time that bias has increased as I have applied management improvement concepts. As you gain experience working on improving systems you gain experience showing the wisdom of Deming’s 93-97% figures. My belief is that he increased the percentage of problems attributable to the system over time as he experienced the same thing.

5 Responses to “Find the Root Cause Instead of the Person to Blame”

  1. mgraban
    July 26th, 2006 @ 5:54 pm

    Why do we tend to blame people when we have near misses in Aviation?

    http://kanban.blogspot.com/2006/07/why-do-we-blam

  2. Curious Cat Management Improvement Blog » Blog Archive » Dangers of Extrinsic Motivation
    August 10th, 2006 @ 3:34 pm

    […] Find the Root Cause Instead of the Person to Blame […]

  3. Curious Cat Management Improvement Blog » Going lean Brings Long-term Payoffs
    September 10th, 2006 @ 8:32 am

    Eliminating non-value added steps and reducing handoffs reduces waste directly and also eliminates potential errors thus improving quality. Poor quality results in products that customers return which is more waste. Poka Yoke is a great example of a tool that eliminates waste by preventing errors thus reducing waste and improving quality…

  4. Curious Cat Management Improvement Blog » European Blackout: Human Error-Not
    November 18th, 2006 @ 12:40 pm

    Why design a system where “human failure to check whether the outage of a second transmission line” would cause such a loss of power across Europe? By saying human error was involved you imply the person should have done something differently meaning your system should have been designed to prevent such a mistake from occurring…

  5. Toyota IT Overview
    December 10th, 2006 @ 11:01 am

    […] customizing the code, to its business processes, and not the other way around. Yes. Yes. Yes. IT should support your processes not dictate them. […]

Leave a Reply





  • Recent Trackbacks

  • Comments