Home > Blog

Tips and Insights

Over our 28 years of explaining, we've accumulated a wealth of valuable information that doesn't fit neatly under our web site tabs. This body of knowledge includes some tools we have developed, approaches that have worked well, other approaches that failed, and a large amount of miscellany that could be called "accumulated wisdom" or perhaps more accurately "battle scars"

We organized this section as topic threads that invite further insights and comments. We welcome your additions.

We also welcome questions and suggestions for new topics.


Thursday, October 11, 2007
No Matter What You Call Them, Work Instructions Need to Work

Even though what something is called doesn't change what something is (you remember Shakespeare's "a rose by any other name . . ."), when semantics creep into an industry, it can cause problems. I generated this list of possible terms for identifying work instructions in just a couple of minutes (and missed how many more?):

  • work instructions
  • standard operating procedures
  • job aids
  • standardized work instructions
  • job planning
  • product design documents
  • technical manuals
  • user instructions
  • procedure manuals
  • policy manuals
  • job skills
  • training tools
  • detailed process sheets

Isn't communication hard enough, without having different words mean the same thing? I'm laughing, of course, because we are talking about the English language here, where multiple meanings, multiple pronunciations, multiple spellings is the bane of meaningful conversation.

I don't think using different terms for an object or a process is necessarily a Lean or quality issue when it happens between different companies, but it could be an issue if it's happening within the company and hindering communication between departments. Take, for instance, the engineering department and the shop floor. If engineering is in charge of writing instructions-and they often are-they may use terms for parts that don't match what the shop floor technicians and mechanics call them. And if the engineer and the user don't agree (or confer ahead of time) before naming the parts, the potential for confusion when reading the instruction rises; i.e., if a worker wants to find out how to fix the thingamajig on the hoosit, she's in trouble if the engineer has named it the wallabaloo on the cratshis. She won't find what she needs unless she looks through the entire manual.

We were exposed to this issue when we worked with the United States Postal Services maintenance department. Barcode label printers at bulk mail centers are high-speed, high-volume machines that can disrupt an entire station if they go down. USPS maintenance, which handles dozens of machines and infrequently works on these printers, needed to diagnose and fix them quickly. Not only did they have to read through the columns of text in the table of contents to figure out what procedure they might need, they also had to figure out which term matched the part they needed to repair.

USPS Samples

We solved this problem with a visual table of contents that allowed maintenance to identify the part based on what it looked like and/or where it was located on the machine. The user could then turn to the page of the operation that applied to it.

Even though this is a viable solution, it may not always be possible, and it could be the writer and user forget what terms they agreed to use. A better solution might be to have departments talking to each other regularly, and to have the people doing the work involved in creating the work instructions. Conversation will build understanding, and when that happens, not only will there be agreement on the terms, there will also be agreement on the standard best practice-and that is part of a Lean, quality world.

Labels: , , ,