There are nonconformities, and then there are nonconformities

Quality management system (QMS) audits rarely result in zero nonconformities. Usually, these findings point to real weaknesses whose resolution allows the auditee to increase process effectiveness.

In other words, finding and correcting nonconformities is part of a larger process that is ultimately productive.

This is the system working as intended. Nonconformity is the common enemy, and the auditor and auditee are on the same side, each contributing their own skills to the never-ending quest for continual improvement.

However, there is also another type of nonconformity, which good auditors find painful to document. Auditees can’t be faulted if they perceive findings this type to be mere technicalities, and their resolution as inefficient busywork.

I think of these as audit traps, and they are set by the auditees themselves, by imposing trivial requirements that go unmet, or unwittingly holding on to outdated requirements.

Allow me to share some real-life audit trap examples:

The complacent organization

Some companies excel at implementing a QMS that meets ISO 9001 requirements and simultaneously enhances process effectiveness (as intended). They sail through the certification process and generally run a smooth operation.

Sustained success, however, can lead to complacency. When key personnel do their job well without the need for documented information, the company may drift away from documented requirements without even noticing.

While auditing a medium-size distribution company, I asked for records of the two most recent management reviews, which were in good order. Both meetings had been held in July, but their procedure required management review to take place every June.

I was told the company’s fiscal year ends in June. By having management review in July, they were able to see all the data for one whole year. This made sense, but it was at odds with their procedure.

By gathering all relevant data, reviewing it periodically and making evidence-based decisions, the company brilliantly followed the spirit of the law, but also neglected the letter of the law.

Is this discrepancy purely a technicality? Arguably yes, but it is also a nonconformity.

Half-hearted implementation

Some go down the path of certification only when they feel they have no choice, perhaps because key customers impose a certification deadline, or other external reasons.

Seeing certification as a bureaucratic distraction, they subcontract the work to a consultant expecting to get a documentation package that gives them conformity to the standard. To them, the physical quality manual and the QMS are one and the same.

(In contrast, a management representative I once interviewed suddenly had an epiphany and exclaimed “The QMS is not the manual, it is the air we breathe!” He was right.)

Before auditing the production process at a small repair company, I asked if they had a documented procedure for control of nonconforming product (strictly speaking, this is not required by ISO 9001:2015). They had one and shared it with me.

It quickly became evident that their actual practice was completely different from the procedure. Both the procedure and the actual process seemed reasonable, so either would probably have worked well enough.

As I explained that this was a nonconformity, the management representative rolled his eyes and screamed “Are you really going to write me up for not following a procedure I am not even required to have?!” The answer, of course, was yes.

Lack of familiarity by process owners with documented information became a pattern during this audit.

As auditors always explain in the opening meeting, audits are performed against two criteria: The Standard and the organization’s own documented information. Failing to fulfill the requirements of either one is a nonconformity.

More is better (?)

Some organizations create detailed documents for almost everything they do. When weaknesses emerge, they respond by creating more documents, adding paragraphs, or making sentences longer.

At a small robotics company, I was auditing the receiving process. Their procedure stated that packing slips were filed in a cabinet belonging to the Purchasing department. In fact, they went into a Production filing cabinet.

Manufacturing floor space for a new product had expanded recently, displacing the Purchasing filing cabinet. Another nearby cabinet was being used out of convenience.

Excessive detail was a pattern in this company’s documentation. In a dynamic environment, keeping documentation synchronized with the actual practice can be more costly than it is worth. As a result, what is said and what is done become two different things, and nonconformities can easily result.

Are they really trivial?

By definition, audit traps involve discrepancies that can easily be perceived as trivial. Nevertheless, a conscientious auditor has a duty to document then as nonconformities.

Even so, the mere realization that these conditions were allowed to occur should lead management to ask, “What else in our QMS may be outdated, unnecessary or just incorrect?”

This is, essentially the expectation set by ISO 9001:2015 in clause 10.2.1.b.3: “…determining if similar nonconformities exist, or could potentially occur…”

It is said that when a fox falls in a trap, it will bite off the affected leg to free itself. While this may better than the alternative, not falling in the trap in the first place may be better still.

Seen in this light, the prevention or correction of even seemingly trivial nonconformities can give an organization the opportunity to become leaner and more effective.

Audit trap avoidance

So, how can organizations avoid audit traps altogether?

While each organization must find its own solutions, these basic tips are a good start:

• Ensure process owners know the documentation that pertains to their areas of responsibility. As much as possible, they should be directly involved in their creation and maintenance. This way, they can ensure that documentation is useful, used as intended and updated when necessary.
• Using a consultant to document the QMS is perfectly fine, but the organization cannot evade its responsibility to review the documentation critically. The consultant is likely to start off with a generic template, and it’s up to the organization to adapt it to ensure it makes sense for them specifically. There is no excuse for using documentation that nobody in the company has read.
• When creating documentation, two opposing needs need to be met: On the one hand, it is necessary to document everything that is important to obtaining planned results. On the other hand, excessive documentation can easily become unnecessarily onerous. The goal is to make the right tradeoffs between these elements, while keeping the system as simple as possible. Ensuring documentation is just specific enough to be useful, without creating unnecessary constraints, should be an ongoing effort.

Now go forth and prevent.

What is “the context”?

