LOD, are we there yet

After going through the [US]AIA  E203 document Draft (actually the G202 where LODs are described) and BIMforum's LOD Specification I got a bit excited. Maybe, just maybe, LOD is maturing and might actually be useful in a practical way.

To be honest it was Brian Renehan's excellent blog post Developing LOD (Level of Development) that made me think progress had been made. It clearly set out the differences between the original E202-2008 and the new E203-2013.

Mind you, the 20 odd pages that the [US]AIA Digital Practice Documents Guide took to describe LODs left me with the impression it shouldn't be this complicated. So I thought I would try and write a simplified, concise description of LOD. But when I studied it closer I found I couldn't follow the way some things were supposed to work, and felt there were some things missing.
I think I understand what is being attempted, but am not confident my reading of the literature is correct. And if I am having trouble understanding it, there must be others out there in the same boat.

So before attempting my "LOD for Dummies" post I thought I should write about my concerns to see if they are shared, or are, in fact, completely wrong.

Isn't BIM about Data?

In the [US]AIA E203 under every LOD description (except LOD100) there is the sentence:

 "Non-graphic information may also be attached to the Model Element".

"may"? I would have thought "non-graphic information" - i.e. data - would be a requirement for it to even be called BIM.

How do you derive information if there is no data, just geometric modelling? I call that 3D drawing, not BIM.

LOD100 is silent on "non-graphic information", but presumably it is not a requirement just like all the other LODs. Yet there is an assumption information can be "derived" from areas. Yet isn't area "non-graphic information" ? After all you can create a graphical representation of say a floor, without an area attached to it. That is what CAD software does.

And why are elements to be "graphically represented"? Don't we want them to be geometrically represented? Something that represents the critical 3D shape and size of elements. Strictly speaking an element can be "graphically represented" by a 2D symbol.

I find this approach strange and unnecessary. Why would you even distinguish between graphic and non-graphic information? The point of BIM is that they are tied together. You might as well use CAD and spreadsheets.

LOD 100 - how does it work?

The big one for me is I really could not follow how LOD100 would work in practice.

To recap G202 says:

“2.2 LOD 100 – Model Element Content Requirements.
The Model Element may be graphically represented in the Model with a symbol or other generic representation,
but does not satisfy the requirements for LOD 200.
Information related to the Model Element (i.e. cost per square foot, tonnage of HVAC, etc.) can be derived from other Model Elements.”

Firstly I don't see how "graphically represented in the Model with a symbol" helps anyone. Unless that symbol has data that can be extracted it is pretty much invisible to other softwares. There seems to be confusion between drawings and BIM.

But data is not mentioned as I discussed above. Shouldn't there be a requirement in the LOD100 description for gross quantities such as areas and volumes? How can estimating be done without it? Or is there an unsaid assumption all BIM software will have this anyway?

Perhaps the most significant part of the LOD100 description that it "does not satisfy the requirements for LOD 200". That is you allocate LOD100 to everything in the model that doesn't satisfy any of the other LODs. But of course that means LOD100 can't really be used for anything. You don't know if the element has been put in the BIM to just satisfy a documentation requirement, or as a work-around, or is actually a representation of something real. So I don't think that is the intention.

I don't understand what the process is for identifying information "derived from other Model Elements”. The example of lighting being costed on the basis of floor area is given. So OK, lights are not modelled, I get that. Therefore they are not in the BIM.
But how do you communicate that the quantity of lights is to be derived from the floor area? Is it something you put in the LOD table, or is there an expectation that data associated with floors includes information about lights (and all the other things derived from floor areas)? But then why does this need to be explained in the BIM at all?

Surely it would be simpler to say lights are not in the BIM model and leave it at that. In the costing example the estimator then knows not to rely on the BIM for information on lights, it will have to be calculated within the estimating process using other information. There is no need for the BIM to indicate what that other information is, as the costing expert the estimator makes that call. It is not up to the BIM to tell anyone how to do their work. It is just a resource, and the LOD table merely tells people what is in the BIM and how reliable it is.

So I really don't know what I am supposed to do to comply with an LOD100 requirement.

I understand it is supposed to provide notional information, but I can't envisage how the [US]AIA G202 definition might be used on a real project. 

LOD 500 - confused?

LOD500 has caused some confusion. Certainly Brian Renehan writes about it in his blog post.

To recap the [US]AIA definition in G202 is:

"2.6 LOD 500 - Model Element Content Requirements.
The Model Element is a field verified representation in terms of size, shape, location, quantity, and orientation. Non-graphic information may also be attached to the Model Elements.”

One area of confusion is BIM Use. By LOD500 uses like clash detection, time sequencing and costing are no longer in play. So it makes no sense to say an LOD500 element has these BIM Uses. About the only use left is Facilities Management. Yet FM is not a BIM Use the BIMforum LOD specification or [US]AIA G202 includes by default (although that doesn't mean it couldn't be included).

The other is the lack of definition around data. It may not be necessary to upgrade the element's graphical representation at all, because it already meets the LOD 500 definition. All that may be required is that data associated with the model element is upgraded to describe what was built or installed. But you wouldn't get that from the definition because non-graphical information is optional.

Like LOD100 I am pretty sure I understand what is being attempted, it is just not being explained very well.

Missing LODs

Not Everything is BIM

There is no method to describe things that aren't to be used even though they are in the BIM. Despite what others think we BIM authors don't create our BIM models purely for their benefit. At the moment our main purpose is the generation of printed drawings and schedules. Our BIM models also end up with design options and other deliverables (like GreenStar or LEED). This means our models contain things of no interest to anyone else, or the proscribed BIM uses. But how would they know?

Not Everything is in the BIM

The other missing descriptor is that there is no method to describe things that aren't in the BIM. In the [US]AIA guide there is a suggestion to use 'NM' (not modeled). But I think it should be integral to LOD descriptions.  It is just as important to know what is not modelled as to what is.  There should be an explicit way to say something is not in the BIM, not just a 'suggestion'  in the guide.

Is Creation of Construction Documentation a BIM Use?

One of the uses we are all using BIM for at the moment is for the creation of construction documentation - drawings and schedules.

Yet this is not mentioned as a BIM use. I'm not sure why not.

No-one builds straight from a BIM model. Some construction tasks might make use of the BIM model, like laser set-out and other surveying tasks, but drawings and schedules are still required to explain how, and scope what, is to be built.

Certainly authors of BIM models are using their model for this use. But could we say others are utilizing BIMs that are not their own for their documentation?

Possibly not. I can't think of an example where this happens. You might use some-one else's BIM for design or analysis (engineering or otherwise), but generally not for producing your drawings or schedules. If you did you would effectively be taking information some-one else is responsible for and presenting it as work you are responsible for. Something I would have thought should be avoided.

But using BIM for the creation of construction documentation is a valid use, and one that needs to be encouraged. I am constantly surprised at how few in the AEC industry use BIM to generate schedules, how many details are still done in isolation using CAD.

