Standards: Baselines for Improvement

by John E. “Jack” West

There are many kinds of standards: ones that apply to a wide variety of products and services, ones that cover a wide range of processes and test methods and even ones that provide guidance or requirements for management systems. Most products have at least some related standards. Table 1 lists a few of the many types of standards.

Standards abound in business and industry. Some are company standards while others may be developed by national or international standards development organizations (SDOs).

In the world of consumer goods and services, standards are most often invisible to us as purchasers. Of course, if our job involves testing in a paper mill or buying computer components, we see references to the applicable standards every day. They form parts of the contracts we have with our suppliers and may govern how we perform processes in our own organization.

But why do we have all these standards? Perhaps it all started with the need for things to fit together physically, but that is another story.1

Standards are an important and integral part of commercial interactions. At their best, they facilitate trade by establishing level playing fields for all competitors; at their worst, they can be used to restrain international commerce by excluding potential trading partners that cannot meet their rules.

Standards developers need to be constantly vigilant and root out situations that could cause standards to become nontariff trade barriers. The world’s standards systems also need the help of those who actually use their documents.

There are three things users can do. The first is the easiest. Two and three are more difficult.

  1. Participate in the standardization process by volunteering to help write, review and edit new and revised documents.
  2. Learn to correctly read, interpret and use standards.
  3. Develop a broad attitude toward the long-term utility of standards: continual improvement.

Reading and Understanding

In reading and understanding a standard, it is useful to identify the role the document plays in the customer-supplier relationship. Table 2 (p. 92) illustrates some possible relationships as they may apply for product, process and testing standards.

It is important to remember the customer organization’s expectations as well as those of the supplier organization. Your goal should be to make certain your use of the product, process and testing standards aids both organizations in meeting their needs and objectives. While a win-win result is not always possible, it is certainly good to go into a new project with the attitude you will achieve that result.

Notice the product, process and testing standards are key inputs during identification of product requirements. And we all know identification of requirements is a critical element of an effective quality management system.

Proper use of these technical standards is needed for the overall quality management system to meet its objectives. This is an important concept that is often overlooked.

The example in Table 2 is a simple one and does not consider the complications brought about by other stakeholders such as regulators. But a similar approach can often be used in these different situations, and similar thinking can be used for other types of standards, such as those for statistical sampling and other statistical methods.

Read the standard carefully with a positive attitude. You will probably find that most of it is straightforward and easy to understand. Take careful notes on those sections that appear to be less clear or seem to require, suggest or imply requirements that may be difficult to accomplish. As you do so, you should remember a few rules.

Rule 1: If it says it, it probably means it. Or perhaps better, if it can be read that way, it will be. Consider what might be the most difficult interpretation for you to implement, and remember that if the standard can be interpreted that way, it is very likely it will be in the future.

Remember the difference between requirements (using words such as “shall”) and guidance (using words such as “should”). Normally, guidance is an option, but in some situations, guidance becomes a de facto requirement. And in many cases, failure to follow reasonable guidance can cause problems (even legal ones) later on. It is best to get clarification of intent up-front. This brings us to the next rule:

Rule 2: Get clarification if there is any doubt at all about intent or interpretation. You may want to discuss the issue with your customer. If discussions are held up-front, they can often be a source of long-term close cooperation with the customer’s technical and purchasing people.

If you can’t get agreement on a reasonable approach and the customer prepared the specification, you may just need to find the most practical way to comply with the interpretation.

If it is a standard developed by a SDO, you may wish to address the issue with the committee responsible for the standard. Most SDOs have formal processes for requesting official interpretations, and formal interpretations often take a long time—time you may not have. So it is always best to reach a written agreement with the customer if you can.

Rule 3: Brainstorm the simplest, most effective, most efficient methods to implement the requirement. This rule can be applied before discussions with the customer, after you have customer agreement or customer involvement in the standard’s application. List as many methods as you and your team can think of. Then select the ones that look best.

A good way to do this is to use tools like process failure modes and effects analysis to determine the risks of not meeting requirements with a given approach. Commonsense methods of implementation are best. If you can’t find a commonsense way to implement a requirement, you should work with the customer to get the requirement changed or clarified.

Rule 4: Test your own method for applying the requirement against the wording of the standard. Even in cases in which you have no question as to what is required, it is useful to cross-check to be certain you have covered all the bases, particularly if the standard is complicated.

Rule 5: Plan needed changes. Identify the gaps between what you have done in the past and what is now required.

You will need to identify the changes in processing, new equipment, equipment improvements, technology changes, training and anything else that will be needed for implementation. You will need an implementation plan that is agreed on by each involved part of the organization.

