If nothing else, a procedures has to tell us how to proceed therefore the sequence of steps is critical to whether a statement or document is a procedure or something else. Specifications, contracts and records are not procedures as they do not tell us how to do anything. These describe the outputs resulting from carrying out procedures or tasks, leaving us to decide any further actions necessary to use these outputs. The output will more than likely be used as inputs to other procedures.

A set of self-assembly instructions is a procedure as it tells how to proceed to assemble the product. But the wording on the label telling us not to put hot objects on the surface is an instruction or a warning (a special type of instruction). As procedures are normally used by people they are designed with a user in mind. The user is normally an individual or a group of individuals, although procedures can cover a sequence of steps each of which is performed by different individuals or groups. However, perceptions of procedures vary considerably depending on the context in which they are created and used. Any sequence of steps, no matter how simple or complex, can be expressed as a procedure that is intended to cause someone to act in a certain way to accomplish a task. The key is that the steps follow a sequence. A random collection of statements is not a procedure unless we rearrange these in a sequence that enables someone to proceed.

Within the context of management systems (and more specifically, ISO 9000) the procedure has, for many, taken on particular and sometimes peculiar characteristics. Such (documented) procedures may be written, not as a sequence of activities or steps but as a series of requirements or a series of responsibilities. Neither of these can be procedures as they do not tell us how to proceed, what steps to take or how to measure the result.

Such procedures often follow a uniform format with a purpose statement, applicability statement, responsibilities and then procedure statements. Often there is no connection between the purpose statement and the procedure. Purpose statements often address the purpose of a document not the purpose of the task which the sequence of tasks is intended to deliver. Again, if such procedures (and rarely they do) contain measures of success, these are probably quantitative measures related to the task itself and not to why the procedure is carried out. The most common perception of such procedures is that they are simply associated with paperwork and filling in forms.

We seem to think that we have created a procedure by classifying a document as a procedure. These documents are often thought of as high-level procedures. Procedures do not have to be documented to be procedures and do not have to be only high level. We often hear of procedures addressing the elements of IS0 9000 and work instructions being used at departmental level to guide activities. These characteristics of procedures only serve to constrain our thoughts and our intent.

When does a document qualify as a procedure?






© Transition Support Last edit  23/05/2018 







Transition Support

A flexible approach to business improvement