At the end of the day if the construction documentation doesn't match the BIM that BIM is going to be pretty useless, whether you are using it for design, analysis or anything else. Which is why this should be addressed as part of LOD. I always include "creation of construction documentation" as a BIM use. It may only be the authors using their own BIM for this use, but it needs to be stated, and participants need to be held accountable if they agree to it.

End of a Milestone is Too Late 

The [US]AIA E203  guide rightly says milestones are not equivalent to project stages (concept, schematic,  documentation  etc.). 

Their example LOD tables put these milestones are across the top which puts a practical limit on how many milestones there can be (otherwise they won't fit on a printable page). 

[US]AIA G202 LOD Table

This infers there shouldn't be that many of them, and further that all elements will probably meet the same milestones.

But the reality is BIM deliverables don't necessarily all happen at the end of a project milestone, and don't necessarily involve every element in the project. It is more likely certain elements will require a level of resolution before other elements can progress.
For example milestones might be the week number of a project stage, or if the program is not sufficiently defined divided into, say, 10 parts. Then certain elements can be targeted to reach their LOD level earlier or later.

 Brian Renehan suggested an alternative LOD table format in his blog post Developing LOD (Level of Development). I've created an example of a similar table below.

after Brian Renehan's LOD table

Milestones (MS) are a column, and LODs run across the top. LOD tables will then be a fixed width (i.e. LOD100 to LOD500) but allow a varying number of milestones per element. 

Certainly the LOD table structure in the [US]AIA G202 will work if there are limited BIM milestones, but I believe Brian's alternative provides greater flexibility.

Am I wrong?

Generally l believe the [US]AIA E203 Document conception of LODs is good. Restricting LOD 400 to only fabricated elements makes practical sense. As does utilizing LOD 500 to identify only those elements actually requiring field verification.
The BIMforum Specification has clear and concise descriptions of the [US]AIA LOD definitions, along with a sensible addition of an LOD 350 for installation information.

And to be clear I am not commenting on the whole [US]AIA  Digital Document set, only the LOD part. Nor do I consider it to be the only definition or only use for LOD. The LOD concept has a wider application than a single legal document in one country. But the [US]AIA E203 Document is a good starting point.

So I am supportive of the [US]AIA and the good work they have done. It is just that there are a few things that I believe don't quite seem clear enough to make practical use of LOD.

I'd be grateful if anyone can put me straight.

to COBie or not to COBie

When BIM and FM are talked about COBie always gets a mention. No self proclaimed BIM evangelist ever misses the opportunity to insist COBie must be a deliverable.
But must it? Is it the easiest, or even best, way for a construction team to deliver FM information?

What is COBie?

COBie is an acronym for "Construction Operations Building information exchange".
Its purpose is to exchange information that is gathered during construction to be passed on to a building's facility manager. COBie defines the way this information is structured, and the formats that can be used.
COBie is managed by the buildingSMARTalliance, a council of National Institute of Building Science (US).
The aim is that it becomes the standard way this information is delivered. A noble cause, but not without some notable problems.

What COBie is not

COBie is not a predefined list of what information is required. What it does define is how information is to be structured and what the minimum data fields are. It is a data format, not a standard on what information is to be provided for FM.
So to ask for 'COBie' without defining what you want in the 'COBie' is a bit like asking for a MS Word document without saying what you want written in it.

What does COBie look like

COBie can be delivered as a spreadsheet or an xml file (a structured text file, a bit like HTML). xml files require software to make them human readable so unless a software (or web service) is proscribed COBie is normally requested as a spreadsheet.
The theory is a spreadsheet can be filled manually by humans, yet still retain the possibility of populating data automatically via software from BIM models.
However don't think you could deliver COBie through entirely manually filling in a spreadsheet. COBie spreadsheets may be human readable, but are not human friendly (except maybe to computer programmers). True, you could set up human friendly spreadsheets that fed data to COBie spreadsheets, but that doesn't overcome the enormous amount of data that has to be manually typed in, checked and verified.

What COBie contains

Unlike IFC COBie data is just information in text and numbers, it doesn't include geometric information. It may contain the sizes of components and their X,Y,Z coordinates, but not enough information to recreate the components in 3D software like IFC can.

Because it is for FM COBie data is supposed to only contain information about "managed assets". Assets that:

• require management
• require (considerable) on-going maintenance
• has consumable parts requires regular periodic inspections

 Therefore COBie is not intended to exchange ALL information about a building. For example it is not meant to include information about flow systems like air conditioning systems or water pipework. BuildingSMART's approach is to have other  information exchange formats (some still under development) to do this: HVACie (for Heating Cooling and Air Conditioning systems), WSie (for Water System information exchange),  Sparkie (for electrical system information exchange) to name few. See the NIBS web site for a current full list of 'ie' projects.

The concept is that there will be overlaps. For example equipment in HVACie that requires maintenance will also be in COBie. In theory if information exchanges are largely automated from BIM this overlap shouldn't involve (much) extra work for users. Not so if done manually as the same information will have to physically entered multiple times.

COBie only sets out how to structure information that lists equipment, it doesn't dictate how information about a piece of equipment is structured. So COBie will define how to list, say a pump, but not how to list the manufacturer, model, rating etc. This information is defined by another information exchange - SPie, Specifier's Properties information exchange.
The objective of SPie is to create set of product templates that can be used by manufacturers to export product data into an open-standard format consumed by designers, specifiers, builders, owners, and operators. So its use is beyond just COBie.
Product information can be included in a COBie deliverable, it is just that you will need to refer to SPie rather than COBie on how that data is structured.

COBie and IFC

So how does COBie fit into IFC?
COBie is what is called a Model View Definition (MVD) of IFC. A sub-set of data that is useful for a particular purpose. COBie is the Facilities Management Handover model view.

SPie is the product data model view, HVACie the mechanical systems model view, etc.
All the model views ending in 'ie' (for 'information exchange') are actually a sub-set of Model View Definitions. They are specifically for exchanging information. Other IFC MVDs may be for other purposes, for example displaying certain components in a view.

In theory a COBie deliverable could be extracted from an IFC export. However all the data required would have to exist in the IFC file. Just exporting an IFC file in itself won't guarantee a valid COBie deliverable.
Conversely COBie data could be pushed into an IFC file. But again it is not automatic. Matching objects would have to exist in the IFC file. If a pump doesn't exist in the IFC file, COBie can't push data into it.
Using IFC to deliver COBie is NOT easier and quicker, it adds another layer of tasks. Which is why both IFC and COBie are usually requested by owners.

COBie innards

I don't intend to go into detail about how COBie is structured (my view is as AEC professionals we shouldn't have to), but there are some notable things to know that effect how a BIM model is structured.

