The great thing about standards is that there are so many of them. There are standards for just about anything. Early in my days as an engineer a colleague of mine was looking describe the specifications for the newly released CD-ROM drives for PCs. He ordered what he thought was the right standard from ISO and got something entirely different. Mind you, it didn’t stop company reps from claiming full compliance when we asked them about their new systems. In another case, I called upon full DOD-STD-2167A compliance for a standard computer software project back in the day only to find that the cost ballooned far beyond expectations (almost as bad as some of the other over-specified common every day products.) Thankfully, someone took the time and walked me through the standard I had casually referenced and pointed out all the processes, documentation, reviews and attestations that I had invoked for my relatively small project. Lesson learned, I started reading standards and specifications to understand all the mandatory, optional, normative, informative and other nuances found within. I liked it so much that over the years I also contributed to a few including: ACP, DOD, IETF, ISO, TBS and others.
Standards are great since they help make things work as expected. For example, they help make sure that when you plug in an electrical appliance, so that it safely performs as expected. While standards frequently help things work, sometimes different interpretations or optional functionality within standards can prevent stuff from working properly together. That’s just one reason why it’s super important to know what parts of the standard are important to you and what parts are not so important. There are several others reasons too, including perhaps the most important one: cost. Yes it can be a pain to have to wade through what can be hundreds of requirements, but ultimately simply pointing to a specification number is entirely unhelpful.
Technology seems to be evolving more rapidly than ever before and sometimes the speed of innovation outpaces existing standards. New approaches for meeting requirements can create discord with the existing standardized status quo. That’s when it becomes even more important to understand those details behind that specification or compliance standard number. Maybe that new capability makes a number of requirements obsolete, or perhaps far exceeds the tolerances of days gone by. Organizations, and the people using specifications to help their organizations, owe it to themselves to build out a comprehensive understanding of the specifications they are using and the rationale behind asking for them.
Perhaps it’s the pace of change, but recently I’ve also seen an increasing number of people ask about non-existing certifications or ask about compliance against standards that don’t apply to a particular scenario. While not quite as egregious as the ISO Open Cold Storage of Cabbage standard I pointed to above (you saw that, right?), they are unfortunate none-the-less. Calling out standards that don’t apply to your type of business or regions where you operate can create a drag on your business that you just don’t need. So before you cite a standard or specification, take a moment to ask yourself what particular parts of the standard are most important to your business so that you can be sure that the solutions you specify do everything you expect them to.
By the way, sometimes people might simply call out an arcane standard with the hopes of cutting a meeting short by stumping the supplier sitting across from them. You’d never do that, right?
Thumbtackhead 