23 February 2015

Define your BIM Services

More and more architects and engineers are finding BIM deliverables appearing in their engagement agreements.

There seems to be an attitude amongst owners and contractors that authors of BIM models should provide everything that BIM can do. They think that architects and engineers are already putting information in so why can't they put their information in as well? For FREE.

A view based (touted by some BIM evangelists) on the idea that the those creating BIM information for their own purposes are best placed to create everyone else's BIM information.


Here are some examples of demands put to architects.
Let's start with an all encompassing clause:
"The consultant's costs for such participation shall be deemed to be included in their PSA fee unless explicitly excluded and agreed in writing."
From a contractor:
"Export from the model to Excel all items that appear on drawing schedules or specifications with identification marks to track against delivery dockets."
"Provide, in CSV, a file that contains the X, Y, Z coordinates to use in electronic survey equipment. (all corners or centerlines if circle penetration) etc."
"Ensure all modelling processes follow actual construction methodology."
From an owner:
"Include following parameters in all Revit models:
  • ReplacementCost: - numerical value representing cost to replace the product in Australian Dollar (AU$)
  • AnnualMaintenanceCost: - numerical value representing cost to maintain the component per year in Australian Dollars (AU$)
  • ContactMaintenanceContractor: - email address for organisation responsible for supplying maintenance service"
  • AssetIdentifier: - Owner asset identifier alphanumeric value.
  • Barcode: - Owner asset identifier numeric value.
  • MechAssetRegisterLocations: - internal network address of owners mechanical asset register
  • ElecAssetRegisterLocations: - internal network address of owners electrical asset register


All design professionals undergo tertiary training. They are not trained in everything, they are trained in their field of expertise. There are also clear demarcations in expertise between design professionals, which is necessary in any team structure. It is not that hard to come up with a clear definition of where the expertise of each profession lies.

This scope is established in legal cases by relying on what a 'reasonable' architect or engineer would do, and what they would be held accountable for, in the same circumstances.

This same argument can be used for BIM. What would an architect or engineer provide to perform the services of a 'reasonable' professional. Anything beyond that is extra.

But before we look at how this might be used to define scope, let's look at what can't be used.


You can't say design professionals have always only provided paper documents (or PDF, essentially the same thing) therefore that is all a normal design services consists of.

Some design professionals get confused between HOW they do things and WHAT they are engaged to provide. Architects and engineers are not engaged to provide just documents, whether electronic or paper. They are engaged to provide a designed solution along with sufficient information to explain the design and for it to be constructed. You can not argue you should be paid extra because you are delivering your services using different tools.

You can't say the quality or competency of what has been provided in the past is a measure of the quality and competency that should be accepted now.

As an example architects and engineers have always had to provide coordinated documentation. In reality it was extremely rare for everything to be fully coordinated, so it was accepted within the construction industry that there would be 'stuff ups' on site. Even though design professionals were in theory responsible they were rarely held accountable as it was so difficult to achieve using 2D drawings and schedules.
Now the tools are available there are no excuses. If you don't use BIM and a coordination error occurs you are open to the accusation of "why didn't you use BIM?" (which can end up in court).
And you certainly can't say you should be paid extra so you can do your job more competently, as the question arises - "does that mean on your normal fee you are less competent?"

You can't claim demands to use BIM is an exploitation of your services because others are reaping the benefits.

The mindset of exploitation builds on the previous ones above. It is based on the fallacy that BIM is not beneficial for design professionals, to both their efficiency and quality of outcome. The reality is the fact it can be beneficial to others is a bonus, a bonus the smart professionals market.


As mentioned above the point to keep in mind is what would a 'reasonable' professional do.
To know what is reasonable you need to define what design professionals do:
Design professionals provide designed solutions along with sufficient information to explain the designs and for them to be constructed.

That doesn't change with BIM.

Designs solve the same problems, they just may use different methods to come to a solution. It may be arrived at by analysis software run on a BIM model rather than analysis run on a simplified separate 3D model, or rule of thumb mathematical formulas based on manually measuring 2D drawings.

Similarly for information, it is the same information but in a different form.
Rather than schedules being excel spreadsheets they are extracts from the BIM model. Both contain the same information, it is just managed a different way. The fact this means objects in the model contain schedule information is a bonus, not an extra burden.

Because an architect could model structure and then use software to do a structural analysis, so coming up with a structural design, does not make them experts at structural engineering. Nor does access to crowd simulation software make an engineer an architect. Availability of software, even expertise in its use, does not make someone an expert in the field. If that were the case every user of MS Word would be a best selling author.

Yet there is this view that if design professionals are forced to use FM software they instantly become  not only experts at Facility Management, but professionally responsible for outcomes.

How can design professionals protect themselves?


One way to cover yourself to create a BIM statement for your organisation. This may just establish BIM policy so everyone in the firm is on the same page, or it could be for explaining your BIM approach to clients and other design professionals you work with.

Example BIM Statement (for architects):
Normal Architectural services cover brief establishment, design to meet that brief, and sufficient description of that design for it to be constructed.
Whilst these services might include consideration of construction and facilities management where they impact on design, they do not include provision of construction or FM services normally provided by contractors and property managers.
Therefore our architectural deliverables only include information pertinent to our services, they do not include information relevant to construction or FM. For example the architect does not model pour breaks in concrete floor slabs, nor include barcodes in schedules of equipment. The architect is not responsible for these, is not able to assess what is required, so does not include them.
That is not to say the architect is incapable of including construction or FM information. These additional services could be provided as long as they are identified as separate from normal architectural services, and issues such as scope, responsibility, PI coverage, time and cost are taken into account. 


The best way to shelter from unreasonable demands is to define what it is that you do.
The trick is to do in a way that doesn't make it look like you are being difficult, negative, or cutting off future opportunities.

This should be done in promotional material, Expressions of Interest (EOI), Requests for Proposals (RFP), client agreements and consultant agreements.

The wording in each type of document obviously needs to vary as they serve different purposes, but the meaning needs to be consistent across all to avoid contradictions. I've seen a client use words from an EOI to insist a service be provided even though that service wasn't mentioned in the client agreement.

The salient points to make are:

  1. Clearly define scope of your professional services.
  2. Your office does use BIM to do your normal work (if you do).
  3. You can provide the products of your normal work to third parties. 
  4. You have the capacity to provide additional BIM services (if you can and want to).

You should already be defining the scope of your services and that doesn't have to appear within or adjacent to a description of BIM in your document, which is where the other points may appear.
It should go without saying that you shouldn't claim to use BIM if you don't, I mention it here because unfortunately it occurs a bit too often.
You might also want to slip in some paragraphs about working collaboratively, leadership and other icing on the cake.

