The Elsmar Cove Business Standards Discussion Forums More Free Files Forum Discussion Thread Post Attachments Listing Elsmar Cove Discussion Forums Main Page
Welcome to what was The Original Cayman Cove Forums!
This thread is carried over and continued in the Current Elsmar Cove Forums

Search the Elsmar Cove!

Wooden Line
This is a "Frozen" Legacy Forum.
Most links on this page do NOT work.
Discussions since 2001 are HERE

Owl Line
The New Elsmar Cove Forums
Thread Closed  Topic Closed
  The New Elsmar Cove Forums
  ISO 9001/4:2000
  Meeting the INTENT

Post New Topic  
profile | register | preferences | faq | search

UBBFriend: Email This Page to Someone! next newest topic | next oldest topic
Author Topic:   Meeting the INTENT
Marc Smith
Cheech Wizard

Posts: 4119
From:West Chester, OH, USA
Registered:

posted 29 July 2000 11:16 AM     Click Here to See the Profile for Marc Smith   Click Here to Email Marc Smith     Edit/Delete Message   Reply w/Quote
From: ISO Standards Discussion
Date: Tue, 25 Jul 2000 09:41:01 -0500
Subject: Re: Intent vs requirement /Marshall/Hankwitz

From: "Hankwitz, John" John.Hankwitz@qtiworld.com

> From: "Art Marshall"
> This is just an observation, and was wondering why......
>
> Many times while reading some of the email on this list,
> I see things like ".... meeting the intent of 4.8,..." etc.,
> instead of.... meeting the requirement of 4.8.... (snip)
> Why are folks using the word intent and not requirement?

Art,

I would guess because the "requirement" is words, and "intent" is what's behind the words. All too often, users read and use the words without having a clue as to what the words are saying, or think they say something that just isn't true.

As an example, ISO 9001:1994 4.1.2.1 Responsibility and authority states, "The responsibility, authority, and the interrelation of personnel who manage, perform, and verify work affecting quality shall be defined and documented..." You have no idea how many people insist that this mandates the creation of an Organizational Chart.

I often see the same thing when people reference Deming's 14 points. They rattle off a point as a example to help make their point, and it's obvious they haven't a clue about the point being made. It's clear they never took the time to read the book and are therefore operating on misguided assumption.

John Hankwitz

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

From: ISO Standards Discussion
Date: Tue, 25 Jul 2000 09:43:29 -0500
Subject: Re: Intent vs requirement /Marshall/Arbuckle

From: "Donald Arbuckle" iso9kda@doitnow.com

Art brings up a good question, and since I have probably used both words as much as anybody else, I suppose I ought to explain my "intent."

The standard defines requirements, which are things that must be done. It does not define "how" to do them; (thank heavens!) that is left up to the organization to figure out. In many cases, the requirements can be met in a number of ways, depending on the outcome that best serves the organization. That is the "intent" of the requirement.

When I refer to "intent" I am speaking in terms of what is best for the business in meeting the requirement itself. I accept that "intent" is always up for interpretation by others and believe that one organization's reading of "intent" may be different from another's. That is what makes the world go round. I believe the standard gives us the right to "interpret" the requirements in the Introduction itself, "The design and implementation of a quality system will be influenced by the varying needs of an organization, its particular objectives, the products and services supplied and the processes and specific practices employed." Just like everything else, then, "Reality is nothing more than the perception of the masses." Substitute "Intent" for Reality.

Donald A. Arbuckle

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

From: ISO Standards Discussion
Date: Tue, 25 Jul 2000 09:45:25 -0500
Subject: Re: Intent vs requirement /Marshall/Humphries

From: "Edwin Humphries" edwin@e-quality.com.au

Art,

The history of ISO9000 is from a very specific industry: defence engineering contracting. If one simply applies the strict requirements (or even worse, the normal interpretations from that industry) to other industries, one ends up a bureaucratic nightmare, irrelevant to the organisation or to the needs of its customers - hence not conforming to ISO9000!

Therefore, one has to use a little wisdom and insight to understand what ISO9000 is trying to achieve, and work out how, in a normal "other" industry environment, one is going to achieve the same ends.

This is improved in the Y2K DIS, but not completely eliminated.

Best Regards
Edwin Humphries

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

From: ISO Standards Discussion
Date: Tue, 25 Jul 2000 09:49:47 -0500
Subject: Re: Intent vs requirement /Marshall/Kozenko

From: Write9000@aol.com

Art Marshall inquired:
"Why are folks using the word intent and not requirement?"

Everywhere I've seen "intent" used in a post, it's been to explain this nuance: that the strict interpretation and application of a stated requirement just does not make good business sense.

David M. Kozenko

IP: Logged

Marc Smith
Cheech Wizard

Posts: 4119
From:West Chester, OH, USA
Registered:

posted 29 July 2000 11:20 AM     Click Here to See the Profile for Marc Smith   Click Here to Email Marc Smith     Edit/Delete Message   Reply w/Quote
From: ISO Standards Discussion
Date: Tue, 25 Jul 2000 13:21:03 -0500
Subject: Re: Intent vs requirement /Marshall/Arbuckle/Scott

From: Pfscott2@aol.com

Don concluded with...
Just like everything else, then, "Reality is nothing more than the perception of the masses."

Art,

While I certainly wouldn't leap to Don's conclusion, what is "intended" by a "requirement" does depend on many things, not the least of which are the perceptions (grids, biases) of the one(s) attempting the translation. Hopefully, and I think generally, there is sufficient range in the areas of agreement among those implementing a system and those auditing the system that a useful standardization process results.

Count me among those whose perception is that one gets good return on the investment when one straightforwardly approaches the requirements of a standard, implements them in a way that demonstrably makes good business sense, and fanatically avoids resorting to elaborately constructed illusions to pass an audit.

Regards,
Phil Scott

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

From: ISO Standards Discussion
Date: Tue, 25 Jul 2000 13:35:40 -0500
Subject: Re: Intent vs requirement /Marshall/Scalies

From: "Charley Scalies" scalies@snip.net

Art,

That's a fair question. Assuming for a moment that there is a difference,
given the choice what would folks rather do? Meet the intent of the standard
or the requirement? I'll bet the answer will differ depending upon whether
"Job 1" is Registration or Quality.

What is the intent of 4.8? Making sure that, at all times, you know what it is you are working on so that you can match it to its requirements. Does ISO really care how you do that?

What is the intent of 4.5? To have a "master list or equivalent" or to be certain that the right documents are right there, where and when they are needed, and that they are used.

What is the intent of 4.3? To review contracts and complete Contract Review forms or to be certain you and your customer have a meeting of the minds and that you have the ability to do what you agree to do?

Have you ever seen someone deliver an ISO9000 orientation where all they do is recite the "requirements?

4.1 says, ..... 4.2 says, .... By 4.7, everyone in the room is catatonic. On the other hand, a highly effective orientation can be done using only a single graphic as the tool to describe what an ISO9000 quality system is really all about. I do it all the time. I think I leave my audience better informed: I know I leave them breathing.

