5 Whys and Pointing the Finger

Posted on February 8, 2012 | in Teamwork | by

Harvard Business Review

Yesterday, Harvard Business Review posted a video of Eric Ries (identified as their “entrepreneur-in-residence”) showing how to find the “human causes” of technical problems using the 5 Whys approach.

(I’d embed the video here but I’m not so technically savvy when the code isn’t already provided for me. So to watch the video, click here.)

Anyway, one of the key points Eric brings out is that for technical problems there is typically an underlying human problem that causes it, which he demonstrates using the 5 Whys technique. As a lean practitioner that depends on teamwork, coaching, and collaboration, this is probably the last thing I want to do.

The example he uses in the video (server problem caused by insufficient training) points the finger at the manager for not providing adequate training for the engineer that implements the coding issue. I view the process for identifying the cause in two ways.

One, how do we know that the training was insufficient? Does the process of creating an engineer that is adequately prepared identify what training needs to be completed first? If not, then it’s a process┬áproblem in that the standard isn’t created.

And if the process identifies the incorrect training, it’s again a process problem. Does the manager not follow the process? If so, why does he not follow it? What outside force is keeping him from completing it?

And two, we could probably pretty easily say that any and every problem can be traced back to a human cause. Every process is created by humans, so naturally every cause is human made. However, coming to that conclusion is a fruitless and wasteful endeavor because the point is to solve the original problem at the point where the dominoes start to fall. Must we go back to the creator of the elements?

So if you want to make sure “human causes” don’t exist, you must create foolproof processes where human intervention is necessary but not a curse.

And by no means should we point a finger at a person when it’s really the process that’s at fault.

Related Posts Plugin for WordPress, Blogger...
TAGS: , , , , , , , , , , , , , , , , , ,

3 Responses to “5 Whys and Pointing the Finger”

  1. Don C says:


    I generally agree to with your points.

    Lately I’ve become more sensitized to seeing it as neither solely people or process. I think Don Reinertsen had some useful criticism of the glass bead game as demonstrating that it’s only the process or system.

    I got pointed to a nifty book called Apollo Root Cause Analysis that I found useful. One of the points it made is that you can find as many causes as you have time for. When you start RCA you have to have a sense of what kinds of answers are acceptable.

    In the spheres I travel in I feel like I’m sensing a backlash against the notion of “it’s the process’s fault”. Personally, I think that’s the place to start, but at some point, practically, the organization may need to decide the person is more of a problem than their process can accommodate.


    • Chad Walters says:

      Don –

      Thank you for the comment.

      I completely agree with you – a root cause is a root cause, whether it’s a process or people. I believe lean practitioners try to drive home the “look at the process” concept first to prevent immediately pointing the finger at the operators – telling the operators they’re wrong kills any hope for teamwork and cooperation.

      The fact remains that, yes, sometimes there are people that are the problems in a process. But couldn’t it also be stated that the process in bringing the problematic people into the fold had a breakdown as well? How does HR know they are bringing in the right people and leaving out the wrong ones?

      Might that be process analysis overkill? Certainly. (I do that sometimes.) It might be more tedious to seek out the “perfect” person instead of seeking someone that is “good enough.” In the example explained in the video, the person didn’t receive proper training but Eric said it was a people problem when there was a breakdown in the process of knowing if that operator is prepared enough for the work. That said, the process owner must realize that at some arbitrary point the process shouldn’t be expected to accommodate every anomaly a person might have and that it’s simply easier to remove that person from the process.

  2. Pingback: Politics and (the Lack of) Root Cause Analysis | Lean Blitz – Do it better.

Leave a Reply

Your email address will not be published. Required fields are marked *

Get Lean Blitz in your Inbox!

Subscribe to a daily digest of Lean Blitz posts by clicking here!