An example for EOI or RFP:
Our office uses BIM processes to deliver buildings using up to date software including Autodesk Revit.
We takes a leadership role over this process and work collaboratively with other members of design teams to facilitate coordination and integrated design solutions.
We can support construction processes and FM kick-off through the provision of project architectural information in electronic format, including 3D models and schedules as data.
We has the capability to provide additional services including BIM Management, BIM Coordination and inclusion of construction and FM data in architectural models.  

An example for client agreements:
We employ BIM processes utilizing Autodesk Revit in the production of architectural deliverables. Besides [the capability of] being active participants in design and construction BIM workflows, We [can/may/will]  provide these deliverables as structured data useful for populating construction or FM systems. 
We [can/may/will] provide BIM leadership to the design team to guide overall project BIM processes through the design phase of the project.

Another approach is to make a list defining what you consider to be included and excluded from your standard services. Again this could be an office policy document or on a project by project basis. Some examples:
Participate in BIM planning process
  • attend nominated number of BIM only meetings
  • manage BIM planning process
BIM Execution Plan
  • in-house project BIM Plan
  • change once to align in-house project BIM Plan to project BIM plan
  • create in-house project BIM Plan to specific requirements
  • create project wide BIM plan with other participants
  • manage project wide BIM plan during project


Design professional tend not to share information around their relationships with clients. A fact clients take advantage through divide and conquer.
Some BIM demands are quite scary, not just the hit on profitability, but also the possibility of litigation not covered by professional indemnity insurance. Yet professional design firms are largely left to fend for themselves.

One would expect our professional organizations to take some leadership, even if it was just to be clear about what does and does not constitute the services of their members. The usual argument is that it is a commercial decision what services a firm offers and is paid for. But the reality is most commercial clients of design firms are larger and more powerful than they are, it is hardly the level playing field the commercial decision argument is based on.

The idea is not to restrict services design professionals can provide, nor dictate what is paid. A firm can always decide to provide additional services, and even decide to do them for free. A firm can obtain and offer the expertise required to provide FM services, or enhanced BIM services. These are the commercial decisions a firm makes.

What we can't let happen is the normal services and expertise we have be expanded without our consent into areas we have little expertise, or indeed, interest in.

This is not just an issue for the owners of design firms. If your bosses agree to do extra work for free they are not going to be giving you anything extra to do the work. They will expect you not only to do the extra work, but also to learn how to do it, and all this within the same time frame. And really, do you want your job to become one largely of data entry?

The expectation of free BIM services will pervade our industry and jobs unless we make a stand. Owners of design firms need to be clear that BIM services are extra, employees need to make their bosses aware that extra work takes extra time, and work outside their expertise takes training.

And we should all be sharing our experiences more. If you come across what you believe are unreasonable demands say something. Tell your colleagues, complain to your professional organisation, write letters, write emails, comment where pertinent, hell, even write blog posts.

12 January 2015

Renaming (UK) NBS Shared Parameters

The UK National Building specification (NBS) has released a Revit shared parameter file containing the shared parameters that conform to their standard. This is another sterling contribution by the NBS towards the UK's aim of BIM Maturity Level 2 by 2016. But before getting too excited there is a problem - a significant problem.


The National Building Specification (NBS) in the UK is a commercial organization owned by the Royal Institute of British Architects (RIBA). It produces specification products for architects and has lately been developing a range of BIM products.

One of it initiatives is the development of a National BIM Library of manufacturer BIM components. The aim is to be software agnostic but to be relevant in the real world, and the fact that IFC doesn't cope well with component definitions, they are including different software formats, including Revit.
As part of this process they have had to define standard parameters for the components in their library. They developed the NBS BIM Object Standard document explaining these parameters. And that is why they made available a Revit shared parameter file containing these parameters.

The NBS is to be applauded for their efforts. Their web site clear, concise and open to everyone, and all these tools are freely available.

But . . . .


The names of the parameters in the NBS shared parameter file are not identified as belonging to, or originating from, the NBS.
Which is a bit rude considering we are inviting those parameters into our models to live amongst our, and other guest parameters.

Although the parameters are in their own group and have unique GUIDs (Global Unique IDentifiers) many names are regular English words, with ambiguous parameters like "Revision", "Version", "Name". Revision of what? - COBie export; specification; schedule; O&M manual; manufacturer model?
And some parameter names are identical to built in Revit parameters. For example "Description"; "Manufacturer"; "Finish".

For Revit users this is a problem. Unlike older softwares Revit doesn't use the name of things as the main identifier. Like a properly constructed database it uses an internal unique identifier. The name is merely another piece of data associated with that identifier. That is why when you rename, say a section detail, or a sheet number, it renames all references everywhere - instantly.

When creating schedules Revit lists all parameters available as fields that can be used in the schedule. As names are just data, if there are multiple parameters with the same name they will be listed. So if you use the NBS shared parameters there will be two available fields called "Description".  The problem is you can't tell which is which. Both the group they are in and their GUID are not accessible when creating a schedule.

But the problem is wider than for mere Revit users. Imagine the scope of this problem when there are multiple models from multiple authors. Lists of fields all with the same name, with no (easy) way of identifying who created them or what they are for.

Which parameter?
The created schedule is equally unhelpful:

The usual way around this issue is to not just ensure names are unique within the project, but that they help identify where they came from or what their purpose is.
The most common approach is to prefix or suffix custom parameters with an acronym identifying the author firm or organization. For example the ANZ Revit Standards group adds an '_ANZRS' suffix to its shared parameters, software house RTV Tools uses a 'RTV' prefix, Codebook uses "CdeB_".
And parameters without a prefix or suffix are assumed to be built-in Revit parameters.

ANZRS Shared Parameter file example

With a prefix or suffix parameters can be identified by their name:

Identifiable parameters
Which makes the schedule much more user friendly:

But the NBS has decided their parameters are the only ones anyone needs. To quote from a LinkedIn discussion:
"We see the launch of the NBS BIM Standard as a document that the industry will adopt and apply to the content created for projects whether this content is created by the NBS, designers, or content creators."  

Apparently the ONLY document we will all adopt.


What NBS is ignoring is that BIM deliverables are only one of many things model authors require from the parameters in their models.

As design professionals our primary deliverable is sufficient information to construct the facility, things like door schedules, finishes schedules, room data sheets. These may include some parameters required by other deliverables like COBie, but there are parameters not required by COBie, as well as parameters required by COBie that we don't use.
Contractors use the designers information to organize the construction of the building. Again there is not a one to one relationship between what they require and other uses and deliverables.

We also use parameters for our own internal purposes, such as various analysis like daylight contribution, structural design, mechanical system design, construction sequencing etc, as well as for internal QA and compliance. For example to check building code compliance I created a ARCH_VentilationArea parameter for windows that calculates the area available for ventilation when a window is fully open.

