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.

IP and BIM PROCESS

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.

IP CONCERNS

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.

THEFT OF EFFORT

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.

THEFT OF IDEAS

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.

LOSS OF CONTROL

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.

BIM IP APPLIES TO

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.

RIGHTS

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.

BE CAREFUL WHAT YOU WISH FOR

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.

WHAT CAN YOU DO

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
BIM / IPD [AUS]

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.

EXAMPLE REVIT SPECIFIC METHODS

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.

CONCLUSION

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.

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.

WHAT NAMES IN BIM ARE USED FOR

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.

BIM IS NOT CAD

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.

THE DOS LEGACY

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.

WHAT MAKES A GOOD NAMING SCHEMA

Apply these simple principals.

UNDERSTANDABLE

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
    not
    110brick and plasterbd13.
• Use punctuation that is meaningful:
    brick110 / stud92 , insul50 / plasterbrdMR13 + tiles
    not
    brick110_stud92_plasterbrdMR13_insul50_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:
     .plasterbd
  - name things that are standard differently:
    2.5 text   is standard;
    Black 2.5 bold   is not standard.

COMPREHENSIVE

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

WORKABLE

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.
e.g.
brick110 / stud92 / plasterbrdMR13
became
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.

CONCLUSION

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.

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.

WHY IT IS 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.

WHAT CAN A BIM MODEL DO?

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).

TAKING RESPONSIBILITY

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.

THE PRACTICAL REALITY

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.

CONCLUSION

'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.

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?

TOLERANCES

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).

MODELLING WALLS

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.

CONCLUSION

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.

Schedules from BIM - why is it so hard?

One of the uses of BIM, and increasingly a deliverable, is that what is on drawings matches what is in schedules.
In theory it seems simple. If your BIM software is a database you just extract the data.
But just because it is possible doesn't necessarily mean it is practical. Can the people who provide the content and manage schedules do it themselves or do they require specialize computer skills (or assistance from some-one with those skills) to do it?
Do I fire the person who knows the difference between a passage and a privacy mortice latch, and replace them with some-one who knows the difference between a type and instance parameter?

Schedule creation and management is poorly supported in BIM authoring softwares. It is as if they are an afterthought, something to assist drawing creation, rather than important documents in themselves.

Why Schedules are Important in BIM

Human Comprehension

I have previously written about BIM being a deliverable for construction in its own right. The conclusion at the moment is it can't. Therefore we will continue to rely on drawings and schedules to communicate to other fellow humans. Even if you can export data from the BIM model to another database, at some point a human is going to have to read and understand that data.

Quality Assurance

Schedules are a great way to test data for errors. By manipulating how schedules are sorted and filtered obvious mistakes can be quickly identified.
They can also help rationalise design decisions by exposing similarities (or unnecessary dissimilarities) between elements.

Consistency

But by far the most important reason to use BIM for schedules is consistency. By using data extracted from objects that appear on drawings there is going to be much greater consistency between drawings and schedules. This is often not appreciated as the inevitable errors in manually constructed schedules are discovered by some-one else further down the chain. As a young site engineer once told me, "BIM projects are great, I don't have to spend hours checking schedules match drawings, I just know they are going to be right".

How Schedules Work in BIM

