Procedure on "How to write a procedure"

[MD]

Significant subprocess of implementing QMS process is writing and implementing procedures. I think that in most cases it would be helpful to have procedure on how to write and implement a procedure. Has anyone come to same conclusion? (I think that for consultant company it could be procedure to support their own iso9k2k 7.5.1.!). I would be very grateful for sharing some samples here. Pls say if you are interested to see what i have come to.

 

[noboxwine]

NO OBLIQUE VERNACULAR

MAKE IT AS SIMPLE AS POSSIBLE AND DONT PAINT YOURSELF INTO A CORNER! THERE IS NOTHING IN THE STANDARD THAT TELLS YOU HOW TO DO IT. JUST MAKE IT SHORT AND EFFECTIVE. FLOW CHARTS, PICTURES, AND NO BIG WORDS ! BIG WORDS MAY DAZZLE A SPINELESS AUDITOR, BUT WILL ADD NO VALUE TO YOUR PROCESS. HERE IS AN EXCERPT FROM MINE:


..........ANY FORMAT THAT IS EFFECTIVE IN SHOWING HOW A WORK OBJECTIVE IS ACHEIVED.......

SIMPLE WORKS. I'LL SEND YA A FEW SAMPLES TO YOUR PRIVATE ADDRESS. GOOD LUCK !

 

[Claes Gefvenberg]

I'll agree to all of the above and mention that all of our procedures start with:

1. Scope (of the procedure)
2. Purpouse
3. Responsibility

First of all, it forces the writer to think things right through, and secondly, it helps the readers immensly.

/Claes

 

[apestate]

The Problems of Documentation

I've been waiting for someone else to bring this up.

Something about the endless regress of documentation makes me giddy. I spent an afternoon working my way out of a logical problem.. how to approve my document approval document.

How to approve document control at all. It cannot have the authority to approve itself, it isn't alive. so I finally decided that when I released my baby, it was *born*

a procedure to write a procedure I have to decline. a format, yes. I've got a sort of loose format. Purpose, Scope, Responsibilities, Forms, Procedure, Records, attachments, related documents, references, Revisions. if one of the above don't come in handy, I leave it out.

I leave alot of it out. Then again, this is a small operation and it would be hard to confuse the responsibilities of the preventive maintenance coordinator and the corrective action coordinator, because I am both.

Still. I wouldn't write instructions on how to write instructions. If I did, it would be a page long--maximum. The format and a few simple lines of text to explain each section would be sufficient instruction to any author.

Of course, I could see a need for procedure writing/approval procedures. I guess an organization large enough, that changes its procedures often enough, that manages itself with enough people -could- require a procedure and a process map to get the job done, but frankly I think my Latvian brother is doing too much work.

If -I- did something like that, it would look something like this.

 

[apestate]

uaea

 

[tomvehoski]

I agree you probably don't need/want a procedure on how to write a procedure. Usually I just use the same template so everything looks the same. This is still not required though.

I do see instructions for writing necessary in some areas. For example in software development - naming conventions, screen colors, fonts, etc. Same could be said for printing design. If you have multiple people working on the same finished product, you need to have the instructions to make sure everybody does things the same way.

Also avoid work instructions to fill out forms. It is not necessary to have an instruction say "Enter your name on the name line", "Put the current date in the date box". I have seen several places document themselves to death like this.

Tom

 

[Mike S.]

As a sub-procedure to Document and Data control, I decided to write a "procedure"/WI on how to write internally created documents. Maybe I'm weird, but I find it helps. We internally create routers, part (CAD or hand-drawn mechanical drawings) drawings, specification sheets/catalogs, and procedures/WI's. I wrote a procedure on what each must contain, what the basic format should be, the approval and revision process, control process, naming formats, heirarchy, etc. With so many kinds of different documents I find that I myself need to reference this WI.

BUT...some companies may not need this. It depends on the complexity of the documents they create, size, etc.

 

[Craig H.]

MD

I didn't see if you are ISO 9001 registered, but 4.2.3a has a "shall" requiring a documented procedure for document approval, and b-d have other document requirements. You could knock all of these requirements out by describing the structure (Scope, etc, as Claes outlined) and including the other areas, as well.

If you are not ISO, QS, etc., then decide if you do really need one.

In either case, as noted above, keep it simple. One page would be great, if possible.

Craig

 

[barb butrym]

IMHO

I find that I like the procedures/WI no matter how small.... Though certainly not required.

My reasons? I have enough to keep straight in my head. if there is a guide that tells me bare minimum, semantics, definitions etc....I don't have to remember them. As you all so eloquently stated above.........the resposibilities, who what when why where, purpose, distributions, what happens on exceptions.....yadayadayada.

Same goes for a data base/spread sheets what does each field mean? what are the choices, acronyms ... consistency and sanity for search criteria....if nothing else.

When you work in a vacuum (ie small shops),,,it mY SEEM LIKE OVERKILL...but in reality, how often do you pick it up? If its seldom, why try to remember all that stuff..write it down then forget it...reference it when you need it. I guess its a matter of preference....it makes sence to me to have one. Then if i need to handoff the function, its dead easy. IF it doesn't makesense.....then don't have one.

 

[Karen-Dawn]

How to Write a Procedure

I agree, keep it just as simple as possible but give the users tools they can use as well. We are very heavy into documentation and mostly use Word. So my document control procedure defines what type of info is to be included in a procedure, notification or specification and the positions of the authorizing authorites for each document type. I actually used 'templates' to design each of the document types with their applicable sub-headings, purpose, scope, instructions, etc. Users now just go to file\new, click on the document type they are going to write and fill in the blanks. It works great. All procedures etc look the same and none are noncompliant for not containing specified information.

P.S. You can even write macros so a window appears when the template is first opened, the author enters all the header information such as date, responsible department, etc. and then the info is inserted in all headers on all pages. Another great way to reduce negative audit results...

Hope this Helps,
Karen-Dawn