Use a Revit Road Map to get to BIM

Unless you want to get hopelessly lost all journeys require a road map. Sure you can wing it and see where it gets you, but using a road map means you will not only get there faster, but also arrive at the correct place, not a place that might or might not be where you need to get to.

BIM is new and still evolving. Pretty much everyone is on a journey to implement BIM into their work practices. We all have need of a road map.

BIM may be a process, but it is a process that is not possible without software. You can't create models, or extract information from them, without software. So the beginning of any road map starts with the software being used. And you can't do anything if no model exists, so the obvious starting point is BIM authoring software. Revit is my example, for no other any reason than I know it well. The specifics may differ but any BIM authoring software will require similar milestones in their road map.

Not all software is BIM capable

It may seem obvious, but it is worth stating: Make sure the software you are creating a road map for is BIM capable.
And be aware that BIM authoring software works differently from CAD and 3D drawing programs. For a start in BIM capable software many people work together in a single file. What they do will have an effect on everyone else working in the model. Things are shared - where a particular wall is required the same wall component has to be used by everyone.
The model is also used for more, much more, than just drawing or image production. It is used as a repository for information about the building. A fire rating is given to a wall not just so its tag will be correct, it is so anyone using the model, from fellow designers, other engineers, and contractors, can tell instantly from within the model (or exports of that model) that the wall is fire rated.
And because it contains this information the model can be used for checking. Fire rated walls and fire rated doors can be colour coded to check fire compartmentalisation and that fire walls have corresponding fire rated doors.

If your authoring software can't do these things then it is not BIM capable. Not all software that do 3D modelling is BIM capable. A BIM add-on to a CAD (whether 2D or 3D) program is unlikely to be BIM capable to any degree of sophistication. Also it can be difficult to get users to model BIM if they have the opportunity to just draw. Don't waste your time on these softwares.


There is nothing particularly unusual about a BIM software road map. If you use proper BIM software the way it was designed to be used the result will be a good quality BIM model suitable for others to use. Indeed you can do no more than this. We are not software engineers, none of us should be expected to delve into the innards of our software to get a particular result. If that is a requirement it is beyond the scope of design professionals and should be paid for, so someone else can do it.

PEOPLE

I said above any BIM road map begins with software. Not entirely true. First you need the people in place to make the road map and to oversee the journey. No journey is going to happen by itself. Just buying software and making it available is no different from dumping a whole lot of unicycles in the office and expecting people (who?) to ride them (how?) to get somewhere (where?).

First there needs to be someone on the executive team responsible for making it happen. Just reporting to senior management on progress will not work, someone senior has to actively push it.

There needs to be an expert responsible for implementation, usually a BIM Manager.

Project teams need to be restructured.
Every project must have a Model Manager responsible for the well being of project models.

Team responsibility must be adjusted.
Individuals must be made responsible for the totality of parts of the building, each being responsible for managing the drawings and schedules their part of the building requires. For example the Facade: from window including elevations, details, material schedules, Interiors: walls, including wall types, doors, door schedules.

To assist on-going implementation there should be a component (called Families in Revit) manager responsible for creation and management of component libraries.

And finally there should be a system of "experts", people who gain expertise in particular aspects of the software and/or BIM processes. Like a stair expert, railing expert, wall expert, etc.

But perhaps the most important issue to do with people is a cultural change across the organisation. The acknowledgement that the task at hand is no longer to produce drawings, pictures or standalone schedules, but to produce a virtual model of a real building, a 'Digital Twin'. This is why project teams need to be restructured.
Non-users of the software must also change their approach. Rather than asking for a particular drawing or set of drawings, senior architects and engineers should be asking for information about a particular part of the building. If they are seeking to validate or check something ask for that information. Traditional drawings may not be the most efficient way to present it. In the fire rating example above a coloured coded set of 3D views will provide more digestible information than a black and white plan with wall tags. Quicker to produce and less tedious to check.

COMMUNICATIONS STRATEGY

