John Shook: “A Technical Problem or a People Problem?”

John Shook dives into some of the messy issues of true root cause in his most recent post.

We touched on a similar issue here a few months ago. But it is always worth coming back around to people because because in this system (actually in any system) there are always two issues with people.

  1. People are the most fallable part of the process.
  2. The process cannot operate without them.

The reflex is often to go into total denial about #1 and expect people to be vigilant and perfect every time. “Weed out the bad apples, and everything will be fine.” Of course that doesn’t work.

In John Shook’s example, he traced through Ohno’s classic “5 Why” example.

1. Why did the machine stop?
There was an overload and the fuse blew.
2. Why was there an overload?
The bearing was not sufficiently lubricated.
3. Why was it not lubricated sufficiently?
The lubrication pump was not working sufficiently.
4. Why was it not pumping sufficiently?
The shaft of the pump was warn and rattling.
5. Why was the shaft worn out?
There was no strainer attached, and metal scrap got in.

Then Shook asks a really interesting question:

Why was no strainer attached?

Why not indeed? Isn’t that somebody’s job?
And now, as he points out, we have transitioned from “technical” to “people.”

Maybe the standard work for the maintenance worker or machine operator didn’t go far enough. Or maybe the standard work did specify changing the strainer but the worker failed to observe the standard. How was the standard developed, how was it communicated and trained? How easy was it to “forget” to change the strainer?

Coming, as I do, from mostly “brownfield” environments, the existance of standard work in the first place isn’t something that we can take for granted.

Nevertheless, Shook is making a critical point here. It does not matter whether there was no standard work, or whether the standard work broke down for some reason that we do not yet know (another “Why?”). This is still a process problem. We must start with a working assumption that the team member cares, and is doing the very best job possible, given the expectations, the resources, and his understanding at the time.

I am aware of a couple of cases where engineering change implementation pulled up short of actually observing the new installation and looking for unforeseen problems. One of them was quite subtle, and actually took a few weeks to find the basic cause, much less the root cause.

Another resulted in a bolt snapping during final torque. Messy to fix, but better in the factory than in the field.

These are additional cases where technical problems resulted from process breakdown, and in both cases, it was a case of unverified or blindly held assumptions, and not following through with the customer process.

Shook concludes with two really important points, and I can’t agree more. First:

…the work design must also include the “human factors” considerations that make it possible to do the job the right way, and even difficult to do it the wrong way.

I like to say “Make the right way the easy way” if you want things done in a certain manner.

Which brings us to Shook’s final point: You have to look at the total package – the human and the technical as an integrated system. You can’t separate them because. You can’t “take people out of the process.” All you can do is construct the process to give people’s minds the most opportunity to focus on improving the work rather than burdening them with making sure they get it right.

Always work to support people to do the right thing in the right way. If the organization carries a belief that it is necessary to force or “incentivize” people to do the right thing, then there is a people problem, but it isn’t with the workers.

2 Replies to “John Shook: “A Technical Problem or a People Problem?””

  1. A very good message Mark.

    I used to be an electrical and instrumentation techincian. I could fix anything. I was known as Mr. Fixit.

    Then they made me a supervisor. For a long time I struggled trying to fix people. I tried in vain to fix the situations and fix people’s issues just like I fixed the machines. Over many years I learned how to work with people in order to fix their issues and situations.

    (I still love fixing machines. It’s so much easier than fixing people and their issues.)

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.