Written process that is ineffective as evidenced by multiple interpretations

[CliffK]

Why are those documents in your system at all?

ISO 9001 requires only six procedures. Anything else that goes into your quality system should pass a value test.

ISO 9000 provides a little bit of help, if you have it. In the 2000 edition, the guidance is in 2.7.1. Paraphrasing here, documents have value if you need them to:
- conform to customer requirements
- improve quality
- provide training
- have a repeatable process (standardization is a worthy objective)
- show traceability
- provide objective evidence (applies to the inescapable six, possibly to a few other requirements)
- act as a basis for audit activity (sometimes writing a procedure can be like giving the auditor a club so he can beat you with it)

Any document in your system that doesn't do one of these things is a good candidate for removal or pruning.

Cliff Kachinske

 

[Jen Kirley]

The example that I have chosen is a very simple process, in actuality, that is easily understood and lends itself to ojt. I get the impression that the formal training based on the documentation is "suffered" (no new employee is apt to admit to not understanding fearing that they may be judged incapable) and there is no testing conducted to determine the effectiveness of the document based training.
Further investigation just this morning brings up another point: There are process descriptions for the process and work instructions for the process and the difference seems blurred at best. I will compare the two to determine similarities. WOuld one document suffice?
It will take some time to get all the worms back into the can.
Thanks for your input and consideration.

Okay then, what I understand is this:

a. The process existed long before it was written down.
b. The written process is interpreted differently among its users.
c. The process is simple enough to learn with OJT.
d. No evaluation of understanding is done.
e. In spite of its simplicity, employees might not admit if they don't understand it because they do not want to be judged incapable.
f. No harm is done if the process is not done to the letter of the document.

I'm with Steel and Cliff with the question "Why is there a process document for this?"

The standards ask for limited numbers of written processes, but say in many other cases that processes will exist. There's a big difference between the two; it's easy to forget that and make the system harder than it needs to be.

I have a term for a too-strict process: audit swamp.

A process should be documented and regulated when the result of doing things improperly could harm the product/service, external customers (including failure to satisfy requirements) as well as internal customers.

If a process document is being liberally interpreted yet it needs to be followed, a fix requires an understanding of the problem's true nature.

