Separating requirements, intent, and implementation: A lesson from ASTM Committee Week
During the recent bi-annual ASTM Committee Week, I participated in a thought-provoking discussion at an E36 workshop focused on harmonizing quality management system (QMS) terminology across multiple standards. Although the workshop centered on terminology, one exchange highlighted a broader issue that frequently arises in standards development, audits, consulting engagements, and certification activities.
The workshop brought together participants from various committees to review existing quality management requirements, determine whether they should remain, and discuss opportunities to improve consistency and clarity.
In most cases, however, the conversation was not about whether a requirement should exist. It was about what the requirement was trying to accomplish, why it mattered, and how organizations might choose to implement it.
When requirements aren’t as straightforward as they seem
Several requirements generated interesting debate. For example, this requirement launched heated discussion:
Document the company ownership and organization structure.
At first glance, the requirement seemed straightforward. However, one participant expressed concern that documenting ownership information in the quality system should be removed, as it would expose sensitive ownership relationships and business information. For organizations that routinely share portions of their quality system with customers, auditors, certification bodies, and others, this is a legitimate concern.
As the discussion continued, it became clear that people were not debating the same thing.
Some were focused on the requirement itself.
Others were focused on a particular implementation of the requirement.
Those are not necessarily the same.
After listening to the discourse, I suggested that the requirement could be satisfied without placing sensitive ownership information into a widely distributed quality document. Ownership information could be maintained within a separate controlled document and made available to individuals with a legitimate need-to-know. The organization could then reference the existence of that information within its quality system documentation.
The concern was addressed, yet the requirement can be fulfilled.
That discussion reminded me of a principle that applies not only to standards development, but also to auditing, consulting, certification, and quality management in general.
Before debating how a requirement should be implemented, it helps to understand what it requires and why it exists.
Separating the what, why, and how of requirements
Quality requirements are often interpreted as though they prescribe a specific solution. In many cases, they do not.
A requirement describes what must be achieved.
The intent describes why it must be achieved.
The implementation describes how a particular organization chooses to achieve it.
Confusion often occurs when those three concepts become blended together.
In the ownership example, the requirement was to document ownership and organizational structure. The likely intent was to ensure that governance, authority, accountability, and organizational relationships are understood and documented. One possible implementation would be to place that information directly in a quality manual. Another would be to maintain the information in a separate controlled document. Both approaches may satisfy the same requirement and intent.
Once the discussion shifted from a specific implementation to the underlying objective, alternative solutions became easier to identify.
One requirement, many valid solutions
This is one of the strengths of effective management system standards.
Organizations differ significantly in size, complexity, culture, risk, resources, and business models. A family-owned business, a publicly traded corporation, a testing laboratory, and a consulting firm may all need to satisfy the same requirement while using very different approaches.
Requiring every organization to implement a requirement identically often adds complexity without adding value.
What matters is that the organization understands the requirement, understands the objective behind it, and can demonstrate that its chosen implementation achieves the intended outcome.
This principle is also valuable during audits.
When an auditor encounters an implementation that differs from what they expected, the first question should not be:
"Why didn't you do it the way I have seen elsewhere?"
A better question is:
"How does your approach satisfy the requirement and its intended objective?"
Organizations should be prepared to answer that question. Auditors should be willing to listen to the answer.
My takeaway from Committee Week
The workshop was intended to improve consistency in quality management terminology. It certainly accomplished that objective. However, my primary takeaway was not about terminology at all. It was a reminder that quality professionals often debate implementations when they believe they are debating requirements.
Many disagreements that appear to be about wording are actually discussions about intent, implementation, or concerns about future consequences.
When we separate those topics and address them individually, solutions often emerge quickly.
Whether developing standards, implementing a quality management system, conducting an audit, or responding to a finding, it is worth asking three simple questions:
What is the requirement?
What is the intent behind the requirement?
What implementation best meets that intent for this organization?
Implementation answers are not always identical across organizations, and that flexibility is often where the most effective solutions are found.
I'm interested in hearing from others involved in quality management, auditing, certification, or standards development. Have you encountered situations where a requirement was interpreted as prescribing a specific implementation when other effective approaches were available?
About the author
Ed Nodland is the founder of GapCross and an active participant in ASTM International standards development. He writes about quality management, auditing, and practical approaches to implementing standards.