After defining who will do what the next milestone is to set a communication strategy. There is no point going on this journey alone, the whole organisation has to come along as well. And the strategy must ensure stragglers don't get left behind. After all, not everyone wants to move forward.

A communication strategy may tie in with existing processes, so can vary from office to office. But as a minimum there needs to be:

• In-house BIM Software Manual
• Regular Training (at least initially)
• Regular Seminars (where 'experts' can shine)

A regular newletter to keep everyone informed, and hopefully interested, could also be added to the list.

BIM Software Manual

The BIM Software Manual must be instantly accessible to everyone, and be searchable. It must be easily updated and added to, and allow users to comment.
The only thing I know of that fits this criteria is an on-line wiki. Word documents printed to PDF are not even close, even if those PDF pages are added to the office intranet. I once worked in an office where the original word file for the BIM manual had been lost, making it really, really, hard to update.

Creating a wiki these days is trivial. It can be done with any of the many web site creation services available. You can lock it down with passwords, or keep it in-house by creating it on your own servers. WordPress.org is a free version that can be installed on your office's servers. I've installed Wordpress many times, it is not hard or time consuming. You can probably use a Sharepoint Intranet (don't use it to 'share' word documents as a manual though) if you already have it, although the last time I tried that it was so time consuming I gave up. Maybe it has improved.
If you can't, or have trouble, getting official permission set up a demonstration wiki on a free web creation service, like Wordpress.com, or free hosting service with a wordpress.org install. Just make sure you use one that can export the site (i.e. not Google Sites)

Because a wiki is interactive you don't have to wait until you have all the information available before setting it up. Just set up it's headings and progressively fill in the information, in any order. If you already have a CAD manual you might have a whole lot of drafting standards you can immediately put in it. And don't worry about getting headings right, you can easily change them later on, including their order. It is not like you will have to cut and paste enormous amounts of text within a word document.
What ever you do don't fall into the trap of "we'll do when we finished the manual". The reality is the manual will NEVER be finished. As the office becomes better at using the software processes should be changed, things that don't work should be revised, and then there is the fact software changes with every new version. You will never get on top of it so just accept that and work with it.

The type of headings you might start with could include:

PROTOCOLS
Protocols for managing Revit
STANDARDS
In-house standards, including naming, to follow when using Revit.
PRACTICE
Explanations and procedures for workflows
GUIDELINES
Guidelines for best practice.
TIPS and TRICKS
Tips and tricks for using Revit.
ASSISTANCE & HELP
Sources of help, specific problems, bugs, and their solutions.

Regular Training

You can't expect people to be able to use software without some training. Even if they know how to use the software new people will need to be introduced to the way your office does things.
For new learners short bursts of training of no more than 4 hours are better than a whole day, or multiple day long sessions. Also no more than 5 to 6 people at a time, any more and some will get left behind. For more experienced users keep sessions to an hour and on specific topics. They will be busy and won't be able to spare more time than that.

Regular Seminars

Set up regular seminars, with the emphasis on regular so people can plan to attend them. Lunch times are best as you are more likely to get people attending. Provide lunch and even those not that interested will attend.

Newletters or Regular Posts

I have found a good way to keep everyone informed and somewhat interested is a regular email newsletter, or if your organisation uses social media, regular posts. Include things to do with the software and its use, titbits about general IT, BIM and your industry.


So that is the soft start, setting up the framework to make it happen. Now for the hard information you will need.

FOLDERS & FILES

Anything involving computer files requires some way of organising them. Unless you are a brand new start up or moving from paper straight to BIM you will already have a way of organising computer files. But it is worth at least reconsidering the way you organise files to suit your BIM software.

I find many design offices have electronic filing systems based on archival storage, usually following the paper filing system that predated computers. But we also need somewhere to store files currently being worked on - Work in Progress (WIP).
The requirements for WIP is different from archival storage. People are opening, saving and closing files much more often; linking of files makes the location of file and paths critical; long folder and file names become a productivity hindrance.
So it is worth developing a folder structure exclusively for WIP that is not embedded within the archival system.

Another missing part of most computer filing systems is that there is no place to keep current documents. For drawings that is the equivalent of the old project drawing stick set. As drawings change so quickly now it is impractical to rely on a printed set of drawings, so there should be a place in the filing system where the latest drawings can be kept for anyone to access.
Of course if you use a document management system (like Newforma, Aconex, BIM 360, etc.) you will have that functionality and not need it in your filing system.

It is also worth putting some thought in to file naming. Because of the way BIM authoring software files are shared and linked together file names can be a help or a hindrance. Overly long file names are a pain for everyone, as are highly codified names. One thing worth putting in Revit file names is the version, but keep it short: R18 somewhere in the name is quite adequate.

NAMING STANDARDS

Unlike CAD and 3D drawing programs BIM software have a lot of things that are named by users. When I say a lot, I'm not exaggerating. Here is a list from Revit 2017:

Area Schemes

Arrows

Beam Systems

Browser Organisation

Cable Tray Fittings

Cable Trays

Ceilings

Color Schemes

Conduits

Curtain Panels

Curtain Systems

Design Options

Detail Groups

DGN Export settings

Dimensions

Duct Fittings

Duct Systems

Ducts

DWG/DXF Export settings

Family File names

Family Type names

Fill Pattern

Filled Regions

Flex Ducts

Flex Pipes

Floors

Foundation Slab

Handrails, Top Handrail

IFC Export settings

In-place Families

Legend Names

Levels

Line Patterns

Line Styles

Linked Files

Materials

Model Groups

Mullions

Pads

Phase Filters

Phases

Pipe Fittings

Pipes

Piping Systems

Print Sets

Print Settings

Project File name

Railings

Ramps

Reference Planes

Repeating Components

Roofs

Schedule Names

Scope Boxes

Selection Sets

Sites

Spot Coordinate

Spot Elevations

Spot Slope

Stacked Walls

Stair Parts (10 in total)

Stair Path

Stairs

Sub-Categories

Text

View Filters

View Names

View Tags

View Templates

View Types

Walls

Worksets

This list excludes naming and numbering required for normal document production - Sheet numbers, Sheet titles, codes for tags, etc. So you can't just take your existing CAD manual and "adjust" it.

The important point here is that users should NEVER be in a position where they have to make names up. If everyone is making their own names up with no guidance how an earth can you expect anything other than a massive mess? Where users are unable to find what they need (e.g. a wall type) so create a new one, leading to multiple components for the same thing.

It is critically important that every single thing that can be named has guidance on how it should be named, and that guidance has to be articulated as a standard that must be followed.

But that doesn't mean naming has to be rigidly defined. Defining a naming structure with guidelines will have more chance of being followed than a fixed list that has to be referred to, or worse, memorised. The same guidelines can even be used for naming multiple types of things.
As long as the guidelines are not too ambiguous. I have seen a manual where the naming guideline for components was a prefix that described what it was, typically its category. But it didn't have a list of standard prefixes so I found casework family names prefixed with Case_, Casework_, Casement_,  Join_,  Joinery_  & Joineries_. Not very helpful!

I've written about naming before (The Nature of Naming), but I'll repeat the important points here.

• Be literal - names should be understandable to anyone not working on the project
  (pb13, not P01 or L13).
• Keep name lengths to the minimum necessary to still be understandable, abbreviate and truncate where possible. 
• Avoid padding.
  (Line-Xhatch   not   Line - Xhatch;    pb13/stud92/pb13   not   pb 13 / stud 92 / pb 13)
• Use Major-Medius-Minor name schema
  (Glass Clear not Clear Glass)
• Define structure but be flexible on specifics
  (plasterboard13,   plasterbd13,  pbd13,  pb13 are all acceptable)
• Consider how names will list alphabetically
  (Light, Medium, Wide not Light, Medium, Heavy)
• Use CAPITALS purposefully
  (e.g. use capitals for views on sheets, sentencecase or lowercase for all others; capitals for fixed prefixes.)

There are a few of other points to consider when naming in BIM software.

Names are for your purposes only, it is NOT project data:

Names are what I call HUIDs - Human Understandable IDentifiers. They are for the humans creating the model, for everyone else there is the data within objects for them to use.

This means that names must be human understandable. Highly codified naming systems (like using Omniclass numbers or IFC names) defeats the purpose of having names in the first place. It is also pointless because that data can be part of the data within the object anyway.
This is why I refuse to follow any outside demand to use their naming scheme, typically from contractors, but also by COBie. Happy to provide a parameter for their name, but names in our software are for our purposes only.

Name what something IS, or name for what it is FOR:

When deciding on a name it seems easier to name it by what it is, (Text 2.5, Solid Grey, Line 05, pb13/stud64/pb13). This is a carry over from hand drafting which found its way into CAD. You didn't draw using a wall, you used a 0.5 pen. But in BIM software you do "draw" using a wall, and not only that, you can name it what you want.
So in BIM software if you want you can name things after what they are for. Instead of naming a wall type pb13/stud64/pb13 you can name it Internal Stud-Typical.

There are a number of advantages to doing this. It is easier for users to identify what to use - there is less likely to be duplicates for the same purpose, and it is easier to change later.

Say you have two people working in the same project, one thinks internal walls need insulation, the other doesn't. One creates pb13/stud64,insul50/pb13 the other pb13/stud64/pb13. The project becomes a mixture of the two types. If the name was Internal Stud-Typical from the start they would have had to fight it out (or actually do some research instead of guessing) before it got to that stage. And even if they made the wrong decision no big deal. As all internal walls are the same type so just the properties of that type need to be changed. If they each used their own walls someone would have to find all instances of the wrong walls and changing them to the correct type.

This follows through to annotation objects. Name a Filled Region Clearance-Disability instead of Xhatch Red and it is trivial to change all instances of filled regions used to show disability clearances to something else, just change the parameter values of  Clearance-Disability. It also makes it possible to create view filters that only hide disability clearances. If you don't do this and you need to make a change then every occurrence across all views have to be found and manually changed, and forget about using a view filter.

That said it can be difficult to enforce naming strictly based on what something is used for. It can also get messy when projects become complex, particularly during documentation. Indeed some projects end up without a "typical" internal wall at all.
A good solution is a hybrid - usage and content: INTstud_pb13/stud64/pb13. Or one I use during documentation - code and content: W.S01_pb13/stud64/pb13.

Yes, a bit redundant, and yes, more management as the name has to be changed if the content changes. But remember names are HUIDs, they are there to help users do their job. And if a bit of redundancy, or indeed management overhead, helps, then it is perfectly justifiable.

Published Standards

I hear you all saying about now, "Can't we just use existing published standards?" Sure, you can try.
Firstly they don't cover everything that needs naming, secondly keep in mind BIM standards are not created to make your work easier, but so it is easier for those that use your models. Remember that names are for your users, not for others, so what is the point following a standard created for some-one else?
That said it may be worth reviewing standards and using the bits that are useful to you, or altering it to make it useful to you.
For those interested have a look at bimblog.house as Dan tries to force his house to follow published BIM standards.

PARAMETERS

Besides all the things built-in to Revit that have to be named, there are things that users create that must be named, such as parameters.

Parameters are used to drive parametric behaviour (Width in a door family), for tagging, (Mark and Type Mark), and scheduling (Width, Mark, Type Mark).
There are Family parameters that are created to work within a family only (typically for parametric behaviour), and Shared Parameters which work across all families and projects (only Shared Parameters can appear in tags).

Not all parameters require naming, some are built-in to the software, like System Parameters that behave like Shared Parameters but can not be renamed.

Besides naming there are other things that users require guidance on:

• Parameters have a data type: Integer, Number, Length, Material, etc.
• Parameters are grouped under built-in parameter headings: Dimensions, Materials, Construction, Graphics etc.
• Parameters can be Type driven (different types of things vary), or Instance driven (each item can vary even if the same type).

Managing parameters is beyond the scope of this post, but things that should be considered are:

• Define what built-in parameters are to be used for.
  For example Type Mark is tag code, Type Comment is drawing note, Description is schedule description.
• Create naming standards for parameter names.
  Major-Medius-Minor using CamelCase is popular. Don't use math symbols in names (like dashes or slashes).
• Create a different naming standard for Shared Parameters.
  Shared Parameters are seen by everyone who gets the model. It is polite to identify it as your parameter.
• Guidance of parameter type heading to be used.
  e.g. Dimensions for gross parametric changes, Model Properties for changes to parts, Visibility for changes to object, Graphic for changes to representation.
• Guidance on data type.
  e.g. dimensions must be Length, array values Integers, materials Material (never Text), when Text may or may not be used.
• Guidance on when to use Type or Instance.
  e.g. Objects that are schedule by type should use Type parameters, Materials are always instance.
• Guidance on Project Parameters
  When should be used, when should instance parameter vary between groups. 
• Methods for managing Shared Parameters.
  Protocols for adding new parameters, location of Shared Parameter file, etc.
• Establish standard Shared Parameters that are required for schedules.
  Review your standards schedules and document which parameters are required to create them.

PARAMETER CONTENT

As mentioned above parameters hold values used in tags and schedules. To improve accuracy, efficiency and readability of tags and schedules it is worth revisiting the tag type codes you currently use and how your schedules are structured. Methods used in manually created schedules may be cumbersome in Revit, and there may be things you can now do that were too difficult to do manually.

For example paragraphs of descriptive text are difficult to manage in Revit schedules. Data should be kept concise as possible and separated in to multiple parameters.
This is not a quirk of Revit, it is a requirement for BIM. Computers don't understand descriptive sentences, they only understand precise data. Including the manufacturer, model, colour and supplier address all in one sentence, as one piece of data, will prevent anyone using the advantages BIM brings.

One of the things I find in manual schedules is that there is often duplicates, or close duplicates, in codes within different schedules. For example CO used for - concrete wall; to identify columns; and as prefix for material colours (CO01). Or WB for - masonry block wall; whiteboard; and weatherboard.
It is worth creating a unified list of standard codes for everything to prevent this happening. Now, I realise this is not actually possible, no-one can predict every code that may possibly be used in to the future. But it is possible to develop a naming system that divides up codes so duplicates are less likely.
I use a system that uses a category prefix. The examples above become W.CO,  C.CO  and  M.CO01. W.WB,  I.WB  and  M.WB. (I wouldn't actually use these codes, but you get the idea).

Another thing I commonly find is a confusion between what is a material (e.g. plasterboard) and what is a construction system (e.g. plasterboard stud wall). Then you see both the material and wall type are tagged PB in a project. But they are clearly different, and Revit makes it explicit because walls and materials are completely separate things.
To avoid confusion I use a totally different naming schema for materials than construction types (no prefix as per my example above). I also make sure material tags are graphically different from type tags.

LOADABLE COMPONENTS

Components, called Families in Revit, are separate files that are loaded into a project file. In Revit files are also different categories - Casework, Doors, Plumbing Fixtures, Windows etc.
Besides guidelines for naming the files there should be guidelines on how they are to be constructed, and how parameters are to be used in them. They appear in schedules which means the data between families must be consistent. And families are used by multiple people, so must not be overly complex to use.

Creating Families requires quite different skills to working in a project model, which is why I suggested above that a Family Manager be appointed. In fact I would go further and say that not everyone should be expected to create families. There should be a dedicated office family creator, or an elite of family authors (probably more realistic).

Even if handled by experts it is still worth documenting guidelines for creating families, a separate Family Creation and Management manual. Of course it should still exist within the office BIM Software wiki, still be searchable, still be commentable. But it talks to a higher skill level than the rest of the office manual.

There are a few standards available on Family creation. The AEC (UK) Revit Standard and ANZRS for example. If you involved in mechanical engineering you should definitely be referring to  BIM-MEP [aus].
But as I said above I wouldn't just absorb them whole, take from them what will work for you.

PRINTING & DOCUMENT CONTROL

To me printing and document control can be a massive time waster. It often takes hours to produce a print set with transmittal, all because there is no work process in place to automate what is an extremely simple task.
So it is really important to have a standard procedure in place for preparing drawings for issue, printing, and transmittal creation. One that any idiot can follow (then you might be able to get the project director to print their own drawings).

I don't know about other BIM softwares but Revit is crap at managing printing and document control (it doesn't natively print to PDF, nor can it add revisions numbers to file names when printing). The only realistic solution is a third party add-in to do it for you.
So pick one, make sure everyone has access to it, then document the workflow using your choice of third party software.

PROJECT MODEL PROTOCOLS AND GUIDELINES

Another time waster is reinventing the wheel every time something has to be done. And then there are things in Revit that if not done the right way at the beginning are either impossible to fix (like physically move a model to new coordinates) or difficult and confusing (like unravelling how groups have been set up), or just time consuming (like moving things between worksets).
So it pays to document (and then enforce) best practice workflows, protocols and guidelines for as many things you can think of. As a start I suggest the following:

• Project set up:
  Project Base Point, method to set Survey Point, CAD surveys etc.
• Managing Linked files:
  When to use linked files, what they contain, which files which sheets live in, etc.
• Worksets:
  Building breakup, which to have closed on loading, etc.
• Phases & Phase filters:
  What to use phases for, filters to use, Graphic overrides, etc.
• View protocols:
  When to use what type of view, managing working, management, temporary views.
• Category use:
  When to use what categories
• Group Protocols:
  When to use groups, groups and worksets, mirroring groups.
• Options:
  When to use, when to remove.
• Reference Planes:
  when to use, how to manage

Keep in mind this will be an unending task. Best practice is something that evolves, and should be constantly challenged. Comments can be valuable here if you encourage users to pitch in with their views (a.k.a. bitch and complain) when things don't work, or could work better. Just don't take it personally.

BEST MODELLING PRACTICE

It is always useful to have a model constructed as best it can be. This section is where you can set out how to model well, and by extension modelling expectations. Some of the things you might start with:

• Degree of Detail:
  e.g. only model what is visible at 1:50.
• Simplify - diagram rather than realistic representation:
  e.g. use model lines for joints and casework doors & drawers
• Hosting:
  on Levels or Reference Planes not object faces
• Best Practice for all system components:
  Walls, Stairs, Railings, etc.

Like Project Model Protocols & Guidelines this section will be forever a work in progress.

STANDARDISING WORKFLOWS & AUTOMATION

Once naming, protocols and guidelines are in place it becomes possible to define whole workflows - what is the best process for getting particular tasks done. And once you know what a workflow involves it is possible to automate all, or at least some of it.

This is when you start reaping the benefits of BIM.

Workflows can involve - model checking; for compliance with your manual; for checking completeness and accuracy of the model. Like the fire rating check mentioned above.
They can also involve tasks usually done manually, such as automating room numbering; door numbering; sheet and view creation; management tasks like renaming views.


But you can't do any of this if your models are not set up in a known and consistent manner. If you haven't got to your destination, the end of your road map.

Of course the end of your road map is not the end of your trip, you will continue to travel back and forth over that road. Those workflows and automations that are now possible need to be integrated into your BIM Software manual, replacing the old methods.

Indeed this Revit road map is not the whole journey, it only gets you an airport, the beginning of your next adventure that will take you to places you have never seen, or imagined. The journey to true and pure BIM.

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?