By the NBS assuming their standard will be the only one creates a headache for software vendors who are trying to sell their software across the world, and for large firms that operate in different countries. Believe it or not there are other standards than the NBS.


If the NBS continue to remain recalcitrant there is a work around in Revit.
Note that this will only work if done BEFORE any NBS components are placed into your project. Once a shared parameter exists in a project file, whether brought in by placed components or created via project parameters, its name can not be changed. This is the case even if you attempt to remove all references to it by purging all components and deleting all project parameters.

1.  Edit the shared parameter file by adding a prefix to each name (e.g. NBS_ or COBie_ ).

(the quickest way is to open the shared parameter file in spreadsheet software like MS Excel, OpenOffice Calc, Google Sheets, do the edit then save or export as a tab delimited file)

2.  Point Revit to your edited NBS shared parameter file.

3.  Add each parameter from your edited file to your project (or Template file) as Project Parameters.

(you may find an add-in to do this faster, e.g. CTC Shared Parameter manager, RTVRushforth Projects for paid, Case Apps for a free tool)

4.  Point Revit back to your standard shared parameter file.


Now when any components from the NBS library are inserted into your project all the NBS parameters will use your names instead of the NBS names.

Parameters in NBS component (Revit family .RFA file):

Parameters of component placed in your project:

Doing this won't disadvantage anyone else in the project.

Even though the name is different the GUID is the same. So if you link a model from someone else that uses the standard NBS name that data will appear in your model under your renamed parameter. If they link your model your data will appear under the name they used for the parameter.
If someone is extracting data for, say a COBie export, it should make no difference as long as the export relies on GUIDs and not names.
If names are critical then either rename the field in your Revit schedule or rename columns in the receiving software (e.g. COBie spreadsheet).

What you DON'T want to do is create your own new shared parameters (via Revit's Shared Parameter dialog) that mimic the NBS shared parameters. If you do this your parameters will have a different GUID to the NBS parameters and therefore will not contain the data in NBS components.


It is disappointing the NBS has taken this attitude. Part of the BIM revolution is the breaking down of the "silos" people work in, allowing people to work collaboratively. The NBS approach seems to be  to replace the silos of others with their particular silo.

Not very BIM like.

18 November 2014

IP - it is not all yours, get used to it

When discussing BIM with those yet to take it up the topic of Intellectual Property invariably comes up. It is so important to them it comes across as a major reason they are not using BIM (although I suspect it is more of an excuse).

For some reason BIM authors (architects, engineers, etc) think that because they create the initial BIM information they have the right to full control and to charge for the BIM model throughout the life of the building.

Then on the other hand we have contractors and owners who believe, because they are paying the authors, that they have absolute rights over all BIM created to do as they please with it.


One of the tenets of BIM is that all information is contained in one place; the BIM model (which may be an amalgam of several BIM models). And that all parties have access to this information so everyone is working on the same, up to date, information.

One of the effects of this is that there can be no duplicates of the same information.
The architect schedules doors, the hardware supplier adds to that schedule, they don't create their own. The architect doesn't model ductwork, they use the mechanical engineer's model.

So for BIM to work at all project participants must not only have unrestrained access to each other's BIM, they are not allowed to create their own version of some-one else's.
If any party tries to restrict access the whole process starts to collapse.

However access doesn't necessarily mean unfettered control. This is still a place for IP rights.


One of the problems discussing IP is that often people are talking about different things. They have different reasons for, or place more emphasis on, particular concerns.
But even then I don't see much mileage in these concerns, certainly not enough to withhold information.


The old "why should I give away my work for free" argument. It has the appearance of taking the moral high ground but has a number of flaws.

Money is only one form of compensation. Barter is another. In the BIM context if everyone shares everyone benefits. For example allowing the quantity surveyor to directly measure from your BIM model means more timely estimates reducing the risk of you doing unpaid abortive work when the estimate blows the budget.

We work in a market economy, just because you place a dollar value on what you have produced doesn't mean others will. There is little point with-holding something from others that has no actual value, or a lessor value, to them. All you do is damage your reputation, and possibly the chances of future work.

And lastly the reality of the industry. If information is withheld that is required contracts will be changed to ensure that information is made available. The danger here is contracts invariably overreach, they are more onerous than they need to be. We are already seeing this with contracts that take all IP rights away whether justified or not.


BIM doesn't make any difference to IP rights over original ideas which are already covered by copyright law.
Does the possession of a BIM model make it easier for some-one to copy your design, to break the law? In a sense, because BIM contains more information that is structured more efficiently than traditional product like CAD files, spreadsheets and drawings. But the theft itself is no easier. In fact it could be argued it would be more straightforward to identify a stolen BIM model due to the uniqueness of how data is arranged, as to compared to a drawing consisting just of lines and text.

There is also a belief among some that every idea they come up with is unique and universally cherished.
That parametric door that can represent nearly every possible type of door is just as valuable to the contractor who just wants to know what each door is. The clever equipment schedule that you believe gives you a competitive advantage so will be copied by everyone who sees it because it is so brilliant.
Your innovative work practices are important to you but are rarely suited to anyone else.
Experienced BIM authors know that components sourced from elsewhere are never exactly what is needed to fit their own work practices. Many a time I have spent more effort trying to rework some-one else's component than it would have taken to recreate it from scratch.


Some have concerns that if they provide their work in an editable format (whether BIM or CAD) some-one will make changes to their work without their knowledge and/or permission.
To make changes to work attributed to some-one else is fraud and clearly illegal. To withhold your work is overkill and the equivalent of never getting out of bed to avoid anything bad happening.

Some believe if  they maintain control they are in the best position to ensure their intellectual effort, their design, will be carried through in a way that they will be happy with. That if they are not in full control others will make poor decisions compromising their brilliant ideas.
This argument is hard to convince owners and contractors as they expect the documents you provide as part of your service to contain enough information for your design to be fully realised. If you argue otherwise they just see it as evidence your documents, and your design, is deficient and you intend to 'fix it up' later at their expense.

There is also a belief that with a copy of an original work contractors or owners are free to get others to take over the job. Again most jurisdictions have laws that already cover this, and in any case possession of your IP is unlikely to be the deciding factor in your client making this decision.
It ignores the fact that BIM output is the result of expert knowledge and professional responsibility. It is not like a set of Ikea instructions anyone can use. Only very cavalier professionals would take on the responsibility of some-one else's work without spending a significant amount of time checking it.


