Standards - Why don't we use them?

Its been a while since my last post, I took the opportunity of being in New Zealand for RTC Australasian to do some sight seeing. I have to also admit I was a bit "overBIMed". I found being immersed in a world solely of BIM, even for only a few days, taxing and a little demoralizing. But that's just me, my real love is architecture, not the technologies used to create it. It is certainly not a reflection on RTC events and how they are run. RTC are particularly great for those learning Revit and those wanting to improve their skills. I recommend it to those in the Americas and Europe where up coming RTC events are happening.

My talk on BIM execution plans, and my contribution to the Principle's Forum, didn't follow the "BIM is fantastic and problem free" line of most other contributors so I (deservedly) copped a bit of backlash.
One accusation was that I was being overly negative (some-one has to be), including not being supportive enough of open standards like IFC, COBie etc.

To be clear I think standards are a good idea, and more than likely necessary for BIM to become really useful. But a good idea is not enough. There is a bit of a circularity in standards - they are only useful if enough people use them, but to be used they must be capable of being useful, that is, practical.

The way BIM evangelists talk there is no good reason not to use standards. So why don't we? If they are so fantastic why do we need convincing?
I've tried to tease out some of the reasons that make us resistant to using standards.

WHY DO WE RESIST STANDARDS

STANDARDS REDUCE EFFICIENCY

We all try and be as efficient as possible. We work in a competitive field, there is no slack, no leisure time for processes that aren't immediately necessary.
So we try use the most efficient process for the task at hand. This is why processes are different on different projects. Each project has its own drivers and participants.
Using standards may be more efficient overall - over the entire project life - but not necessarily more efficient for each participant in doing what they need to do.

STANDARDS ARE NOT ALWAYS RELEVANT

At best standards strive to be "average best practice". Some would say lowest common denominator. Within any standard, for a particular project, there will be some parts of that standard that are not applicable, and there will be things that the standard doesn't cover.
For this reason, in the real world, it is never possible to "fully" comply with a standard.

STANDARDS GET OUT OF DATE

By their very nature standards are consensus documents. Even if many parties don't contribute, many parties have to approve and agree to its contents. This means they take a long time to appear, and are rarely updated as it takes so long. The latest version of IFC took 6 years to be published.

ANOTHER THING TO CHECK

If you comply with something some-one has to check that it is happening. To use a technical drawing standard as an example, not only does some-one have to check a drawing communicates what it needs to, it also has to be checked it complies with the standard. And they are not the same. The fact a text note is in a font not in compliance with the standard doesn't mean it is not communicating what it needs to.

STANDARDS OVERSHADOW THE REAL WORLD

The danger in unquestioningly imposing standards is that those standards are treated as more real than the real world. Complying with the standard becomes more important than ensuring that the job at hand is achieved. To use the example above, drawings are only checked to see they comply with the technical drawing standard, not that they adequately communicate.
I've been called into meetings with contractors because they couldn't get the information they require from drawings that slavishly followed a drafting standard (AS1100) but didn't communicate the information they needed.


Looking back on these reasons, it occurs to me that the problem is not standards in themselves, but the way we approach standards.
If we treat them with absolute reverence, or conversely if we treat them as just another unquestioned burden, these problems will occur. But if we treat them as a resource, something useful in certain situations, they become a practical proposition.

Like I said above, standards are a good idea. There only a few, but powerful, reasons to use standards.

WHY USE STANDARDS

COMMON UNDERSTANDING

Standardizing the way things are done, and being familiar with that standardization, improves communication and comprehension. Having a standard for graphically showing door swings means everyone immediately knows which way a door opens.

REDUCES ENDLESSLY INVENTING THE WHEEL

Having an agreed way of doing something means everyone can spend less time working it out from first principles.

REDUCES THE NEED FOR LEGENDS AND EXPLANATIONS

In principle you can use any method you want as long as you explain it. But explanations take extra effort. By following a standard you can just refer to that standard rather than include detailed legends and schedule notes.


These are generic reasons. But with computerization, and the wealth of data BIM produces, there are other reasons for using standards.

BIM and STANDARDS

This may come as a surprise to you, but computers are not people. Computers are not good at using context to classify information, they require more precision (an example of which I explore in my post Which direction is Depth?).
If one digital system is going to communicate with another the information exchanged must be in a knowable form. The obvious way to achieve this across many different softwares is to impose some form of standard. There are many standards within the software industry that us users are (thankfully) unaware of. So when I talk about standards I mean ones that effect how we work, not how the software works.

Which leads to some interesting points.

WE DON'T CONTROL OUR SOFTWARE

Us users can only control what we do, we can't control what our software does. So when we are asked to provide IFC files, for example, all we can do is provide what the software produces. If it is inadequate there is nothing we can do (beyond employ programmers to work around the problems). No software vendor will  take responsibility for what their software produces so it puts us in an impossible situation.

WHY ARE WE RESPONSIBLE?

And at what point are we, the users, responsible for ensuring adequate communication between different softwares? How much effort is reasonable to overcome what is in essence a problem outside our areas of expertise?
Is it reasonable to ask us to rename all our components (e.g. Revit families) just so the FM software can understand what it is being given?
Is it reasonable to ask us to use phasing (in Revit) in a way that helps the 4D software work? (we have just had this request on a project).

But when I get these requests I always wonder why. Why are we being burdened with extra work because of the inadequacies of software. Or is it the inadequacies of standards?

I'm not an expert on either, so I can't answer that. Perhaps it is a mixture of both. All I know is we are the bunnies caught in the spotlight.


But back to what we can control. Overall standards are a good idea, even ones to do with software. But use with caution. Treat them as guides, not commandments. Use them where they are useful, ignore them when they are not. And if following a standard creates more work, say so, don't fuel the myths peddled by the BIM evangelists.

In my next post I'll have closer look at the elephant in the room, IFC and it's sibling COBie.