Standards: Are They Important and Why?

A guest author gives us a quality expert’s overview of the significance, importance and origins of standards. We are grateful to Jon M. Quigley, PMP CTFL for this excellent article. We consider some of the points raised here as they apply to barcode quality and the relevant ISO standards.

__________________________________________________________________________________________________________________________________

We seem of two minds about standards. We either believe these to be “the be all end all”, or that standards mean nothing.  Standards do not necessarily “solve” our problems any more than standards “create problems”.  It should be clear that our talented and trained staff should think the use of standards and the applicability through, rather than summarily dismiss or embrace them.

To decide that a standard is applicable, or not, we must know something about the standard.  We should neither embrace nor summarily dismiss the contents without some measure of skeptical review, specifically, we will want to answer questions such as these:

1. How was the standard developed?
2. What environment(s) were considered in the development?
3. Are there specific applications that were considered in the development of the standard? For example, was the standard derived from a variety of industries and equipment application?
4. Was customer use or application information gathered?

a. The Good about Standards

Standards can help us cut down on the amount of research required to understand how things may work. Standards are often developed by a range of people, expertise or companies contributing, for example, SAE International has many vehicle standards under development at any given time, with many industry experts contributing to any one of those standards.  The same is true for the ISO standards.  This multiplicity of perspective and experience can be helpful in assessing or articulating the range of variation that may be witnessed in the field.  It is true, that the multiple perspective from a variety of people working on the topic, and a variety of applications, can help to identify key parameters and a better idea of the range of variation of those parameters in the field.

b. The bad about Standards

There is a downside of standards.  For example, when we just embrace the standard as if it were some sort of definitive law.  This work often originates from industry pundits or proponents that we may believe are highly credible, we may attach a strong degree of confidence without corroborating evidence.  Any deviation from the standard and our actual product application and operating environment represents a risk that the standard does not adequately represent our application.

c. Variation

The problem is the variety of events and environments that can occur in the field.  Did the standard gather all relevant parameters, and the range of values those parameters may take?  This includes the way these parameters interact, the sort of thing we ascertain through design of experiments for example.  How do we know what sort of effort went into the creation of the standard?  Though there may be a range of participants in the creation of the standard, we may not know the sort of things that went into the generation of that material.  Being part of generating the standard can help mitigate this risk.  Customers also vary in how they use the product.  This variation, not understood and captured in a standard, represent risk to our specific application.

Standards and design

In the course of our work, we may put together some specification that describes how we desire the system or the product to work. The standards will help with some of this, as we point to specific items or clauses within the standard, hopefully these specific items have alpha numeric designator that will clearly define and delineate one set of deemed applicable standard elements from others.  For example, we may not want to just say, must conform to the standard.  Are there specific parts of the standard in which we wish the product must conform?

If for some reason we do not think the standard represents our specific application, we can set about experimenting the parameters (such as ambient light, contrast ratio or vibration) that we believe may impact our specific equipment and application.  We can conduct this exploration of a range of equipment and environmental scenarios.  Upon completing we can compare the results to that of the standard, and that may give us some sense of suitability of the standard to our specific application.

If our organization is appropriately technically skilled, we can build models and simulate the environment to learn more about what happens in our specific application.  Modeling and simulation are only half of the effort. We will also need to include activities that test the simulation results.  This requires such activities as instrumenting the environments in which our product will be required to work, for example, accelerometers to understand the vibration or light sensors to measure the range of ambient light to which our product may be subjected.  Comparing test results and model results will provide us with the measure of continuity between the model and the real world.

If we have explored our specific applications, we can include our findings in the technical documentation regarding the product.  If in our explorations we find that our identified parameters and the variation reside within the standard, then adopting those specific elements from the standard may be appropriate.  At any rate, we may choose to have our product conformance to more stringent values than that indicate in the standard to account for tolerances and to provide a greater margin for error.

Standards and testing

When we test the product, we should not be solely focused on the specification or the standard.  This does not stress the variation in the environment nor the variation that the product itself that will have an impact on how the product performs in that environment.  It is prudent to not just test the product to determine conformance to the specification, but to test the limits of the product to truly understand the product.  This is true whether we use standards or some internal generated requirement.

Summary

The standard provides us material regarding the environment or specific application that can reduce the work required to determine this on our own, thus saving time and money.  However, it does come at a price, accepting the standard as is, means we are assuming that the standard applies.  We can explore our equipment and the range of variation to which it is subjected and compare against the standard to ascertain congruence between the standard and our specific application.

Standards are not evil, no more than ad hoc and on the fly are.  In my view, standards can help us if taken for what they are, a homogeneous representation of a nonhomogeneous environment.  It is up to our talent to make some sense of the standard, know the source of the standard where possible, and understand the implications of real-life deviations from the standard. Testing does not end at testing to standards at any rate, as that will likely only tell you where the product passes. We are more interested in where, when and how the product fails. That requires more than a standard.

___________________________________________________________________________________________________________________________________

Jon M. Quigley PMP CTFL has multiple master level degrees including a MSc in Project Management.  Jon has nearly thirty years of product development experience having ceded 7 US patents and awards. He is experienced in both agile and conventional approaches to the work, as well as teaching these topics at technical schools, universities (including a guest lecturer at Wake Forest’s Charlotte campus) and to other businesses.  He writes on project management and associated topics with product development from idea through manufacturing including quality tools and techniques.  He has written and contributed to more than 11 books, and authored scores of magazine articles at more than 40 different publications.  He has also given numerous presentations at product development conferences on a variety of topics of product development including testing and project management.  He has been interviewed by numerous business and project magazines in addition to podcasts on a host of project and product development topics.  

Jon is on Twitter  @JonMQuigley @ValueTransform and on linkedin at https://www.linkedin.com/in/jonmquigley/