IP applies to many things but this post is about BIM. The 'products' of BIM that IP may impact include:

  • Whole BIM model (federated or integrated)
  • BIM Model contribution (as separate model or co-author)
  • BIM model components (e.g. equipment, doors, etc)
  • Editable drawings from the BIM model (e.g. CAD files).
  • Editable schedules from the BIM model (e.g. Excel files).

Note that the last two items existed before BIM. Generally BIM has not created new IP issues, just extended existing ones.


There is often a misconception that obtaining IP protection means complete ownership, giving full control to the 'owner'. This is not correct, IP is a safeguard, not a title to ownership.
IP applying to a 'product' is managed by assigning 'Rights' to it, who has the right to do what with it. Often IP discussions are really about Rights, not the application of IP per se.

Rights are something authors should be concerned about. It is where the risks and rewards lie.
What are the types of Rights people are concerned about when it comes to BIM?

The right to:

be identified as author.

Sometimes called 'Moral Rights'. This is covered by IP law in many countries and does not change with BIM.

decide what uses are permitted.

An author should be able to stipulate what their model is suitable for, or more realistically stipulate what it has been created for and let others make the call if it is suitable or not (authors don't necessarily know what other professionals require so how could they be definitive about what their BIM is suitable for?).
But this shouldn't extend to complete denial of access for uses not permitted. Firstly, not all possible uses can be predicted, and secondly even a model unsuitable for a particular use may still be of some use as long as its limitations are known and acknowledged.

The best way to deal with this Right is for authors to stipulate what their BIM model has been created for (i.e. their particular uses), and an affirmation that it contains all information they, as authors, are engaged to produce.
For example an architect would say their model "contains sufficient information to describe the materials and location of those materials". What they shouldn't say is their model is "suitable for estimating uses" as it infers they have modelled every material in accurate quantities.

decide who can use it. 

Some believe their 'ownership' of their BIM contribution gives them the right to withhold it from whomever they choose. Whilst an author may have a good reason to prevent certain parties from using their work their reasons may conflict with the needs of other project team members and the project as a whole. The outright power of veto doesn't work in a BIM project.

However it is reasonable to insist you be notified if some-one else receives your work. There may be matters you need to inform other parties about the content and status of your work. An all too common occurrence is contractors providing design professional's work to sub-contractors that is inappropriate, incomplete, or not reissued when superseded. I have personally experience a situation where the piling contractor was given our documents (architect's) to put directly in their survey total station, when all our documents had were roughly placed piles for context. They should have been given the structural engineers drawings, but neither ourselves or the structural engineer knew they had been provided with our BIM model.

The usual way to deal with provision to inappropriate parties is to stipulate the work can only be provided to those directly involved in the particular project it was created for. The way to deal with inappropriate use is to define uses that are permitted.

demand payment for its use.

Traditionally only drawings and written material were provided to others, which they referred to but didn't directly use to generate their work. But a BIM model can be integrated into other's work, for example running an analysis or directly measuring quantities. Because of this some believe they should get a cut in the obvious windfall others are getting.
But there is no windfall. Everyone is relying on getting the information they require from everyone else, no-one has budgeted to pay extra.

That is not to say there are no situations where you can charge. Certainly if your work is to be used for a different project, or purpose not involving your particular project. But charging project participants is not normal practice. If you intend to do it within your project you need to make that clear at the very beginning of the project, when negotiating your engagement agreement. And good luck with that!

use it for other projects and purposes. 

It is perfectly reasonable for authors to expect their work will not be used for projects and purposes they are not a party to. This is what standard IP covers, and is what is lost when all IP is signed away.
There is no reason for IP to be completely signed away for BIM to work, as long as all parties agree to provide their work to other members of the project team. It is when there is a belief that there will be resistance to this that owners and contractors try and take everyone's IP via contract clauses.

The best way to fend off attempts to take complete control of your IP is to be accommodating. Show that you will make your work available to all those that will require it for the project.


But with Rights come responsibility.

  • If you claim authorship you are forever associated with the project.
  • If you dictate what your BIM model can be used for you accept responsibility that it is suitable for that use.
  • If you refuse to provide your BIM to some-one you will be expected to provide good reasons and prove it does not impinge on your obligations to the project.
  • If you insist on the Right to charge for use of your BIM model you take on the responsibility of your BIM model being suitable for the purpose you are charging for.
    In most legal jurisdictions the act of accepting money infers you have provided a useful product, no matter what any written agreement says. You can't charge a Quantity Surveyor for using your model for measurement and not accept responsibility for it's accuracy and completeness. 

You might consider forgoing Rights you may be entitled to avoid responsibility.
For example forgo the right to dictate what your BIM can be used for and instead provide it on an 'as is' basis.


Always keep in mind that BIM processes require information to be not only shared, but shared in particular formats. That means you have to provide your computer files to others, there is no way around this.
But that doesn't mean you have to forgo all IP protection. The best approach is to assess whether the rights you want impede the flow of information within the project or not. If they don't, insist on them, if they do, work out a way to achieve your aim another way or accept it is not going to happen.

Specific advice on IP in contracts and agreements is beyond my expertise so I leave that to others. Some resources:
Designing Buildings Wiki (UK)
National BIM standard - US

Generally you should expect that each participant retain IP rights over their contribution, and that the rights of others only extend to their requirements for the particular project.

You may have limited control over agreements with others but what you can do is manipulate the data you provide to others. For example sheets and annotation (text and dimensions) are not required in the BIM model you provide when you are also providing drawings and written schedules.

Methods include:

Make recipients aware of limitations:

Have standard written "conditions of use" that can be included in agreements with others and included with all document issues.

Use non-editable file format:

Provide IFC, Navisworks, DWF, PDF etc instead of your authoring software.
(These formats, to varying degrees, allow access to BIM data.)

Remove temptation:

Strip BIM models of all but essential elements and data.

Identify your work:

Embed ownership data within BIM objects.


There may be others, but I have used these in the past:

