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

[Randy]

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

To my question: Where do you say 'thats enough Procedures'?

When you have what you need to effectively do the work necessary.

Should a company have a procedure for everything that has a start and end?

Absolutely impossible to do..you'd wind up meeting yourself.

I realize we don't need procedures for restroom visits.

Wanna bet? I have one if you need it. Ever been to the head on a submarine, or off-shore oil facility?

You need what you need and only you can come up with the correct answer here.

 

[v9991]

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

while, we might agree that assessing the need for a documented procedure/WI for any given process must be evaluated[rationalised!]; consider the following thoughts!

1. what will be the basis/rationale for deciding whether documented-procedure/WI is required or not?
2. how do you justify your judgement for not having any defined-procedure?
3. how do you justify your 'policy' which says that the "procedures will be documented as the need arises [ok, based on continuous evaluation of need for defining a procedure!]"! [ i guess 'need' is identified/realised through the problems arising out/due of the process]?
4. even if the above approach may well be received for engineering/automotive industry standards where you can retrospectively justify for not having an defined procedures for any process. HOW do you justify the same from the approach where, the need is to define the procedure for 'assuring the product/process quality'. Some times the procedures are equally important as 'production-controls' ?

i might be putting forth these thoughts from point of view of regulated environments[viz., pharma/medical devices scenario]...

thanks in advance for the clarifications
valiveti.

 

[bobdoering]

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

Another way to look at the question of how many procedures to write is what a true quality minimalist would do:

Write no procedures, run the business totally on 'urban legend' and whim of the day management.

Whenever a situation that more scrap was made than was the cost of the overhead to write and maintain the procedure (cost justification), and the root cause was someone claiming they did not know what they were supposed to do, write a procedure.

Whenever a situation that only one person knows how to do a process, and there is a risk that they may leave the company, retire or die, and the cost of the overhead to write and maintain the procedure (cost justification) is less than reinventing the wheel to determine what the process was, write a procedure.

Not very pro-active, but it is what a true quality minimalist following the concepts of quality level TCE would do.

Disclaimer: I am not a proponent of quality minimalism. I just know there is a grass roots struggle to keep its concepts alive. The movement's motto: Keep it simple - darn simple! Bask in the luxury of being simple minded!

 

[Pancho]

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

Where do you say 'thats enough Procedures'? Should a company have a procedure for everything that has a start and end?

Here’s a slightly different take on this issue: documentation is required for continual improvement.

The documentation of your system, and any QMS, is, of course, used for training and quality assurance. While it may be alright to avoid writing a procedure when it isn’t necessary to produce quality, often this truism is used as an excuse for not writing a procedure that is really needed (or a work instruction, or any other QMS document).

Remember that another use for your documentation that is at least as important as the others is Continual Improvement. Jim above mentioned that a process is documented when designed. Yet most processes evolve after their initial design and implementation. If a process or task is not documented, then how can it be improved?

I believe the reason why documentation as a tool for Continual Improvement is often forgotten is not because it does not exist, but because there are (or, rather, were) several practical obstacles to using it in such way, such as accessibility of documentation, writing skill and the need for control.

Accessibility and writing skill make improving a document difficult even when a potential improvement is spotted. And control of printed documents, and many types of electronic ones, is difficult enough when they change only occasionally. When changes multiply, often control is often lost and documents can end up with erroneous information.

But we are going through a revolution at this very moment. And it will change our perception of what should be documented. The revolution comes in the form of collaborative software called a wiki (and complementary bug-tracking software). With a wiki, you can capture the unique expertise of every person that has any stake in the procedure: the person that designed the process or task, the person actually following the procedure to do her job, and trainees and trainers reading the procedure. They can all improve it. My company used a wiki to implement its QMS. We now have much more useful documentation than I could have ever predicted that we would need, and our processes are much improved as a result.

To summarize, if in doubt write a document. Make these documents accessible and open to all with a wiki, and your processes will improve.

Good luck!
Pancho

 

[JaneB]

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

Here’s a slightly different take on this issue: documentation is required for continual improvement.

Really? If you are saying one 'must document in order to do any kind of continual improvement', I disagree.

To summarize, if in doubt write a document.

Yikes! No! I'd disagree with that one too!! I'd never give this advice. 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
  

The last thing we need to be doing in the world of quality is adding to the mountains of useless (and unused) documents.

That said, I do agree that a wiki can be a useful tool, and I can quite understand that if you came from a position of having no (or almost no) doco, or having obtuse, hard to read and hard to find doco to having a wiki with clear & available info available at the click of a mouse, then that would be an improvement and that it could definitely assist with process improvements. But please, doco isn't the answer to all things, nor the best thing since sliced bread either.

 

[bobdoering]

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

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
  

The last thing we need to be doing in the world of quality is adding to the mountains of useless (and unused) documents.

See? Now that is quality minimalist approach! Write documents as corrective actions, not as a preventive approach.

I just love the notion of "mountains of useless (and unused) documents." Sure, it is great if the personnel that have been trained on what would be a documented process do not leave the company until if finally closes the doors, so you never need to train anyone ever again, or they never forget their training. And, sure, they may not be read every day - but that does not mean that having paid the insurance against not having a consistent process by having the process documented is not going have a benefit one day in the future. And, if they were never used, it just shows your training process is sloppy, and based in urban legend and rumor. That is not the documentation's fault.

 

[Pancho]

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

Really? If you are saying one 'must document in order to do any kind of continual improvement', I disagree.

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?

Yikes! No! I'd disagree with that one too!! I'd never give this advice. 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

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

• What if your client's master craftsman that does not need no stinkin document gets hit by a bus?
• What if your client gets an order that exceeds her capacity? Good luck trying to bring Joey Junior up to speed!
• And lets say Joey is brilliant and comes up with a new and improved way to do his work. How does your client's organization capture that knowledge?

"write a document only when there are some signs/data/evidence to show that not having this documented is causing problems"

Betcha your clients will take you up on that advice too often... to their detriment.

 

[somerqc]

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

Although I generally side on the minimalist side of documentation, I believe in writing your procedures in such a way that people can and actually do read them when needed (i.e. remind one how to do things, training, etc.).

My current employer has (kicking and screaming at one point) evolved to the point where we are enhancing our procedures and realizing that procedures for all key processes is a good thing when written and structured properly.

As a general rule, we eliminated most of the gibberish one sees in many manuals (re: regurgitation of regulations, long winded purposes and scopes, etc.). This doesn't mean we don't have these things; but, we do limit them to what is required or make references to them (i.e. OHS regulations)

The minimalist approach is due to the fact that in the past procedures were written for the lawyers and auditors of the world and NOT for the business.

Like anything, the pendulum swings back and forth over time and ending up in the middle. Is either approach perfect, NO - but, there are good points to both approachs that should be considered by anyone creating a QMS.

 

[dianel]

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

My last ISO auditor suggested we had less documentation. What it boils down to is that you have to do what is right for your company. We had some duplicated efforts in some areas and could use some streamlining. We like to use our documentation as a training tool for new employees so probably become more detailed then it needs to be. What standard were you audited to? ISO asks for 6 procedures. The rest are what processes the company decides are needed.

 

[bobdoering]

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

We like to use our documentation as a training tool for new employees so probably become more detailed then it needs to be.

Do you mean that the documents are too detailed to be effective for training, or that documentation used for training is too detailed for the system?