The ISO 9001 requirement to define the context of the organization is as important as it is poorly understood.

Intuitively, it makes sense that organizations should understand themselves before they can ensure their management systems (quality or otherwise) are capable of delivering the intended results.

The organization should understand the market it serves, its business and regulatory environment, the products it makes (or services it delivers), knowledge unique to itself, and more.

To implement this, the Standard has explicit requirements in clauses 4.1 (relevant external and internal issues), 4.2 (relevant interested parties and their requirements) and 4.3 (scope of the quality management system).

Where to start

ISO 9000:2015 (not to be confused with ISO 9001!), provides some useful guidance about relevant internal and external issues. Under the heading “Fundamental concepts,” it lists some potential internal factors: values, culture, knowledge, and performance. It then goes on to mention external factors such as legal, technological, competitive, market, cultural, social, and economic environments.

This is a helpful way to visualize relevant external and internal issues:

Each organization must determine its own relevant issues, but these examples are a good starting point.

Relevant “interested parties”? Stakeholders!

Before defining the needs and expectations of relevant interested parties (4.2), we have to define the interested parties themselves, but only those that are ‘relevant to the quality management system.’ ISO 9000:2015 lyrically defines an interested party (or stakeholder) as a ‘person or organization … that can affect, be affected by, or perceive itself to be affected by a decision or activity’ of the organization.

Relevant interested parties should vary from one organization to the next, but generally include customers, employees, external providers, stockholders, regulatory agencies, and the community.

Many organizations find table to be very useful. It lists the relevant interested parties and assigns specific external or internal issues to each one, along with applicable risks and opportunities (as defined in clause 6.1):

What is not applicable?

Next, in clause 4.3, the organization must explain why particular requirements are not applicable. An organization can be certified, while not fulfilling some requirements of the Standard, only if the requirements that are not applicable ‘do not affect the organization’s ability or responsibility to ensure the conformity of its products and services and the enhancement of customer satisfaction.’ Although the prose is beautiful, it is not Charlotte Brontë, but ISO 9001:2015.

By far the most common nonapplicable element is 8.3 (Design and Development).

Next, the scope of the quality management system ‘…shall state the types of products and services covered…’

What do we do and how does it affect our certificate?

An organization’s ISO 9001 certificate states what activity is actually certified, the ‘scope of certification.’ This should mirror the management system scope.

If anything about the scope changes, it is vital to alert the certification body. A special audit may be required to ensure the continued validity of the certificate.

Relevant changes include physical relocation, expanding to additional locations or acquiring other businesses, changing the products and services the organization delivers, etc.

Who we are, what we believe in, and how we behave

An organization that complies with the requirements of clauses 4.1, 4.2 and 4.3 knows exactly what it does for a living, the internal issues that make it what it is, the external issues that can affect it, who its relevant interested parties are and what matters to them.

In short, such organization truly knows itself and is ready to tell the world what it believes in (the quality policy) and what it intends to do about it (its quality objectives).

Now go forth and prevent.

As a quality professional, you have surely heard of the requirement for continual improvement. Or is it continuous? Hmm…

Is there a difference, or are we just splitting hairs? Plenty of people use ‘continual’ and ‘continuous’ interchangeably, much like ‘preventive’ and ‘preventative’…

As I teach this part of the course, my students almost invariably gloss over the difference, generally using the more familiar term and talking about ‘continuous’ improvement.

In actuality, there is a distinction, and not without a difference.

Let us start with the ultimate source of wisdom in our business (bow your head or roll your eyes, your choice): Under clause 5.2.1.d, ISO 9001:2015 requires organizations to establish a quality policy that “includes a commitment to continual improvement of the quality management system.”

So, we should use ‘continual’ because the Standard says so. End of discussion, right? Well, yes, but there is also a better reason.

Personally, I have done this work long enough, and drank so much Kool-Aid along the way, that I find the Standard generally makes sense, and there is a good reason it is written a particular way. It is possible to ask why the standard imposes a particular requirement, and actually expect a sensible answer.

‘Continuous’ is something that is always happening, while ‘continual’ is a recurring event, meaning that it happens occasionally, but is not happening at every point in time.

An analogy may be helpful:

Every point in a ramp is going up, in a continuous way.

In a staircase, all points on any given step are at the same level. Yet, as we go from one step to the next, there is a sudden jump to a different level, and this happens repeatedly, in a continual way.

The idea of continual improvement is closely related to the P-D-C-A cycle, which is discussed in clause 0.3.2 of the Standard. (Yes, there is life before Clause 4, and the Introduction -Clause 0- is a great read.)

Under P-D-C-A, we are expected to start with an action plan (plan), then implement it (do), while monitoring performance (check). Once the process has run for some time, we should use the data we collected to find ways to improve it (act). We then prepare a plan to implement those improvements, and the cycle continues.

In this way, we have periods when the process runs smoothly, with recurring jumps in performance as a result of implementing improvements. In other words, the P-D-C-A cycle drives the periodic implementation of incremental improvements – ‘continual’ improvement!

On the other hand, if we tried to implement a ‘continuous’ improvement model, we would have to always deploy changes. The process would never stabilize and there would never be an opportunity to collect data and plan the next move. The result would be chaos, just the opposite of improvement.

Now go forth and prevent.