(This is the sixth installment in my “Answers from LinkedIn” series. This is also the second part of a two-part response to an issue raised in a LinkedIn group I belong to. Please read the first part before reading this part, just to avoid confusion.)
So how did policies and procedures get so hopelessly intertwined, or clouded, as the original discussion starter put it? If policies and procedures serve different purposes, where did we go wrong?
There are a few answers to that. One seems to be a “one-stop shop” mentality around many organizations’ documents. Let’s combine the policy with detailed descriptions of processes that only the responsible group needs to be aware of. So no matter who you are, regardless of the situation, everyone grabs the same document. It sounds efficient, but in most cases the individual grabbing the document needs about 10% of the information in that document. Remember your policy audience!
Another contributor to the confusion has been, for better or worse, ISO. Not so much the standard but the documentation structure that developed as part of the certification effort. Central to this discussion is the familiar documentation hierarchy:
2. Operating Procedures
3. Work Instructions
(In my Writing Operating Procedures book, I reverse the order of the elements of the hierarchy, but this order is fine for this discussion.)
First of all, ISO does not mandate or even mention such a hierarchy; you will not find it in ISO-9001, AS-9100 or any other Quality Management System variant. The hierarchy is all good and well, except that organizations began populating each level with the wrong information.
The policy level is rarely an issue (other than cramming the policy document with 15 pages of procedural actions taken at high levels in the organization). But somewhere along the line a major breakdown occurred around “what is an Operating Procedure?” Some of the software I saw designed to make procedure writing easy contributed to the problem. The problem is that Operating Procedures took the following form:
1. The Receiving Department removes the raw material from the truck and stores it in the holding area.
2. The QC Department pulls samples of the material and delivers it to the Lab for testing.
3. When the material passes testing, the QC department locates the material and places green (acceptance) tags on the material containers.
4. When the containers are green-tagged, Production Control moves the material into the Production storehouse.
…and so on.
To the uninitiated, this appears to be a procedure. After all, each element is numbered! The problem is, this “procedure” only tells the reader who is responsible to do what (it also provides an order in which actions are taken). This is, by definition, a statement of policy, because I am not telling anyone how to do anything. Now, this is a useful document; I am not knocking the fact the information is documented, but calling it an Operating Procedure is incorrect. It is a Policy.
Now by having policies spill over into my Operating Procedure level (or tier), I end up compressing multiple types of procedures into a tier called Work Instructions. There is a clear, substantial difference between an Operating Procedure and a Work Instruction, but these get grouped together (and in fact, too often, I end up with a hybrid Operating Procedure / Work Instruction document that an employee only needs half of at any one time) and it is not only clouded, but it leaves the poor worker in a heavy fog through which they are expected to carry out their assignments.
Simply: Operating Procedures exist to describe how an activity (task) is performed; its audience is the task performer and its sole purpose is to facilitate learning the task. Work Instructions are detailed instructions to execute a task under particular circumstances (e.g., make a specific product). Its audience is the worker while doing the task. My rule of thumb is, if the document is one the worker needs at their side to reference while performing the task, it is a Work Instruction. Both of these are different purposes than the purpose for a policy.
There is much more I can state regarding this issue. That is why I wrote Writing Operating Procedures, which for a limited time I will still offer for free to anyone who writes me at firstname.lastname@example.org. Thank you for reading and I welcome any comments.