We add another layer to the standard document pyramid which Mike mentions above. Craig has part of it in his reply... For my organization, the Top layer of our pyramid is composed of the Quality Policy and our Goals and Objectives. Also, as my site is just one manufacturing uint of a larger whole, our headquarters has another series of documents which also fall into the top layer = we have a corporate Quality Policy with supporting principles as well as a corporate ethics policy (which is also part of the top level documentation).
As for the original topic regarding procedures, we believe in setting some common outline requirements and then suggest optional additions to be included as necessary. Also, it's helpful to have the individuals who own the process either write the procedures themselves, or at least serve as a reviewer of the documents.
Our common procedure requirements are to have a unique Title and Identification #, a Department who owns the document, the Area(s) to which the document applies, the type of document (training, calibration, preventive maintenance, test method, process control, etc.), and the following:
(1) a Purpose
(2) a Scope or Application
(3) Safety (for safety concerns specific to the document, sometimes this is N/A)
(4) Procedure
Some of our optional categories (to be used when appropriate):
(5) Definitions specific to the procedure or unique to our organization
(6) Associated Documents (when one document refers to another)
(7) Roles and Responsibilities (when not specified in the body of the Procedure, a separate section may be used... sometimes, this would also be where employee competency requirements are discussed)
(8) Distribution and Notifications List (who needs to know about the document?)
(9) Equipment
(10) References (Journals, books, regulations, etc.)
Flowchart when you can. This can help describe the process and help keep the document to a reasonable size. I typically try to use at least one flowchart, two at most to provide guidance in the process. If more than two flowcharts are needed to describe the process, then perhaps the procedure may be trying to cover too much ground?
In my organization, we have been through the extreme ends of the spectrum when it comes to documenting our system (from overdocumenting our systems [the old 40 to 50 page procedures] to not enough documentation to understand the process [the one page procedure that does not tell you much]). Over the years, we have fluctuated back and forth a little, gradually finding ourselves somewhere near the equilibrium state between the extremes. Procedure sizes now run around a 4 to 5 page average size. We do have one or two documents which exceed 40 pages, but they are justified in our eyes(vendor safety manuals and such).
Hope this helps? E
