To write or not to write. That is the question. How many procedures should I write?

[dianel]

Re: To write or not to write. That is the question.

I mean that from an auditing QMS standpoint...it is more detailed than required...but from a training standpoint...they are useful.
I am not here to make any auditors job easier, just to do what is best for the company and its employees. It may mean more revisions and some may not agree to put more than the minimum out there. If it is out there it is auditable and you are opening yourself up to more opportunities to get NCR's or OFI's. For our company it is worth the risk. You might as well utilize this tool as much as possible.

 

[bobdoering]

Re: To write or not to write. That is the question.

I mean that from an auditing QMS standpoint...it is more detailed than required...but from a training standpoint...they are useful.
I am not here to make any auditors job easier, just to do what is best for the company and its employees. It may mean more revisions and some may not agree to put more than the minimum out there. If it is out there it is auditable and you are opening yourself up to more opportunities to get NCR's or OFI's. For our company it is worth the risk. You might as well utilize this tool as much as possible.

That's what I'm talking about!

 

[JaneB]

Re: To write or not to write. That is the question.

Are you saying that you do not need documentation unless not having it is causing problems?

Nope.

I said:

• to write a document only when the need really is there, and
• you're clear about the purpose and the main audience

I gave only a single example of when 'the need really is there' - when you'd write as part of CA perhaps. I did assume some background & intelligence on the part of a reader to know that yes of course one also writes documents as part of good planning and management (PA if you insist) and yes, not waiting to see if there's a problem first. And no, I didn't list all of the times when one might decide a document was really needed.

Presumably my meaning was unclear - why not ask to clarify? That's what I did, requesting more information from the OP before launching straight into advice on the base of assumptions and not enough information.

Similarly, perhaps I've misunderstood your meaning about 'always write a document in order to improve'.

But I do not think your unpleasant and snide comment about potential effects on my clients was either courteous or warranted. And if that's the level of discussion you want to descend to, I don't. And won't.

What it boils down to is that you have to do what is right for your company.

Yes. Exactly.

 

[Pancho]

Re: To write or not to write. That is the question. How many procedures should I writ

Sorry, Jane, you are right. That was uncalled for.

I am sensitive to the minimalist approach. In my business we will often take any excuse not to write a needed procedure. Been known to done it meself.

 

[Yarik]

Re: To write or not to write. That is the question. How many procedures should I writ

Originally Posted by JaneB

My advice is always to write a document only when you are clear that

• the need really is there - eg, there are some signs/data/evidence to show that not having this documented is causing problems
• you're clear about the purpose and the main audience

Jane, your disagreement seems a bit empty when you ignore the existing question directly relevant to the issue: If a procedure or task is not documented, how do you improve it?

Are you saying that you do not need documentation unless not having it is causing problems? That advice would not seem to meet 4.2.1.d of the standard IMHO

Panchobook, I think you've misunderstood Jane. Jane's criterion was "...write a document only when ... the need for it is there", which is much more general than "...when not having it is causing problems".

Jane, I think you could've addressed Panchobook's specific question about possibility of improvement very simply: when the need to improve a procedure is there, and it cannot be improved (in auditable way) without documenting it first - yes, it does make sense to go ahead and document it.

The point I'm trying to make here is: I think that detection of the need to improve a procedure does not require the procedure to be documented. But, once such need is detected (and, IMHO, proven to be worth the trouble) - well, then documenting the procedure is very likely to be unavoidable.

