Mistake-Proofing Mistakes

Written by Bruce Hamilton, President, GBMP

Published January 21, 2016

There is a popular lore provided by Shigeo Shingo that the original name for mistake-proofing (poka-yoke) was “fool-proofing” (baka-yoke). Shingo chided managers at Panasonic for using the latter term, as it was disrespectful to workers, essentially calling them fools. Shingo substituted the word “fool” for “mistake,” because, as he aptly noted, making mistakes is part of humanity. “Mistakes are inevitable,” he said, “but the defects that arise from them are not.”

Notwithstanding Mr. Shingo’s admonitions, however, I still hear the term “fool-proofing” used regularly, and occasionally with a little more venom, “idiot-proofing.” No doubt, these derogatory terms, along with others like “screw-up” and its less gentile derivatives, have given a bad name to one of the most energizing, empowering and creative tools from the TPS toolbox. 


Many organizations never even get out the blocks with this technique because of an overt insulting, blaming environment. Who wants to report a mistake, when the reward is blame and ridicule? Like Mr. T from the 1980s American television series The A-Team, managers tend to blurt out the wrong words when mistakes occur. Bad habits die hard. But even for more enlightened managers there are still some common hurdles to creating a really powerful poka-yoke system. 

A few weeks ago I gave a short webinar for AME on poka-yoke and was asked this question by a viewer: “How do I ensure effectiveness when using the poka-yoke device? People usually don’t want to continue using it.” Here, with a few embellishments, was my response:

“The general answer to this question from today’s webinar is that if people don’t find a particular tool purposeful, they don’t use it. More specifically for poka-yoke, there are seven reasons team members do not see the tool as purposeful:

  1. Sometimes to assure quality, an additional step is added to the operation to prevent or detect the defect, but this step is not considered in the standardized work, i.e., no additional time is allowed. If the device or method requires an extra step that takes more time (e.g. the use of a check list or matching parts to a template) then employees will feel rushed and pressured to choose between rate and quality.
  2. A corollary to the absence of standardized work is the lack of communication with team members, team leaders and managers. An undocumented and untrained standard is not a standard.
  3. If the device or method causes strain to the employee it won’t last. 
  4. For detect-type poka-yoke devices (i.e., a defect is created but detected before it can pass to the next operation), the concept involves swarming the defect when it’s trapped in order to understand its root cause. I see many cases where defects are trapped, but there is no follow-up. Defects pile up, or they are picked up occasionally by engineering or quality, and no feedback goes back to the production line. When problems don’t get fixed, this promotes cynicism. It’s not poka-yoke, just a scrap sorter.
  5. Sometimes, as suggested in the question above, a device is put in place, but the defect persists. This could mean the device isn’t used by the team member, but it can also mean the device just doesn’t work. More PCDA is needed. If the device doesn’t work, team members will be the first to know. Telling them to use something that doesn’t work is disrespectful and disengaging.
  6. The term poka-yoke is used too broadly to describe countermeasures that have nothing to do with human error, but relate more to providing proper tooling and fixturing to team members. For example, if a particular job requires super-human sensor capability to complete (more muri), creating fixturing to make the job doable is not a poka-yoke solution. My father, who was a machinist by trade and an artist by avocation, could draw a straight line freehand around an entire room. Most of the rest of us would want a straightedge and a level to complete that task. The point is when we refer to such countermeasures as “mistake-proofing,” we’re once again disrespecting team members.
  7. Most importantly, if the employee who uses the device is not included in the solution, there is typically little commitment to use it, especially if any of points 1 through 6 apply.

Now, that’s a long-winded answer to a short question. The short answer is that the “technical” portion of poka-yoke doesn’t work if it is not grounded by a quality culture.