Verbal Instructions - How does it hold up against the standard?

[Jim Wynne]

Possibly a more accurate statement (trite though it may be) should be 'if it isn't recorded, it didn't happen'.........rather than what has been quoted before.

I'm almost afraid to ask, but how is "recorded" different from "documented"?

 

[sandman23]

in a real working environment we have this what we called "judgement call". anytime we receive any verbal instruction its up to us to evaluate it if we need to document. If you think it is critical you can put the instruction on email and send it to the person to confirm if you interpreted the verbal instructions correctly.

Those experienced people knows this, "saving your ass in case.."

 

[Claes Gefvenberg]

I'm sure we all give or receive verbal instructions, but when it comes to important product related tasks, or customer requested changes, how does verbal comunication hold up against the standard?

I think it holds up rather well when we have a look at my favourite note in the standard:

The extent of the quality management system documentation can differ from one organization to another due to
a) the size of organization and type of activities,
b) the complexity of processes and their interactions, and
c) the competence of personnel.​

This allows us to build reasonable systems adapted to the true needs of our respective businesses.

/Claes

 

[sandman23]

I think it holds up rather well when we have a look at my favourite note in the standard:
This allows us to build reasonable systems adapted to the true needs of our respective businesses.

/Claes

this is the exact answer..

 

[Jen Kirley]

I see a lot of good replies, I tried to be vague so that I could get a general idea about the issue before diving in deeper. I like the saying "If it isn't documented, it didn't happen", but also the suggestion that a group of surgeons cannot productively work with written instructions is spot on.