1. Is the document is inappropriate (and why) for the users?
2. Does the document resemble the process?
3. Is the written process viewed as unrealistic because it somehow adversely impacts another process?
4. Do the personnel do not wish to use the documented process? (and why)
5. Are the personnel unable to understand the process or its document? (see #1) If so, could the objective be simplified to a flow chart, flip chart, pictures, colored/numbered/symboled steps, and so on? Let's consider the national statistic: an estimated 20% of adults are functionally illiterate.

I have attached a paper about people not following processes in this thread. If the problem is truly personnel-related (I did notice you used the word fear, too) the article addresses that.

However, I'm going to come full circle and urge you to, in all cases, ask "Why is this important?" as I listed in a - f above. I know the warehouse example is only an example, but the logic path to a problem like this could be repeated for many other process problems.

 

[Paul Simpson]

I am struggling with a written process that appears to be ineffective as evidenced by multiple interpretations.

Do the multiple interpretations result in material differences to the process output? If not then there is no noncompliance.

If you have significant differences in process output then you have the evidence for your noncompliance.

 

[BradM]

Part of the problem could be that we've written what we thought the auditor wanted rather than writing what we actually do in any activity / procedure.

I would just like to commend you. So many times, it's difficult to encourage people to think, and to see things from a different perspective.
You have done a really good job at providing detailed, thought-provoking follow-up posts, which lends to creating more interesting discussion.


So many times on the Cove, regular posters get frustrated. They are NOT frustrated with personalities or the questions asked, for the most part. It's frustration that stems from management putting too much pressure on people who don't have time nor training to do what is being asked of them. Too, many folks are so nervous and scared about possibly not passing, they have had the ability to think scared out of them. A good quality system can bring so many rewards to an organization, if management would just take the proper steps.
*************
I know I'm calling out the pink elephant here, but they should be doing what they say they're doing. Otherwise, their quality system is not working. They have a system, just not the one they say they have.

As far as writing this up, I'll leave that to my more experienced auditor colleagues. But I would make sure management understood the inconsistency, and take actions to align the real process with the documentation system.

 

[JaneB]

The folks who are charged with execution, on the floor, are bright and intelligent people who understand the process. If you ask 3 of them for an interpretation of the written documentation, you will get feedback that suggests confusion and some sheepish looks.

All really strong signs that the written documentation either isn't used or isn't useful. (And if it's horrible, complex & overdone, then it won't be useful for them, and is often the root cause)

If you know what's supposed to happen, you go forth and execute and conveniently ignore the instructions.

= Problem. If you can only do it if you 'know' what's supposed to happen, & ignore the instructions, then those instructions are useless. Sooner or later you'll get bitten in the behind by that. I'm with Jennifer - is something needed in writing? Or would it better to focus very hard on what training is required, and ensure adequate training (including assessment of competency) and adequate records thereof.

Part of the problem could be that we've written what we thought the auditor wanted rather than writing what we actually do in any activity / procedure.

Oops! Classic mistake. Infinitely better, more useful, less maintenance & more effective if you write it up for yourselves, not an auditor.

You say there are 'process descriptions for the process and work instructions for the process and the difference seems blurred at best.' And ask if one document would suffice. You betcha. (Or even perhaps none).

We're probably facing re-writing most all of our documents to simply the system and get away from the "ISO Speak Techno Jargon" which is more similar to Code of Federal Regulation sort of construction. Keep in mind that the entire company is 20 people. Should we torch it and start over?

Depends on where you are now, & implications thereof, though I'd lean toward it if it's all as jargon-laden and obtuse as you indicate. Yes, it'll take a little while. But you don't have to do it all at once. Do one at a time, and do it over a period. Look on it as an improvement opportunity: continuous imp. in action, simplifying the written system. But there are multiple problems inherent in having crappy (that's a technical term BTW) procedures, such as: no one likes them, they give people a bad attitude toward the 'quality' system, and trying to audit against crappy procedures is misery-inducing and time-wasting. Simple, clear and streamlined is much better.

One way to do that might be to focus on: what do we need in writing so that we agree how something is done, there aren't major variations in interpretation, and/or someone relatively new can actually follow it and find it useful?

...the piece at which we are looking is entitled "Warehousing". In actuality, the process involves picking, and pulling finished goods for labeling, stretch wrapping and staging prior to shipment.

Plus I'd seriously focus on using words/terms that are understood & what they use. If it's called 'Pick, Pull & Stage' for example, and if you decide you need a procedure, an instruction - or a checklist? - then that's what I'd call it, rather than 'Warehousing'.

 

[METerry]

First, thanks to Cliff, Paul, Brad, and Jane (as well as anyone I have missed). Where else could I have received personal, thoughtful advice from a experienced team of people from around the world?
I will take more time tonight to re-read your posts and consider the best way(s) to 1.) re-configure, revise, or revamp our system, and 2.) to sell the position that it needs to be done (these may not be in the correct order).
There is also the issue of our current auditor. While he has steadfastly reminds us that he can't tell us what to do, I keep hearing "the auditor requires these records" or "says we have to do it this way" which is in my interpretation consulting as opposed to auditing. There is a marked difference in his verbal communications and those that are written (I have some stories I could tell). Since I have not personally heard him say we "have to do this this way", I cannot determine whether this is the source of the "requirements". I may suggest we have the conversation with the registrar to see how difficult a change would be.
I also want to find the ISO guidance and review that as suggested.

 

[JaneB]

METerry,
You're very welcome - people here love to help! And there's a lot of excellent people giving excellent advice. For my part, I love helping people understand the Standard better, rather than have them suffer or perpetuate the same old misunderstandings, which surely ain't quality in any way that I understand.

I keep hearing "the auditor requires these records" or "says we have to do it this way" which is in my interpretation consulting as opposed to auditing.

Interesting. I'm gathering you are already certified then, rather than in the process? You're right: you must do it this way is NOT in the ISO 9001 Standard (though it's still - depressingly - said, it is NOT true). But if the Standard says 'records of xyz shall be kept'... then by golly, they shall be. The argument - ahem! - discussion, can then be about what is kept, whether it adequately demonstrates the requirements are met, etc... a better discussion. Trying to argue you don't need records if the Standard says you do is a fool's game, and (rightly) unwinnable.

My best advice: Know thy Standard. As well as you can.

Read it, think about it, ask about it (we love to debate it in here), consider it, come to understand it.

Then the real joy and challenge becomes: how can I interpret and apply this requirement orset of requirements to these particular set of circumstances in our business or organisation, in the way that suits us best, and assists us to reach the objectives we've set?

That's a challenge worth rising to, IMO. (Rather than, 'how can I do this to suit the auditor'. That way lies misery and frustration.)

There is a marked difference in his verbal communications and those that are written (I have some stories I could tell). Since I have not personally heard him say we "have to do this this way", I cannot determine whether this is the source of the "requirements". .

It may not be. It may be misunderstanding or misinterpretation of what he said. (It may not be - but first, let's be generous and fair to all parties).

I also want to find the ISO guidance and review that as suggested.

Very good idea.