In the last post, I presented the following “procedure:”

 1. The receiving department receives the raw materials, checks for accuracy and then places the materials on shelves to be available for production.

2. The production clerk receives the work order, identifies and pulls the raw material for the order, and tags it for delivery to the assembly area.

3. The warehouse operator pulls the work order, gathers the raw material for the order into a tote box, checks the material against the order to ensure all materials are present, and delivers the materials to the assembly area.

4. The assembly area supervisor receives the order, and distributes materials to the assemblers based on the assembly work they will perform.

5. The assembly workers put together the finished units from the materials, and place them in a bin to go to the testing area.

6. The assembly supervisor delivers the bin of finished units to the testing area.

7. The test technicians perform quality assurance testing on the units, and place the acceptable units in a bin for delivery to the packaging and shipping area.

8. The packers place the units in boxes, with all necessary instructions and other paperwork.

9. The shippers place the boxed units on a pallet, and prepare the pallet for shipment to the customer.

And I made the assertion this is not a procedure, even though countless organizations have stacks of such documents like the one above, labeled as procedures and audited as such.

The Missing Element

While the “procedure” describes who does what, and when it is done (at least relative to another activity) it lacks the most important–and in this writer’s opinion, the only truly procedural–information: the “how.”

An operating procedure, as the second level (Tier 2) of the documentation pyramid (click to view again)  really should only describe how things are done. The “what” of the organization’s activities identify what needs to be described, and the operating procedure tells how each “what” is performed.

Looking back at the “procedure” above, it really functions as a policy statement, as its principal focus is on who does what. You cannot gain from the “procedure” how any activity is performed. Should that document be discarded? If the document is useful to the organization, then no, keep it. Just don’t call it a “procedure.”

In the next installment, we will discuss the audience and purpose for procedures. In the meantime, I would like to thank Jeff Hansen of Tamarack Scientific in Corona, CA for his interest in the Mr. Procedure blog. I hope that you find this information useful in your organization!