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.