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.