ISO9000 is not 18, 19 or 20 requirements. It's about 1 thing. A quality system. It's a forest, not a collection of trees. The trees are important, but getting too hung up in the "requirements" without being fully cognizant of their intent and how they all fit together results in, as the hackneyed saying goes, not being able to see the forest thru the trees.

Finally (at last!) if you were given just 30 minutes in which to conduct an audit of the effectiveness of a quality system, would you try to audit all 18...20 elements (requirements) or would you go straightaway to verifying whether or not the quality policy was being fulfilled (intent)?

Charley Scalies

IP: Logged

Marc Smith
Cheech Wizard

Posts: 4119
From:West Chester, OH, USA
Registered:

posted 29 July 2000 11:21 AM     Click Here to See the Profile for Marc Smith   Click Here to Email Marc Smith     Edit/Delete Message   Reply w/Quote
From: ISO Standards Discussion
Date: Tue, 25 Jul 2000 13:56:54 -0500
Subject: Re: Intent vs requirement /../Kozenko/Hartman

From: dhartman@phdinc.com

David M. Kozenko stated, "Everywhere I've seen "intent" used in a post, it's been to explain this nuance: that the strict interpretation and application of a stated requirement just does not make good business sense."

Perhaps showing my age a bit: Exactamundo! Or as the Quality Director at one of my former employer's would say "Meet the requirement, but don't do anything stupid."

The idea is to implement a quality program that meets the requirements, but does so in a fashion that does not hinder, but benefits the company. I have been responsible for the creation and implementation of ISO 9001 and 9002 programs at 8 small to large companies in the past 8 years and have never seen an instance where I could boiler-plate the entire program (perhaps portions, but never entire programs). To develop a single way of meeting the requirements and forcing it on every facility or company would be too cost prohibitive, or would not be implemented properly/consistently, since in many case entire cultures would have to change.

Maybe I'm too naive, but I enter most successful companies with the thought that the way they are doing business more than likely meets the "intent" of the ISO requirements, one just has to interpret (and document) what they are doing in such a fashion that it clearly addresses the ISO requirements. I realize that 8 companies is not a large population (perhaps not even a significant population), but so far I haven't been wrong.

BTW: If you didn't catch it, the significant words in my theory are "successful companies". Companies that aren't successful might even benefit by performing a realistic gap analysis against the requirements (not that a quality program is the cure all for company ills, but in many cases it wouldn't hurt).

David Hartman

IP: Logged

Marc Smith
Cheech Wizard

Posts: 4119
From:West Chester, OH, USA
Registered:

posted 29 July 2000 11:23 AM     Click Here to See the Profile for Marc Smith   Click Here to Email Marc Smith     Edit/Delete Message   Reply w/Quote
From: ISO Standards Discussion
Date: Wed, 26 Jul 2000 09:17:41 -0500
Subject: Re: Intent vs requirement /Marshall/Pfrang

From: "Pfrang, Doug" dpfrang@nicoletbiomedical.com

"Intent" is often invoked when someone doesn't want to comply with a particular requirement of the ISO Standard and can't figure how else to avoid it, or, what is more pernicious, when someone wants to impose a requirement that isn't in the Standard at all. Because it is entirely subjective, the "intent" of the Standard can be anything someone wants it to be, which is precisely why all arguments based on "intent" are unreliable. This is especially true when dealing with someone who was not part of the ISO Standards committee, because such a person has no trustworthy knowledge of what the "intent" is anyway. What matters is what the Standard _objectively_ requires, and the only source for that information is the Standard's actual wording.

-- Doug

IP: Logged

Marc Smith
Cheech Wizard

Posts: 4119
From:West Chester, OH, USA
Registered:

posted 29 July 2000 11:28 AM     Click Here to See the Profile for Marc Smith   Click Here to Email Marc Smith     Edit/Delete Message   Reply w/Quote
From: ISO Standards Discussion
Date: Thu, 27 Jul 2000 11:15:52 -0500
Subject: Re: Intent vs requirement /../Pfrang/Andrews

From: eandrews@usffiltration.com

Doug wrote (in part);
"What matters is what the Standard _objectively_ requires, and the only source for that information is the Standard's actual wording."

All right - I tried to stay out of this discussion; however, I feel the need to relay a little story (true) that I keep in mind to illustrate "intent" vs. actual wording.

Several years ago a client of mine was undergoing an ISO 9001 audit by a representative of a well known registrar. We were in the 'Quality Records' phase of the audit. The auditor, with copy of Standard in hand and reading word for word 4.16, wanted to see where in their procedures they had defined the "identification, collection, indexing, access, filing, storage, maintenance, and disposition of quality records.". The client confidently showed where in each applicable procedure they had identified how the quality records were identified, how (by date/alphabetically/numerically, etc.) and where they were filed, who had access, for how long (minimum) they were filed and how they were to be disposed of.

The registrar auditor, peering over his glasses, asked where in each of the procedures the client had addressed the "indexing" of the records. The client patiently pointed to the part of each procedure that explained how the records were filed (by date, etc.). The auditor, now getting a bit impatient, stated that what the client had described was the 'filing' part of the requirement (as the client had even called it 'filing' in the procedures). the auditor wanted to see where the 'indexing' part of the requirement had been specifically defined.

At this point in the, obvious disintegration, of the audit process, I intervened. I had a mini-conference with the auditor and it is at this point where I used "intent" vs. "word for word" interpretations of the Standard. It is obvious, to most anyway, that the "intent" of 4.16 of ISO 9001 is for a company to have a defined system in place that describes how quality records are identified, how they are stored, who can get to them, how long they are to be kept, and how they are disposed of so that those who need the information, be they internal people or external auditors/customers, can get their hands on it. Period.

Anyway - it has been so long that I forget what the final outcome to this story was (agreement or finding?); however, the story has stuck in my mind as a good example of how individuals can get lost in the "wording" of the Standard and lose sight of the "intent".

Sorry to be long winded on this one - but I thought it might be a story worth telling for this topic.

Ethan Andrews

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

From: ISO Standards Discussion
Date: Thu, 27 Jul 2000 11:19:34 -0500
Subject: Re: Intent vs requirement /../Pfrang/Humphries

From: "Edwin Humphries" edwin@e-quality.com.au

Doug,

In the words of the immortal bard: I disagree with what you say, but will defend to the death your right to tell such LIES! :-)

Actually, I agree with some of it: "intent" IS often used in the ways you describe. However, I believe that a literal interpretation of ISO9001 will get you into trouble more often than not, UNLESS you try and understand what the writers intended by the requirement.

So often, the Standard refers to "where applicable", "where relevant" and "where appropriate"; all too often, the simplistic interpretation is that it must always be applicable, relevant and appropriate. Examples:

1. "A master list or equivalent document-control procedure identifying the current revision status of documents shall be established and be readily available to preclude the use of invalid and/or obsolete documents." Here, the "master list or equivalent document-control procedure" are merely examples; the intent is that the use of "invalid and/or obsolete documents" is "precluded".