Embed "Conditions Of Use":
Create a Starting View and put your Conditions Of Use on it.
(Revit always displays this view when opening the file so it is hard for someone to argue they didn't see it).

Only export the model, excluding all annotation and sheets:
Create 3D view, hide what you don't want to include, place this view on a sheet. In the Project Browser right click over the sheet and pick Save to New File. Open the new Revit file and add a Starting View with Conditions Of Use.

Delete specific views and sheets:
Create a schedule of views, manually delete views. Do the same with a Sheet List.
Or use an add-in to delete views, sheets, etc.

Make your work identifiable:
Add parameters to all your families that contain copyright information (place as a formula so it can't be easily edited).
Prefix all your shared parameters with your organization's acronym.


Get used to the fact that no-one is using BIM as a pretext for stealing your IP. Others don't want to own your BIM, they just want to be able to use it.

They want the right to use the model to check if a hole can be drilled without hitting any pipes or wires. Everyone understands use of BIM doesn't give them the right to construct an identical building somewhere else.

IP is an issue of concern, as it always has been, but not sufficient to block or hobble the use of BIM.
Let's stop chasing windmills and get on with the real game, making IP in BIM fair to everyone.

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, new media and ... men.

The complete series, "AWAKENING the lost woman", "CAPTURING the lost woman" & "FINDING the lost woman" is available now on Amazon, Kobo, Google Books, Barnes & Noble and iBooks.

30 August 2014

The Nature of Naming

BIM is by nature a shared environment. For example in the context of Revit each discipline team work together in one file.
This new paradigm means things have to be shared, people can't isolate themselves in the CAD files they are working in and name things however they want. Nor can they create new things to suit their own purposes. Anything created in a BIM file is for everyone to use.

How things are named becomes critical, because it is how different things are recognised by different people.
Not only so people can find the things they need, but also so things that are the same are not created multiple times with different names.

Many things are named in BIM, from filenames to parameters. This post concentrates on the naming of components (families in Revit). But the principles expounded are applicable to all naming.


Who uses and relies on names in the BIM model?
Receivers of BIM information don't care what the name of an object is. The information they require comes from object parameters. You don't produce a wall schedule for the contractor that lists the Revit names of walls, you list wall code, thickness, materials, fire, acoustic ratings etc. Indeed, if you are asked to use a particular naming schema by a client or contractor in your BIM software politely refuse. It is totally unnecessary.

The purpose of names is so BIM authors can identify things when they are creating them. When confronted by a list of wall names in their software they can identify and select the one they need. Or if what they need doesn't exist they can create a new one using a naming schema that others will understand, so someone else can use the wall that they made.

If objects have so many parameters why is the name of it so important? The information is there, you just have to expose the relevant parameter value.
This is true. But the stumbling block from a practical point of view is "exposing the parameter". In an ideal world (with ideal software) you could sort and filter by all the parameters an object has rather than just its name. There are Revit add-ins that do this to varying degrees (I welcome comments suggesting such add-ins). Revit out-of-the-box does not. The other issue is even if you could select by parameter the name still has to be unique. Unless the add-in controls naming of components, you still have to come up with a way to create unique names.
That said, an add-in may be a viable solution. But for the rest of us who can't get our bosses to pay for add-ins the problem remains.


Naming was also important in CAD. Every office had a CAD Naming Standard. But there are important differences to BIM.

The most obvious difference is that the output of CAD is drawings, lines on paper. In fact many CAD standards did little no more than describe lines. Layers names like 5_PEN.

With BIM you are dealing with objects, virtual objects that represent things that exist in the real world. When you model a wall you are creating an object that has (in Revit) upwards of 24 different bits of information, or parameters (in Revit speak).
In CAD you might have three; colour, pen weight and line pattern. Enhancements like multi-lines might increase this by 3 more by adding thickness dimensions, but still no-where near the number BIM encompasses.

In reality correct naming was not that critical for CAD. If a layer (or Level in Bentley) was named WALL_BRICK in one CAD file and BRICK_WALL in another, as long as they had similar line thicknesses  and patterns the drawings produced looked the same.

In BIM if you have two wall definitions with different names that are actually the same wall (i.e. have identical parameters) not only will your schedules be misleading (i.e. identical walls with different codes), if there is a change made to one and not the other that change won't propagate across the project (e.g. MR plasterboard changed to Fibre Cement sheet).
The effect is the BIM model becomes unreliable.


CAD software started to be used back in the days of DOS (Disk Operating System). This was a text based language developed in the early 1980s when computers had very little memory. So little the length of filenames had to be restricted to 8 characters. And even then only uppercase letters (A-Z), numbers (0-9), and the underscore (_). This was because other 'punctuation characters' (including spaces) were used by DOS for programming.
Although these restrictions only applied to filenames they were usually applied to internal naming as well (early AutoCAD had restrictions on layer name length, Microstation Levels only used numbers up to 63). This was due to a mixture of software creating files hidden from users, internal memory constrictions, or just habit on the part of software coders.

It wasn't until the introduction of Windows NT & 95 (Apple always had fewer restrictions) these restrictions started to relax. Dashes (-) became permissible, the file name length increased to 31 characters, lowercase was displayed.
Now most punctuation characters are allowed, (only  \ / ? : * " > < |  can't be used), and restriction on length is 260 characters.

Many CAD standards still used today were originally created back in the days of DOS, when CAD naming schemas obsessed with the number of characters and only allowed letters, numbers and underscores.
Even today many IT and CAD managers still insist these old DOS restrictions be maintained, because back in 1998 they had an incident where it mattered. When pressed their best reason is do it "just in case".
Indeed there is still software around where it matters, but I find if this is the case invariably there are other reasons not use it (I tried an accounting package with these restrictions but stopped using it because it was like using software from 1998). To me it is an indicator of software which is ancient, or considers coding more important than usability.

In 2014 there is no practical reason to restrict naming schemas to suit computers from 20 years ago.


Apply these simple principals.


The most important criteria for a naming schema is that it is understandable by everyone who will interact with it.
This is not as onerous as you think, as mentioned above only BIM authors make use of names so this cuts down the audience considerably.
There are many ways to make a naming schema understandable. There is really no one size fits all. What works in one office may not work in another. Architects respond differently to engineers, a design office will respond differently to a documentation workhouse.

How do you make a naming schema understandable?
  • Be literal:
    call 13mm plasterboard, for example, plasterbd13 not P01 or L13.
  • Be consistent:
      brick110 and plasterbd13
      110brick and plasterbd13.
  • Use punctuation that is meaningful:
      brick110 / stud92 , insul50 / plasterbrdMR13 + tiles
  • Manage the unmanaged:
    Use a prefix and name structure to identify objects that are managed.
    For example:
    - prefix material names to separate them from rubbish that comes in with imported files:
    - name things that are standard differently:
      2.5 text   is standard;
      Black 2.5 bold   is not standard.


Naming schemas need to be capable of naming absolutely every possibility for objects they are applied to.
If they don't how do your users name something the naming schema doesn't account for? They make it up, and each one will make it up in their own unique way. To say something is hardly ever used is not a solution, it is a cop-out, what I call an excuse, not a reason.
This doesn't mean a naming schema has to be ridiculously long. By utilizing meaningful punctuation fields of information can be optional - left out if not relevant. If necessary the schema defines what the value is by default, and how it is added to the name if it is not the default.
  • Define a name schema to include all variances that are possible, not just those that are probable:
    In Revit look at all the Type parameters of the object being named and make sure the ones that will cause a new type to be created has a place within the name structure.
  • Use optional fields:
       brick110 / stud92 / plasterbrdMR13
       can be extended to
       brick110 /stud92 , insul50 / plasterbrdMR13 + tiles
  • Assume default values:
    walls are internal unless nominated otherwise,
       -/block140/- is interior wall;
       -/block140/-.e is exterior wall


There is no point creating a fabulous naming schema if no-one uses it, or uses it properly. It has to work in practice.

It is a trap to think because you have a captive audience in your office you can rely on training to enforce a naming schema.
The reality is Architects and engineers, the BIM authors, don't care about naming schemas. Nor should they be expected to. They are hired to provide their professional skills in designing a building. And that is what they want to do, not obsess over how they name things.
People new to the office, or project, also need to be considered. No boss wants their highly paid engineers spending hours learning naming schemas, they want them producing billable work.

And relying on training will only be effective if the naming schema actually works. An all too common assumption is that if only everyone used it properly there would be no problems. Whether it does what it needs to do is never challenged.

How to make a naming schema work:
  • Set general rules for name creation rather than a rigid rules:
    names follow major-medius-minor rule rather than 3 uppercase letters, underscore, 4 lowercase characters, underscore, 2 numbers.
  • Create a naming structure rather than a rigid standard:
    allow 13mm plasterboard to be named plasterboard13, plasterbd13 or pb13, not just PB13.
  • Document naming schemas:
    don't rely on people memorizing what they learnt at a training session; provide examples, cheat sheets, easily update-able and searchable documentation (i.e. web manuals or wiki)
  • Adjust naming schemas to suit particular projects:
    work with project teams to get a schema they are comfortable with.
  • Investigate how people use naming schemas:
    instead of forcing recalcitrant users into training ask them what they would change to make it useful to them.
  • Review naming schemas in the light of experience:
    don't be afraid to make changes when it is warranted.

As an example of making changes to suit users, I recently added tag codes to the front of wall and material names.
brick110 / stud92 / plasterbrdMR13
W.B201_brick110 / stud92 / plasterbrdMR13

To me this is poor practice as codes are unique to a particular project, and there is an overhead in keeping the names matching the code parameter (in our case Type Mark).
But users felt more confident selecting items clearly identified with the code used in tags. (Wall types not yet assigned a code were named: W.Bxxx_....).
From a purely data management view not ideal, but if it helps people do what they need to do so be it.

The bottom line is BIM standards, including naming schemas, should never be considered set in concrete. BIM software development is fast moving and standards need to move with them.


At the end of the day naming schemas, and office BIM standards in general are for humans, the users of BIM software, not the software itself, the IT system or those that run it.
When dealing with humans a rigid purely logical approach is rarely successful. What is called for is 'fuzzy logic' (to use a software term); simple rules that have a degree of flexibility.

Despite my examples above, (which are not from a real naming schema), I have deliberately not been specific because I don't believe there is such a thing as the perfect schema. To be practical a naming schema has to suit the people who work with it, so they (or someone in direct contact with them) need to be the ones who work it out.
What I have tried to do is reveal some of the guiding principles behind a workable naming schema.

Creating BIM standards is a hard and thankless task. You will never satisfy everyone, you will never achieve the perfect standard, and the job is never completely finished. But there are benefits to even partially successful standards. It is worth the effort.

There will always be resistance to change, but don't accept excuses masquerading as reasons:
  • I don't like it:
    - it is not an aesthetic decision so who cares what you think.
  • We have always done it that way:
    - if that was the case we would still be drawing on linen with quills.
  • People are already familiar with the current system:
    - not relevant if the current system is unsuitable for BIM.
  • It works now so why change it:
    - does it? really? let me show you otherwise . . .

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, new media and ... men.

The complete series, "AWAKENING the lost woman", "CAPTURING the lost woman" & "FINDING the lost woman" is available now on Amazon, Kobo, Google Books, Barnes & Noble and iBooks.

02 June 2014

BIM is not so Real after all

In my last post, Keep your BIM Model Real, I explored the issue of relating a BIM model to the real world. One of my conclusions was to "actively include tolerances in our BIM Models".

I was wrong.


Firstly there are technical reasons 'padding' quantities is bad practice. In my previous post I tried to show that it didn't matter for quantity take-off. But accurate quantities are important for other purposes as well.
As Tim Froise pointed out in an LinkedIn discussion:
' But there are occasions where the volume is important. If the wall component is considered for its U-value, there is an additional 36% of plasterboard material, which is significant.
He also points out it will affect acoustic and thermal mass calculations.

Indeed he is right. Materials in Revit have values assigned to them that can be used for these types of calculations.

And materials with padded thicknesses make a difference.

I can't justify rationalising away all these valid uses for accurate data.

But perhaps the most pertinent comments were about why I though it OK to mess with the BIM model for my own purposes.
From Tim McDougald:
' I watched this argument at my old firm between two different Architects within the same building. One wanted everything drawn "real" and the other rounded everything off.
I recognised myself as one of those architects. And it is true, there is no consensus between architects (which is why I started analysing this issue).
The view held depends on what particular problems an architect is grappling with. For example at design stage the aim is to please the client, so architects tend to minimize construction allowances so higher usable and lettable areas can be achieved. During documentation the aim is constructability, construction allowances have to be found to ensure what has been designed can be achieved in the real world.
But this has nothing to do with the BIM model. It has to do with the competencies of the architects involved.

Embedding the solution into the BIM model risks reducing the designer's obligation to directly deal with their professional responsibilities. Architects who think their BIM model will 'take care' of constructability will feel confident they can ignore construction limitations. Engineers who let their software come up with solutions don't feel the need to explore alternatives.

And this is what my last post attempted to do. Shift architect's responsibility to consider constructability on to the BIM Model.

Another comment, this time from David Conant:
' I think the pressure to make a 114 wall at 120 is really another manifestation of "don't make me change the way I do things" without questioning why. '
The error I made is all too common. An approach that tries to embed too much into BIM models. To use them as much as possible to solve problems we encounter, ignoring how this may effect others using the model.
What we need to appreciate is that there are limits to what a BIM model (and hence BIM processes) can do, and to modify our expectations accordingly.


On "questioning why", as David suggested, I recognised the traditional  purpose of dimensioning is to provide the contractor with clear instructions, or requirements, of where things are located. By rounding dimensions we are attempting to make it easier for them through expressing requirements in a clearer manner.

This is because in traditional construction documents the purpose is to provide the contractor with sufficient information to fulfil requirements that designers (i.e. architects and engineers) identify.
This often leads to a battle between contractors and designers, where designers try to provide as little information as possible, and contractors demand specific 'how to' instructions. The architect provides a note - "fix securely", the contractor wants a drawing showing the location of every screw.

Now using BIM doesn't (or hasn't yet) overcome this. Contractors still want more in the model than designers think is necessary or reasonable (and to be honest practical). On the other hand Architects, and especially engineers, don't see why they need to model enough to create a coherent virtual building.

But the significant point here is the different ways traditional documents and BIM communicate information.
As explained above traditional documents attempt to explain what the requirements are. Those who receive them expect those documents to directly communicate requirements without interpretation.
A BIM model is a facsimile of requirements. It is a representation of the final product of those requirements (i.e. a virtual model). And as such can only every reflects what the real world requirements are, it does not specifically spell them out.

For example traditional documents might have all fire rated compartments identified on drawings with a heavy dashed line. This directly tells the contractor where fire compartments are located, and by inference which walls and doors have to be fire rated.
In a BIM model those walls have their materials and construction modelled as virtual walls and doors that meet fire rated performance requirements, they may even have data associated with them stating their required fire rating. But it will be up to the contractor to extract information from the model that identifies their location, and hence extent of fire compartments (contractors need to know this because it is not just materials that create fire isolation, it is also the way they are put together).


So to go back to my dimensioning example.
So yes, architects should represent walls correctly without padding, and not worry about dimensions that are unobtainable in the real world.

The consequence of this is that dimensions will not be as clear and instructive as found in traditional documents. The contractor will not be able to merely read off dimensions and use them directly, dimensions will have to be interpreted to make them useful on site, in the real world.

I see this as another consequence of utilizing BIM, an example of roles and responsibilities changing. Is it a bad consequence? I think not. The contractor is best placed to make decisions about what is best on site. And honestly, if architects were any good at it I wouldn't be spending so much time trying to find a fix for it!

The bigger picture here is that a BIM model - a virtual building - does not communicate information in the same way traditional documents do.
Traditional documents are designed to spoon feed relevant information, to highlight what is critical and what is not. BIM models just provide information. True, much more information, but not all of it is relevant to a particular recipient. It is the recipient's responsibility to extract the information they require, and if necessary manipulate it to make it useful.

For contractors no more "we didn't do it because you didn't specifically tell us to", with BIM it is "you should have identified the need from the model", (although "we didn't do it because it wasn't in the model" is still fair enough).

I've used contractors as an example, but the same applies right across all AECO processes. We all need to recognise that BIM is not the same as traditional delivery, and that it does not provide information in the same manner.


Great, glad we got that sorted. But what does that mean, how should this insight effect what we do now?

As I have written before in my post Can BIM alone be used for Construction, there is currently no practical way to deliver a project purely using BIM. We are in transition. We use BIM where we can but are still expected (and contractually required) to provide traditional documents.

This is where I came unstuck with dimensioning. Traditional documentation calls for rounded, padded dimensions. But we are using BIM software, and it is not designed to do this (nor should it be).
So on the one hand I'm trying to fulfil my contractual obligations, on the other trying to produce good quality BIM, both to help my processes and for others to utilize.

What is the solution? All I can think of is a hybrid.
Use real thicknesses and unapologetic actual dimensions, then add 'clear' or 'min./max.' dimensions where there are critical requirements to be met.

If you really feel the need to pad walls do it be adding a 'tolerance' layer.

But there is nothing preventing walls used at early design stages, when their construction is unknown or undecided, from being thick enough to incorporate tolerances.
For example use 150mm or 130mm for generic internal walls instead of 100mm. This is where BIM helps, it is a trivial exercise (at least in Revit) to change walls from one type to another.


'Why bother' you might ask. If we are not doing real BIM why try and do things in a BIM like manner?

The reality is BIM is not an all or nothing proposition. A lot of money is always at stake on a building project, involving lots of people with differing views. The risks are enormous, so BIM will be used where there are perceived benefits and low risk, BIM by itself will never be the most important driver.

We users of BIM know its benefits, but must be prepared to demonstrate them. And the best way to do that is to be prepared. To embed BIM practices in what we do even when we don't need to. And where necessary resist following traditional practices where they conflict with good BIM practice.

A BIM model is not, and can never be, 'Real'. It is repository of data that creates a facsimile of the real world. It is up to us, the creators and users of that BIM model, to use that facsimile to inform what we humans need to know to create the real thing, in the real world.

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, new media and ... men.
Book one of the series, "Awakening the lost woman", is available now on Amazon,  Google Books,  Kobo  and  iBooks.

03 April 2014

Keep your BIM Model Real

Many of us only work in the world of our BIM models. The closest we get to something real is the drawings and schedules produced by our BIM software (even then we may never see them as physical objects, document issues are often via PDF or DWF).

Often we forget what we are doing is for the real world. That we are showing real people using real materials and real tools what we want built.

Another thing we tend to forget is that what we produce is going to be used by different people for different purposes.
An architect may only think his work is for showing what he has designed will look like, an engineer to explain the rationale of his solution. Sure, they might provide more information they think others will use, but not a lot of thought goes into it.

Conversely, those that use what has been produced don't understand why it doesn't explicitly cater for all their requirements.

None of these issues can be completely resolved. BIM software will never exactly match reality, authors will always privilege their own requirements, and a BIM model will continue to be used by multiple people for multiple purposes.

If it is always going to be a compromise what are the practical things we can do to address these issues?

An Example - WALLS

Within a BIM model walls have a number of purposes:

show what is to be built 

Walls are made from materials, with certain properties. There is an expectation there will be enough information to build them, that what walls are made from is identified, as is the order they are placed.

locate to be built 

Walls represent real objects that real people have to build. They need to know where it is located, with sufficient tolerance to make it humanly achievable.

boundary for analysis

Walls can be used as boundary elements for various software analysis. But each analysis will have different expectations. Not every wall may be required, the boundary may be at the edge of a wall or somewhere within it, particular information about what the wall is made from, or how it behaves, may be expected.

measure quantities 

Walls can be measured for costing and procurement purposes. Accurate area and volumetric information is expected.

construction schedule

Walls can be made up of different materials that are placed at different times. The expectation is that these materials can be separately allocated to different milestones.

I don't intend to go through every issue, instead I'll use accuracy as an example.
What are the expectations in terms of accuracy? It is not a two way street however, for example the cost estimator does not model walls, the architect does. So for the architect, what level of accuracy is reasonable?


We all understand a real person in the real world can not be as accurate a a computer. Let's put some numbers on that.

In our BIM software we can be precise up to 16 decimal places. This is often important to our software, but in the real (metric - millimetre) world that is accuracy to 0.1 femtometres, which is narrower than a proton (1.6 to 1.7 femtometres). If the unit is feet it becomes 30.48 femtometres, which is still smaller than the width of a hydrogen atom.

In the real world standards have been set to define what is reasonable. Some examples:

From the U.S. "Minimum Standard Detail Requirements for ALTA/ACSM Land Title Surveys 2011":
"The maximum allowable Relative Positional Precision for an ALTA/ACSM Land Title Survey is 2 cm (0.07 feet) plus 50 parts per million".
So the minimum degree of accuracy expected for land titles is 20mm.

From the Guide to Standards & Tolerances, published by the Australian Victorian Building Commission:
"Departures from documented external dimensions of buildings are defects if they exceed L/200 where L is the documented overall length of wall, or 5mm, whichever is greater."
"Departures from documented dimensions of service rooms and areas are defects if they exceed L/200 or 5mm, whichever is greater."
"Departures from documented dimensions of heights of building elements such as beams and posts are defects if they exceed L/200 or 5mm, whichever is greater."
i.e. 5mm per 1000mm (3/16" per 3' 3 1/2")
"Departures from documented dimensions of habitable rooms and areas are defects if they exceed L/100 or 5mm, whichever is greater."
i.e. 5mm per 500mm (3/16" per 1' 8")

Some allowable inaccuracies are quite large:
"Finished floor levels are defective where they depart from documented RL or FFL by more than 40mm" or depart from floors of the same level."
And there are more for specific materials:

From this it appears it is generally considered unrealistic to expect on-site measurements of less than to the nearest 5mm (3/16 inch).


Let's go back to our wall example.

A typical (metric) wall is two layers of plasterboard either side of a structural stud.
13 plasterboard + 92 steel stud + 13mm plasterboard, total thickness 118mm.

But is the built wall going to be exactly 118mm thick everywhere? Of course not.
For a start it will thicker wherever there is a joint.

It will also be thicker in corners (both internal and external), which like joints are also stopped up.

 And this is before we factor in the imprecision of on-site measuring.

If the architect is to achieve required minimum clearances then this needs to be taken into account.
You might rationalize that surely a code checker won't worry about a few millimetres. But no-one can take the risk. I have seen a building inspector insist walls tiles be removed from a toilet wall because the width he measured was slightly less than the required 900mm. There was also a court case here in Australia where the architect, building surveyor and contractor were found culpable for a balustrade 20mm less than code height (someone slid down the balustrade and fell, resulting in brain damage. Apparently, according to the court, if it was 20mm higher it wouldn't have happened).

What about rounding? We are all guilty of using dimensions that round to the nearest 5mm, or (gasp) 10mm.
The problem is Revit doesn't always round up. We always want to ensure minimum dimensions are met, we are not so worried about maximums being exceeded, so we need to round up.

Depending on the actual dimension, Revit may round up or down.

Also the 2 or 3mm rounding changes a dimension by may not be enough to account for construction tolerances. In-situ concrete requires quite large tolerances, 25mm (1 inch) is not uncommon.

Rounding generally is not good practice. Rounding errors mount up, and you can end up in the embarrassing situation where your short dimensions don't add up to longer dimensions.

The correct way is to locate things ACCURATELY. If the end walls are supposed to be 600 apart, model them 600 apart. Objects should be modelled so they are increments of 5mm apart, then actual dimensions you have in your model will be achievable in the real world.

I know it is not always possible, but just because it can't be done all the time is no excuse to never do it.

But I digress, back to our wall:

Therefore to ensure minimum dimensions are at least achievable on-site we need to increase the width of the wall. Based on the 5mm minimum measurable rule that means a multiple of 5mm, remembering that you don't want possible mis-measures to be minus 5mm.

So a 118mm wall becomes 120mm, (2mm tolerance) or to be safer 125mm (7mm tolerance).

Now, according to the Guide to Standards & Tolerances:
"Unless shown otherwise, dimensions shown on drawings for internal walls always refer to the structure's dimensions."
So we also want to rationalise the dimension of the structural steel stud.

The wall we make in our BIM software becomes:
17.5 plasterboard + 90 steel stud + 17.5mm plasterboard, total thickness 125mm.

Now it is true we could add another 'layer' into the wall for tolerance.
13 plasterboard + 4.5 tolerance + 90 steel stud + 4.5 tolerance + 13mm plasterboard.

But this adds another line into the graphic representation of the wall.
Not only is this confusing to anyone looking at the drawing (and a potential recurring RFI topic), it adds additional complexity to our BIM model. We already cope with large, slow files (in Revit that is), we don't need to make it worse.

So the architect is happy. But what about others?

When an estimator extracts quantities from the BIM model they are going to be wrong. But how wrong?

If we take volume of plasterboard, every 100sqM of 13mm plasterboard has a volume of 1.3cuM, for 17.5mm it is 1.75cuM, a difference of 35%. Not insignificant.

But something like plasterboard is measured by area, not volume. When measuring wall linings errors in area measurements will occur at corners and end walls.
Looking at internal corners (there are more internal corners than external corners or ends walls in a building), there is an under-measure if walls are thicker.
So 2 lots of 4.5mm will not be measured, and assuming 2.7m high walls, total area is 0.0243sqM.

Put another way there would need to be 41 internal corners to lose 1sqM of measured area, which is close to 10 rooms (4 corners per room). Say an average room is 3m x 3m, total wall area for 10 rooms is 324sqM. A loss of 1sqM equates to 0.3%. Which is insignificant.

So while it can be quite dangerous to rely on volumes out of a BIM model, areas are not such a problem. Of course this is not the case for every material. Mass materials like concrete are usually safe (tolerance in concrete placement is accounted for in attached linings). Structural steel may be OK if realistic structural members are used (which generally happens if the structural engineer is the modeller).

The take home point here is to not rely on thicknesses parameters to define what a material is. The above example has 13mm plasterboard, but when modelled at 17.5mm if its thickness is used to identify the type of plasterboard it could be mistaken for 16mm plasterboard, on the assumption a 1.5mm tolerance has been allowed for.

There is another reason thickness is not a good indicator of what a material is. Walls in BIM software have homogeneous layers. When materials overlap there is no way to use their real thickness in the thickness parameter.
The example below is a stud wall with insulation. The insulation is within the same 'layer' as the studs, but is not the same thickness as the studs. Therefore we have to nominate the stud layer thickness as 40mm, even though they are actually 92mm studs.

There are plenty of other parameters that can be used to define what a material is. It is not really necessary to use the thickness of a modelled material.


I've only provided limited examples here, but these lessons apply right across all things in BIM models. The specifics may be different, but the issues are the same.

Don't assume a BIM model has just been made for you and your purposes.

In particular no-one should presume, or ask for, absolute accuracy from a BIM model.
We should all expect, and actively include, tolerances in our BIM models.

And most of all, don't forget why we do the work we do. To build things in the real world.