Equipment must exist in a 'space', IFC's name for rooms. If it exists in more than one room the recommendation is to use the room it is accessed for maintenance from. Under COBie a piece of equipment can only exist in one 'space'. Therefore if you want it identified with more than one space you need to enter it multiple times, which of course creates a whole lot of other problems, so is not recommended.
But 'Spaces' can be grouped into 'Zones', so equipment can also be identified by the zone they belong to. Example of zones are Lighting zones, Fire Compartments, Secure zones, etc.
Equipment can also belong to a 'System', which is not related to 'spaces' or 'zones'. Systems group equipment that perform a specific function. Examples of systems are HVAC service, Cold Water reticulation, electrical distribution, etc..
Not all BIM software have 'zones' or 'systems' as defined by COBie so workarounds may be required.

How to name things is not defined in COBIE, but it does say everything must have a unique name that is human readable, for example "AHU-03". BuildingSMART recommend basing names on the US National CAD Standard abbreviations. As construction terms differ between countries this won't work everywhere, but local standards could equally be used.
This requirement is a little surprising as it is not strictly necessary. A unique identifier for each component is also required by COBie (a GUID), and easily supplied when exporting from BIM software. I presume this requirement is to make COBie  data more human friendly for manual data input, as I don't see why it would be required by an FM database either.

Another requirement for COBie is to assign a classification code to each component. A classification standard like Omniclass (US) or Uniclass (UK) is suggested, but COBie does not proscribe what should be used.
I'm not sure why this is required at all, an FM database doesn't necessarily use a classification system. But that said, getting into the habit of applying widely understood classification codes to BIM components will make BIM more useful across a whole range of uses.

Questionable Practices 

There are a number of issues that could potentially cause problems. Some are due to poor practices in the way COBie is used, others are built into COBie itself.

The requirement to create a unique name has caused some users to mix data together. This includes the COBie web site which offers this advice:

"if there were two sinks of type “Sink-A” in space “100” the unique names of each of these components following the algorithm shall be “Sink-A-100-01” and “Sink-A-100-02." 

This is poor practice because separate data fields are being combined into one field.  If the room a component is in changes (either because it is moved or the room number is changed) the component will have to be renamed. The same if other data used changes, like the System it is a part of, manufacturer, supplier, authoring company, etc.

The example above can be avoided by users, but COBie itself has examples built in. Doors and windows are required to have the rooms on either side, separated by a comma, in one field, e.g. [G.03,G.04]. Although this data can be created programmatically by combining two fields, it then has to be either programmatically separated by the FM database on input, or the database has to do a complicated text field search to find which doors are in which rooms.


Every component in a COBie output is identified with the author and supplier. Supplier I can understand, but I'm not so sure author ("createdBy") will end up being very reliable in practice. As it is a required field it is likely the BIM author of the component will be initially listed as author. But they may not have provided all information, or indeed any of the critical information. And they are unlikely to be the ones responsible for verification. If the author is not changed at later stages it is likely the draftperson or component authoring company who created the BIM component will end up as the contact.
Another quirk is that the mandated method to identify is via an email address. Email addresses are generally for individuals. To identify one person from an organization for information that is expected to be current for years to come is in my view a bit silly.

More concerning is there still seems to be some issues "under the hood" that those trying to create products for COBie are struggling with. See this example on the COBie linkedin discussion group.

Is COBie still Beta?

Does all this mean COBie is immature, not ready for business use?
To be fair COBie is an open source initiative, it is not a product being developed for a specific sales launch date. As long as there are interested people it will continue to develop and change.
Interestingly Bill East of the USACE, COBie's guru, believes COBie has moved from concerns with development to concerns about use:

" Those who just want it to work (mainstream users) are now engaging on the early side of the adoption curve regarding getting answers to issues directly relevant to daily practice. This new constituency brings its own questions and concerns..." [link]

So although COBie is not fully developed I believe it is beyond beta. It is now in the realm of user testing. I just hope the COBie team are still open to making changes, not just to tackle user issues but also to improve the way COBie interacts with software. Just offering to test software is not enough (like the COBie challenge, discussed below), it should be a two way street.

When COBie is a Deliverable

There are organizations that request COBie, define what they want, and use it to populate their FM system. The USACE and University of Southern California are two examples.

But I've been involved in a few projects now where the owners have demanded a COBie deliverable without defining what that is. They just ask for a "COBie file at completion of schematic design, design development and construction documentation" (I'm an architect, presumably they made similar requests to others for later stages) . They say nothing about what they want in that "COBie file". In an attempt to get a bit more information we asked what they they intend to do with the "COBie file". A lot of talk about the need for open standards but they don't have a specific use in mind. It seems they believe that by using an open standard they can avoid making decisions.

Now this situation can be a blessing in disguise. You get the opportunity to decide what you deliver. As Bill East himself says:

"If the owner doesn't specify up front, then you get to do what you want. My recommendation, however, is that the COBie Guide be followed even if the owner has not provided their own Appendix A. If the COBie file provided by the designer does not contain the identified attributes (or if the designer did not provide a COBie file at all) then I would also provide the minimum attributes for COBie.Types as would be required for existing contract's paper deliverables." [link]

But only if you define what you will provide. A generic COBie deliverable that is not defined by some-one, anyone, is dangerous. For all I know we are the only ones required to provide COBie and the owner is expecting us to include all services and constructed information, not just architectural information.
The COBie web site gives some guidance, but the bottom line is that COBie is only a format, so if an owner asks for COBie it is reasonable to assume they mean provide what you would normally provide on paper (or digitally) in a COBie format.

Who provides COBie and When?

COBie covers all information required to operate a building. From room names to purchase date of equipment. This information obviously comes from a variety of sources. Therefore there will be a range of people involved in providing information. Whether each has to provide it in COBie format is a matter for their individual contractual agreements. Certainly the bulk of information is provided by the services sub-contractors, but design professionals need to set up the structure for this information. Spaces, Zones and Systems must be set up before equipment can be added.

As COBie is for facility management you would think it only needs to be delivered at the end of construction. But COBie defines 5 different stages, from Early Design Stage to System Commissioning Stage, with COBie deliverables expected at each stage.

Whilst in theory COBie could just be delivered at the end of construction, it is not considered best practice.
Firstly those involved early in the project (architects, engineers) may not be around at the end. So if their contribution hasn't been captured some-one else is going to have to put it in. You might think this is preferable, because by the end everything is known, whilst earlier on there are a lot of unknowns. But remember the aim of COBie is to avoid re-entry of data, to use information already captured.
Secondly time is important. If an FM system is not up and running when a building opens, data captured during construction gets further out of date every day it remains outside the FM system. Even if, several months after sending construction documents to India to get turned into COBie, it is 90% correct, that 90% will still need to be verified, manually, on site.
A third reason is to practice. Each project is different, with different participants, and COBie itself is not bullet proof. Doing multiple COBie exports before the final deliverable gives everyone a chance to get it right. So there is some certainty the FM system will be up and running on day one.

Are COBie Deliverables Free?

