Procedure Development Methods - What are the main things that go wrong?

[MD]

This question has been discussed still i believe it will always be open.
What are the main things that go wrong?
1. Procedures are so detalized that employee preforming processes often violate the procedure because it is just too descriptive.
2. Procedure document contains policies not "specified way to carry out process".
3. Procedure document is in subjunctive mood not "specified way to carry out process".
4. Action in critical situations not described well enough.
I notice that 2nd and 3rd nonconformity approaches mainly when porcedures are being developed as a text, not flowcharts.
I conclude that every procedure should be developed first drawing the process by flowchart.

Should we worry about procedures with policies developed when implementing our QMS?
Recently I had a discussion with a consultant who wanted to assure me that "if i write a procedure with policies instead of "spec. way to carry out proc." AND company dont mind, consequently they agree that policies procedure is useful to them! And I cant go against my customers needs!"
Should we agree with this consultant?

[Edited: replaced "politics" with "policies".]

 

[M Greenaway]

MD

Please expand on what you mean by politics - are you meaning policies ?

Sorry for the confusion but both words have widely different meanings.

 

[MD]

Right.

True i ment "policies" when said "politics". In other words: Statements of what would be great to be done, what should be done.. phrases in personnel training management procedure like "we believe that human resources are our most valuable resource" and so on.
Sorry english is not my native. Lots of chances for improvement for me in this field

 

[M Greenaway]

MD

Your english is superb compared to my command of foreign languages.

I think such policy statements have their value and their place. Strictly speaking a procedure should be specifically telling someone how to carry out an activity. It should be specific and direct, and as such 'auditable'.

Statements such as 'it would be nice if everyone was well trained' are weak in a procedure and cannot be audited.

I have seen very loose procedures written in this manner, which is OK if you just want a document on the shelf that wont 'trip you up', but you might argue that such a 'procedure' serves no purpose (other than to audit) and as such should be scrapped.

Policy statements traditionally sat in the Quality Manual - but with ISO9001:2000 you probably dont need those either (apart from the general Quality Policy).

 

[E Wall]

Ditto

Rather than say it again in different words, I will second what Martin posted! As usual he's hit the nail on the head.

Good luck MD,
Eileen

 

[JodiB]

I have found myself including "policies" into the procedures I'm writing, but that is because I was directed to make the procedures user-friendly rather than a dry document that only told what to do.

So statements such as "it is helpful if you first....because....." or "it is important to understand the facts surrounding the event prior to taking any action" or " this is done to ensure that the XXX is in a format that WWW can use efficiently " are included.

The idea is to provide a readable document that explains not only what to do but the reasoning behind it so that the user understands why it is important to do it that way and to hopefully lead the user into being able to make independent judgments when required since a written procedure can only go so far. There will always be occasions when the employee must act on his/her own. I think that it also encourages employees to formulate "better ways" of doing things if they understand the intent of an action.

Have we done the wrong thing? Is this something that will be written as a nonconformance at an audit?