Causes of Mistakes

He Just Made a Mistake

Technician Mistake
Technician Mistake

Can't a person just be careless? Of course they can, but the question misses the point. The verbiage "Person Was Careless" should never end a Cause Map. It's just as useless, in fact, as Procedure Not Followed. A better question is, Specifically, what did not go well?

The specific procedure the technician follows may not be the issue, but organizational or supervisory procedures may need to be examined. Perhaps training is an issue. If the person is just not a match for the organization, hiring practices enter the picture. Some may fear that straying to these seemingly unrelated topics may be "getting off in the weeds," or getting into too much detail. The opposite is most often true: People do not go into enough detail and, by doing so, they de-rail the incident investigation. Sure, a certain issue or procedure may not be related, but it doesn't mean it's not at least worth discussing.

If the technician's duties are critical enough to wreck havoc because of an error, should additional procedures, secondary workers, or some other line of defense be put in place to prevent error? Think of an airliner. What if a pilot is just plain careless on a bad day? That's why the copilot is there. He's a backup-part of what's called layers of defense, a proven method for ensuring a consistent process.

How many layers do we need? This depends. Consider again Bob, the talented instrument calibrator who made his first mistake after two decades on the job. As mentioned, the incident may still benefit from a Cause Map. Incidents rarely if ever have just one cause, so there's more to the story than the once-in-20-years mistake.

But once we discover the system of root causes, we have a decision to make. Is the error rate acceptable for the organization? This depends on the incident's impact on overall goals. If the error involved loss of life, an organization will spend much time and money to change and improve the work process, and perhaps add those extra layers of defense. If the error led to the first system shutdown in years and to prevent it (that is, change the work process) would require a complete and costly system overhaul—the error rate may be acceptable. Of course, none of this analysis is possible if the Cause Map stops at "Procedure Not Followed."

Simplifying Safety

Consider a case involving workers not wearing proper personal protective equipment (PPE). Management's first investigation of the problem might involve writing a process map that shows the procedure: Workers arrive, go upstairs to retrieve PPE, then downstairs to their work area. They write a Cause Map and determine that the people don't wear PPE because (obviously) they're not following procedure. Human nature and perception again plays a part here. In the back of their mind, frustrated managers may believe the workers are just lazy, don't care, or don't think they'll get hurt. Even worse, a manager may think people don't wear PPE because, if they get hurt they can sue the company and live out the rest of their days on the settlement.

After launching a root cause analysis and developing a process map and Cause Map, some facts come to light. Employees must walk upstairs to get PPE, then downstairs again to their workstations. Why couldn't PPE be placed close by or even at their workstations? A problem like this actually happened, and when PPE was moved closer to workers, its utilization shot through the roof.

Of course people don't want to hurt themselves, and they're not out to get the organization either. They just want to get through their day a little easier. A proper root cause analysis clears the emotional Fog of Frustration that surrounds major problems, shows people the steps involved and, ultimately, the solutions.