We have a design process that involves dozens of changes before design completion. During preliminary customer approval, the customer often decides there are additional requirements that were not previously documented. There is sometimes a billing component to that, but that portion appears to be functioning well. There is some evidence though (through corrective actions and ncmr's) that we are missing customer requirements in design or manufacturing. It SEEMS self evident that we need them in writing between our company and theirs, if something takes place in a face to face meeting or over the phone it should be confirmed in an email.

But.

Cases that are not cut and dried are either Assumed/Implied requirements or a breakdown in internal communication (where typically a project manager tries to claim that ‘obviously’ a ‘common knowledge’ assumption should have been made, but the workers can verifiably argue there is enough case-to-case variation in recent history that an assumption on their part is not possible).

Verbal communication may be (at least partly) to blame.

Maybe a log sheet would help, showing what changed on what day and who authorized. It needn't be complex but the objective is to be able to carry on with one or more members of the team missing.

I agree in principle about the surgeons and written instructions analogy, but hospitals that have introduced checklists in their operating rooms have brought good results.

Since humans make poor databases, it makes sense to use whatever tool raises efficiency and overall effectiveness. A wide enough scope should be considered when evaluating effectiveness, including not just the impact on the group's activities (no doubt it would add time to complete entries on a log) but the eventual outcome. If design errors are reduced, the cost to rectify would probably be greater than that of filling out a log. All of this is what 4.2.1 is talking about.

 

[vanputten]

One method to determine effectiveness of the verbal instructions is to interview those involved to see if they corroborate each other's understanding.

 

[qusys]

In a production line it is a common practice to give verbal orders to operators from the supervisors, based upon temporary priorities.
It is important to assure that info has been well understood by whom then shall operate according to it.
If I am not wrong it is also possible to accept phone orders in sales process, but then the personnel shall record, following internal procedure for example.
Another example , always in production, could the area meeting for verbal passdown for shift to shift , even though it is also a comon practice to punt it black on white, but in case of few people this could not be effective for time consuming.

 

[Jen Kirley]

I see a lot of good replies, I tried to be vague so that I could get a general idea about the issue before diving in deeper. I like the saying "If it isn't documented, it didn't happen", but also the suggestion that a group of surgeons cannot productively work with written instructions is spot on.

We have a design process that involves dozens of changes before design completion. During preliminary customer approval, the customer often decides there are additional requirements that were not previously documented. There is sometimes a billing component to that, but that portion appears to be functioning well. There is some evidence though (through corrective actions and ncmr's) that we are missing customer requirements in design or manufacturing. It SEEMS self evident that we need them in writing between our company and theirs, if something takes place in a face to face meeting or over the phone it should be confirmed in an email.

But.

Cases that are not cut and dried are either Assumed/Implied requirements or a breakdown in internal communication (where typically a project manager tries to claim that ‘obviously’ a ‘common knowledge’ assumption should have been made, but the workers can verifiably argue there is enough case-to-case variation in recent history that an assumption on their part is not possible).

Verbal communication may be (at least partly) to blame.

After more thought...

Verbal communication may be partly to blame, but in my view it's a teensy weensy part. It's troubling to read:

where typically a project manager tries to claim that ‘obviously’ a ‘common knowledge’ assumption should have been made

because I've been bitten by that "You should have known" beasty myself. This is called tribal knowledge, and it is a morale killer. Then you said

the workers can verifiably argue there is enough case-to-case variation in recent history that an assumption on their part is not possible

This looks to me like a classic example of why customer change requests ought to be logged somehow. A written procedure to do so isn't as important as actually making sure all the customer requests are accurately addressed.

This is less of an issue about internal communication and more about change control.

 

[tmoreau]

After more thought...

Verbal communication may be partly to blame, but in my view it's a teensy weensy part. It's troubling to read: because I've been bitten by that "You should have known" beasty myself. This is called tribal knowledge, and it is a morale killer. Then you said This looks to me like a classic example of why customer change requests ought to be logged somehow. A written procedure to do so isn't as important as actually making sure all the customer requests are accurately addressed.

This is less of an issue about internal communication and more about change control.

Yes, I agree. I guess I have been looking at the verbal component, there cannot be any control or log when its all verbal.

We have a form integrated with our procedures that provides this mechanism "Project I/O Notes (Meeting Minutes)" where important input, decisions, characteristics, and change requests can be noted. There is a stunning resistance to using this form because it is 'extra work' compared to cornering someone in the hall on their way to the bathroom/important meeting and rambling on about this or that.

We also have written standards in a wiki that anyone can edit, to record as much of the "shoulda known" tribal knowledge as possible.

So I think we have multiple ways to address this (record, document), but its not being utilized in favor of verbal comunication.

 

[Jim Wynne]

Yes, I agree. I guess I have been looking at the verbal component, there cannot be any control or log when its all verbal.

We have a form integrated with our procedures that provides this mechanism "Project I/O Notes (Meeting Minutes)" where important input, decisions, characteristics, and change requests can be noted. There is a stunning resistance to using this form because it is 'extra work' compared to cornering someone in the hall on their way to the bathroom/important meeting and rambling on about this or that.

We also have written standards in a wiki that anyone can edit, to record as much of the "shoulda known" tribal knowledge as possible.

So I think we have multiple ways to address this (record, document), but its not being utilized in favor of verbal comunication.

After you've been burned a few times, you develop an acute sense of when something should be expressed in writing. Part of what I've learned is Trust No One. A brief illustration:
I once worked for an OEM, and later worked for a machining job shop that supplied the OEM. I walked into the owner's office one day and found him examining a part and drawing that I was well familiar with, and I knew it would be trouble. It was a "finesse" part, one that was not suited to the present situation. I'd had many struggles with it on the other end. I told the owner as much, and advised him to not accept the job. He didn't listen, and the disaster I feared began to take place.

There was a feature of this part--a sealing surface--that had to be .005" to .007" wide, and bear no nicks or scratches. In addition to machining, it had to be passivated, which necessitated special racks and extremely careful handling. The first lot of parts through our shop had surfaces that were mostly awful, and as much as .005" over the UTL. Much sorting and hand-lapping (on a surface plate) was done, but it couldn't help the dimensional problem, which was not reworkable. I was told to contact the customer and see if I could get them to buy off on the dimensional issues.

My contact was the person who had replaced me as quality manager for the OEM, and who had worked for me, and who (I thought) was a good friend. I explained the situation to him, and he said that he'd talk to the design engineer (whom I also knew) and see what he thought. He came back to me the next day and told me that they would accept parts that were as large as .010", or .003" over the UTL. More sorting was done (which involved measurement under a microscope with a reticle). The "good" parts were then shipped. Two days later, I was informed that the parts had been rejected due to an oversized sealing surface. I called the QM, who (A) said that they could not accept any out-of-tolerance parts and (B) summarily denied having told me otherwise. Not only that, he told my boss, in writing, that I must have made the whole thing up because he would never have given such permission. I called the design engineer, who told me that the QM had never even talked to him about the issue until the over-tolerance parts had arrived.

There's an old saw in journalism about fact-checking: "If your mother says she loves you, check it out." I would add to that: ...and get it in writing.":