Painless Nonconformities

“Nonfulfillment of a requirement.” That’s the clear and concise definition of a nonconformity offered up by ISO 9000:2005–“Quality management systems—Fundamentals and vocabulary.” The definition leaves little room for ambiguity. A nonconformity is the identification of an incident involving either an error or an omission. Something wasn’t done or was done incorrectly.

The challenge is for the auditor to describe what the nonconformity actually is so that the auditee comprehends what’s wrong. It’s important for auditors to take the lead. They must describe the nonconformity so that it’s fully understood and they must do so using language that avoids confrontation and diffuses any suggestion of blame.

Objectivity is the auditor’s best ally in the description of nonconformities. The statement of nonconformity shouldn’t ascribe blame, purport to identify the root cause, or presume to suggest a solution. How the nonconformity is expressed is almost as important as what it describes.

There are three constituent parts required for each statement of nonconformity:

1) Description of what is wrong

2) Reference to the applicable requirement

3) Evidence to substantiate the finding of nonconformity.

Say what’s wrong
The notion of stating what’s wrong seems so simple as to obviate further discussion, but many people have a hard time simply saying what’s wrong. They postulate what might have happened. They suggest solutions—without knowing what the root cause of the problem really is. They jump to conclusions. One of the more typical ones sounds something like this: “The technician didn’t do the tests as required.” Unless you were standing directly behind the technician and observed her specifically missing that step, all you have is conjecture. If you’re not in the room, you can’t state objectively that something wasn’t done. All you can say for sure is: “There is no evidence that the test results were recorded in the database, as required.” The difference between the two statements is that the first one says the technician screwed up. The second says something didn’t happen the way the document says it was supposed to. The first gives the auditee’s supervisor little option beyond the ubiquitous “retrain the operator” scenario. The second statement presents the opportunity to ask a whole bunch of questions, such as:

• Were the tests actually done?
• Is it possible the tests were done, but the results not recorded?
• Are the results recorded elsewhere?
• Did this person get different instructions from her supervisor?
• Has the process changed?

All of these questions increase the likelihood of a broader, more detailed understanding of what happened, which enables root cause analysis. Statements offering suggestions or helpful hints carry similar risks of myopic perception of a given situation, thereby limiting effective root cause analysis.

Refer to the specific requirement.
If you can’t tie the statement of nonconformity to a documented requirement, all you have is something you don’t like, and nobody cares. Requirements are found in standards, such as ISO 9001, procedures, work instructions, user manuals, drawings, bills of materials, CAD files, contracts, purchase orders, regulatory requirements, like the FDA’s current good manufacturing practice  (CGMP), etc. They say what should be. When citing the requirement, be specific. If it’s found on a drawing, give both the drawing number and revision level. If it’s in a quality management system (QMS) standard, quote the applicable subclause. Contracts should reference the date, number (when applicable), and any amendments or revisions. It’s important that the auditor demonstrate that this is indeed a requirement and for the auditee to have a starting point to begin investigating the problem. Without the reference to the requirement, an auditee or process owner is justified in asking, “Where does it say that it’s a requirement?”

Provide the evidence.
Without objective evidence, an auditor hasn’t a leg to stand on. It’s nothing but hearsay. The evidence substantiates the finding and diffuses any potential argument from the auditee. Evidence can be found in written reports, databases, completed forms, lot-traceability tags, time sheets, physical objects, or statements from interviews. Evidence should mirror the requirement. If it doesn’t, there’s a problem. Instead of telling a supervisor that someone screwed up, an objective statement boils down to: “Here’s the requirement; there’s the evidence. And they don’t match.” There’s no finger pointing or even a conclusion as to which is correct, the document or the practice.

In writing up a statement of nonconformity, there are a few other things to remember. Be clear and concise. You may want to consider doing a review and edit before submitting the audit report and nonconformities. Have an awareness of your audience. Use language they will understand. Avoid jargon and excessive use of acronyms. If people can’t figure out what you’re saying, their ability to respond is greatly diminished.

The statement of nonconformity is the input into the corrective action process. It provides the initial specification for that which will ensue. A well-worded statement of nonconformity creates the impetus to move the corrective action process forward.

And remember, just as Joe Friday told us on Dragnet: “Just the facts, ma’am.”

About The Author