As I mentioned above, the idea of COBie is to capture data that already exists. If that is the case shouldn't it be free - at no extra cost?
After all it is just the same information in a different format. Like providing a book in a different language, and translation is free isn't it?.
As ridiculous as this sounds there are plenty of people who subscribe to this view and fall for it. From developers offering free COBie to potential buyers to architects and services sub-contractors allowing it to be added to their services for no extra charge.

My response is to offer our Revit model. If we are not being paid for it because there is no cost involved, why can't the owner (or contractor) create their own COBie? If they claim they don't have the expertise then they need to pay some-one who does, just like we have to. COBie is not an area of expertise of AEC professionals, and nor should it be.

So if you are ever required to provide a COBie deliverable make sure you cost it. You may decide to throw it in to get the job, but don't think you can just load it on to the team delivering the project. It takes time and expertise, factor that in.

And if you are in a position to request COBie, only do it if you are actually going to use it. Don't ask for it because you might have an unknown  use for it some time in the future. As I said above, if the FM system is not up and running from day one all that COBie data is next to useless.

Should COBie always be Required?

COBie is one method for providing construction information for Facilities Management. It is not the only method, and not necessarily the best. Its purpose is to be vendor agnostic, the one you use when you don't know where the information will end up.
But what if you do know? Does it make sense to force construction data into a COBie format, then the FM system extract that data from COBie. Wouldn't it be simpler to just provide the data from construction in a format the FM system understands? Particularly if that FM systems talks directly to your BIM authoring software.
More and more FM systems are utilizing BIM information to populate their data, and the Internet to allow multiple people to provide data in a managed way. For example Veo by M-Six.
To be honest, sending around excel spreadsheets to be filled in sounds so 1990s (although to be fair, COBie doesn't have to work that way. See Ecodomus below).
`
So, no, COBie should not always be required. Ideally an owner would know what FM system they will be using and deliverables for that system are tailored to suit it. And the extra work is identifiable and compensated for.

But be careful what you wish for. The ultimate aim of COBie is to be THE way construction information is delivered for Facilities Management. That means the AEC industry learns one system, not multiple proprietary systems. Even if COBie might be a bit more difficult to use at the moment, that scenario sounds better to me.

The Future of COBie

COBie sounds like a good idea. A standardized way to deliver information, in a format based on a broad standard (IFC), using easily accessible and understood technology (spreadsheets).

But when I look at how COBie works something doesn't seem quite right. At first I thought what perturbs me is that COBie is based on trying to automate, or make more efficient, an old fashioned paper based system. Rather than starting from the idea that data is already in electronic format and just needs to be "exchanged" into another format, it starts with the idea that most information is on bits of paper. So its paradigm is based on organizing those bits of paper in a way that is familiar with how people do it now.
I still suspect there is a little of this but it is certainly not the intention of COBie. As Bill East himself says:

"Generally, direct use of spreadsheets is -not- recommended, except as last resort. Use of over 20 COTS ( Commercially available Off The Shelf ) products that allow COBie data to be created/updated/exchanged without anyone using the data file directly is recommended." 

So I ask - why is it so difficult? Authoring softwares seem to have to go through the hoop to output COBie compliant data. Even though Revit did pretty well compared to other authoring softwares in the BuildingSMARTalliance COBie challenge, (see below for more detail) a substantial 'toolkit' was required, that apparently is so complicated AutoDesk haven't released it for general use.
Yet FM softwares appear to have no problems. Of the 5 who participated in the challenge for COBie handover all achieved it with no errors.

To me it seems a bit lop sided. The creators of the information are being forced to structure their data to suit FM, without a thought to how FM could manipulate available data to suit their purposes. Which is surely fairer. After all it is FM who gain all the benefit, not the authors.

But this is not a comment on the usefulness of COBie itself. As I said it is a good idea. But by loading the effort onto those that don't benefit I wonder if it well ever gain traction.
Once BIM authors are awake to the extra effort involved they will all demand payment. And in the construction industry where costs are constantly trimmed I can see COBie being value managed out of most projects, particularly if there are commercial alternatives that are easier (and therefore more cost efficient) to use.
Surely a more sustainable approach is not to rely on government mandates, but to utilise market forces. Establish what construction information can be extracted easily, and the methods that the beneficiaries of that data might use manipulate that data. A good start would be to remove requirements that do not already exist in the construction process. For example, why does the construction team have to generate a unique names? Can't the FM system do that once it has the data?

As an open source project COBie could, in theory, change. But only if it takes seriously the difficulties facing BIM authors. Rather than just attacking commercial BIM authoring softwares for not 'supporting' open source, and accusing AEC professionals of not 'collaborating'.

Making COBie Practical

COBie is real and there is every chance you will one day be asked to be involved in a COBie process. What are the best ways of approaching COBie demands?

Define what a COBie deliverable contains

Whether you are an owner mandating COBie or a draftperson on the tools, you need to know what is to be delivered. If you can't find out make it up yourself and share it around. If no-one else puts their hand up you have at least got a fall-back position.

Use software that makes it easier.

Not all software are equal at exporting data to COBie. BuildingSMART runs regular "COBie challenges" open to any software vendor. In January this year they held a challenge for model authoring software. Autodesk Revit, Graphisoft ArchiCAD and Bentley AECOsimBuilding participated. Success was measured in how long it would take to manually fix or add information the softwares mismatched. The results were:

• 503 minutes (8.4 hours)    -  ArchiCAD 
• 218 minutes (3.6 hours)    -  AECOsimBuilding
•     9 minutes (0.15 hours)  -  Revit

I'm not suggesting anyone completely change the software they are using just to make COBie easier, but be aware how much effort (and therefore cost) it takes will depend on the software you use. Just because your software is better at IFC doesn't mean it is better at COBie.

There are also alternatives to a raw spreadsheet (e.g. Excel) format. An example is Ecodomus, a web based service that has free COBie functionality. They have an add-in for Revit that uploads data to their web site. The data can then be edited and/or added to by anyone with Internet access, and finally exported as a COBie compliant spreadsheet. Some owners, such as University of Southern California allow Ecodomus as a delivery method for COBie data.

There are also COBie utilities that are useful. Onuma provides a free COBie2 validation service.

BuildingSMART provide a list of softwares on their web site, although I don't know how up to date they keep it.

COBie deliverables are relatively new so I expect there will be more such softwares that take some of the pain out of it. When you are at the point of having to make a decision I suggest you check to see what is available. It may end up saving you a lot of time.

Structure it to suit the way you work.

COBie is supposed to capture data that already exists. It should NOT interfere with the production of other deliverables, like construction documentation. Resist calls to change the way you structure your BIM model just to suit what some-one thinks is required for COBie.

I have been requested, and seen examples of it happening to others, to rename all our Revit families (components) to suit what the contractor thinks is required for COBie. They are trying to comply with the "everything must have a unique name" requirements. They think that means the name used in the authoring software. But to COBie it is just a data field, it doesn't matter where it comes from. If they want their own name for things create a parameter for it (you can in Revit, I don't know about other softwares), and direct that parameter to the COBie name field on export.
The same goes for room numbers and names. If they want to use a different numbering system create a room parameter to hold the COBie space number. There is no technical reason that the Revit (or other software) room number has to match the COBie space number.

As I've said above the requirement for a unique, human readable component name is a COBie quirk, it is not needed for BIM authoring or FM softwares. The best way to create this name is to use data you already have. You shouldn't need to manually create names just to suit COBie. In Revit you can use Family, Type and Mark. Not only is it unique, but should be human readable if you have good Revit standards in place. You could also use the schedule code you are using for documentation, although this may not be human understandable nor unique. Remember the name has to be unique across all disciplines over the whole project.

Try keep as much data creation as possible within your authoring software. Although it is possible to do tricks in excel to manipulate data to suit COBie it adds another task and another possibility of error. That said, it may not be practical. The two rooms in one field problem I spoke of above is solved by the Revit 2013 COBie toolkit in excel, not in Revit.

Pick an easy to use Classification System

If your client doesn't proscribe a classification system, and you don't need a particular one for your own processes, minimise the effort where you can by using the easiest one at hand. Some BIM authoring softwares have classification codes built in. For example Revit has Uniformat (a sub-set of Omniclass) for all objects and Omniclass for components (family files). Mind you it still involves work. When you create a new wall type you still have to select the appropriate Uniformat code, Revit just makes it easier by only listing codes relevant to walls.
A word of warning - if you do decide to select which classification system to use make sure you communicate this to your client. You don't want to have to re-enter it all again later (not for free anyway) when they finally decide what they are doing.

Workflows & Responsibility

Providing COBie is more than just a single software export. The total COBie deliverable is provided by a range of people. And what you provide may depend on what others have provided. This all means there is a workflow involved. You may not be in charge of the workflow, but you need to be aware of what it is and where you fit in. Otherwise you may find yourself adding data to an outdated COBie spreadsheet and have to do it all over again.
And be clear about what you will be contributing. Authors of BIM models are often pressured into including information they are not responsible for just because everyone else perceives it is easier for them to do it. The mechanical engineer shouldn't be putting in product information if supply is performance based. The mechanical sub-contractor should do it, or the mechanical engineer should be paid to do it.

Set aside Time

COBie is not just going to fall out of your BIM model. It will take time to set it up, test it, and then do the export and validate it. Keep in mind it will take a lot less time if you use some-one who knows what they are doing.
Ideally it should be programmed to avoid other deliverables. It is silly to expect COBie to be delivered on the same day as a milestone document issue. They are required for different purposes so why increase the stress levels of everyone?

COBie Resources

Official COBie web site:
http://www.nibs.org/?page=bsa_cobie

Bill East's article at WBDG:
http://www.wbdg.org/resources/cobie.php

COBie UK 2012:
http://www.bimtaskgroup.org/cobie/

UK NBS on COBie:
http://www.thenbs.com/topics/BIM/articles/whatIsCOBie.asp

Youtube lessons:
http://www.youtube.com/results?search_query=COBie-Class


Linkedin discussion group for COBie:
http://www.linkedin.com/groups?gid=2638637.
 It is moderated by Bill East, the COBie man so is the best place to ask questions.


COBie software and toolkits:
Autodesk Revit COBie toolkits.
For Revit versions 2011 upwards.

Ecodomus
Free COBie Revit add-in that links to Ecodomus web app.

Solibri
Solibri model checker has an extensions package for COBie.

Onuma COBie Validator
Free on line COBie 2 validator.

2013-01-10-UsingGoogleDocsForCOBie.pdf
Description of how to use Google Docs (now called Google Drive) spreadsheets for COBie. Using Google Drive means you effectively have a free web service accessible by multiple parties.

buildingSMART alliance information exchanges: Means and Methods
buildingSMART alliance suggestions.


Revit and COBie:
For some more comprehensive information on Revit and COBie have a look at Brian Renehan's post on his BIM Fix blog about COBie and Autodesk Revit

Bored with BIM? Need a present for that special woman in your life? The Lost Woman series follows the adventures of Christina as she makes her way through a world of design, fashion and ... men. Book one of the series, "Awakening the lost woman", is available now on Amazon,  Google Books,  Kobo  and  iBooks.

IFC, What is it good for?

"IFC, good God, y'all
What is it good for?
Absolutely nothing, say it, say it, say it
Oh IFC, is an enemy to all mankind
The thought of IFC blows my mind
IFC has caused unrest within the AEC community
Frustration, then dissatisfaction, who wants to fail?"

with apologies to EDWIN STARR


Looking through blog posts and discussion groups there seems to be a lot of dissatisfaction with IFC. Some samples:

"It can (if done properly) be used for a static as-built record Information, but even when used for this purpose validation of the data is critical."

"Data Loss IFC has a horrible habit of losing information or dropping data when exporting from its native format."

" IFC is that it doesn't currently support all the clever time saving parametric stuff that we expect from BIM components these days. IFC is all about the geometry and data and upon export it normally dumbs it down to just that."

" The biggest barrier in my opinion is that no matter how good IFC becomes, it will never be as good or have the functionality as the native BIM package it was created in. "

"It annoys me when I see new BIM users (most of the time without software experience) shouting about how we must all adopt IFC & openBIM now-today, because on the outside it looks like a perfect solution, when in fact its actually a load of work arounds."


So what is going on? We keep getting lectured by BIM evanglists about how wonderful IFC is. These same evanglists are busily lobbying governments and large corporations to mandate IFC deliverables. There seems to be a lot of claims about what IFC can do, but little on what it can't do. I don't put myself forward as an expert on IFC and welcome comments that prove me wrong, but I thought I would share my investigation into IFC.

WHAT IS IFC

I won't go into a lot of detail of what IFC is, but paraphrased from wikipedia:
"IFC is an object-based file format with a data model developed by buildingSMART to facilitate interoperability in the architecture, engineering and construction (AEC) industry, and is a commonly used format for BIM. The IFC model specification is open source and is an official International Standard ISO 16739:2013.
For more information look at the buildingSMART web site, and as an example of their view of what Revit users need to know.

PROBLEMS WITH IFC

EXCHANGE FORMAT DOES NOT EQUAL OPEN FORMAT

One of the things many people don't seem to appreciate is that IFC (and by extension COBie) is an exchange format. It is not a common format, like open source formats (DOCX, JPEG, XVID, etc.), or common proprietary formats (DWG, PDF etc.)
IFC is designed to be a format that only exchanges data between other formats. When you import IFC into a software it gets converted into that software's format.
Software that can open IFC files directly are IFC viewers, they can't actually edit the IFC file.

It is a good idea, an agnostic data format.
But what it means is that there are two points of possible error creation - when the IFC is exported, and when it is imported.
With common formats there is only one - at import when using the software's format, or at export when using different software.
So although an exchange format like IFC may be theoretically more efficient across an industry, in practical terms for individuals it is not. To get a specific result it is easier (and quicker) to write one set of code in one software than to write two sets of code in two separate softwares.

FUNCTIONALITY

IFC doesn't seem to capture all the functionality of BIM authoring softwares. For example it contains size dimensions, but doesn't know which geometric entities these dimensions control. So it can't transfer working parametric objects.
Effectively an IFC import creates static objects, no longer editable.
This behaviour perpetuates problems that BIM is supposed to overcome. If size parameters are exchanged and are editable, but the geometry doesn't change with those edits, there is potential for situations where the scheduled size of equipment doesn't match its geometric size. Which makes spatial planning and clash detection unreliable.

BUILDINGS ONLY, NOT COMPONENTS

Although you can create an IFC file of a building that contains components, you can't create an IFC file of only one component. The file is effectively a building with one component in it.
I find this surprising. You would think an open format for distributing components would be high on the priority list.
There are a number of initiatives to create BIM component standards, like the UK NBS National BIM Library. But they have had to include Revit files due to the lack of functionality of IFC files.
That said, it should be entirely possible for a component IFC file schema to be created, and I believe buildingSMART is looking at this. See this presentation.
But currently IFC is not a suitable format for components.

ARCHIVAL QUALITY

IFC is pushed as an archival format. The argument being that the constant upgrades to proprietary software formats means any files retained now will be unreadable in the future. Whilst IFC, being a published standard, will always be readable.
But as explained above IFC is not a software format. It is an exchange format that requires other softwares to create and read it. Therefore it relies on proprietary softwares to maintain the ability to read older IFC formats. Which seems to me no different from relying on those proprietary softwares to maintain the ability to read their own formats. One could argue it is more likely they will do this for their own format than for an external format they derive no income from.
There is a mitigating factor though, the fact that IFC rarely gets updated means proprietary softwares don't have very many versions of IFC converters to maintain.
But the fact remains the problems of archival storage of digital data are NOT solved by using IFC.

AS-BUILT and FUTURE WORKS

IFC is pretty much useless for As-Built BIM that will be used as a resource for future changes to a building. As an exchange format IFC can't be directly edited. And most data that handles the original authoring software functionality has been lost in the exchange. So at best IFC can only be used as a static background in an authoring software with editing capability restricted to deleting parts.
Even if you import this static model there is the problem of loss of fidelity when an IFC file is imported into an authoring software. Without painstakingly checking every element it is not known whether everything from the IFC model has been replicated.
Then once the changes have been made in the authoring software, the export back to IFC is also problematic. If only part of the building has been changed how do you integrate that into the original IFC model?  If the whole building is exported back replacing the original IFC model how do you deal with the time lag that means differences in data content, or the problems that arise if the IFC model is linked to a third party database.

COMPLEXITY

I have looked through the IFC and COBie descriptions, and I'm sure if I tried really hard I could understand it. But I don't want to try, I've got more important things to learn that are actually relevant to my area of expertise. I'm an architect, not a computer programmer. I'm sure most people in the AEC industry feel the same way.
Just look at what IFC stands for - Industry Foundation Classes. What does that even mean? (when I talk about IFC to a project team they ALWAYS get confused and think IFC is "Issued for Construction").
Does this really matter? IFC is a software standard, not a human process standard. In theory us users should be shielded from the inner workings of IFC by the software we use. But the reality is we end up having to delve into IFC because the softwares don't provide what is required for us to do our work. We are also getting owners with specific IFC deliverables, that describe these deliverables in IFC terms.

DOES IFC ACTUALLY WORK IN THE REAL WORLD

This issue is one I can't answer because I am not a computer programmer. All I can go on is what I read in discussions and blogs by people who know a lot more than I do. And I have to say what I have read is concerning, some of the issues seeming to be rather fundamental.
It seems some that have tried to use IFC are, if not exactly giving up, accepting IFC limitations.
Jon Mirtschin at GeometryGym has been using IFC as an exchange method to transfer data generated in Rhino by Grasshopper to BIM authoring softwares. I saw him speak at an IFC 4 launch, and what he does is amazing, and he is a strong IFC supporter. But he admitted he was having problems with IFC and has started to write code to import directly into Revit to overcome them. It seems you can only go so far with IFC.
On another front Bentley have announced they are developing an "RFA interpreter" that can import rfa files (Revit's component file format) into their BIM product.

But even given IFC's problems, and despite my scepticism, IFC is actually being used around the world.

WHAT IS IFC USEFUL FOR?

Lets not throw out the baby with the bathwater. Underneath the practical limitations there is a fundamentally good idea. The fact is it is not, and never will be, the panacea it is claimed to be. But IFC must be useful for something.

ANALYSIS

Generally a BIM model used for analysis purposes doesn't require the whole model. Structural analysis only requires the structural components, thermal analysis only requires spaces, zones and envelope data. Some analysis software only requires parts of a building, or does the analysis one part at a time (e.g. floor by floor). Because IFC is an open format receivers of IFC files can break up them up without requiring the authoring software. Their analysis software may do it, or it can be done manually with third party software like simpleBIM at datacubist.com.
As IFC is usually simpler than the format of the authoring software so analysis softwares require less code to get the information they require, and it is easier for them to manipulate that data before importing it. This issue is becoming more important as cloud computing is taken up for analysis.
If all an analysis software does is the analysis then a static model like IFC is sufficient, but if you want to modify the model based on the results of the analysis IFC won't work for you.

So if you want to provide your model to some-one else for them to do an analysis IFC is a good idea, but if you want to do an analysis yourself that will result in changes to your model your authoring software is better.

FACILITIES MANAGEMENT

A Facilities Management system does not need the ability to easily modify a building's geometry. The geometry is mainly there as a navigation tool for the data the system holds. In fact you don't want people to accidentally move fixed elements  around (which can happen in authoring softwares).
You also don't want an unnecessarily complex file format that can do more than you need.
So using IFC for FM makes sense. It is a simple format that has its geometry locked down. It also makes sense, in theory, for FM software houses to utilise IFC as they can then import data from multiple sources. I say in theory because they then become victim to the quality of IFC those sources create.
Of course if you need to make changes to the building's geometry, like add a door or change a wall, you will need to do that with a different software and try and integrate that change back into your IFC model. I'm not aware of a way to do this, but I suggest you make sure you have a robust, tested, process before committing to a reliance on IFC for FM.  

COORDINATION

Current specialized clash detection software work by importing static models. They don't attempt, or have the capability to, alter imported geometry. Therefore IFC is a prime candidate for these types of software.
The ideal situation would be to have the ability to alter model geometry to over come clashes whilst doing the clash detection. But currently authoring softwares are not good enough at clash detection to make this practical. And then there is the issue of who makes the changes. Should the BIM Manager, who is not a structural engineer, have the ability to make changes to the structural model?

So at present, until authoring software improves and the responsibility problems are resolved, IFC is fine for clash detection and coordination.

WHAT IS IFC NOT USEFUL FOR

AS-BUILT FOR FUTURE WORK

IFC is not an authoring software format and in its current form is too limited to be really useful for making changes to an existing building.
However the pain associated with dealing with IFC could be alleviated by careful construction of the IFC model. For example by breaking it down into linked sub-models. If it is contemplated that IFC be used for As-built, as a minimum the process for updating building geometry should be established before hand-over to FM.

EXCHANGES BETWEEN AUTHORING SOFTWARES

IFC's inability the keep the data authoring softwares rely on to make them useful means IFC is a bad choice for model exchange. If all you require is a static background IFC may be usable, but only if you are confident all objects survive the double transfer - firstly from the originating software and secondly into the receiving software.
The other problem is even if you get the IFC into your authoring software the control you have over it (visibility, display, data content) may be limited.

COMPONENTS

IFC simply doesn't have the ability to contain the parametric properties we expect from BIM components. Maybe one day it will, but for now don't waste your time.

SHOULD IFC BE SUPPORTED?

When ever I bring up the shortcomings of IFC in public I get berated for not getting involved. It is open source, they say, anyone can contribute they say. But I'm an architect, I don't have the expertise to solve any of these problems. My contribution is limited to bringing up the short-comings of IFC. And I don't see how bringing up these issues in a closed forum could possibly be more effective than doing it publicly.

But should we practitioners support IFC? I believe we should. It is fundamentally a good idea.
Certainly volunteer to buildingSMART if you think you can contribute directly.
But if you want to contribute some of your time for free, my view is the most effective thing you can do is give IFC a try. Test it out, experiment with it.

And share you experiences. If things don't work bitch and complain, if they do heap praise on it.

IFC RESOURCES

IFC DISCUSSION
Linkedin:
http://www.linkedin.com/groups/Industry-Foundation-Classes-IFC-3690870

IFC VIEWERS
Solbri:
viewer: http://www.solibri.com.au/other-products/solibri-model-viewer
optimizer: http://www.solibri.com.au/other-products/solibri-ifc-optimizer
Tekla:
http://www.teklabimsight.com/downloads.jsp
List of IFC software:
http://www.ifcwiki.org/index.php/Free_Software

IFC / REVIT
Open source Revit to IFC Exporter:
http://sourceforge.net/projects/ifcexporter/files/

IFC to Revit importers (both are optimized for services and/or structure):
GeometryGym: http://geometrygym.wikidot.com/downloads
ArchiCAD: http://www.graphisoft.com/downloads/interoperability.html

Tekla (optimized for structure):
http://www.tekla.com/international/solutions/building-construction/Pages/export-revit-tekla-structures.aspx

IFC SOFTWARE
Software like simpleBIM (http://datacubist.com) can clean up IFC files.

EXAMPLES OF IFC USE:
Geometry Gym:
http://geometrygym.blogspot.com.au
http://geometrygym.wikidot.com

NBS [UK] Revit Plug-in:
http://www.thenbs.com/products/nbsplugins/index.asp

Bored with BIM? Need a present for that special woman in your life? The Lost Woman series follows the adventures of Christina as she makes her way through a world of design, architecture and ... men. Book one of the series, "Awakening the lost woman", is available now on Amazon,  Google Books,  Kobo  and  iBooks.

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.

BIM for free

l thought BIM meant others could make use of the BIM data each of us created for our own purposes. Now it seems to mean others telling us what BIM we have to do to suit their purposes. When did this happen?

 
When I first starting pushing BIM one of the arguments was that besides the productivity and QA benefits others could make use of the data we put in as part of our normal processes. A benefit at no cost I argued.
But now I have trouble convincing people to take up BIM because they fear clients will start asking for extra services, expecting it for free. 
This attitude is not surprising when looking through current BIM guides and example contracts. The owner is expected to make BIM demands & deliverables.

Why not have a system where BIM data that will be produced is made explicit by each participant and everyone, not just the owner, offered it 'as is' for their own purposes?
If this is done as part of the selection process those with the best BIM capabilities will float to the top. They may even get better fees.

A by-product of this approach would reduce the importance of single Project BIM Execution Plans and "BIM Managers". Each participant does their own BIM plan setting out what they do and don't do. They refer to each other's BIM plan to see what they will get and therefore what they have available to work with. Then each can negotiate with others to change what is being provided to come to mutually beneficial arrangements. 

Surely this is a better approach to encouraging BIM take up than dictatorial demands that creates resentment rather than enthusiasm. 

HOW?

But for this to happen authors (typically Architects and engineers) need to be clear about what BIM they will produce, and just as importantly what BIM they will not be producing.

And consumers of BIM (typically contractors and facility managers) need to be clear what they require to use BIM in their processes. They need an idea of the minimum they require, and the cost/benefits of "nice to have" extras.

I am constantly surprised at how rarely this happens. Design consultants marketing the benefits of BIM without specifying what they will actually provide, owners asking for BIM without even knowing what FM system the BIM data will be used for. And then there are the contractors who say we're not using BIM at all if it costs any extra, no matter what the overall project cost saving might be.

On the face of it the contractors appear to be the only honest ones. But they are throwing the baby out with the bathwater. You can get BIM for no cost.

If the design team use proper BIM software, the way it was designed to be used, useful BIM deliverables can be extracted.

There are some limitations. Information is limited to that required by the author to inform how their part of the building is to be built; design intent by the consultant team, fabrication by sub-contractors.

The other limitation is it may not be delivered in the BIM format required for down stream use.

Even with these limitation there are quantifiable benefits in using this BIM data. There may be extra costs collating this data into a usable form, and converting it into the required format. But like every other part of the construction process I would expect a cost / benefit analysis to inform what is worth doing and what is not worth doing. 

So why aren't we concentrating on how available BIM data can be used, rather than fantasizing about the missing BIM data and how it could be used?

Using BIM to Shirk Responsibility

In the BIM evangelist's ideal BIM workflow, where does responsibility lie, and how it is defined? And what does the term "collaboration" actually mean in a BIM context?
I've explored collaboration before (Real Collaboration - Working with Engineers), but it is bandied about so much it deserves more thought.

As BIM workflows are taken up this issue of responsibility is a sleeping dragon. IPD is put forward as a solution, but all that really does is take the problem out of the court room into a board room, where not all players are equal (see my post Integrated Project Delivery: Bad News for Architects?).

But am I being alarmist? Is it really going to be a problem? The test is what happens in the real world - let me tell you a story . . .

You want me to do what?

There is a project, a Design & Construct (D & C) project. The first contract is for the piles that hold the building up. The piling D & C contractor has to design and build the piles (even though the project has a consultant structural engineer). Let's be clear - they are responsible for the size, location and number of piles.

The architects notionally draw the piles in their model to recognise their existence. The structural engineer puts them in their drawings with spacings and locations, based on their designed structure; where they think they should go.

The architects were asked by the head contractor to set out and dimension the piles. The project architect didn't want to do it, the structural engineer said the architect shouldn't do it, but the director in charge wanted to keep the head contractor happy.

As the contractor provided no information it was done based on the structural engineer's drawings. They were using CAD, the architects were using Revit. The architects inspected the structural engineers CAD drawing and there were some dodgy dimensions - dimension text that didn't match the measured distances. So the CAD file was ignored and the piles set out based on notes and dimensions in the CAD drawings.

The architects issued their drawing, as a CAD file, to the head contractor. A little while later they got a call from the site foreman. Why didn't their CAD file match the structural engineer's CAD file? There was one extra pile in one location, one less in another. On investigation it was found the structural engineer's note - max. 1800mm centres - was followed, but their CAD file had the piles spaced greater than that, 1823mm. In another spot they showed 3 piles with dimensions that had been faked. When the piles were laid out using these dimensions they were very close together, much closer than 1800mm, so one pile was left out. The architect who did the modelling followed the structural engineer's drawing to the letter.

When the project architect went through it with the structural engineer, they said 1823mm is fine, and that yes, they did intend to have 3 piles very close together.

Now THEY can make that call, structure is their area of expertise and their responsibility. But all the architect can do is follow their drawing, or risk a negligence suit for wilfully overriding the advice of the appropriate expert.

ISSUE NO. 1

If you get someone to draw up the work of some one else they don't understand what they are drawing.

In BIM terms, if you expect some one other than those with the expertise to model or enter data you are likely to get incorrect or at best sub-optimal results.

But wait, there's more . . .

The head contractor has a surveyor on site. The architect was issued a survey drawing that supposedly showed the as-built location of the piles. It was a CAD file. But the piles shown matched their earlier CAD file, the incorrect one.
Did the contractor build off the incorrect CAD file or is the surveyor passing off the architect's CAD file for something they have measured on site?
As the site foreman made the architects change their drawing I suspect the latter (I haven't heard if they ever found out).

ISSUE NO. 2

Using the work of others and passing it off as your own.

Whilst I don't get too upset about others using my efforts to line their pockets, I do have a concern about accuracy and responsibility. When using the work of others it is far too easy to not bother to check that it is correct for your purposes. There is a tendency to blame others; the contractor didn't follow the drawings, the architect drew it wrong.


And if the incorrect CAD file was used by piling contractor to build off why were they using the architect's CAD file to build from? As a D & C contractor shouldn't they have produced their own set-out drawing? It would have been easy to do, they had CAD files both from the architect and the structural engineer.

ISSUE NO. 3

Using the work of others to shirk responsibility.

By not producing drawings under their title block there is no evidence the piling contractor made any mistakes in the design of their set-out. The only evidence is the architect's and the structural engineer's drawings. But these two parties were not responsible for the piling design. The contractor has effectively shifted their responsibility to others.


So what you say, sounds like a normal day at the office. It all about human error, nothing to do with BIM.
But it is always about human error, that's why we have contracts, a legal system and technologies like BIM, to ameliorate our human foibles. And one of our human foibles is to shift future blame (i.e. responsibility) on to others where we can.

Contractors are "killing it"

But is this story typical? What led me to write this post is a comment I read from another blog - Epic BIM. It was about another topic, the comment was put forward as an example of contractors keeping solvent by leveraging BIM. It was the way they did it that caught my attention:

" I had to work on a way to shrink my contingency. I quickly learned that I could take the CAD drawings and load them up into a data collector, which allowed us to lay out in the field 100 times faster than I had been doing, plus much more accurate. This lead into better scheduling of my equipment on site. Those two things alone made such an impact on the margins that it became a 'no turning back' point for the entire company. All this, allowed me to roll this up in my next bids, where I was killing it. "

So they are "killing it" because they are taking the work of others - their CAD files - and using them directly do their work.

Engineers must feel the pain. They are now being required to do what they previously didn't - model accurately (see my post Should Engineers model accurately?), but it is others who are reaping the profits.
Architects are used to it. Getting their own drawings back as shop drawings with the only difference being a new title block is not uncommon.

I'm not being critical of contractors earning more money by being innovative, my concern is who is perceived to be responsible. If a piece of ceiling falls and kills someone because the CAD file was missing some hanging points who is at fault? The CAD file was "incorrect", but the author of that file was not responsible for adequately supporting the ceiling, the contractor was.
What is going to happen in court? I don't know about the rest of the world, but here in Australia the legal fraternity, like most lay people, is quite ignorant of the complexity of building practice and the division of expertise and responsibility.

As I see it, the only protection we can utilize is the "use at own risk" clauses we use when issuing CAD and BIM files. Although I don't know if they will actually help when someone's life or large amounts of money are involved.

The alternative is to take responsibility for everything and associated risk and try and get paid for it.

ISSUE NO. 4

It is unreasonable to expect one party to take responsibility for, and therefore be expert in, everything.

If the producers of BIM models take on the responsibility of the completeness, accuracy and appropriateness of their model for any future purpose they will need to be experts in absolutely everything.



It is why we have professionals, who have Professional Indemnity Insurance. Expertise is split between architect, engineers, surveyors etc., and if they make a blunder they can be sued for the damage they caused. How does this work in a BIM workflow, where everyone works "collaboratively"?

The problem is "collaboration" is poorly defined, which is an invitation for everyone to have their own definition of what it means.  I've sat in a BIM Execution Planning meeting where the Quantity Surveyor thought "collaboration" meant we, the architects, would put their costing codes into our model so they could use our model for their estimates.

A definition of "collaboration" I like is "sharing". We will freely share our data with the rest of the project team. But only on an "use at own risk" basis. Our work is suitable for defining the architectural (or engineering) design intent, nothing else. Everyone who uses our data must satisfy themselves it is suitable for their purposes, end of story.

Unless data is shared on this basis it is too risky to do so. It shuts down "collaboration". I don't see how forcing collaboration through contracts without this protection will work.
Yet I see commentators making light of this concern by invoking the "BIM must be mandated to succeed" and that it will all be fixed "once we get BIM contracts" mantras.
And in any case why are we not questioning the assumption that collaboration can only be achieved via compulsion, and not through enticement? Seems a very "anti-collaboration" approach.

Another misguided approach is to insist that a BIM Execution Plan will magically solve it without detailing how. It doesn't matter if the BIM Execution Plan says the model must "be suitable for", say FM or 4D or 5D. The reality is that architects and engineers don't have expertise in these areas, so how can they possibly deliver what is required, let alone expected?

The bottom line is no one should accept enforced collaboration through BIM contracts without safeguards to their risk and responsibilities.
Until someone comes up with a viable alternative I continue to recommend everything be issued as "use at own risk", no matter what the contract says.

Another reminder for this year's RTC Australasia conference in Auckland 16th to 18th May, where I'm presenting "BIM Execution Plans: Avoiding the Noose".