Standards Are Not Just Rules. They Are Agreements to Build Better.
Why better buildings begin with owners understanding what they want, and project teams committing to delivering it.
We have more construction standards, digital tools, and sophisticated BIM technologies than ever before. Yet our industry continues to struggle with familiar problems: miscommunication, rework, unexpected costs, fragmented information, and buildings handed over with data that nobody can realistically use.
Why?
I believe we are often trying to solve an information problem with technology when the real issue begins much earlier.
We haven't clearly established what we are trying to achieve, why it matters, and how everyone involved will contribute to that outcome.
This is where standards should make a difference.
The Owner Needs to Know What They Are Asking For
Every construction project begins with an intention.
An organization needs a new facility. A developer sees an opportunity. A municipality needs infrastructure. An owner wants to improve the performance of an existing asset.
But an intention is not the same as a clearly defined requirement.
What does success actually look like? How should the asset perform? How much should it cost to operate? What information will be needed to maintain it? How will the owner verify that the delivered building meets the original expectations?
These questions need answers before we start debating software platforms, modelling responsibilities, or file formats.
I am not suggesting owners must become BIM experts. Quite the opposite.
Owners need to understand their objectives well enough to communicate them, and the industry needs to help translate those objectives into meaningful, measurable requirements.
That responsibility cannot simply be passed down the contractual chain with the expectation that somebody else will figure it out.
Standards Are About Establishing Agreements
When I think about standards such as ISO 19650, I don't see them simply as rules for naming files, organizing folders, or delivering models.
I see an opportunity to establish a common understanding of five fundamental questions:
- What are we trying to achieve, and what information is required?
- Why is that information necessary?
- Who is responsible for producing, reviewing, and using it?
- When does it need to be available?
- How will we collaborate, exchange information, and verify that it meets the requirements?
The purpose is not to produce more documentation.
It is to bring everyone to the table early enough to agree on how the project will work.
A BIM Execution Plan, for example, should represent a real commitment between project participants, not another administrative requirement completed during procurement and forgotten afterwards.
Standards give us a framework, but people must give that framework purpose.
Stop Expecting the Next Person to Figure It Out
Construction relies on an extraordinary chain of people translating ideas into reality.
An owner's abstract goals become architectural concepts, engineering solutions, construction documents, fabrication information, and eventually physical components installed by skilled trades.
Every participant adds knowledge and makes decisions that influence the final outcome.
However, when the original requirements are incomplete or poorly communicated, those decisions are made with assumptions.
Architects often become the default interpreters of information that should have been clarified collectively. Consultants work with incomplete expectations. Contractors identify conflicts during construction. Trades are asked to resolve problems that should have been addressed earlier.
And every time information is misunderstood, recreated, or corrected, somebody pays for it.
We have normalized this cycle through contingencies, change orders, requests for information, redesigns, and rework.
Of course, construction involves uncertainty, and not every change is avoidable.
But preventable confusion should not be treated as an inevitable cost of doing business.
We should be investing more effort in establishing the right information before decisions become expensive to reverse.
Communication, Collaboration, and Commitment
For me, successful BIM and information management depend on three principles.
These principles are not exclusive to BIM.
They are fundamental to delivering any complex project successfully.
Technology can connect systems. Standards can establish processes. But neither can create commitment on behalf of the people using them.
The Building Doesn't End at Handover
One of the clearest examples of our fragmented approach appears at project completion.
After years of design and construction, an owner may receive thousands of documents, models, drawings, and asset records.
But can the facility management team actually use them?
Can they locate the equipment they need to maintain? Can they trust the information? Does it connect to their maintenance systems? Does it reflect what was installed rather than simply what was designed?
If we never established those requirements at the beginning, we should not be surprised when the information delivered at the end fails to meet them.
We have confused delivering data with delivering value.
The real measure of successful information delivery is whether the next person can use it to make the decisions they need to make.
That principle should apply to everyone, from the architect interpreting the owner's vision to the bricklayer constructing a wall, and eventually to the maintenance technician working on the building decades later.
BIM Is Not the Goal
A building is not successful because its project team followed a naming convention, produced a coordinated model, or delivered a complete set of digital files.
It is successful when it fulfils the purpose for which it was created.
BIM, standards, and digital technologies should support that outcome, not become the outcome themselves.
And that requires a shift in how we approach projects.
Owners must take responsibility for defining what success means, supported by professionals capable of translating their objectives into useful requirements.
Project teams must agree on how they will work together before information begins moving between them.
And every participant must understand that the information they create serves someone beyond their immediate contractual obligation.
We need to stop thinking about information as something we hand over, and start treating it as something we collectively develop, preserve, and improve throughout the life of an asset.
The next time we begin a project, perhaps our first conversation shouldn't be about what BIM software we will use or which standard we must comply with.
Perhaps we should start with a more important question:
“Do we understand what the owner is trying to achieve, and are we all committed to making it happen?”
Because if we cannot answer that question together, no amount of technology or documentation will solve the problem.