Documented Systems - Compliance vs. Effectiveness

What do you say to a person who tells you that their group are doing a great job in very difficult conditions, short of staff, working all the hours, and they don’t have time to keep the documentation up to date or hang around being audited? If you know that these guys are good and what they say is true, then what do you say? What do you do?
In these circumstances, I make plans to bear down on them at Management Review until they squeak. But I usually ease off and try to get positive, do what I can to help, and finish up with all the action items for myself.
The documented system is right for me. It suits my nature and my temperament. Maybe it isn’t always right, for everyone, in all situations.
Shortly, I’m going out to try my hand at consultancy in the big, cold world. That will knock some of the breeze out of me. I feel it already, no longer cocksure of the position I take, knowing it’s theoretically correct and that I can back it up ‘til hell freezes. I won’t be able to say; ‘This is right and that is wrong’, anymore. I’ll have to say; ‘This is me and that is my product, do you care to buy?’.
So, what do I say when the guy says ‘What’s in it for me?’. Do I say,
‘If you do this, then this will follow.’? or,
‘This is the theory. You put it into practise at your own risk’.
How can you sell a documented system when you, and the other guy both know that these systems seem to fail as often as they are successful, while operations without documents can often be high flyers? Is the documented system really the answer, or is it necessary most of the time because of deficiencies in qualification, training, communication and leadership.
The well armed, trained, disciplined and well officered troops don’t always beat the ragged rebels. In fact, it seems that the ragged rebels usually win out in the long run.

[Kevin Mader]

John,

I asked Marshal Thurber, a quality consultant and Deming disciple, at a lecture his opinion of "documented systems" such as you would find for ISO. I can say that I thought I knew the answer before he gave it. Like you, I thought to myself; what is the benefit of documenting a system if it does nothing to truelly improve the product? Does the customer care if your system is documented? Yeah some. How about the Consumer? Probably not. But it does provide structure for those of us who like things straght forward. His answer: "It's just paper. You need to focus on the system". The only benefit, in my opinion, to documenting a quality system is to help folks to understand the system, a general overview (a training tool as you stated). It is why I my general opinion of ISO is that it is fairly useless (alone anyway). The essence of it is good and consistent with my beliefs, but by itself it ensures nothing. The issue of having to document everything we do, well, it is just paperwork. I believe Marshal is right on this.

So what do you tell the guy who asks "What's in it for me?"...hmmm? I say give him the straight of it, just as you have presented in your post. Perhaps you'll stir up some quality management consulting outside of ISO consulting?

[Don Winton]

…short of staff, working all the hours, and they don’t have time to keep the documentation up to date or hang around being audited?

Try this:

4.1.2.2 Resources
The supplier shall identify resource requirements and provide adequate resources, including the assignment of trained personnel (see 4.18), for management, performance of work, and verification activities, including internal quality audits.

Seriously, if they do not have time to do it right, when will they have time to do it over? Only problem here is that right is subjective. Perhaps appropriate is a better term. It would also appear that a lack of commitment to the system is rearing its ugly head.

The documented system is right for me. It suits my nature and my temperament. Maybe it isn’t always right, for everyone, in all situations.

Just because a system must be documented does not mean it must be cumbersome and difficult to work within.

My spin. When an organization agrees that a Quality Management System is needed, they must be committed to its effective implementation. The key word is effective. AND, what is effective for one organization may not be appropriate nor effective for another.

How can you sell a documented system when you, and the other guy both know that these systems seem to fail as often as they are successful, while operations without documents can often be high flyers?

“Throughout History, Civilizations Have Risen by Setting Noble, Long–Term Goals for Themselves, but Civilizations Have Fallen by Being Shortsighted in the Attainment of Those Goals.”

Research and Development, Innovative Notebook

I do not believe that you sell a documented system, you sell its benefits. The usual criteria goes something like this: If everyone in your operation were abducted by aliens, how would you stay in business? Remove ‘tribal’ knowledge from the system, and it can continue to function without the tribe. But again let me state that just because a system is documented does not mean it must be cumbersome. What is appropriate is better. A master machinist does not need work instructions to manufacture a product from an engineering drawing nor does a Registered Nurse need work instructions to administer a flu shot. I also believe that when systems do fail, it is because of a lack of commitment and a lack of understanding of what is actually required from ISO (or whatever). Contrary to what most believe, ISO 9000 does not require reams of documentation and paperwork. That is one of the “myths.”