2. "Purchasing documents shall contain data clearly describing the product ordered, including where applicable: a) the type, class, grade, or other precise identification; b) the title or other positive identification, and applicable issues of specifications, (etc.); c) the title, number, and issue of the quality-system standard to be applied." All too frequently, this translates in practice to a requirement to provide such information on orders whether relevant or no, and to rule any orders lacking any of the information as non-conforming. The INTENT is to ensure that the goods are sufficiently well described that the supplier can be in no doubt as to the identity of the goods required; frequently that can and should be done without most, sometimes all, of the information specified.

3. How many companies have procedures for Customer-supplied goods or for Statistical techniques that are not used, simply because someone insisted that these elements must be dealt with in some form, that the "where relevant" clauses still apply to everyone. The INTENT here is obviously to ensure that such activities, IF CARRIED OUT, are under appropriate control, and not to insist that every company uses them.

My point is that the concept of "intent" plays an essential role in the development of an effective (and fully compliant) quality system. Systems should not be developed by people with no practical experience of business or the industry in which they are operating, and they should be implemented with minimum impact and building on existing systems, rather than replacing them. You simply can't do this without considering or attempting to understand the "intent" of each clause.

Best Regards
Edwin Humphries

IP: Logged

Marc Smith
Cheech Wizard

Posts: 4119
From:West Chester, OH, USA
Registered:

posted 29 July 2000 11:31 AM     Click Here to See the Profile for Marc Smith   Click Here to Email Marc Smith     Edit/Delete Message   Reply w/Quote
From: ISO Standards Discussion
Date: Thu, 27 Jul 2000 12:03:17 -0500
Subject: Re: Intent vs. requirement /../Staples/Arbuckle

From: "Donald Arbuckle" iso9kda@doitnow.com

The auditor was wrong and you were right to not accept it as a nonconformance. I also question the value of it as an observation, but at least you were able to get back to the audit. (I would question the value of the audit itself, given how odd the auditor appears!)

I would also agree with you that the word "intent" should be left out of the audit, unless the intent is defined (verbally by someone in a position of authority) or in a document. Then it is appropriate to verify the intent and effectiveness of the process to ensure intent is met.

Oh, one other word that has no place in and audit, especially from the auditor's mouth..."should." I cannot think of any reason why an auditor would use that word.

Donald A. Arbuckle

IP: Logged

Marc Smith
Cheech Wizard

Posts: 4119
From:West Chester, OH, USA
Registered:

posted 29 July 2000 11:36 AM     Click Here to See the Profile for Marc Smith   Click Here to Email Marc Smith     Edit/Delete Message   Reply w/Quote
From: ISO Standards Discussion
Date: Fri, 28 Jul 2000 10:34:19 -0500
Subject: Re: Intent vs requirement /../Pfrang/Andrews/Kozenko

From: David M. Kozenko Write9000@aol.com

In the ISO9001:1994 Standard you will find the word "Indexing" in only a few places.

Ethan's post (quoted below) is a perfect example of what sometimes happens in the real world, when everyone wants to do what makes good business sense, but not so many people know that "Indexing" is a librarian's term that contemplates some sort of relational databasing, be it manual or fully computerized, or some mix 'tween the two.

In this example, I have to give the credit to the 3rd Party Auditor, who realized that the "intent" of the meaning of "Indexing" just blew right over everyone's head, and let it go.

Ethan, if you did "Index" to suit the intent, in your example, then I missed it and I apologize.

David M. Kozenko

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

From: eandrews@usffiltration.com

Doug wrote (in part);
"What matters is what the Standard _objectively_ requires, and the only source for that information is the Standard's actual wording."

All right - I tried to stay out of this discussion; however, I feel the need to relay a little story (true) that I keep in mind to illustrate "intent" vs. actual wording.

Several years ago a client of mine was undergoing an ISO 9001 audit by a representative of a well known registrar. We were in the 'Quality Records' phase of the audit. The auditor, with copy of Standard in hand and reading word for word 4.16, wanted to see where in their procedures they had defined the "identification, collection, indexing, access, filing, storage, maintenance, and disposition of quality records.". The client confidently showed where in each applicable procedure they had identified how the quality records were identified, how (by date/alphabetically/numerically, etc.) and where they were filed, who had access, for how long (minimum) they were filed and how they were to be disposed of.

The registrar auditor, peering over his glasses, asked where in each of the procedures the client had addressed the "indexing" of the records. The client patiently pointed to the part of each procedure that explained how the records were filed (by date, etc.). The auditor, now getting a bit impatient, stated that what the client had described was the 'filing' part of the requirement (as the client had even called it 'filing' in the procedures). the auditor wanted to see where the 'indexing' part of the requirement had been specifically defined.

At this point in the, obvious disintegration, of the audit process, I intervened. I had a mini-conference with the auditor and it is at this point where I used "intent" vs. "word for word" interpretations of the Standard. It is obvious, to most anyway, that the "intent" of 4.16 of ISO 9001 is for a company to have a defined system in place that describes how quality records are identified, how they are stored, who can get to them, how long they are to be kept, and how they are disposed of so that those who need the information, be they internal people or external auditors/customers, can get their hands on it. Period.

Anyway - it has been so long that I forget what the final outcome to this story was (agreement or finding?); however, the story has stuck in my mind as a good example of how individuals can get lost in the "wording" of the Standard and lose sight of the "intent".

Sorry to be long winded on this one - but I thought it might be a story worth telling for this topic.

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

From: ISO Standards Discussion
Date: Fri, 28 Jul 2000 10:40:38 -0500
Subject: Re: Intent vs requirement /../Humphries/Kozenko

From: Write9000@aol.com

> Humphries stated:
> Systems should not be developed by people with no practical experience of business
> or the industry in which they are operating, and they should be
> implemented with minimum impact and building on existing systems, rather
> than replacing them. You simply can't do this without considering or
> attempting to understand the "intent" of each clause.

I agree with every part of Edwin's post except the portion quoted above, and only for this reason:

As a (take your pick ---> ) consultant's, quality manager's, ISO-Guru's medically measurable intelligence quotient increases, his/her ability to transcend the "industry specific" limitations in applying ISO9000 is correspondingly greater.

I have applied ISO9000 to several medical practices, and the only business or industry experience I have there is (albeit as a patient) professionally limited. But something magical happened when I kicked the quality butt of a doctor or two ;o) and I may never get the "cross pollination" award for ISO9000 application, but I'm confident in saying I might have saved a life or two for what little I've done there to the big picture.

To Edwin's credit, I must say that I did figure out how to blend what I knew about "systems" with that which was already in place.

Nothing personal Edwin. I will consistently slam anyone who even suggests that cross-pollination of ISO9000 precepts should not be attempted, much less, won't be successful.

Just an IMHO, 7 cents, 2 cents, take your pick

David M. Kozenko

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

From: ISO Standards Discussion
Date: Fri, 28 Jul 2000 10:43:49 -0500
Subject: Re: Intent vs. requirement /../Arbuckle/Kozenko

From: Write9000@aol.com

> Arbuckle writes:
> I would also agree with you that the word "intent" should be left out of the
> audit, unless the intent is defined (verbally by someone in a position of
> authority) or in a document. Then it is appropriate to verify the intent
> and effectiveness of the process to ensure intent is met.

