Too much Detail: Why is my computer so slow?

As BIM gets used on larger projects one on the most common complaints is how slow, and hence frustrating, working in Revit becomes. Using a more powerful computer only helps up to a point. There are metrics on what specifications a computer should have (which I won't go into in this post), but even an adequate computer won't make working on a large project the pleasure it should be.
Many people blame large file sizes, after all Revit project files of 400Mb are not uncommon.
Those that still think the CAD way believe that splitting a project into a number of linked files will solve the problem.
But if  Revit is to do all the things BIM is useful for, everything needs to be instantly accessible. Therefore  everything has to be in one file, or if in several linked files all those files need to be loaded in to your computer at once.
The reality is file size in itself, whilst an indicator of underlying problems, doesn't have a huge impact on working in Revit. The worst it does is slow down opening and saving the project file (which can still be a pain).
A greater culprit is graphic complexity, or geometric density. The more 'stuff' Revit has to deal with the longer it takes to do anything. Geometric density effects Revit in two ways: view regeneration and constraint calculations.

SLOW VIEW REGENERATION

The slowing of view regeneration is caused by the complexity of calculating hidden line removal.
I can appreciate this because back in the late 1980's, when AutoDesk released AutoShade, it would take 36 hours to do a hidden line image of a pretty simple office building. Which was longer than it took to manually trim out the hidden lines.
You may notice that software that is faster than Revit at showing 3D, like Navisworks, always uses a shaded view, no lines. In fact you can speed up 3D views in Revit by using Shaded visual style with Show Edges unticked. Try it on a large project.

When I say 'stuff', I mean detail. Every extra line that has to be calculated adds to the load.
The company logo on the Blanco cooktop family adds 136 lines that Revit has to deal with. And Revit doesn't know it is just a logo and not important.

Besides the number of lines, curves also present a calculation challenge. The line Revit draws to represent the edge of a curved surface is not based on a fixed location. Its location has to be calculated based on the angle you are viewing it from. The more curved surfaces, the longer Revit takes.

SLOW EDITING

Everything is connected in Revit, the more complex the things the object you are working on is connected to, the longer Revit takes. I had a situation where it was taking just under a minute to draw a wall in a car park. We racked our brains, ransacked google, but to no avail. Then we noticed it took no time at all to draw the same wall outside the car park floor. After some help from AutoDesk we worked out it was the Room placed in the car park that caused the problem. The car park floor was large with complex edges, and had a single Room element placed in it. Whenever a new wall was placed Revit was recalculating the Room area, (and whatever else it calculates), causing the delay. This is an extreme example, but the lesson is Revit does a lot of calculating on the fly. And although this may not be noticeable on smaller projects, it become significantly noticeable on large projects that are over-modelled.

OVER-MODELLING

I see this all the time. From the mechanical drafter creating photo-realistic fan units no-one will ever see, the new Revit user modelling a walking stick to place in a hospital project, to every family I have ever looked at provided by a manufacturer (a sink that included the bolts, wing nuts and brackets to install it is my favourite). And not just families. Existing conditions that are to be demolished modelled as if they are going to be rendered, curtain wall mullions modelled to shop drawing detail standard. The list goes on.

Here is an example of a chair in an elevation view. The simplified version shows the geometric extents of the chair without all complexity that the realistic model shows. To represent how many extra lines there are I printed both to separate PDF files. The realistic model file was 2.7 times the size of the simplified model file. When there are 10 chairs it goes to 4.5 times larger, and the time to process the realistic model file was noticeably longer.

Why do people do it?
Why do all that work when it will never be seen in any of the 1:50 to 1:200 scale drawings they appear? It wasn't such a problem with CAD, why is it a problem with BIM?
Because they can.
Revit has the tools to do exquisitely realistic modelling. And they are not that hard to use. Learners are the worst culprits. They think they are doing a good job (and they are if the task is to produce photo-realistic renders), but are completely unaware of the consequences. Other culprits are contracting BIM 'experts' who don't stick around to see the consequences of their work,  design architects who rely on photo-realistic images because they lack the imagination to visualise their design, and those who don't use the software but direct those who do, like project architects and directors.

I really see this issue as one of the biggest facing BIM use at the moment. Hopefully in the future as people become more familiar with BIM and computers get more powerful it will diminish. But for now it can't be ignored.

HOW TO AVOID OVER-MODELLING

The first step is to define the scale everyone needs to model to.
It is a simple metric that is easy to imagine and test. For example specify that only elements and detail that can be seen on a 1:100 drawing be modelled. It is easy to calculate the size of the smallest elements that can be modelled. Assuming a 0.25mm line thickness is used, anything smaller than 25mm will appear as a single thick line on a 1:100 drawing.
Specifying 1:50 (which is probably more realistic), anything smaller than 12.5mm will appear as a single line.

There is little point modelling to suit construction details. It is not possible to produce readable detail drawings from a realistic model. Things are too close together.
Flashing is a typical example. Steel flashing is 0.6mm thick. On a 1:5 drawing that is 0.12mm. By convention flashing is drawn using a thick pen, say 0.5mm, 4 times thicker than the flashing. And flashing is placed between, or on, other elements along at least one edge. Add in the pen thickness for those other elements and the full extent of the flashing is no longer visible on the drawing, there is just one thick blob.
Construction details have to be 'faked', things drawn further apart than they are so they are readable on a drawing.


SUGGESTED WORK PRACTICES:

• If it is intended the model you are working in will be used for documentation treat it as if you are documenting, even if at schematic design stage. Only model sufficiently for documentation. (Depending how clean the design process was, sometimes it is better to discard a schematic design model and start a new one)
• Keep in mind the fact that high levels of detail are only ever required for parts of the project, not everything in the project. An external view doesn't need the inside to be detailed, a view of one room doesn't require every instance of furniture in that room to be highly detailed across the whole project, a window sill detail is of only one window, every window doesn't require that level of detail.
• If additional detail is required for a particular part treat it as a separate task, don't alter your main model. Create new views rather than edit existing views, place one off families rather than replace an existing one with a more detailed one, create new easily identifiable materials, etc. Then these can be deleted from the project when no longer required, and removed when providing to other consultants (who also struggle with your huge files).
• Don't try and put everything into your project files. Consider making copies of the project file if radical changes are required to achieve a one off deliverable (e.g. an alternative design for discussion). Using Design Options is not always the most efficient path.
• Using different families of the same thing to show different levels of detail isn't good practice. Schedules won't be correct, counting numbers becomes complicated.
• Swapping out families is also not good practice. Unless carefully controlled parameters can be lost or altered, dimensions deleted and schedules completely messed up.
• If you want to use this method do it in reverse -  make a copy of the BIM project for rendering, swap out families ONLY in this copy.
• If Detail Levels aren't adequate use custom shared parameters and filters to control visibility in individual views. But be careful you don't make it so complex others receiving your model (or others working on it in your office) don't understand what you have done.

MODELLING TIPS:

• make use of Fine; Medium; Coarse Detail Level settings in families.
• simplify shapes; avoid curves. Particularly rounded corners and edges you won't see in a drawing.
• turn off visibility of model objects in plan and use Symbolic lines (2D lines) and Masking Regions. But don't use symbolic lines in elevation. They won't be visible in section and elevation views that are not exactly perpendicular to those lines. Use Model lines (3D lines) instead.
• use Model lines (3D lines) for very thin objects (e.g. wire shelf) and joints (e.g. where drawers, cupboard doors meet).
• use fill patterns instead of modelling (e.g. meshes).
• keep it simple. Model what everyone needs to know, not what the object looks like.   

Ultimately it comes down to training and oversight. Everyone working on your project must be aware of the consequences of over-modelling, and be familiar with the methods to avoid it.

Next post I'll offer a strategy for creating families suitable for both realistic views and documentation drawings.

Which direction is Depth?

Using family components from different sources is always a pain. Not just because some are made so badly, but because everyone seems to create them differently. One such point of difference is names used for  dimension directions.
In English I count 7 different ways to describe linear dimension directions:

breadth

depth

height

length

long

thickness

width

But we only need to describe 3 directions, sometimes 4 if we want to include a material thickness.

Until BIM it didn't really matter. We used context to decide, usually the context of convention. But in BIM a lot of this context is lost. Schedules is an obvious example. For a start if there is no consistency you end up with 7 columns instead of 3. And the height of one component may be the same direction as the depth of another.
Another context lost is the region, country, and/or industry. Components are available world wide over the Internet. The convention in one region, or industry in one region, may be the opposite of another.

When I bring this problem up, no-one is interested. I haven't found a standard that addresses it (AutoDesk and ANZRS are silent). People say it doesn't matter. And it doesn't. It doesn't matter which definitions are used. What does  matter is that the SAME definitions are used.  And the most effective way to do this is to come up with simple rules that can be applied in any situation.  That shouldn't be too hard. Or is it?

THE PROBLEM

The basis of the problem is, as I mentioned, humans understand direction names by context. Ignoring any particular industry conventions, the two common types of context are proportional and orientation.
Proportional is when you define the longest dimension as length, next longest width, smallest depth. This the way most people normally think.
Orientation is when you define each direction by its orientation in respect to a reference direction. This could be the person looking at it (height is up/down), an absolution reference plane like the ground (height is forward/back), or a coordinate system (height is Z axis).
There is a very good investigation of this in the NatSPEC BIM Portal, under Workshop, Describing the dimensions of BIM objects.

SUGGESTION 1

Neil Greenstreet of NatSPEC, who authored Describing the dimensions of BIM objects, came up with a schema that tried to address how most people treat direction naming. A full description is on the NatSPEC BIM Portal, but in essence it is:

For unfixed materials, use a proportion-based schema:
1. Use length, width and depth for cuboidal forms.
2. Use length, width and thickness for linear or planar forms.

For installed (or ready to install) elements, use a mixed orientation-based/proportion-based
schema:
1. Use height, width and depth for cuboidal forms.
2. Use height, length and thickness for vertical planar forms.
3. Use width, length and thickness for horizontal planar forms.
Note: The difference between cuboidal forms and planar forms would need to be defined by
an agreed aspect ratio.

My feeling is this is too complicated. There are too many different rules. Also a proportion based schema will never work where components are parameter driven. You can't change the label of a parameter when its value becomes the second longest instead of the longest.

SUGGESTION 2

Thinking about this problem I believe the best approach is to use the idea of orientation only. The orientation that works in the majority of situations is based on standing in front of the object.  You need no other context than the object and your (imagined) self.
This rule works for most objects:

DEPTH   =  FRONT to REAR
WIDTH   =  LEFT to RIGHT
HEIGHT  =  BOTTOM to TOP

An alternative could be:

WIDTH     =  FRONT to REAR
LENGTH   =  LEFT to RIGHT
HEIGHT    =  BOTTOM to TOP

It doesn't really make much difference, but I stuck with the first rule as Revit uses these names in the casework template.

But some objects don't fit this rule. Objects like beams, ducts, floors. Although hard to precisely define, these types of objects could be described as having a horizontal orientation - dimensions parallel to the ground plane vary the most.
When standing in front of these objects the rule becomes:

DEPTH    =  BOTTOM to TOP
WIDTH    =  FRONT to REAR
LENGTH  =  LEFT to RIGHT

By defining 'Front' as the cross section (cut through smallest dimensions) the rule becomes:

DEPTH    =  BOTTOM to TOP
WIDTH    =  LEFT to RIGHT
LENGTH  =  FRONT to REAR

Which is a little closer to the first general rule.

Thickness deserves its own rule:
THICKNESS is distance between two faces of single material  (or component made of materials permanently fixed together).
e.g. door panel, plasterboard, steel beam, duct insulation.

This is simpler than the NatSPEC way, but is it simple enough?

SUGGESTION 3

If direction rules are based on where 'Front' is, another approach is to have separate rules for where 'Front' is located. The advantage of this is that only one direction rule is required.
If we think of horizontally orientated objects as objects we have to bend to look down at, or to look up at, we could describe them as objects that are above or below. For example when looking down on a bucket or sink, or looking up at a beam or ceiling, Front to Rear becomes Depth in respect to the viewer.

So if we have one direction rule:

DEPTH   =  FRONT to REAR
WIDTH   =  LEFT to RIGHT
HEIGHT  =  BOTTOM to TOP
for objects above & below length is used instead of height:
LENGTH  =  BOTTOM to TOP

And two orientation rules:
GENERAL RULE
FRONT is side accessed by a person standing on the ground.
ABOVE & BELOW RULE
FRONT is top or bottom of object, bottom is cross section or end of object.

DIRECTION ORDER

An allied issue is the order of direction descriptions when naming objects.  As this is not as critical I would term this a 'convention' rather than a standard.
The AutoDesk Family guide recommends WxDxH (page 27).
In the Australian home construction industry windows are alphabetical (in English) HxW.
Australian steel uses DxW, timber sizes use DxB (for breadth, which is same as width).
I tend to use DxWxH as depth is lest likely to vary, width more likely, and height (or length) most likely. For example in a set of cupboards for each depth you have a range of widths and heights.
ANZRS recommends adding a letter after dimensions (e.g. 300d x 600w x 700h), which is eminently sensible whatever convention is used. But ANZRS don't make a recommendation for the actual order, which would be helpful.

CONCLUSION

I must admit, I don't feel I have come to a definitive answer. Perhaps there is not one. Maybe my 'rules' are really only useful as conventions, to be applied in the absence of clear definitions.
What do you think? What conventions do you use?

A REVIEW: BIM IN PRACTICE - EDUCATION

It is a scandal how far behind teaching BIM is at the majority of academic institutions.  I though academia was supposed to be leading innovation, not trying to play catch-up. Doing research on BIM is not the same as teaching it.  We don't need any more dry, out of date, utopian, and ultimately irrelevant, papers about BIM.  We need building professionals with a good understanding of BIM and the skills to make it work.

This is the fourth and last post of my comments on the Australian Institute of Architects and Consult Australia group of documents under the title "BIM in Practice". My first post was A REVIEW: BIM IN PRACTICE - Legal & Procurement, the second A REVIEW: BIM IN PRACTICE - BIM Management Plans, and third BIM PRACTICE - BIM Outreach; advice to the various players in BIM projects.

All documents are available from  BIM/IPD[AUS] (http://www.bim.architecture.com.au/).

The documents are really discussion papers, and pretty much represent current thinking about BIM by BIM experts in Australia.  These posts are not so much about what is in these documents, as what is wrong (in my opinion) and what is missing. But please keep in mind that I agree with the vast majority of what they contain, and that my aim is not to denigrate this outstanding effort.

E - EDUCATION

Clearly written set of documents that, unlike the other workgroups, suggest a way forward.
And something really needed. Whilst those doing BIM are learning by experience, there needs to be some thought put in to how that knowledge can be passed on to future BIM users.

Three areas of approach are clearly articulated:
 - teaching of BIM concepts
 - teaching of BIM methodologies
 - teaching of collaborative practice

An issue not touched on is the danger of BIM education straying outside the area of expertise of those being taught.  Whilst it might be beneficial to teach architects how a structural engineer uses BIM to do their work, you don't want to encourage architects to actually do, and take responsibility for, structural analysis. Even if it is as easy as Autodesk is telling everyone when you use their cloud analysis service.

E1 - BIM EDUCATION & BIM LEARNERS

Separating out the different types of BIM learners is useful. Convincing a CEO to adopt BIM is a different task to making someone proficient in BIM tools, as is teaching project leaders and managers how to manage BIM teams and projects.

It is NOT clear "that shared BIM database servers will play a more significant role in supporting collaborative processes".  Another example of the single unified database fallacy.
The danger is by making this assumption problems that exist now are put aside as not being important as they will be solved "when everyone moves to a single model".

A discussion on specialisation within BIM tasks may have been worthwhile.  The range of skills and knowledge required across all BIM competencies is beyond a single human being. Even using BIM software like Revit it is not possible to be competent at everything it can do. Particularly when some tasks might only be done a few times a year, or once a project.

E2 - BIM LEARNING PROVIDERS

Good points are made about academia. It seems academia is just like any other large, conservative organisation. Those at the top don't understand BIM and have no interest in it.

Anecdotally (mainly from students) BIM teaching in academia is disappointing. It would be interesting to see a comparison study of which institutions are doing what with integrating BIM into their courses.

IPD and single shared BIM databases solve a lot of the problems encountered while using BIM. But if that is all learners know they will have no skills in how to overcome those problems when they end up on projects in the real world that don't use these technologies.
This exposes the issue that only teaching future BIM users what is considered desirable is not going to help the industry. Nor is relegating BIM to post-graduate research projects "about the future".

New roles bring new expertise and specialisation. Managing large amounts of digital data is new to the building industry and not currently considered a skill required by building professionals. Perhaps building professionals are not the appropriate ones to take this role on. But some-one has to, it can't just be ignored.

BIM involves those from cost control through to building product suppliers, to facilities management. It is important education policy captures all players, not just some.

The role of reference sources is not discussed.  It is unrealistic to think that once you "teach" someone BIM they will know everything about what they will be called to do.  In CAD this was possible. The skills to draw a stair are the same as drawing a window. But in BIM software there are different tools to construct stairs and windows. There may even be more than one tool to model windows.  The role, creation, maintenance and accessibility of reference sources must be integral to all training.

E3 - BIM LEARNING SPECTRUM

Very good dissection of the issues and clearly articulated (being an architect, I'm a sucker for a good diagram).

A national framework for BIM competencies is suggested, with an on-line "BIM Learning Hub" that centralises it all. And that this be done by a newly created "National BIM Institute" (NABIMI)?.

If it is set up with just another government grant with no on-going funding (like all BIM initiatives in Australia so far) I don't see it doing much. It might work if picked up by one of the academic institutions or professional bodies.  After all, it could generate income if used by enough BIM education providers.
An ambitious, but an interesting idea, worthy of further discussion.

CONCLUSION

BIM education has a lot of catching up to do.
A National BIM Institute setting a BIM education agenda is a worthwhile idea.  Particularly for those who don't know where to start (and there seems to be many).

In thinking about academic institutions it is hard to see how BIM can taught if students don't know how to use actual BIM technologies - which means softwares.
One of the problems I see at a number of architecture schools is that it is considered not their role to teach what they call "the tools of the trade".  Not as a part of the core course anyway. Their view is it is up to the students to learn whatever they deem appropriate. The argument given is that they are teaching architecture, and it is not their place interfere with what tools students use.  The result is students have a mish-mash of softwares they use, often using 3 or 4 different programs on one submission (e.g. Rhino, AutoCAD, Photoshop, MS Excel). And of course different students have different skill levels, from each other and within the softwares they know.
I would of thought, if you are concerned about teaching architecture, a better approach would be to restrict them to one software. After the initial learning period students would spend less time wrangling software and more time on the architecture. Product from students would also be more uniform, making it easier to identify good architecture from merely good IT skills.

I understand it is even worse in engineering schools, where it is considered below an engineer's dignity to be involved in drawing, which in their view includes 3D modelling.

And then there is collaboration. Students work in teams within their facility, but rarely with students from other facilities.  It would be great if this happened more often, as a matter of course rather than one off research "pilots".

I could go on. Maybe in a future post.

But perhaps I'm wrong. Let me know if I am.
If you have a view please add your comments to my blog, or go to BIM/IPD[AEC] (http://www.bim.architecture.com.au/) and put your comments there.


This is my last blog on the BIM in Practice documents.

A REVIEW: BIM IN PRACTICE - BIM Outreach

There are many participants in BIM processes. Indeed the theory is that the more participants the greater the advantage. But what are their roles? Are we expecting too much from some (clients), and too little from others (cost planners)?

This is the third post of my comments on the Australian Institute of Architects and Consult Australia group of documents under the title "BIM in Practice". My first post was A REVIEW: BIM IN PRACTICE - Legal & Procurement, the second A REVIEW: BIM IN PRACTICE - BIM Management Plans

All documents are available from  BIM/IPD[AUS] (http://www.bim.architecture.com.au/).

The documents are really discussion papers, and pretty much represent current thinking about BIM by BIM experts in Australia.  These posts are not so much about what is in these documents, as what is wrong (in my opinion) and what is missing. But please keep in mind that I agree with the vast majority of what they contain, and that my aim is not to denigrate this outstanding effort.

O - OUTREACH

This set of documents consists of sections on the participants in BIM.  It includes documents on:

Clients

Architects and Building Designers

Engineers

Contractors / Builders

Quantity Surveyors and Cost Planners

Facility Managers

Manufacturers and Suppliers

Its stated aim is to "not to sell BIM . . but to provide practical advice".  A worthy aim and mostly achieved.

O1 - EDUCATING CLIENTS - What to ask for when requesting BIM

The title of this section says it all.  There is a tacit assumption, without explanation, that clients will request BIM, and that they need educating about what that is.

But clients are paying for a built facility, not a process. Remember, they have their own jobs to do, why would they waste their time getting involved in the internal processes of someone they are paying to do the job? Does your accountant insist you understand how the tax office on-line submission system works? Does a doctor ask you to not only arrange your own blood tests, but expect you to tell him which ones should be done?
To tell clients they will get a better service with BIM is a moot point - they already expect a competent service. For example, why would they pay extra, or put their effort to, having less clashes on site? Their view is those they are employing are already responsible for avoiding clashes. Why would they care what method is used?

The assumption you can make the client responsible for instituting BIM on a project is unrealistic. They are not interested, nor have the experience or competency to do it.
The exception may be large organisations like government departments (e.g. US Veteran Affairs, GSA, Defence), sophisticated developers, Private Public Partnerships (PPP) and clients who are also contractors.
But these organisations are large, projects have big budgets, and are (usually) done by large AEC firms. They will look after themselves. They have their own legal agreements, deliverables and processes. They don't need the help of professional organisations like the RAIA and CA.

The list of considerations in this document (basically the heading list of the BMP, refer to my previous post A REVIEW: BIM IN PRACTICE - BIM Management Plans) includes issues that the client should never get involved with:
- software selection
- hardware and network resources
- training and support
- data exchange methods

This document is misguided. If the point is to advise clients how to ensure BIM is used on their project, the strategy should be to ask for deliverables only possible through using BIM. Like 3D views of main rooms, walk-throughs, equipment schedules as databases, etc. And deliverables that provide evidence BIM processes are being utilised. Like submission of the BMP at milestones, submission from each firm on how they will resource the project, results of clash detection reports, etc.
Clients should NOT be expected, let alone encouraged, to get involved in the internal processes of AEC teams.

That said, I agree with the statement "Perhaps the most important decision the client can make will be the appointment of the most appropriate design and construction team."  But I would leave out "Perhaps".

O2 - ARCHITECTS & BUILDING DESIGNERS

I liked this document. As an architect I thought it gave a good overall description of current BIM practice. If you are in an architectural firm give this document to your boss.

Technology, Process & Workflow,  Deliverables & Data Quality descriptions are very good.

Model Manager is a new role not appreciated in most AEC offices.  They are absolutely critical to not only achieving BIM benefits, but also ensuring the BIM file doesn't become an unwieldy mess. There needs to be more discussion and dissemination of the role, responsibilities and required skills of Model Managers.

The other new role is the project BIM Manager. But assuming the project BIM Manager will work for the client is not necessarily true nor desirable.
Clients should NOT be encouraged to get involved in internal work flows. The exception might be in novation where the contractor (who becomes the client) takes on the role. Otherwise it MUST be some-one within the AEC team, who is familiar with the actual project and not just the BIM processes of the project.
An alternative model not discussed is the "BIM committee". Made up of Model Managers from each of the project team, with a chairperson. This has the potential to enhance collaboration and best of breed practice. If there are concerns about lack of decisiveness (a common complaint of committees), power and responsibility of the chair can be increased.

Disappointingly this section didn't talk about establishing office BIM protocols. Something that was broached in the Legal & Procurement documents (see my first post: A REVIEW: BIM IN PRACTICE - Legal & Procurement). Unless you want every BIM project to be done to different protocols (for free) you need your own robust protocols that you can use as a basis for establishing services beyond your normal fee.

O3 - ENGINEERS

This section was a little disheartening. Its emphasis seems to be on how to avoid BIM.

It makes points like: "is anyone likely to gain value",  "will the information or data you author ever be maintained?", and "The use of BIM does not automatically result in the production of better drawings in less time, but rather contributes to . . . a higher quality, coordinated design and deliverables".

These are actually good points that should be considered. But the prominence of these points in the document is telling. I have witnessed many complaints from engineers about using BIM, as they say it increases the effort required to create drawings, their traditional delivery. They don't seem interested in the opportunity to improve the quality of their service. Their usual reason is their "fees don't cover it."

For architects BIM does improve drawing production, probably because they have to produce so many drawings. But architects look for more than just efficient drawing, they want better accuracy leading to better decision making and coordination. Even if they don't get more fees.

When I first started getting excited about BIM, one of the potential advantages was speeding up feedback from engineers. Architects always seem to have to wait until the design is complete - and completely drawn -  then wait another 2 weeks while the engineers extract the data they need and do the analysis. By then it is too late to make any significant changes to the design. The idea of being able to bounce alternative ideas back and forth had immense appeal. Twelve years on and not much has changed. Few engineers use their BIM model to do analysis, so there is still a delay while they transfer information from the BIM model into their analysis software.  The original authors of Revit MEP and Structure always conceived them as primarily a platform for analysis rather than just drawing production.  But perhaps AutoDesk has also given up. They are now marketing their cloud analysis services to architects, even though architects have no expertise in the engineering involved.

O4 - CONTRACTORS / BUILDERS

I found this section a bit light on. There are enormous potential gains to contractors from utilizing BIM, so I expect uptake will be very quick once the business case is shown to work.

It makes the point that "design intent models and trade models will continue to co-exist whilst contractual boundaries remain in place".  I believe this is a little misguided, and falls under the single unified BIM database fallacy and the IPD will solve everything fallacy (see my first post: A REVIEW: BIM IN PRACTICE - Legal & Procurement).  There will always be projects where this will happen. I think a more useful discussion would have been of what a trade model (called by some a "Contructable model") actually is and why it is useful.  And that a trade model can be done without design intent models and still bring benefits to the contractor.

The role of BIM shop drawings could have been fleshed out more. If shop drawings aren't all BIM the advantages of BIM won't be possible. Both structure and duct work has to be BIM to clash detect between them. If one isn't, it's not going to happen.

Unfortunately I found a little BIMwash - "Accurate As-built drawings can be made available at handover with the use of BIM and a 3D model". BIM doesn't by definition mean accurate! The same issues with turning 2D design intent drawings into accurate as-builts apply to turning design intent BIM into accurate BIM as-built.

Viewing in 3D so trades get an idea of what they are building is incredibly useful, but not mentioned. Trades work in 3D, but traditional documentation is 2D (even out of BIM software). Architects and Engineers often don't appreciate this and consider 2D drawings the only "real" information required.

It should have been pointed out that 4D BIM (time sequencing) is ONLY a visualisation tool. Seeing construction sequencing visually may help comprehension, but won't reduce the effort required to plan the sequencing. (unlike 5D - costing - where automatic measuring does actually reduce effort).

O5 - QUANTITY SURVEYORS & COST PLANNERS

A bit disappointing, like the Engineers document, but perhaps not as surprising. Few of these professionals use BIM yet.  This document suggests BIM requirements for costing not be done by the expert - the cost consultant - but by others. Who have no expertise, professional responsibility, and more than likely no PI cover for this work.

There is a mistake in table of stages; a misunderstanding of LOD definitions. LOD 300 is for construction, LOD 200 is closer to tender. As there is no real discussion or explanation of LOD elsewhere this mistake is not obvious.

There is acknowledgement that BIM only helps measure quantities of the final product - not necessarily everything that may be required, an important point.

But it also says "it is imperative that the BIM is configured to construction methodology". And "preparation of the ACCM elemental breakdown requirements is added to the BIM".  By who? The assumption seems to be by others, not the cost consultant.
Further, the summary suggests the "design teams" assign cost parameters, and that cost consultants provide advice on how to model correctly. Good luck with that!
Assuming your work has to be done by others for BIM to work is just setting BIM up for failure.

I believe the underlying problem is that the discussion is around current views of 5D BIM, which is essentially adding cost data to a BIM model, either to the mythical "single unified database", or to some-one else's BIM.
So the issues around this are construed as to how to get others to make this BIM suitable for costing.  A more viable alternative is linking or synchronising cost data with a BIM by the cost consultant. Which brings its own issues and challenges, but a path I would suggest is more viable and realistically achievable.

O6 - FACILITY MANAGERS

This section should have started with a discussion about the necessity for a clear commitment and capacity to use BIM for FM.
Although BIM provides a "great opportunity for facility management", it is only true if facility management have the capacity to make use of it. If facility management don't have processes and technology in place, or funds to introduce them, involving them in BIM processes is a waste of everyone's time.

Again the discussion is centred around the single unified BIM database fallacy and the IPD will solve everything fallacy. The assumption is "the BIM model" will have FM data placed in it by the project team.
This may be possible if FM have specific, known requirements, if the client is willing to move money from the FM budget to the construction budget, if the project team has FM expertise.
This may happen on some projects, but mostly it won't. The reality is many facilities will never have the budget required to implement full FM BIM, and most projects won't have the budget to include FM functionality.

But that doesn't mean they can't be helped. There are other possible work methods and deliverables more suited to the lesser capabilities of typical Facilities Management processes. It is a pity they weren't explored.

It is more likely any FM BIM will be based on the contractor's model, or as-built model, than the design intent model. So I don't see why it is necessary "to ensure the BIM is utilised effectively, facility managers must be involved in the beginning of the project". There may be other reasons why this is good practice, but BIM is not one of them.

I would go as far to say that, unless those responsible for FM have clear BIM requirements, FM not be considered by a project team.   There is no point providing for COBIE or other standardised outputs "just in case they might use it".  The only offer that should be made it to make the BIM(s) available "as is" for them to use in creating their own FM solution.

A small mistake, these seems to be an image missing that is referred to in the text.

O7 - MANUFACTURERS & SUPPLIERS

Good to see this document has been included.
It makes some obvious, but often forgotten points:
- different users have different BIM requirements.
- Graphical or data quality is not as important as relevance.

Saying parameters need to be the same and interoperable between software packages is not helpful. Clearly this will never happen. But adhering to some standard, any standard, makes data more useful as its structure and purpose is discoverable. (e.g. in Revit the value in a suppliers parameter can placed in a user's parameter using a simple formula.)

Section on file size and graphic complexity is spot on. We only ever use manufacturer's components as a temporary measure until we create a proper, usable component. They never end up in completed documents.

As a side point quite a number of the images of Revit families provided as examples I would consider over modelled. Look at the HSL-Holder-patient Chart-3D.rfa. Might be OK for a doctors surgery with a few beds, but in a 1000 bed hospital?

It might have been worth mentioning that if manufacturers really want their products used in a project the data in parameters is more important than the 3D graphic representation. It is the data that ends up in schedules, which is where purchasing lists come from.

CONCLUSION

Clearly some players in the BIM world have a way to go yet.  They need to start thinking about the benefits of BIM to their own processes. BIM is a two way street. Some things require more effort, other things are done for you. It is about picking a path that has overall benefits, not just treating it as way to get others to do your work for you.  From expecting clients to lead the BIM process to cost consultants expecting their data to be put in by others.

If you have a view please add your comments to my blog, or go to BIM/IPD[AEC] (http://www.bim.architecture.com.au/) and put your comments there.

My next post will be on BIM IN PRACTICE -EDUCATION

A REVIEW: BIM IN PRACTICE -BIM Management Plans

With all this talk of collaboration and shared agreements why do the all the BIM Management Plans (also called BIM Execution Plans) read like mandated directives?  Add an overseer in the form of a client employed (i.e. client controlled) BIM Project Manager and any illusion parties to a BIM Management Plan are "collaborating" goes out the window.

Disappointingly this approach persists in the recently released Australian Institute of Architects and Consult Australia's group of documents under the title BIM in Practice.

This is the second post of my comments on those documents.  My first post was A REVIEW: BIM IN PRACTICE - Legal & Procurement.

All documents are available from  BIM/IPD[AUS] (http://www.bim.architecture.com.au/).

The documents are really discussion papers, and pretty much represent current thinking about BIM by BIM experts in Australia.  These posts are not so much about what is in these documents, as what is wrong (in my opinion) and what is missing. But please keep in mind that I agree with the vast majority of what they contain, and that my aim is not to denigrate this outstanding effort.

P - BIM MANAGEMENT PLANS

The stated aim of this workgroup is to "provide practical introductory guidance", which I think it does successfully. I just disagree with some the assumptions underlying current thinking about BIM Management Plans (BMP).  Read about these assumptions in the introduction of my previous post A REVIEW: BIM IN PRACTICE - Legal & Procurement.

P1 - WHAT IS A BMP & WHY SHOULD WE USE ONE

It is admitted that a BMP must be binding or is likely to be ignored.  I would add it has to also be USEFUL or it will be ignored.
I have no argument with the purpose of a BMP being to manage risks and ensures BIM advantages are utilised.
There is criticism of current practice being fragmented - each party interpreting and re-entering data. But ignores that this is a critical step in QA on a project, and that BIM needs something just as robust to replace this QA.

P2 - WHAT SHOULD BE ADDRESSED WITHIN A BMP

This document sets out the contents (headings) of a typical BMP.  It is not a BMP in itself. If you have read any other BMPs they will be familiar with few surprises. So my comments apply to many other BMPs as well.

A BMP must be designed so it can be amended, but I don't think the suggestion to "renegotiate the contract" is very helpful. Although it is obvious all parties should agree to abide by the project BMP, including any amendments when they arise, the draft US-AIA E203-2012 document guidelines recommend that if this mechanism is not robust, parties may be able to get out of complying by claiming they didn't agree to amendments. A simple note in meeting minutes may not be sufficient.   I've made comments on this issue in my previous post: A REVIEW: BIM IN PRACTICE - Legal & Procurement.

The document mentions referencing other documents rather than putting the information into the BMP. I believe this should be mandatory wherever possible.  Duplicating information from elsewhere, while easy to do, it is at high risk of eventually being wrong.
An example is project program schedules, which are set elsewhere. It is pointless just duplicating them in a BMP. Better to reference a project program.  If it is thought desirable to put time frames in use time periods (days, weeks, months) rather than actual dates. Wrong information is worse than no information.

Putting a "Project team member BIM capability & maturity statement" in BMPs is unrealistic. It is very unlikely a firm will admit to their BIM weaknesses to other team members, let alone the client, contractor and possibly PI insurer.
A better method is to document the BIM goals, or BIM uses, of each party - what they intend to achieve, not what they expect others to achieve. This will flesh out if these goals have certain requirements from other team members, and start the discussion on whether others can deliver. If all participants do their own goals it can be used to inform what project BIM goals or BIM uses can be realistically acheived.

The problem of terminology - the reality is BIM means different things to different people, and different things on different projects. It is better to admit this and use the BMP to explicitly define what BIM means on this particular project, even if it means copying the definition from somewhere else.
Although mentioned in the document, a definition of what actually constitutes "The BIM model" should be clearly defined for a project in the BMP. It might take the form of "the architectural, structural and MEP models linked together in a single Revit file", or " exports from the architectural, structural contractor, electrical engineer, ductwork contractor and plumbing contractor models linked together in a single Navisworks file". Obviously this description may change over the course of a project, but it is helpful if people can visualise what actual constitutes "The BIM model" everyone refers to.

I don't believe "Project Objectives" as described are appropriate in a BMP.  They either exist elsewhere or are so generic as to be useless. Of course a project objective is the "completion of the project by no later than a given date". Why even say it? This section would be more useful if it contained Client Requirements (clients really set project objectives anyway).  This would make expectations of clients explicit to all parties, and can then be used to ensure other parts of the BMP align with those requirements. This is the only place I would say duplication of information from other documents (i.e. Service Agreements) would be allowed, as most people at the grindstone don't get to see actual Service Agreements.

It is stated that data required by future participants should not be "guessed", but left out until they are appointed. Correct - but must be backed up by ensuring BIM objectives and BIM uses do not include objectives or uses that MAY be required by others yet to be appointed (like 4D BIM before a contractor is appointed).
There also needs to be a mechanism to ensure any BIM uses required are achievable by the party who has to deliver them. There is no point requiring the team to produce BIM "suitable for" 4D if it is not known what is specifically required (because, for example, there is no party yet appointed that will be undertaking 4D).

It is admitted clients may not be interested in BIM, but doesn't address what to do in this situation.
I have a strong view on this issue, but will leave it for my next post - A REVIEW: BIM IN PRACTICE -BIM Outreach, O1 -Educating Clients.

Surprisingly LOD is not explained very well. At least the concepts behind it could have been explained. For example, that LOD is a measure of what information can be used, not be to be confused with the amount of information contained in the BIM.

Setting modelling standards for every individual project seems overkill and unrealistic. Modelling standards should be the responsibility of each author. Either their office standard or one they create for the project. These should be referred to in the BMP, not duplicated. But must be made freely available to all parties so everyone can understand how and what others are doing.
Referencing industry standards is pointless as their broadness means they can never be a true description of what is actually used on a project. The best one could say is the project standards should comply with a certain industry standard.
To insist an office use a different set of naming standards for each project they do is unreasonable. But of course each office's naming standard for the project should be referenced in the BMP, and available to everyone else.
That said - where things are shared  (e.g. views), or the same things created by multiple parties, agreed naming convention for those items should be included in the BMP.  But the BMP should only cover standards for those specific shared elements. All other standards should be by reference.

I don't agree that drafting standards (Documentation) should be in a BMP at all.  A BMP should just define the BIM portion of a project.  By including non-BIM issues people get confused about what a BMP is for, and what BIM actually is. I also have a philosophical objection to professionals being told how to do their work. All offices have drafting standards (even if undocumented) and to impose different standards for every project they do, (via project BMPs), is overly onerous and ultimately unnecessary. If a drawing communicates what it needs to, it doesn't matter what shape, size or font a section reference uses.

IP should really be in Service Agreements, and only included in a BMP by reference. Although there may be some benefit in duplicating it into the BMP for all to see.

Contractual precedence is not necessary in this document.  Anyway, I thought the whole point of BIM is that all output is based on the same information! There is no precedence on a BIM project.
Also not useful while the project is being worked on. One day issued drawings might be correct (more up to date), next day issued schedules might be the more correct document. Depends on when the work was done, and when the documents were issued.

Software, hardware, network and archiving of each office should NOT be a requirement of the BMP. Each office should be left to manage themselves to for fill their obligations.
Only if shared communication and/or data storage is used should this be described, including a commitment to using it, and who is the administrator.

P3 - HOW SHOULD YOU PREPARE & APPLY A BMP

The document suggests "a number of BMPs" will be required. But then assumes there will be one BMP that is updated.
The suggested iterations describe how to deal with lack of information and how it grows as more people become involved. But doesn't address the issue that purpose (use) of BIM also changes:
1.  Archt -Client: schematic design resolution
2.  Consultant team: developed design resolution
3.  Contractor: construction resolution
4.  Facilities managers: Building management
Each of these have different deliverables and therefore different model structure requirements.
Indeed these could be concurrent BIM models. Would a better approach be to have different BMP for different types of models? Is one size fits all really going to work?

The document has a list of other published  BMPs, all from the USA, or based on USA documents (NatSPEC is based on the VA BIM Guide). The list is not very exhaustive, for example the AEC (UK) set of documents is not listed. However, there are more listed on the BIM/IPD[AUS] web site.
But be wary of other published BMPs. Certainly have a look at them, but they are incredibly complex and could never be realistically used without major changes. If you get a client, or boss, saying you have to comply with one of them they are suffering from BIMwash.

CONCLUSION

The role of the client is assumed to be much greater than the reality. And it is not just because the client doesn't "know about BIM yet". Why would a client, who wants a facility, care about the intricacies of BIM?
I suspect this has crept into BMPs because the first ones done were commissioned by sophisticated clients who knew what they wanted (like VA), and needed to force their project team into doing it.  These top down documents aren't going to work on the majority of projects, where clients are paying and expect their project team to provide all services, including BIM advice, to do with their new facility.

There is an underlying assumption that the BIM model is a "single unified shared database model". Yes, it is desirable, but that doesn't mean it has to happen. Look at web based document management systems as an example. Excellent idea, save heaps of time and effort, but NOT used on all projects. And more pertinent, not used through ALL stages of most projects.
A project can use BIM without a "single unified shared database model", but the BMP as portrayed makes it hard to describe how such projects would work.

In my opinion there are sections in the BMP that impinge on individual office practices. This is overly inferring and can stifle innovation.
A BMP should only involve itself with BIM deliverables, not others matters like overall project objectives or drafting standards. It is confusing enough without introducing red herrings.

It worries me that the way a BMP is conceived in these documents means a lot of work in creating, and more importantly, maintaining a BMP. And if some-one is not dedicated to the task, with sufficient allocated time, it will just fail. A lot of projects can't justify a full time dedicated person, and just adding it to the roles a project architect already does will be a recipe for failure.
It may be better to have an underpowered simple BMP than a highly complex one. Something that is manageable, but extensible.
Or is the assumption only projects over $100 million will ever benefit, or use, BIM?

I believe BMPs should describe what each party intents to do rather than tell them what they have to do. But I'll save my alternative vision for another blog post.

If you have a view please add your comments to by blog, or go to the BIM/IPD[AEC] (http://www.bim.architecture.com.au/) and put your comments there.

My next post will be on BIM PRACTICE -BIM Outreach, advice to the various players in BIM projects.

A REVIEW: BIM IN PRACTICE - Legal & Procurement

The Australian Institute of Architects and Consult Australia recently released a group of documents under the title "BIM in Practice".  The documents are really discussion papers, and anyone seeking instructions on how to do anything will be disappointed.  But they are very good discussion papers, and well worth a read.

There are four working group sections:
L - BIM, Legal & Procurement
P - BIM Management Plans
O - BIM Outreach
E - Education

Each is divided into multiple documents of only a few pages, making them very easy to digest. There is good consistency across all sections, avoiding contradictions.  Although by the nature of its structure there is some duplication.

The Australian Institute of Architects and Consult Australia concurrently opened a web site, BIM/IPD[AUS]  (http://www.bim.architecture.com.au/) which contains these documents and links to other resources.
They would like your comments, and provide a comments section on the Resources page.

To me the real power of these documents is the wide range of contributors. Each workgroup section had multiple contributors, at least eight, from a cross section of the Australian building industry. It pretty much represents current thinking about BIM by BIM experts in Australia.

Which is timely, because I believe we need a more robust debate on BIM and on how it may impact on AEC firms. So my posts are not so much about what is in these documents, as what is wrong (in my opinion) and what is missing. But please keep in mind that I agree with the vast majority of what they contain, and that my aim is not to denigrate this outstanding effort.

To summarise my overall conceptual concerns:
A utopian future is being used to avoid dealing with real, current problems and issues.

IPD and the single, unified data model accessible to all are future ideals that would solve a lot of problems. But they don't exist now, and may never be widely used.

The role of clients in BIM is completely misguided, and in my view dangerous.

the assumption that all clients will eventually be asking for "BIM projects" is delusional. Encouraging clients to involve themselves in what is essentially internal business processes of project team members is dangerous.

Not enough thought is being put into where risk and responsibilities should lie in BIM projects.

current practice of providing information on a "no responsibility" basis forces the users of that data to ensure it is adequate for their purposes. They are best placed to do this as they know what they need. Current thinking around BIM doesn't have a robust, equivalent replacement.

BIM Management Plans (BMP) as currently envisaged are confusing and unworkable on real projects.

besides embedding the above problems as core assumptions, current BMPs are not clear on some critical defining information, yet still include information irrelevant to BIM.

This post is about one workgroup - L - BIM, LEGAL & PROCUREMENT.  I'll be posting comments about the other workgroups over the next few weeks.

L - BIM, LEGAL & PROCUREMENT.

All directors or managers responsible for client agreements should read this document. As mentioned above, it won't provide answers, but does flesh out a lot of issues.

The document recognises that other agreements (such as a BIM Management Plans) may alter contractual obligations. The US AIA 203 document also takes this approach. It is suggested that construction contracts could be altered via variation clauses, but I believe misses the point that under BIM, Service Agreements must have similar, easy to invoke provisions, to deal with this required alignment.

Besides the obvious difficulty keeping the two sets of documents aligned, another problem is the BMP may reference parties without any legal relationship. One possible way around this is have deliverables to 3rd parties defined in Service Agreements. For example, an agreement between the client and architect might include deliverables to the client's (separate) FM service provider.

A discussion of the principle that "those best able to manage risk should be the party responsible" would have been useful.

As would discussion about consultant teams working directly for contractors, as in "novation" type contracts. Whereas a client's agreement might only cursorily mention BIM, contractors may insist on quite onerous BIM services to assist (or indeed supply) their own BIM processes.

L1 - BIM & INTELLECTUAL PROPERTY

It would have been worth pointing out that in some areas risk (and therefore responsibilities) may be a more important consideration than IP.  For example, if you claim IP over your components (described as "smart objects" in the document), is there an expectation that you are therefore responsible for providing all required information within them - FM data, costing data, ordering data?

The ramifications of the different formats data may be provided in is well explained. And it seems to be tending towards recommending not issuing native authoring format files (e.g. Revit,  ArchiCAD, etc.).
The need to issue these types of files is lessened with non-authoring formats such as DWF, Navisworks and IFC that can contain BIM information. Which means that information can still be extracted by 3rd parties for their BIM own purposes.

A discussion of the conditions under which authoring models could be provided to others would have been helpful. The reality is this will happen (as happens now with CAD files), so there really needs to be discussion around how this might be done without increasing risk to the author.

L2 - PI INSURANCE

A recommendation is that the PI insurer be informed if "BIM systems" are being used.  I would have thought it more relevant to inform them if contractual agreements have BIM requirements. After all, "BIM systems" can, and are, being used to create only traditional drawings.
I assume insurers want to know what the risks are, so it is important that risk is identifiable. This is where BIM Management Plans (BMP) can help. Although I do wonder if Model Progression Specifications or LOD tables will stand up as proof of risk allocation. Are they looked upon as legal documents by those filling them in?

What happens if some parties contributing to the BIM, which can include contractor, shop drawers and manufacturers, are not covered by PI insurance? It is probably unrealistic to assume every contributor will have PI insurance. Which means there needs to be a way to deal with the responsibility for those contributions.

In BIM loss of documents means loss of data, not paper. It is would have been worth noting inadequate in-house IT management may create difficulties in making a successful claim.

It is disappointing that only two alternatives are offered for sharing of risk; IPD or current practice. IPD will never be used on the majority of building projects, and current practice is clearly inadequate for BIM projects.  How about a third way?

I think it was mentioned in another section, but the fact that the definition of "reasonable professional" is changing with take up of BIM has relevance to PI insurance.

This document has good examples, although not enough, of potential problems with BIM.  BIM methods are better than current methods, but I don't think glossing over potential problems is helpful. Interestingly one of the issues raised, undertaking work outside of one's normal scope, used an example - contributing to estimating - that is put forward as BIM practice in the document on Quantity Surveying (which will be a subject of my 3rd post).

A good example is given about warranting models. It relates to models used directly by contractors on site, for example for laser setouts.  This is good, productive practice, and exploring ways to allow it to happen, rather than just blanket "don't offer any warrantees", is helpful.

It is reasonable to suggest that PI insurers will require information about how a BIM project will be undertaken, including roles and responsibilities.  But insurers need to understand these may change over the course of the project, as different parties become involved. How will this be handled? Should the PI insurer be asked for comment before changes are made to the project's BIM Management Plan (BMP), or is it just issued to them whenever it is revised?  And if comment is required, does that mean comment from the PI insurer of every party to the BMP?

L3 - STAKEHOLDERS RESPONSIBILITIES

"The (BIM) model" is referred to with no definition what that is. I constantly see this in BIM documents.  The assumption appears to be that BIM means a single unified database. But the reality is BIM is usually undertaken using multiple BIMs that can be linked together. There are actually multiple versions of "the model". The architect has what they think is "the model" (e.g. a  linked Revit file), the contractor has their version (e.g. a linked Navisworks file). This leads to all sorts of confusion, people thinking they are talking about the same thing when they are not. I don't believe this issue is intractable, it just needs to be addressed.

Although defining deliverables is good practice, "Models suitable for . . " is not precise enough. Particularly when the author has no expertise in the purpose the model will be suitable for (what do architects know about how a QS or contractor costs a building?).

One of the problem with Model Progression Specifications (and LOD tables) is that software can limit what can be separated. What do you do when electrical engineer is responsible for specifying GPOs, but architect is responsible for precise location? These types of documents (in their current format) do not necessarily overcome all issues of specifying responsibilities.

The idea of in-house BIM guidelines is good. It is better if parties define what they will provide rather than just react to requests. It prevents unrealistic expectations and form basis for claims for additional work. This should be pursued further, for example the RAIA could develop what are reasonable BIM deliverables for architects to provide.

Good section on some of the possible misuses of BIM. For example a contractor using clash detection to identify potential future variations. All can be overcome, but must be recognised first. Should be more of it, and less BIMwash.

As mentioned above, it would have been helpful to have a discussion of the doctrine that those best placed to for-fill responsibility (and manage remedial action) be the party responsible. The author is not necessarily the best party to be responsible.  There is little benefit making the architect (or ceiling supplier) responsible for ceiling hanger positions just because they are engaged to place them in the model, if they don't have direct access to services models or clash detection functionality.

L4 - VIABLE OPTIONS - ENCOURAGING COLLABORATION & "NO BLAME"

Collaboration agreements try to get parties working better together, but are ultimately unenforceable as agreement contents are so subjective; "collaborative values"; "common sense of purpose"; "align behaviours".
And as mentioned in the document, they will never work unless there is buy-in at senior levels.

Collaborative agreement workshops are insulting to most participants - we work that way already.
A more robust approach is collaboration through mutual benefit - you scratch my back and I'll scratch yours. Just define which part of my back for which part of your back.

Early supply chain engagement will only work if the architect maintains their role at early stages, and is not used by clients to reduce cost and risk by reducing design opportunity and excellence. Refer to my earlier blog post: Integrated Project Delivery - Bad News for Architects?

Alliance contracting (essentially IPD) is great - but of limited use. As expressed in the document it is used on "large projects for government clients". But it is too often put forward as THE solution to utilizing BIM. It is not, let's stop spending so much time promoting and discussing it. Large projects with large clients and large consultant firms can afford their own legal advice.

The suggested two staged agreement is an excellent idea. Agreement setting out expectations, followed by agreements with particulars.

CONCLUSION

Don't let my comments put you off reading these documents. There are many good and useful things in them I haven't mentioned. But don't be afraid to question, both these documents and my contribution.
If you have a view please add your comments to by blog, or go to the BIM/IPD[AEC] resources page and add your comments there.

My next post will be on BIM IN PRACTICE -BIM Management Plans.

Make REVIT look like CAD

One of the things (probably the only thing) I miss from AutoCAD is the way different things are displayed in colour on the screen.
In Revit printing is much, much simpler than AutoCAD. But that means what you see is what gets printed, so if you make things a colour they print as a colour.
In Revit you can use  Filters, Graphic Overrides and View Templates to make your views coloured.

Although this is just a bit of fun, using filters in Revit is incredibly powerful. For example you can use them in a plan to show all walls with a fire rating red, and all doors with a fire rating dark red. You can do the same for smoke walls and acoustic walls. You can make all rooms that require an acoustic rating a colour. The uses are nearly endless. And this is something you can't do in CAD.

But back to the fun. Best practice is to have your own personal working views, and use Visibility/Graphic Overrides with Filters to make things different colours in those views. Then save a View Template so you can apply the same settings to other personal views you create.
That way you won't disrupt printing, or the way other people want to work.

MAKE BACKGROUND BLACK
Options > Graphics > Invert Background color.
Note that this will make the background black in every view you see, but it won't disrupt printing.

CREATE A PERSONAL VIEW
First create a personal view:
Duplicate an existing similar view, rename it using your office protocol for naming personal views.

CREATE FILTERS
Create filters that will capture the things you want to colour:
View tab, Graphics tile, Filters button.
Keep filters simple. Use category only filters where possible (i.e. Tick one category, set Filter Rules to none).
e.g.
- Doors
- Furniture
- Specialist Equipment
- Walls
etc.

APPLY VISIBILITY/GRAPHICS OVERRIDES TO FILTERS
Make sure you are in your personal view.
View tab, Graphics tile, Visibility/Graphics Overrides button, Filters tab.
Hit the Add button to add filters.
Against each filter change the Projection/surface Lines and Cut Lines to be what you want.
If you need to add new filters hit the Edit/New button.

SAVE A PERSONAL VIEW TEMPLATE
Once you have your view looking the way you want create a View Template.
View tab, Graphics tile, View Templates button, Create Template from Current View command.
Name it using  your office protocol for naming personal view templates.

In the View Template dialog box under Include column UNTICK all parameters except for: V/G Overrides Filters
(You can leave others ticked if you need to, but generally you only want to change graphic overrides).

APPLY YOUR VIEW TEMPLATE TO ANOTHER VIEW.
Create or go to another one of your personal views.
View tab, Graphics tile, View Templates button, Apply Template to Current View command.
If the View Template you created is not listed, from the drop down list under Show Type: select <all>.

If you want to add further filters later on add them, and change colour settings, to your View Template rather than to an individual view so you can apply it to all the views you need to.