Being of a practical mind I am going to provide a specific example - using Revit.  Not because Revit is the worst offender (I suspect other softwares don't even have the same level of functionality), but because I use and know it, as do many other people in the AEC industry.

In Revit you build a 3D model, then create views (plans, sections, elevations) of that model.
Annotation (dimensions, notes, tags etc) are added over the top of these views to create actual drawings, which are then placed on drawing sheets.

Schedules are another type of view of the model, except they just show data - values placed in parameters associated with objects in the model. This data may include dimensional information, location information, descriptive information, etc.
You can control which data to show, in what order, and include headings, totals and rudimentary formatting.
These schedules can then be placed on drawing sheets.

Schedule data can also be shared with other softwares. There are three methods:

1. Schedules can be exported as a text file in CSV format, (comma or tab delimited), that can be imported into other spreadsheet and database software.
2. By utilizing custom written software code data can be exported to proprietary formats like MS Excel, data can also be imported back into Revit from that proprietary software.
3. Revit can also be connected via custom written software code to an external database, where data can be synchronised between the two.

 Is Exporting the Solution?   

Once a schedule is exported the link between drawings and the schedule is lost. Any changes made in the spreadsheet or database software will not be reflected in drawings. And any changes in drawings made after the export will not appear in the schedule.

So what, you might say,  that is how we have always done it. If someone makes a change they have to "talk" to others so they can do what is necessary to keep the two aligned (see my views on this in the comments of this epicBIM post).
But this where errors creep in. Even if this talking happens, there may be a misunderstanding, it may get forgotten, other priorities may mean it does not get done in a timely manner.
In my experience all but the very small and simplest schedules done this way are full of errors.

Which is why owners and contractors are increasingly insisting schedules be directly generated from BIM models.

So exporting schedules is not a solution. Either the schedules need to be fully managed in the BIM authoring software, or there needs to be a two way link between the BIM software and the spreadsheet and /or database software.

Both of these methods are possible. But how practical are they? Can ordinary architects, engineers, interior designers use them without requiring advanced computer skills?

Using Revit to Manage Schedules

As I said above I am using Revit as an example of BIM authoring software, I am not advocating it, nor am I inferring that it is better or worse than other BIM authoring softwares. But I believe it is necessary to be very specific to get a real understanding of the issues and problems involved.

Revit schedules are 'live'. Change a parameter in an object (e.g. a door) and it will instantly change in any schedule that includes that parameter. Change it in any schedule and it will change the object. (Note that not all BIM software works this way).

This is powerful - and dangerous. For example you can change the width of a door from within a schedule, which can lead to situations where the door no longer fits in the wall. Or change the size of a piece of equipment, which means it no longer fits in the room. As you can appreciate letting a schedule writer who is unfamiliar with how Revit works, or is not conversant with the building's design, loose in the BIM model can lead to havoc.

On the flip side those modelling need to be aware that what they do effects schedules. If they place a new type of door that door has to have the same parameters as other doors in the project. And those parameters need to be filled in.

Scheduling in BIM requires a more holistic approach by all members of the team.

But back to my original point - how practical is it to produce schedules - using Revit as an example?

Problems Creating Schedules:

Categories:
Revit creates schedules based on categories - doors, windows, plumbing equipment, etc. (It is possible to create multi-category schedules, but they become complex to manage).
This means it is important objects are created in the correct category. This is not generally a problem, except when you need to create a custom object for the in-built system 'families' (Revit's name for components).
For example if you create a precast concrete panel as a stand alone object, you can't make it a 'Wall' category so it appears along with all the other walls in schedules.
(There is an undocumented work around. But it doesn't work for all categories).
Also Revit's way of managing custom objects - 'in-place families', does not support all categories. So for example if you want to model a complicated stair rather than battle with either of Revit's inbuilt stair creators you can't schedule it along with other stairs.

Inconsistent Parameters:
In schedules each column represents a parameter that appears in the objects you are scheduling. If all objects you are scheduling don't have the same parameters, or use different parameters for the same thing,  there are going to be problems with your schedules.
The user has to manage this for custom parameters ("Shared parameters" in Revit), but Revit itself is not consistent.
In Revit there are two ways of creating stairs - by sketch or by component. Even though they are the same category as far as schedules are concerned, they don't have identical parameters, so you can't consistently schedule them together.

Doors:
On large projects doors are traditionally numbered after the room they open into. This practice means doors can be easily added without disrupting the numbering system, and it is easy to identify where they are.
Yet by default Revit numbers doors consecutively.
In theory you could use the 'Room To' parameter as the door number, but you can not tag this parameter in a drawing, so in practice it doesn't work.
All this makes creating door schedules unnecessarily complex - and non-BIM. As we have to resort to manually numbering doors after rooms the automatic link between drawings and schedule is lost.

The situation is actually more complex, as the the way Revit handles 'Room To' and 'Room From' is not consistent or workable, particularly since the introduction of the 'Room Calculation point' entity.

Room Finishes Schedules:
One of the most frustrating limitations is that we can not schedule room finishes in Revit. Although there are materials to all elements around a room, Revit can not gather this data into a schedule.
There are addins that attempt to do it, but really it should be native to all BIM authoring software.

Rooms in Linked Files:
Revit allows items in linked files to be scheduled, which is great. But it will only report rooms in the current file. So if you have furniture in a separate file (a common practice) which links in the building containing rooms, Revit won't report the room the furniture is in unless duplicates are made of all rooms and placed in the current file.
Once again, very un-BIM like - separate duplicates of the same thing.

Problems Editing Schedules

If you are managing schedules in Revit you need to edit them. But really all you can do in Revit is change the value of a 'cell'. There are no functions that help navigate a schedule.

• You can't keep headings visible while scrolling through a schedule.
• Rows aren't numbered or highlight-able.
• Column widths of a schedule is the width printed  - which means columns are often too narrow to read their contents in a schedule view.

Where am I?

How can I edit it if I can't see it?

This lack of function makes any but the smallest schedules near to impossible to work on in Revit.

On large projects editing cells in a schedule can be very slow. Particularly materials. It seems Revit makes the changes after each cell edit. Maybe a 'Save' button would help.

Problems Printing Schedules:

The biggest issue is it is not possible to print a schedule across multiple sheets. There are work arounds, but they require messy set-ups and be actively managed to ensure schedules remain within sheet boundaries.

There is also  no in-built method to manage revisions to schedules (clouds don't work as schedules move as rows are added or deleted.). Again there is a work around - create a revision parameter and add it to schedules.


So although it is possible to do most schedules within Revit, it is not necessarily that practical.

Exchanging Data or Linking Software to Manage Schedules

Another strategy is to exchange data with, or link, another software package to Revit.
The advantage of this approach is software more suited to schedule editing and printing can be used. Software that is easier to use, and that schedule writers are familiar with.

Exchanging Data:

The most common methods with Revit is to use an addin that exports and imports to and from MS Excel. I have also seen one that does this with Google Docs (I don't think it is available any longer - pity).
Typically a schedule is exported to Excel, the Excel file is edited, then imported back into Revit where the changes are embedded into matching parameters.

Sounds simple, and works well when what you are doing is simple. But it can quickly become a web of (sticky) spaghetti if care is not taken to be consistent when setting up schedules.

This method can be very dangerous in the wrong hands. Changes in Excel are just text or numbers, and may appear benign, but once put back into Revit they can change the model in ways unintended.

Also keep in mind the process is controlled by addins and not Revit, you are relying on the skills of the addin software engineers to control this process. Some do it well, some are, well, just dangerous.
For example how does it handle objects in groups?

Do I really want to destroy my groups?

It is possible to establish a practical workflow as long as limitations are set on what can be done where. There needs to be restrictions on what can be changed in Excel, typically parameters that control geometric sizes of objects. For example the width and height of doors, (although door panel thickness and stile widths, being within the object, could be editable). Obviously no object can be added via Excel, that has to be done in Revit. Generally it is not possible to add columns in Excel that don't get written back to Revit, although there may be addins that allow this and manage that process.

The main problem at the moment is that all the addins I can find overwrite previous Excel imports. What this means is that any formatting and re-arranging done in the Excel file gets overwritten. Sounds trivial to a software engineer but a deal breaker to an interior designer or architect (maybe not so much to engineers).

The underlying disadvantage for exchanging data is it is not 'live' - maintaining the link between drawings and schedules is a manual process. This is not necessarily as bad as it sounds. Even with instant updating in Revit if you don't issue both drawings and schedules when either are changed the effect is the same - there is a mismatch in the information others have been given.

Linked Database:

It is possible to establish a 'live' link between the Revit model and a separate database. AutoDesk provide a free addin - Revit DB Link to achieve this (available via AutoDesk subscription).

But it is not a full solution. You need to set up the database you are linking to. Then you have to create an interface that humans can use to access and edit the data. This requires computer programmers (or removing some-one from billable work) to set up and manage. And on-going any change to layout or formatting has to be done by these experts (including changes beyond your control like software updates). These systems are so customised that if the person responsible leaves you may be left with a system no-one can use.

So in theory it might sound like the ideal solution but in practice it rarely works out.

A Note on External Software

Relying on external software is a valid strategy, but my concern is it removes responsibility from the BIM software houses to provide workable solutions. Instead of one group spending thousands of hours coming up with solutions many groups spend millions of hours on multiple solutions to the same problems.

And then there is the quality of addins. I have lost count of the number of unusable addins I have tested.

Another failure

If schedules from BIM models is a core requirement then the BIM software houses must provide a way to do it. A way that their ordinary users can manage on their own.

Conclusion

If you can find the right addin (and this is a big 'if') exchanging data is probably currently the best solution. But don't expect it to be easy. Take the time to plan, test and validate it does what you need before implementation.

At the moment it is unnecessarily difficult for the average architect, engineer or interior designer to create and manage schedules from their BIM software. Often the degree of this difficulty leads to errors in documentation that are equivalent, although different, to errors in documentation that occur when schedules are done manually.

Despite what BIM Evangelists say, BIM is dependent on software, if we don't have the tools we can't do it.
And if the expectation is that schedules are generated from BIM models, (which I believe is correct), then we need the software resources not to just make it possible, but to make it practical for the AEC professionals who create and mange them.

Four Things BIM Doesn't Do

If we make the assumption that BIM contains all information about a project (or the 'index' for locating information), what is missing?  What stops us being able to issue a BIM model without drawings? (a question I asked in my post  Can BIM alone be used for Construction.)

I'm not just talking about lack of software functionality, but missing from current BIM processes.
I don't believe these missing things are intractable, a reason to not use BIM. The problem is that they don't seem to be a part of BIM discussion, let alone being addressed.

A BIM model is in theory a virtual representation of a real building. The assumption is that as long as everything is represented that is all that is required. Any shortcomings in practice is purely due to a lack of detail in the model, or poor modelling practices.

Keep in mind here that a BIM Model is not drawings. Currently we use our BIM softwares to produce drawing sets that are contract deliverables. But what about the utopian future BIM evangelists say is inevitable? What would a fully mature BIM model be like?

• All information is in the model, one only needs to 'zoom in' to expose more detail.
• Dimensions can be extracted from anywhere in the model.
• All information about individual elements is available via the parameters they contain (which may include links to data outside the model).
• Drawings are not created by the model author or contained in the model. Users create their own as they need them.

Sounds pretty good, not unlike many descriptions of what BIM is. But this is the description of a fully mature BIM model, once all the various authors and contributors have done their work.

BIM models don't start out with such comprehensive information. They can't. All construction projects are a series of decisions based on previous decisions. Decisions are iterative, a decision may cause a previous decision to be revisited and changed. Interesting the original intent of Revit (an acronym of 'Revise' and 'it') was to make it easier to change design documents, making optimization of designs more practical. Only later did Autodesk re-badge it as a BIM tool.

So when this description of what a BIM model should be is assessed against requirements during the design phase it falls short. The tools to communicate, manage and store information around decisions are missing.

So what are the four big things BIM doesn't do for designers.

INTENTIONALITY 

Although everything is not known in precise detail during design phases there is still information that needs to be communicated. Design intent, what is important and what is not. What requirements are, and which of those are critical, optimal and desirable.

Assigning a wall as 'generic' only says a decision hasn't been made. It doesn't say what the limitations for making a decision are. And it only applies to individual elements, not to groups of elements.
Another example is dimensioning. Not all dimensions are equal in importance. The clear width of an escape stair is more important than the width of a store room. How do you convey this in a BIM model where the recipient extracts their own dimensions?

Rob Snyder, an architect and software developer at Bentley, has attempted to provide a solution. In his own words:

"A model is itself informational, while it 'lays out' an environment of information. Within that environment, we draw attention to specific things and instruct people to look at those things and to do something. These 'drawings of attention' are statements.

There are models and data. These are 'environments'.
There are drawings. Drawings are 'statements'.

I think of it like this - a statement is any means of drawing attention to something specific within an environment, and then saying something about that thing. In AEC, this has conventionally been done by making a drawing. A drawing draws one's attention toward something specific, and says something about it."

Rob Snyder, LinkedIn discussion Oct 2013

Bentely's solution to this problem is 'hypermodeling' - software functionality that provides links within a model to drawings, typically 2D details, although in practice the link can be to anything. It is basically an implementation and extension of web 'hypertext' (now usually referred to as 'links') to modelling.
What it does is provide visible 'tags' in the model that indicate points of importance, complete with links to why it is important.

Graphisoft have a similar solution, which they call 'Hyper-models' under the 'BIMx' brand name. Similar to Bentley it provides links to 2D drawings from within a 3D model.

Is this THE solution to the problem of intentionality?
Snyder, and Bentley's implementation privileges 2D drawings. Which is not surprising considering Bentley's 'evolutionary' approach of combining CAD and BIM. Graphisoft's approach is not so much a solution to intentionality as simply another way to access drawings.

But conceptually there is no reason the idea of hyper-modelling has to privilege 2D drawings. A tag could link to, say, an exploded 3D detail, a render of the architect's design intent, or a performance brief for a mechanical system.

TOLERANCE

BIM models are precise. Computer software requires precision. But the real world is not that precise, particularly where humans are involved.
It is not possible to always measure to the millimetre on a building site. Not all materials are uniform in size, even manufactured ones. Materials and elements move; concrete shrinks, bricks expand.
I discussed this issue in my post Accuracy vs Precision, but in this post my concern is the inability of BIM softwares to cater for the representation and management of tolerance.
Designers - architects and engineers, have to allow for tolerance in their designs if they are to be constructible.
But how do they do this with software that has no allowance for tolerances? Software that requires things to be exactly aligned and touching to work?

An example:

Walls
Walls are defined by the layers of materials that they are constructed from; e. g. plasterboard / stud / plasterboard. The thickness of these are set by the manufacturer's nominal thickness. In this example 13 / 92 / 13 = 118mm. But will this wall be exactly 118mm, everywhere, when measured on site?
Now say you have an escape corridor that has to be no less than 1200mm wide, with 118mm walls on either side. How do you ensure 1200mm is the dimension the building inspector measures after it has been built? You need to make a decision about where it is set out from (an intentionality issue - see above) and where construction tolerances are taken up. The question is how do you do this in a pure BIM model?

A common workaround is to add tolerance to material thickness, so 13mm plasterboard become 15mm. Problem with this is the estimator may cost 15mm plasterboard instead of 13mm, or worse the contractor orders 15mm plasterboard.
Another workaround is to model tolerances. For example add a 'tolerance' material 2mm thick to either side in the above example. The problem with this approach is you see things that are modelled. But tolerance is not something that gets built, it is an allowance that get absorbed when the design becomes real (like collapse of a quantum wavefunction). So it can get confusing for people when tolerances are modelled.

Like intentionality there are many ways this issue could be dealt with. But first it needs to be recognised a problem that requires a solution, something I have yet to see.

COMMENTS 

During the design phase there are many questions and unknowns floating around. Rather than everyone keeping separate lists placing these directly in the BIM model ensures they are available to all participants, in something you know they are going to look at.
What I like about comments in the model is the issues they point out remain in everyone's face until resolved. And in any case if in a proper BIM model they can be scheduled to create lists for those who like lists.

The problem of comments is similar to that of intentionally discussed above. The difference is intentionality is part of final deliverables, comments are part of the process of creating deliverables, but not a deliverable themselves. Nevertheless the solution to both may be similar.

Whilst it is true that elements can have comment parameters, comments do not necessary relate to individual elements. They may relate to multiple elements, elements missing, ("window required here?") or general comments not relating to any particular elements, ("redesign this area").

I find it surprising BIM software doesn't have this ability, or that people are asking for it, as it is common in lots of other softwares.

Once again there are workarounds, but they are usually annotation based rather than embedded in the BIM model. In Revit I use an annotation symbol with parameters that can be scheduled, but of course these are only visible on drawings, not really a BIM solution.

REVISIONS 

It is a normal requirement to identify changes between document issues. The method to do it on drawings is well established. But there doesn't seem to be an established method for BIM.

The method drawings use is not really suited to BIM.  It is not possible to manually flag a revision in the model. A change in the model may effect many drawings, each has to be tracked down manually to have a 'cloud' added. Revisions are added after the fact, whereas the act of making a change could in theory automatically flag a revision.

I have to admit I find the traditional method of managing revisions painfully time consuming, hard to enforce, and often uninformative (how many times have you seen "General changes").
But whenever I have suggested alternative methods that are more efficient and informative it fails to be implemented because it is not "the way revisions are done".

Other softwares keep 'histories' that could generate revisions, so it is technically feasible. (Andreas Ricke of AR Software Solutions has a Revit add-in that can track changes).

But what is missing is an agreed workflow or method that communicates changes. A few off the top of my head: Colour coding elements changed since last issue, automatic attachment of links to changed elements (like hypermodelling).

I'm not sure why a better method for managing revisions hasn't surfaced. Maybe it is a chicken and egg situation. The software houses are waiting for some agreed method from the industry, industry can't explore alternatives because the software can't do what they need.

Conclusion

To me these are the four big things BIM doesn't do that are holding back BIM from being a deliverable for construction in its own right.

I don't believe any are insurmountable. Although they will ultimately rely on software functionality, they require agreed workflows. Something that should come from the AEC industry. We shouldn't just wait for the software houses to make something up they think they can market.

Anyone have suggestions about where we start?