These days, you hear the word standard everywhere.
People join committees, follow procedures, and say they want to “align with standards.”
- But what does it actually mean to align?
- Should we really align with every standard out there?
- And how can we tell which ones truly can be aligned with?
Let’s slow down for a moment and talk about that.
Some standards simply can’t be aligned with
First, we have to face a fact:
Some standards simply can’t be aligned with.
You’ve probably seen these documents before: dozens of pages packed with new technologies and shiny buzzwords, every trendy concept of the moment. You read through it carefully, the structure looks neat, the writing seems serious, professional, even visionary. — and yet, by the end, you can’t quite tell what it’s actually saying.
How do you “align” with that?
The reason is simple: these so-called “standards” were never meant to be aligned with. They chase new ideas and popular terms before they’re proven, or exist just to tick a box — to publish “a result” or produce a deliverable to meet an administrative goal — not because they were built on real, tested, shared experience. No matter how hard you try, you cannot truly align with such documents, because there’s nothing stable or consistent to align to.
The purpose of a standard is not to create superficial uniformity, but to offer a reliable point of reference when it is needed.
So the real question isn’t "whether you should align?"
It’s "what exactly you are aligning with?".
To answer that, we have to understand the fundamental nature of different types of standards.
The nature and types of standards
When people talk about standards, they often classify them by scope or authority — international, national, industry, regional or company level. Or by obligation — mandatory, conditional, recommended, voluntary. These sound systematic and clear, but in fact they only describe the scope of application or the level of obligation. They tell you who must follow it, not what kind of thing it is.
If we look at standards by their content and purpose, we begin to see that there are fundamentally different types:
- A document that defines concepts and terms is a Glossary / Terminology.
- One that explains how to do something is a Guideline / Implementation Manual.
- One that describes steps in a process is an Operation Procedure.
- One that sets objectives or conditions to meet is a Requirement / Criteria.
- One that summarizes knowledge, principles and methods is a Specification / Norm.
- One that defines data structures and semantics is a Data Schema.
The first step in understanding a standard is knowing what kind of thing you are reading. Not every document with “standard” in its title is about standardization.
And one of the most common misunderstandings is to assume that following a standard automatically produces standardized results.
In reality, many standards only define terminology, methods, or procedures. That doesn’t mean they can deliver consistent, repeatable outcomes or interoperable data. They tell you how to think, not necessarily what you’ll get.
How to tell if a standard can actually lead to standardized results?
So how do we know if a standard can actually produce standardized results?
Here’s a simple test:
If different people, in different contexts, follow the same content and end up with the same result — then it truly supports standardization.
Let’s look at some examples from the AEC industry.
ISO 19650 is the international standard for information management in construction projects. It defines many concepts and terms, and it also specifies processes and steps. But how information management is actually implemented depends heavily on project context. Therefore, ISO 19650 serves partly as a Glossary and partly as an Operation Procedure.
A local delivery requirement standard, on the other hand, defines the conditions and expectations for achieving certain project outcomes. It may provide suggested methods, but even if all parties follow the same document, the quality and structure of delivered data can still vary. Data consistency is not guaranteed. It is a Requirement and Guideline, not a standard that produces standardized data.
In contrast, for steel structural design, we have Eurocode 3 in Europe, AISC 360 in USA, or GB 50017 in China. They define shared principles, formulas, and parameters in the region. Different engineers facing the same problem follow the same code should arrive at the same result. That is a Specification, capable of producing standardized and repeateable results.
And take ISO 16739 – the IFC Standard: it defines the structure and semantics of data exchange, ensuring that data created by different software applications share the same meaning and structure. This is a Data Schema, and it’s capable of producing standardized and interoperable data.
In short: only when a standard produces consistent results across different contexts, it truly hold the power of standardization.
Don’t pretend to align
So once we’ve found the right standard, should we align with it in every detail?
Not necessarily.
Many organizations fall into the trap of "performative alignment" — chasing the form instead of the purpose, enforcing surface-level conformity while missing the underlying objective.
Take ISO 19650 again. Some teams strictly divide document statuses into four categories, just because the standard does. But does that really serve their purpose? For an archive office, they might just need one — “Archived.” For a large project team, just one state of "Shared" may not enough. They might need more: internal or external sharing, different levels of sharing. Using the same labels everywhere can actually create confusion, not clarity.
Or consider another case: some believe that simply using IFC means they’re practicing open standards and achieving interoperability. But I once saw a part of rail modeled as part of an IfcBuilding — floating above the ground, positioned on the sixth floor. Technically valid? Yes. Meaningful or interpretable? Not really.
Standards are meant to create a common language, not a common pose.
We don’t need to twist ourselves into an identical shape in the name of alignment.
There is no single universal process. Workflows should adapt to your project, your organization, your environment. Real standardization lies in understanding the standard’s logic, and then using it flexibly — combining and creating a workflow that makes sense for you.
So don’t pretend to align with standards.
Let standards work for you
In the end, standards are not cages. They exist to help you understand boundaries, to align understanding among people, and to produce more reliable and predictable results and data.
When you know what you’re trying to achieve, a standard becomes a compass, not a constraint. It should guide your thinking, not replace it.
Refusing to pretend alignment doesn’t mean rejecting standards. It means understanding what standards are truly for — to be used.
Not every book is worth reading.
Not every standard is worth aligning with.
In the end, let everything work for you.