Also I think that the real need to improve something rarely can be detected (let alone be proven to be worthwhile) without taking a look at this "something" in a bigger context first. And in that bigger context you rarely need to (ideally, shouldn't) know all the details of the procedure: usually, all you need to know is the "interface" between the procedure and the context in which it is being invoked.

In other words, document a procedure (= document particular way to perform an activity or process) from the very beginning only when the need to document it is clear from the very beginning (e.g. when the procedure is very complex, very critical, very rarely used, etc.); otherwise, documentation of the higher-level activity/process realized by the procedure may be more than sufficient as a starting point.

Perhaps it's my background (software development) that is shining through here: the key approach to "managing complexity" in my profession is to always distinguish interface of something from actual realization of that interface. "Surface" from "internals", if you wish. The more clear the distinction, the easier is it to manage complex code (and fix/improve it when necessary).

I am not sure that this approach is directly transferrable to the QMS/BMS domain, but at this point I feel like it is.

Perhaps, the key difference between the problem in question (how much to document?) in these two domains boils down to the following:

software developers cannot have unrealized interfaces (read: undocumented procedures), because computers are absolutely dumb - they cannot do anything without written code (read: very, very, very detailed and precise procedures, work instructions, whatsoever)
​

whereas

organization management system can have undocumented procedures because human beings are smart enough to do a heck of a lot of things without detailed instructions (including improvement of their own activities).
​

Peace??

 

[JaneB]

Re: To write or not to write. That is the question. How many procedures should I writ

At the risk of repeating myself, I stand by what I already wrote (emphasis added):

• to write a document only when the need really is there, and
• you're clear about the purpose and the main audience

To me, it's clear that there are needs in software development, for example, for user specifications, functional specifications, test cases, etc.
(But this thread isn't about that use of 'procedures' which I think is clear from the forum it's in and the context.) And to Panchobook and his particular context & improvement requirement, there also appears to be a firm need. I think he and I had reached a good understanding and appreciation of each other's positions earlier.

 

[Yarik]

Re: To write or not to write. That is the question. How many procedures should I writ

At the risk of repeating myself, I stand by what I already wrote (emphasis added):

• to write a document only when the need really is there, and
• you're clear about the purpose and the main audience

What is the risk of repeating here?! I believe statements like this one are worth repeating over and over, because it's way too easy to fall into "overdocumentation" trap...

And to Panchobook and his particular context & improvement requirement, there also appears to be a firm need. I think he and I had reached a good understanding and appreciation of each other's positions earlier.

I'm glad to know that you had. I just didn't see that from the previous posts (so I jumped in). I think I could blame it on ambiguity of human language: I did not realize that when Panchobook was talking about improvement, the established need for improvement was already assumed. I , sorry.

To me, it's clear that there are needs in software development, for example, for user specifications, functional specifications, test cases, etc.

(But this thread isn't about that use of 'procedures' which I think is clear from the forum it's in and the context.)

And here I obviously failed to convey my point.



I was not talking about THOSE kinds of software-related documentation. I was talking about "interface vs. implementation" distinction in software development vocabulary which seems to be a very good analogy to "process vs. procedure" and "activity vs. procedure" distinctions in ISO vocabulary (or, to some extent, to "overview vs. details", "surface vs. core", and "what vs. how" distinctions in common speak). And then I was trying to explain how that affects the thread's questions like "When to document a procedure?"

Obviously, my excursion to "analogy world" was made at wrong time (you and Panchobook already had a mutual understanding). But I maintain that it is quite relevant to the subject of this thread as a whole. After all, I hope you would not say that everything and everyone is clear about "process vs. procedure" distinction in ISO world, and that this distinction has nothing to do with documentation. Or would you?

Of course, please feel free to consider this question rhetorical - at least, in this thread.

Best regards,
Yarik.

 

[unitedc]

Re: To write or not to write. That is the question. How many procedures should I writ

Thanks to all who have posted. I've read through and have gotten a lot of great responses. Without looking back I may not have mentioned that I work in contract manufacturing for PCBoards. We have different lines that I would think could have a procedure written to each. However as mentioned in responses prior I'm sure our QM would rather be lean as possible when it comes to Auditable procedures. Myself I like the idea of having these in place where possible to maybe cause a more organized atmosphere. Not to say we are unorganized but there could be improvements that would make for easier production IMO. We have a small company and we are fairly new in our ISO acceptance. Mostly I wouldn't want to get us into something that would really get use zinged in the next audit but would love to see efforts that would make a difference in the company.

 

[Jim Wynne]

Re: To write or not to write. That is the question. How many procedures should I writ

Thanks to all who have posted. I've read through and have gotten a lot of great responses. Without looking back I may not have mentioned that I work in contract manufacturing for PCBoards. We have different lines that I would think could have a procedure written to each. However as mentioned in responses prior I'm sure our QM would rather be lean as possible when it comes to Auditable procedures. Myself I like the idea of having these in place where possible to maybe cause a more organized atmosphere. Not to say we are unorganized but there could be improvements that would make for easier production IMO. We have a small company and we are fairly new in our ISO acceptance. Mostly I wouldn't want to get us into something that would really get use zinged in the next audit but would love to see efforts that would make a difference in the company.

The determination of need for documentation shouldn't be based on the danger of getting "zinged." If a document is needed in establishing control over processes and you control the processes in accordance with the requirements, you don't have to worry about auditors.