Rule 6: Confirm your plans with the customer. This rule often encounters organizational resistance. There may well be situations in which it is not appropriate. (For example, if you have developed new and unique technology to meet a requirement, you may not wish to share it.)

Often, the resistance is based only on fear—that the customer may reject the plan or, worse, will refuse to even review it. Unfortunately, these fears are sometimes borne out, but customers are often very helpful at this stage. After all, they should want a win-win situation, too.

Continual Improvement

In an article in the May 2004 Harvard Business Review, Steven J. Spear points out:

Toyota’s much noted commitment to standardization is not for the purpose of control or even for capturing a best practice, per se. Rather, standardization—or more precisely, the explicit specification of how work is going to be done before it is performed—is coupled with testing work as it is being done. The end result is that gaps between what is expected and what actually occurs become immediately evident.

Not only are problems contained, prevented from propagating and compromising someone else’s work, but the gaps between expectations and reality are investigated; a deeper understanding of the product, process and people is gained; and that understanding is incorporated into a new specification, which becomes a temporary “best practice” until a new problem is discovered.2

In other words, the purpose of standardization at Toyota can be viewed as facilitating problem identification and problem solution for improvement.

The ASQ ISO 9000:2000 Handbook contains many ideas that are real gems. One of them is the article on “Improvement and Standardization” in chapter 37,3 which quotes the late Donald Marquardt, who was my predecessor as chair of the U.S. technical advisory group to ISO Technical Committee 176, as saying, “…a standard is the end point of one improvement and also the starting point for the next improvement.”

The chapter explains this concept in detail by describing what the author of the article, Hitoshi Kume, calls the standardize-do-check-act (SDCA) cycle—illustrated in Figure 1. Obviously, this is derived from the plan-do-check-act (PDCA) cycle first described by Walter Shewhart and made popular by W. Edwards Deming.

Kume says, “Daily management activities consist of maintenance and improvement. Maintenance involves setting standards and working in accordance with them and improvement involves setting targets above the present level and working to achieve those targets. To convert a prevailing situation into a more desirable one, existing standards must be altered.”

The message is clear: We should be viewing standards as baselines for improvement, and once we have determined a better way, the standards must be changed to include the improvement. If we find better ways and do not change the standard, we almost always slip back into the old ways.

There are many things standards users can do to drive continual improvement through the standards process:

  • Make comments on the standards they use and be willing to add new ideas they have developed in their use.
  • Develop their own version to guide implementation of new and innovative technology they don’t want to share outside their organization.
  • Share new technology they feel comfortable sharing and use benchmarking studies to define better practices that should be standardized.
  • Perhaps most important, identify severely deficient standards and recommend they either be fixed or canceled.

It’s Up to All of Us

Why should users bother? There are two simple answers:

  • Improved standards can make life better for all of us.
  • Users are the key to improving standards because they can see issues never imagined by the writers.

These ideas are true whether we are talking about the standards of an individual organization or standards developed by international SDOs.

Because there are lots of standards, probably too many, it is up to users to provide the input needed to eliminate the useless ones, improve the ones that are useful and develop those new standards that are necessary.

The systems of SDOs are not perfect, but they are often more flexible and responsive than users might think. Get involved and help. It is a rewarding thing to do because standardization is really a component of continual improvement.


  1. John E. “Jack” West, “The History of Standardization and the ISO 9000 Family,”
    pp. 47-62, from The ASQ ISO 9000:2000 Handbook, Charles A. Cianfrani, Joseph J. Tsiakals and John E. “Jack” West, eds., ASQ Quality Press, 2002.
  2. Steven J. Spear, “Learning To Lead at Toyota,” Harvard Business Review, May 2004,
    pp. 78-86.
  3. Hitoshi Kume, “Improvement,” pp. 483-500, from The ASQ ISO 9000:2000 Handbook, Charles A. Cianfrani, Joseph J. Tsiakals and John E. “Jack” West, eds., ASQ Quality Press, 2002.

JOHN E. “JACK” WEST is a management consultant in the areas of productivity and quality. He served on the board of examiners for the Malcolm Baldrige National Quality Award and is now chair of the U.S. technical advisory group to ISO Technical Committee 176 and lead delegate to the International Organization for Standardization committee responsible for the ISO 9000 family of quality management standards. He is co-author of ISO 9001:2000 Explained, published by ASQ Quality Press.

Average Rating


Out of 0 Ratings
Rate this article

Add Comments

View comments
Comments FAQ

Featured advertisers