The standard requires that you document what you do and do what you document.

The standard requires procedures in only certain sections. While most companies develop procedures for each of the twenty clauses, they are not required except in the clauses that state “the supplier shall establish and maintain documented procedures…” The content and format of the procedures is entirely up to the company. The standard states in 4.2.2 that “the range and detail of the procedures that form part of the quality system depend on the complexity of the work, the methods used, and the skills and training needed by personnel involved in carrying out the activity.”

Upon critical review, ISO 9001 only REQUIRES 16 (17?) procedures. But does 16 procedures make for an effective Quality Management System. The organization must determine this.

The well armed, trained, disciplined and well officered troops don’t always beat the ragged rebels. In fact, it seems that the ragged rebels usually win out in the long run.

When the well armed, trained, disciplined and well officered troops do not have the commitment of their leaders, this is very true. Vietnam taught this lesson and the Gulf War taught the inverse of this lesson. Even Sun-Tzu knew this:

“One Whose General Is Capable and Not Interfered With by the Ruler Will Be Victorious.”

Sun-Tzu; The Art of War

Did this help, or did just muddy the water?

Regards,
Don

Don,
This may seem like a very simple question, but you had mentioned that procedures are only required for 16(17?) sections. What 4(3?) are they not required for? I know Servicing is not required.

Thanks,
Stephanie

[Don Winton]

Stephanie,

OK. Here’s the scoop. Everywhere you see ‘shall establish and maintain documented procedures,’ they are required, otherwise they are not.

These are the sections:

YES: 4.3, 4.4, 4.5, 4.6, 4.7, 4.8, 4.10, 4.11, 4.13, 4.14, 4.15, 4.16, 4.17, 4.18, 4.19, 4.20.

NO: 4.1, 4.2, 4.9, 4.12

Therefore, for 4.1, 4.2, 4.9, 4.12, procedures are not required. Are they needed? That is up to you and the system you decide to put in place.

Hope this helps.

Regards,
Don

[Don Winton]

Forgot something. Section 4.19 is optional, depending upon if it is a requirement.

Regards,
Don

Don's comments are right on the mark, and I have had similar experiences with documentation systems. One of the biggest complaints you hear about ISO is that it proliferates documentation.

Although obvious to quality professionals, the purpose of ISO is not to have a "big honkin' Binder" (Sun-Tzu - Dilbert, what's the difference? ;-) Documentation is the preservation of knowledge.

I work in a union shop where many manufacturing personnel have worked 20 plus years, and did a great job long before ISO came along. Documentation was and still is, a tough sell, keep in mind some of these marketing stategies when faced with someone irate about having documentation:

1) Documentation is not necessarily for what you do on a day to day basis when processes are going as they should. One of the biggest benefits of documentation is that it should describe what to do when things do not go as planned. Who to contact, what to do with the product, or how to CYA!

2) Since I inherited a company that had many long time experienced workers, they would not immediatly be sold on the theory that documentation is needed in case "Aliens abducted them". Something far more strange happened at my company -- forced early retirement! I'm sure this concept seemed as strange to them as alien abductions seem to us, until it happened. All that experience is lost - it wouldn't have been if was documented.

3) Another part of the documentation legacy my predecessor bestowed upon me was, the author (usually management) could write and approve his/her own documentation. The system now requires 3 different signatures (this can vary depending on company size): the author (now usually the operator), the author's supervisor or manager, and QA. The documents are now seen as a "contract" )(agreed upon by both parties) between management and union employees as to what should be done. This was a slow change and in it's infancy, but already has had positive benefits. It eliminates the "he said - she said" arguements, and reduces the number of grievences due to misunderstanding the requirements of the job. In addition, it is beginning to make quality (i.e. ISO-9001) a part of their job, as opposed to a quality add-on.

------------------


[This message has been edited by Christian Lupo (edited 03-11-99).]

[Marc]

I hadn't thought of documentation in the sense of a contract. Good point.