If this thread was a high school dance, then I'd be the D.J. interrupting right now with this announcement:

If you are a firm's Quality Rep. or Quality Manager or similar position of import, and also, in the event you feel there is a question that could reasonably arise regarding your firm's application of ISO9000, where that application is conditioned upon your firm's interpretation of INTENT, then...

By all means, please specify it in your higher level quality documentation, be it Quality Manual, Senior Management Quality Directives, or even Quality Policy, but whatever it is, make it an integral part of your quality system documentation, what your firm's interpretation of the "intent" is, ok?

What will matter most, when the 3rd party auditor has sharpened pencil in hand, is whether or not you have satisfied the requirement of the 1994 Standard: "... and can be demonstrated."

You can blither and blather all you want internally about what the "intent" of a requirement is, but when the 3rd party auditor gets there, all that matters is (1) what you say that matters [which is, in fact, your own interpretation of what "intent" means in your firm's particular circumstances], and (2) any available "prove it" documentation your firm may have to show that it is meeting the "intent" requirements of (1) above.

(In the event I have not sufficiently beaten this "intent" horse to death, please issue clarification inquiries and I will dispatch a flogger of sufficient and appropriate length ;o)

David M. Kozenko

IP: Logged

Roger Eastin
Forum Wizard

Posts: 345
From:Greenville, SC
Registered:

posted 31 July 2000 04:15 PM     Click Here to See the Profile for Roger Eastin   Click Here to Email Roger Eastin     Edit/Delete Message   Reply w/Quote
Wow, this is a great post!! All the wrangling back and forth over "intent" and "requirement" has cleared these concepts up like a slab of thick mud. I understand what is meant by "intent", but how do you audit to intent unless it is defined somewhere? I hate to get too tongue-tied on this one, but I can't audit to something "behind the words"! This is difficult, because I sympathize with those who argue for intent - principally, because Intent = common sense! But even common sense sometimes can mean one thing to a person and something else to another person. So where does this leave us....

IP: Logged

Marc Smith
Cheech Wizard

Posts: 4119
From:West Chester, OH, USA
Registered:

posted 31 July 2000 05:23 PM     Click Here to See the Profile for Marc Smith   Click Here to Email Marc Smith     Edit/Delete Message   Reply w/Quote
Uh, yeah. After the thread I doubt I can add anything. To me it's just semantics. You have to do what it says - intent is in the interpretation. For example, there's a recent thread here on showing evidence of review of POs. We know what the intent is -- to ensure the supplier knows what to send you by adequately describing requirements. Now - if a PO is printed after review and mailed (or otherwise transmitted), does this provide evidence of review or does there also have to be a signature. Does it make a difference if the product being bought is 'off the shelf' hardware store type connectors (nuts and bolts) as opposed to semi-conductor silicon rods?

Intent comes into play where the standard does not specifically say how to accomplish something.

IP: Logged

John C
Forum Contributor

Posts: 134
From:Cork City, Ireland
Registered: Nov 98

posted 31 July 2000 06:05 PM     Click Here to See the Profile for John C   Click Here to Email John C     Edit/Delete Message   Reply w/Quote
We have to remember that we are discussing a standard. The standard is not the intent. The standard is the words. You canāt make objective evaluations of a personās intent, only of a personās actions.
However, it does help a lot if you have a good idea of the intent. So where do you find out what the intent is, ie; the intent of the person who wrote the clause? There is only one place and that is in the words. This is one of the reasons that I have often advised, in this forum; ĪRead the standard carefully. Use a dictionaryā.
What happens when you donāt read the words carefully, follow them and try to glean from them the intent? Well, it just happens that we have an excellent example above in this discussion; the story told by Ethan Andrews.

Ethan,
Your story was certainly, as you hoped, Īworth telling for this topicā. I hope youāll forgive me for using it as an example of the sort of misconception that I try to eradicate with the advice I offered above;

The story tells how your client, when asked where the quality records were indexed, told how each procedure described how the relevant record was filed. (exactly the auditorās concern) As you clearly point out, your client did not meet the standard because they did not provide an index. Not only did they fail in following the words, they did not understand the intent, in fact, they had a preconceived notion about the intent of the requirement for an index.

Why does the standard require an index? Well, it is not for use of the person who implements the procedure that shows how the quality record is obtained. That person is only interested in his/her own records. No, the index is for use of managers and auditors who wish to evaluate the performance of the organisation and see whether they meet their quality policy, or to make decisions whether to take on a prospective supplier or strengthen a department or, maybe, sack their management representative or change their consultant. Those are the sort of things that the index is useful for. The quality records are more important than the method by which they are obtained.

The Īintentā is that we should have an index.

Not only did your client fail to meet the requirement, they failed to understand the intent. In supporting the client, you frustrated the auditor, who was perfectly justified in insisting on the index, and caused the disintegration of the audit. Then, to add insult to injury, you held the auditor up to ridicule, making statements like Īpeering over his glassesā and saying how he reacted Īimpatientlyā to your angelic clientās Īpatient explainingā.
Later you say how; ĪIt is obvious, to most anyway........ā and go on to explain what is obvious to most. Yes, unfortunately, on this point, you are quite correct.

Of course we should have an index. But your dictionary will show you that not only can an index be an alphabetical or numerical list, it's primary meaning is simply, a pointer. So, if you only have five items, you don't need an elaborate list, just scan through the folders - the names become the index. What is the index for a telephone directory? it is the fact that it is widely known that the entries are in alphabetical order. That's what points to the section you need.
Similarly, armed with the will to read the standard carefully, a dictionary to help understand what it says, an open mind and a bit of imagination, you can meet all the requirements, fulfill the intent and do it effectively and efficiently. I don't believe for a moment that to meet the requirements, literally, should cause any problems or any waste of resources. If anyone has a specific case to the contrary, that they can support convincingly, then I'd be glad to hear it - or is it just a notion?

rgds, John C

IP: Logged

Andy Bassett
Forum Contributor

Posts: 274
From:Donegal Ireland
Registered: Jun 1999

posted 03 August 2000 03:07 AM     Click Here to See the Profile for Andy Bassett   Click Here to Email Andy Bassett     Edit/Delete Message   Reply w/Quote
I wasnt going to reply to you John, because i know i am going to go out on a limb in an environment full of ISO experts. But i slept on it overnight and thought i couldnt let the post pass.

I get the impression that you beleive ISO 9000 is a standard and should be complied with lock stock and barrel, without attempting to interpret the intent. I guess my first point is that although ISO 9000 is a standard, it is not the sort that can obejctively measured in inches or litres. Some interpretation is almost inevitable.

I must confess i encourage my customers NOT to read the standard, rather i encourage them to look at whats required to make their business work effectively and produce high quality products (I provide some background steering if necessary to ensure that the standard is complied with). Some people may argue that this would be the case if ISO is followed without interpretation, but i would argue that this is not the case. ISO was designed for making bombs and has now been stretched to suit any industry, which is why i beleive that if it can be used at all the interpretation needs to be stretched.

Without exception, in Žvery company that i have been to, the quality of the output is driven by factors that are NOT included in the ISO standard (if this wasnt the case why has Rover just been sold for 10 pound when Toyota is the fourth biggest manufacturer in the world, the UK having 6 times more ISO certified companies than Japan). ie employee motivation, leadership etc

I take the standard and interpret it in the best way that i think fits the company. For example, when i look at the new requirements for Process Measurements, i may include for example Company Climate Studies, if i think that the company needs a little focus on the leadership issues.

Lastly i suppose i do this dance because i beleive that it will be better accepted by the company and yield better benefits. I use ISO because in certain environments (ie manufacturing) or at certain stages of a companies development (ie ground level) it can be a useful development tool, but only if it is interpreted to suit the company.

ISO to me is nothing more than a company improvement tool, but not in its raw form, and incidentally their are better tools on the market to improve companies.

------------------
Andy B

IP: Logged

Marc Smith
Cheech Wizard

Posts: 4119
From:West Chester, OH, USA
Registered:

posted 03 August 2000 05:49 AM     Click Here to See the Profile for Marc Smith   Click Here to Email Marc Smith     Edit/Delete Message   Reply w/Quote
"...Some interpretation is almost inevitable...."

I'd leave the word 'almost' out of this sentence.

IP: Logged

Tom Goetzinger
Forum Contributor

Posts: 123
From:Milwaukee, WI USA
Registered: Mar 99

posted 03 August 2000 12:33 PM     Click Here to See the Profile for Tom Goetzinger   Click Here to Email Tom Goetzinger     Edit/Delete Message   Reply w/Quote
Andy,
As usual, you've said it very well, and I can't see any reason for anyone disagreeing with what you said.
As I've said many times and repeat every chance I get, IF IT DOESN'T MAKE GOOD BUSINESS SENSE FOR YOU COMPANY TO DO, DON'T DO IT, AND BE PREPARED TO JUSTIFY WHY.

------------------
Tom Goetzinger

IP: Logged

Roger Eastin
Forum Wizard

Posts: 345
From:Greenville, SC
Registered:

posted 03 August 2000 01:12 PM     Click Here to See the Profile for Roger Eastin   Click Here to Email Roger Eastin     Edit/Delete Message   Reply w/Quote
I think Andy has the right attitude about the standard. It should always be applied as a tool to improve business. It is a very expensive burden (especially third party registration) if a company does not take this attitude. I think it's been said many times here before that ISO or QS is a minimum set of steps to take for good business.
However, and I don't think that Tom meant it quite this way, one could say that a certain requirement in the standard doesn't make good business to apply (too expensive, little added value, etc). That doesn't mean that the company doesn't have to apply it (I'm speaking of third party registration). I think that Mr. Hartman (one of the quotes above) said it best: Find out what the company (ie, successful company) is doing presently and check the standard to see where they comply. Document that. If they are not compliant in other areas, see what it takes to get there and document that. Do all this within the current system the company is using. Now if the company is struggling, then the standard could be used as baseline to help that company get started. The job is more difficult, but the strategy is the same. The requirements taken literally are good. Someone could certainly twist them to make them say something that they aren't and I think that's where the standard gets a bad name. There is much good business sense in the standards themselves. I think the work here for a company is seeing where good business practices and the standard meet.

IP: Logged

John C
Forum Contributor

Posts: 134
From:Cork City, Ireland
Registered: Nov 98

posted 05 August 2000 04:56 AM     Click Here to See the Profile for John C   Click Here to Email John C     Edit/Delete Message   Reply w/Quote
Andy,
You said;
ĪI get the impression that you beleive ISO 9000 is a standard and should be complied with lock stock and barrel, without attempting to interpret the intent.ā

That isnāt the impression I tried to convey. What has happened here is that you have misinterpreted my intent because you didnāt read what I said, carefully. In my first paragraph I emphasised the importance of the intent and of understanding it by reading the standard carefully. I gave an example where the reader ignored the requirement for an index, chiefly because he had applied his own, mistaken intent to the clause.

What are we trying to achieve? Well my starting point is that ISO 9001 exists and that people want to maintain certification with minimum cost and disruption. So we canāt just throw it out. My next observation is that it is very badly administered and implemented. Years of investigation have shown me that the reason for this is that people do not understand it, have the misconception that it is a quality tool rather than a management tool and that a lot of people have a personal agenda which is better served by sidelining the standard.

The question then is; ĪHow do we change this?ā and the best answer I have come up with is that, not only will better implementation minimise the cost and disruption caused by certification, it will actually help to make your business more competitive.

Hereās where you come in; As a self proclaimed novice in ISO 9001 issues, and a confirmed critic of it, you are typical of the bulk of management who stand in the way of good implementation. You are from the other camp and, if we can understand you and find out what changes your mind, then we might have the key to changing a lot of other peopleās minds.

It is certain my conviction gains infinitely
the moment another soul will believe in it
Novalis

(ĪWhoās this guy Novalis?ā. Well itās some old poet from Saxony and itās written up in the front of the Conrad story Iām reading. I thought it was quite apt.)

You advise your clients on the implementation of ISO 9001/2 and tell them not to read it, yet you havenāt read it carefully yourself. All you have is Īreceivedā knowledge, rubbed off from the people you worked with over the years. Itās their generalised mass of opinion regards management practise, quality and the standard. What I suggest is that you read the standard for yourself but first, discard the burden of negative associations such as Rover (their troubles stem from too much 4.2 and not enough 4.1), bombs (with the old connotation that Ībombs are bad, therefore ISO 9000 is badā, etc)
Letās face it, as a sharp, up-to-the minute business consultant, you do yourself more good than harm in knocking ISO 9000 when talking to your clients. You are pandering to their misconceptions and private agendas but who could blame you? - thatās business. But it wonāt hurt you to understand ISO 9001 - we wonāt tell.

If you read ISO 9001/2, (just read section 1 and 4.1 for a start - thatās the bit that matters, the rest is just the nuts and bolts) youāll find, in section 1, that the overall intent is to be able satisfy customerās expectations and have a means to demonstrate the ability to do so. In 4.1, it goes on to require that you have a policy (no bad thing) which lays out the general method by which you will satisfy customerās expectations and meet your business objectives. It follows, although it doesnāt say so, that you should have a very clear idea of what your customerās expectations and your business objectives are and also, that you should review these carefully to be sure that they are the right ones, they are met and they work.
Andy, there is a hell of a lot of good stuff in 4.1.1, although it is only a three sentences. Itās the best bit of advice you could give to any business manager. One thing that you get from it, with careful consideration is that this Īqualityā does not mean the quality function, the quality department, the QA and the QC and the inspection and statistics and all that garbage. It means the quality of management and the quality of customer satisfaction. It is relevant to the business goals. It mentions only these items.

For the life of me, I cannot read 4.1.1 without thinking of it in terms of business goals and customer satisfaction. It is, in your own words; Īwhats required to make their business work effectively and produce high quality productsā.

The use of the word Īqualityā is misleading, because it brings to mind all those inspection, AQL and such, things - not management stuff at all, which give people leave to consign ISO 9001 to someone lower down in the ranks. But this is not a quality technique document, it is about management thoughout the organisation but it starts and ends with senior management. It should never, never, never be allowed near the quality manager and the quality department.

Look at the term; Īsupplierās management with executive responsibilityā. What does that mean? It can only mean the CEO. Others have only a portion of delegated executive responsibility. The only person that fits the bill is the CEO.

Letās think about 4.1;
I have no difficulty in implementing it as written; I think that itās great to have a policy aimed at satisfying customers, which is not aspirational, but practical and which has a stated course of action that can be reviewed objectively to see that it has been followed and is working; I think everyone should be clear about what peopleās responsibilities are and that they should be given the authority to meet these responsibilities - and have it written down so that there can be no misunderstanding or argument; I think that management should identify resources needed and have a plan to provide them, including training; I believe that management should meet now and again, to see if their policy is being met and their organisation is working the way they intended and to do something about it if it is not.

Who disagrees with any of this? Who says people should not have a policy, not identify responsibility, not review the implementation of the policy?

These are simple requirements, easy to understand, obviously necessary whether ISO 9001 exists or does not. They are not limited. Employee motivation and leadership (which you raised as a criticsm, because they are not mentioned) are not excluded. They are not there because they are not easily measured objectively and we have to keep in mind that the primary purpose of the standard is to be able to make business decisions about a prospective supplier on the strength of an objective third party assessment. They are a given, without which we will not meet implement our policy - we know that.

Youāll notice that I left out ĪManagement Representativeā? Well I wouldnāt mind if we all left out that particular clause. It is a mistake and Iād bet that, somewhere along the line, it was thrown in by some well meaning Īdo-gooderā. It has no place in a standard aimed at senior management because it gives them the opportunity to offload all their responsibility onto one guy - some long-term, loyal employee who hasnāt got Īthe right stuffā to be made up to a real manager but who deserves a break and will make no waves. Heāll make a mess of the job because he thinks itās about inspection and AQLs and groups of people standing around a pallet, staring at it and trying to think of something clever to say. But, it is in there, so what do we do? Ignore it?
No, we find an easy way to get around it. Nominate either the manufacturing or materials manager, who are deeply involved in the system but too busy to hog all the responsibility. (Never nominate the quality manager because he will see it as a chance to expand his empire and will hire two more guys on the strength of it and take total responsibility for all things ISO.) The nominated manager should do nothing other than see that audits are carried out and that management reviews happen. This person should not relieve other managers of any of their responsibility to meet the policy and implement the documented system.

Donāt blame the standard and donāt make up excuses that itās about interpretation and intent. The intent is clear and there is nothing in 4.1 that is difficult to implement as written. Within the broad framework of 4.1, as written, is a whole world of choice as to the way that we do it, which is not written. Thatās where the freedom to build a system that fits our organisation lies. The standard just gives us the simple headings; Īhave a policy, have a plan, have a contract, document it, define it, review it for a, b and cā. As we all know, Īit aināt what you do itās.....ā.

So, Andy. What about it? Would you get out your copy of ISO 9001/2 and have a serious read of 4.1 and spell out just what your objections are so that we can make some real progress?

rgds, John C

[This message has been edited by John C (edited 05 August 2000).]

[This message has been edited by John C (edited 05 August 2000).]

IP: Logged

John C
Forum Contributor

Posts: 134
From:Cork City, Ireland
Registered: Nov 98

posted 05 August 2000 09:56 AM     Click Here to See the Profile for John C   Click Here to Email John C     Edit/Delete Message   Reply w/Quote
Tom Goetzinger,
ćIf it doesnāt make good business sense to do it, donāt do itä
I checked to see which sections may be optional and I came up with the following;
4.4 (in 9002), 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12, 4.13, 4.15, 4.19. For 4.20, statistics, some statement should be made (in the manual?) that there has been an investigation and it has been found that there is no need for statistical techniques. For the others, I agree, just donāt do it.
An example might be a consultancy firm; If there is no purchased product, the we wonāt have procedures to purchase it, inspect it, etc. But we are talking about interpretation and intent. The decision not to have a procedure to inspect non-existent purchased product, is hardly interpretation or analysis of intent.

Otherwise, where there is a need for the section, then the whole of the section is normally applicable. There are a couple of marginal clauses, eg; in 4.9d, there may be no parameters to monitor, just characteristics. If you buy off-the-shelf material, then it may not be appropriate to do incoming inspection. But this isnāt rocket science. For the rest, either everything is applicable or there is an option written in as far as I can see. Someone else may come up with a couple of other marginals.
rgds, John C

[This message has been edited by John C (edited 05 August 2000).]

IP: Logged

Tom Goetzinger
Forum Contributor

Posts: 123
From:Milwaukee, WI USA
Registered: Mar 99

posted 07 August 2000 05:23 PM     Click Here to See the Profile for Tom Goetzinger   Click Here to Email Tom Goetzinger     Edit/Delete Message   Reply w/Quote
Guess I need to clarify what I meant. I'm sure many have you discovered or experienced situations where a company did something that did not make sense to you, but claimed that "the standard" requires it.
In most cases, the standard required you to do something to meet its requirements. It did not tell you specifically what or how you must do it. My point was intended to convey that one needs to look carefully at what the standard requires, what you are currently doing, and what changes you need to make to become compliant. If what you think you need to do does not make sense, there are probably alternatives that will make sense, and will meet the requirements of the standard. To blindly create new tasks that do not add value just because you think the standard requires them does not make sense. Those who do that sort of thing, without careful consideration of the costs and benefits, do their companies and the standard a disservice.

------------------
Tom Goetzinger

IP: Logged

Andy Bassett
Forum Contributor

Posts: 274
From:Donegal Ireland
Registered: Jun 1999

posted 09 August 2000 10:47 AM     Click Here to See the Profile for Andy Bassett   Click Here to Email Andy Bassett     Edit/Delete Message   Reply w/Quote
Hello John - I thought i might get a bite on this one.

Im not too sure how to reply, if i read through your post and took issue with each point i would be tapping away all night, and anyway its probably not necessary, because when i am forced into a corner i can justify every single part of ISO as well as the next man.

In my 20 years in industry i have been TQM'd TQC'd MBO'd, Kanban'd, Kaizen'd, JIT'd Hoshin'd, Outsourced, Downsized and Rightsized. I dont beleive in any of these things completely, but i do believe they all have something to offer. I would use any of the above if i think the environment needs it, likewise with ISO 9000 i would and do use it if i think its appropiate.

But i guess the issue we are having is how strictly the standard is read, understood and implemented. I stated that i actively avoid forcing the standard down my customers throat, i encourage them to think instead what is best for their business. Why do i do this?
A. My own personal experience is that when a company concentrates solely on the ISO Standard they will miss the big picture and fail to carryout the action that is necessary to improve the company. I dont feel like the get value for money. My experience is simply that certified companies do not offer noticeable advantages over none-certified companies. This i could also quantify by referring to my time as a Purchase Manager. IN THIS PARTICULAR INSTANCE ISO CERTIFIED COMPANIES DID NOT PERFORM ANY BETTER THAN NONE-CERTIFIED COMPANIES.
B. With the best will in the world, it is hard to deny that ISO is a dry difficult topic to swallow, carrying a negative image within industry. Imagine if we tried to acheive improvements in the Supply Chain with such a standard/methodology. Again for this reason i avoid forcing it down peoples throats and concentrate on things that i think will interest and motivate people or companies to try and produce better products.

Once the project is over, before i leave i then ensure that at least one person knows and understands the standard (admittedly, maybe not as well as they should, i still leave telling them to follow the intent and do it if it seems reasonable, and prepare to fight if it isnt).

i have NEVER rubbished ISO in front of customers for the simple fact that it would make my life more difficult later when i wanted to implement it. So stupid i am not.

If i bitch about ISO in this forum its simply becuase i get tired of defending it in front of my customers, and i thought it was a safe environment to let of a bit of steam.

If i come back to what i think is your main point, that is that if the standard was better understood, and more clearly implemented the results would be better, i can agree up to a point of course.
But, I still think there are better tools on the market, and i still beleive that attempting to implement in this way can result in a very negative reaction from the company. I have tried it both ways, and i know which way i prefer.

Regards

IP: Logged

John C
Forum Contributor

Posts: 134
From:Cork City, Ireland
Registered: Nov 98

posted 09 August 2000 06:39 PM     Click Here to See the Profile for John C   Click Here to Email John C     Edit/Delete Message   Reply w/Quote
Andy,
Thanks for the excellent response. I agree about ISO 9000ās negative image and also that the image is justified. The fact that I believe the cause is in the implementation and not in the standard itself is not relevant. When selling the idea I have to find my way despite the image, whether itās right or itās wrong so, to hear it all from you, gives me a better chance to get the opportunity and a better chance to take it.
You made a strong case and put it very well so I will give it considerable thought. Put so bluntly, it crossed my mind that carrying this ISO 9000 flag might not be such a good idea and that I might be better off finding a positive vehicle that could carry me. I could set up as a Health & Safety consultant. But it depends what your trying to achieve, I suppose. It's only a quality standard, after all. It's not an alternative to anything except the absense of a quality standard and, possibly, an inferior documented management system.
It's there. It has to be done. They can do it my way, which is great, or I can do it their way, which is also great.
rgds, John C

[This message has been edited by John C (edited 09 August 2000).]

IP: Logged

Alan Cotterell
Forum Contributor

Posts: 120
From:Benalla, Victoria, Australia
Registered: Oct 1999

posted 14 August 2000 07:44 AM     Click Here to See the Profile for Alan Cotterell   Click Here to Email Alan Cotterell     Edit/Delete Message   Reply w/Quote
I concur with the responses given by Andy Bassett and John C. I would say that the posts on this topic seem to indicate that you can 'stand too close' to ISO9000, and not 'see the forest for the trees'.
I think the most important thing to do in most businesses is make a profit, without it we don't usually exist. To do this we must deliver a product or service which meets or exceeds our customers expectations if we wish to continue long term. We should always remember that the purpose of ISO9000 is to facilitate this. Implementation of the standard without tailoring it to suit the business could be catastrophic in my opinion.
It is also important to remember that quality is only one factor of Operational Risk, the Management System should help to avoid loss by controlling all aspects of Op Risk.
(You might be interested in Australian Standard AS4581 - Management System Integration.)
I think it is important to sometimes 'take a step backwards', and look at the 'big picture'.

IP: Logged

qualman
Forum Contributor

Posts: 14
From:Grand Rapids MI
Registered: Aug 2000

posted 01 September 2000 04:19 PM     Click Here to See the Profile for qualman   Click Here to Email qualman     Edit/Delete Message   Reply w/Quote
John C:

On August 5th you wrote:

ćYears of investigation have shown me that the reason for this (poor administration and implementation of ISO ö parentheses mine) is that people do not understand it, have the misconception that it is a quality tool rather than a management tool and that a lot of people have a personal agenda which is better served by sidelining the standard.ä

I was wondering if you would care to elaborate about using ISO as a management tool rather then a quality tool. Iām a young pup and have always heard that ćThe Standardsä are intended to increase product quality, thereby increasing business, thereby profitability. Is this an ćAmericanizedä view, or do others have the same ćmisconceptionä?

Qualman

IP: Logged

Marc Smith
Cheech Wizard

Posts: 4119
From:West Chester, OH, USA
Registered:

posted 02 September 2000 04:00 PM     Click Here to See the Profile for Marc Smith   Click Here to Email Marc Smith     Edit/Delete Message   Reply w/Quote
quote:
Originally posted by qualman:

I was wondering if you would care to elaborate about using ISO as a management tool rather then a quality tool. Iām a young pup and have always heard that ćThe Standardsä are intended to increase product quality, thereby increasing business, thereby profitability.


I don't think that anyone here (we're all seasoned veterans... ) considers ISO to have anything to do with quality. It has to do with consistency and evidence. It is tending to evolve into a 'quality' thing in a way. The Customer Satisfaction requirement in the year 2000 version is evidence of that. Or at least the perception of quality.

IP: Logged

Rick Goodson
Forum Wizard

Posts: 102
From:Wuakesha, Wisconsin, USA
Registered: Aug 2000

posted 05 September 2000 11:40 AM     Click Here to See the Profile for Rick Goodson   Click Here to Email Rick Goodson     Edit/Delete Message   Reply w/Quote
If you read 'ISO 9001:2000 Explained (ISBN 0-87389-481-2) by Cianfrani, Tsiakals, and West (Jack West, Chairman U.S. Technical Advisory Group for ISO/TC 176) , they state the 'intent' was to increase customer satisfaction.

"A primary thrust of ISO/DIS 9001:2000 is to increase the emphasis on customer satisfaction, which is, after all, a primary reason for the existence of most organizations. Increased emphasis on customer satisfaction was explicitly and clearly defined as a marketplace need in the market research that was performed by ISO prior to the development of ISO/DIS 9001:2000."

Unfortunately, the year 2000 version (FDIS)has blinked. The Customer Satisfaction measurement still allows the option to measure dissatisfaction. Many companies will continue to try and measure 'satisfaction' by looking at customer complaints and warranty claims. Once again we have managed to shoot ourselves in the foot.

IP: Logged

John C
Forum Contributor

Posts: 134
From:Cork City, Ireland
Registered: Nov 98

posted 11 September 2000 06:00 AM     Click Here to See the Profile for John C   Click Here to Email John C     Edit/Delete Message   Reply w/Quote
Qualman,
You asked me to elaborate on whether ISO 9001 is a quality tool or a management tool.
Sorry about the delay in responding - hope you havenāt gone away - but I was doing some extensive elaborating which I think is too much to offer the forum. Here is my conclusion which is not very radical or surprising but, I think, clarifies and supports my thinking;

A tool is defined by itās purpose and the qualification of the user. eg; A hammer is designed to be used by a carpenter to knock nails in wood. It can be used by a violinist to knock screws in plastic but this is unlikely to have a satisfactory result.

ISO 9001 is a tool designed to be used by a Registrar Auditor (3rd party). It is part of a bigger tool, ie; the whole ISO 9000 system and all the people from ISO down to the auditees. This tool is designed to be used by a purchasing manager (of the 1st party) to help select a suitable supplier (2nd party).

ISO 9001 has another use; It provides any company with a model that can be used in developing the documented system and in evaluating itās compliance. What type of tool is ISO 9001 in this situation?

As I see it, quality tools are normally used by the quality department to improve quality by measurement and feedback, ie; traditional QC, implying a control loop. The objective is to find something bad and go back into the process to fix it. Quality specialists are normally involved in this sort of work and it is normally the major part of a Quality Managerās area of responsibility. The tools involved are mainly statistical, eg; Histograms, Charts of fails per time/ department/component, etc, Pareto, Control Charts, and the rest.

ISO 9001 extends its area of impact over a very wide field; It calls for a Quality Policy related to business goals; for staffing the company with people responsible for Īmanaging, performing and verifyingā work affecting quality; for providing resources; for review of the effectiveness and compliance of the documented system, for planning, putting together and implementing the procedures and plans of the documented system and for all the major processes in a business organisation, from purchasing to repairing out of warrentee fails in the field.
This field of responsibility stretches far beyond the area for which the quality manager is responsible. It brings in every aspect of the business organisation. In particular it entails coordinating the planning and implementation of the documented system which defines how senior management want the organisation to operate, and coordinates the departments efforts.
Documentation is not the responsibility of a quality function. It must be designed by those whose responsibility is to manage and implement the process.

The only person qualified and with the authority to preside over such a task, and ensure itās focus, effectiveness and successful conclusion, is the CEO. Not only that but, if the CEO develops and implements the documented system, he/she will use it to ensure that his/her plans are followed and to provide a feedback of information independent of the primary info flow through his/her direct reports. Used like this, the documented system will stay relevant and be effective.

On the other hand, when the Quality Manager is given responsibility for ISO 9001, he/she also inherits the documented system. Department managers, seeing that they are not answerable to the CEO at staff meetings, for the implementation of the doc. system, and having a let-out in blaming the Quality Department when things go wrong, see the excellent operation of the documented system as not being a significant carreer enhancing area and have as little to do with it as they can get away with. Naturely, their middle managers, supervisors and operatives soon get the message and apply the same degree of enthusiasm to compliance and strict use of the documented system.
Meanwhile, the Quality Manager, seeing ISO 9001 as just a glorified Īmeasure, find defects and fixā tool, is pleased to grab it all to him/herself and set up as the authority and controller of everything associated with the documented system. The preventive quality contribution of the documented system goes out of the window and everyone gets drawn into working an elaborate corrective action program which takes the place of Īquality managementā.
Quality struggles to maintain a system where its compliance to ISO 9001 is the main objective and its effectiveness in meeting business objectives is secondary.

My conclusion is that the person who is qualified and has the authority to use the ISO 9001 standard as a tool to develop and maintain the documented system, is the CEO. Also, that the purpose of this tool concerns issues which relate to the management of the whole business organisation. Therefore, ISO 9001 is a management tool.
However, because of the associations with Īqualityā, due to the measuring and reporting department mistakenly being called the quality department, ISO 9001 becomes the responsibility of the quality manager and, as a result, becomes ineffective, and indeed, counter productive in the effort to provide an excellent documented system and achieve the quality improvements which might be expected.
rgds, John C


IP: Logged

qualman
Forum Contributor

Posts: 14
From:Grand Rapids MI
Registered: Aug 2000

posted 11 September 2000 12:18 PM     Click Here to See the Profile for qualman   Click Here to Email qualman     Edit/Delete Message   Reply w/Quote
John:

Thanx for the great response! You have just described what I beleieve to be my current situation. Now, here's a tougher question (for anyone):

How do I get the CEO to actively lead the process, and not just be involved?

Qualman

[This message has been edited by qualman (edited 11 September 2000).]

IP: Logged

Curtis
Forum Contributor

Posts: 11
From:Clayton, NC USA
Registered: Sep 2000

posted 11 September 2000 01:14 PM     Click Here to See the Profile for Curtis   Click Here to Email Curtis     Edit/Delete Message   Reply w/Quote
I disagree that the CEO is the pivotal figure here. The pivotal figure in an organization should be the COO. The key, in my estimation, is to get them to see the model as the means to keep the trains running on schedule and toward the right destinations. So far, I can offer no magic pill for this. 2 of 3 COOs for my organization have instinctively understood that they needed to drive. The CEO is used as a cheerleader when needed.

IP: Logged

John C
Forum Contributor

Posts: 134
From:Cork City, Ireland
Registered: Nov 98

posted 11 September 2000 05:09 PM     Click Here to See the Profile for John C   Click Here to Email John C     Edit/Delete Message   Reply w/Quote
Qualman,
Yes, this is a more difficult question. I'm working on it for years and assembling the argument and the ammunition by figuring out answers to questions like your first one.
How many CEOs, or even direct reports look in on this forum? The answer is obvious and gives a hint at the size of the problem.
Everyone says 'it must come from the top, but, in fact, it seldom does. My achievements in this area have been slow and limited. Pull them in and they seem to be coming along well but then backslide again. There's strong resistance built into every manager, for a variety of reasons.
The first thing is to refuse to do it for them. Try not to take action items from the meetings. Push them at the people responsible and then look to their managers to respond if the actions aren't followed up. Push it back all the time.
Have mgmnt review meetings not less than one per quarter. Ask the CEO 'When do you want your next review meeting?' and things like that. Never do any of the work for yourself, but get the idea across that it is for them that you are doing it, representing them and meeting their goals by delegation.

Curtis,
I guess your COO is Chief Operations Officer. If that means the top person on site, then that's fine. If the COO's direct reports are the operational manager's, then also fine. This is the key point, that the person responsible has to have the authority to make it stick. But you must remember that, if the COO reports to the CEO, then the CEO has the responsibility for everything the COO does so, if the CEO is wrong headed over ISO 9001 and the documented system, then the COO will quite likely not drive it well, irrespective of what he/she thinks. Everyone wants to concentrate on what their boss wants. That's how they got as far as they did. So, if the top guy doesn't want it, it won't happen.
rgds, John C

IP: Logged

Marc Smith
Cheech Wizard

Posts: 4119
From:West Chester, OH, USA
Registered:

posted 13 September 2000 06:41 AM     Click Here to See the Profile for Marc Smith   Click Here to Email Marc Smith     Edit/Delete Message   Reply w/Quote
This thread is continued in the following thread:
https://elsmar.com/ubb/Forum15/HTML/000082.html

IP: Logged

All times are Eastern Standard Time (USA)

next newest topic | next oldest topic

Administrative Options: Open Topic | Archive/Move | Delete Topic
Post New Topic   Hop to:

Contact Us | The Elsmar Cove Home Page

Your Input Into These Forums Is Appreciated! Thanks!


Main Site Search
Y'All Come Back Now, Ya Hear?
Powered by FreeBSD!Made With A Mac!Powered by Apache!