30 November 2012

Where's the contractor? BIM Execution Plan for contractors

To be effective BIM needs to be used right from when a project starts. There are already enormous benefits in using BIM during brief consolidation and master planning. Therefore BIM plans need to start at the very beginning so that work done early on can be utilised later. But current BIM guides assume the contractor is a major party in a BIM plan. Why do these BIM guides assume a contractor is on board right from early conception of a project?

Integrated Project Delivery (IPD) is an attempt to get all the players in a construction project together from the beginning of a project. The theory being, if you can do this, BIM processes for the entire project can be worked out in advance.
IPD assumes enough is known about a project at the beginning to do this. That at the briefing stage, before there is a design, enough will be known to select the best and most cost efficient contractor.
It also assumes the owner is willing to pay for participants that won't be needed on the project (besides this BIM 'pre-planning') for months or years into the future. That's if the project actually proceeds to construction - which many do not.

There is a fundamental flaw in this thinking. The Contractor is rarely around at the beginning of a project.
Yet current BIM guides assume they will be.
I've been in a situation like this. We were meeting to put together the project BIM Execution plan, there was no contractor, yet there were clearly contractor driven BIM processes to be included in the document. The client's BIM 'consultant' wanted to use their take on BIM best practice, even though no contractor had actually done any of it to date. Which would mean the design team would be doing a whole lot of stuff no-one would ever use. When we complained the client wanted us, as lead consultant, to determine what the builder would do, what is 'reasonable' as they put it.
As an architect, I don't pretend to know what goes on in the head of a contractor. We try and detail construction in a way that is buildable, but we can't predict what a contractor will actually do. When we cleverly detail a fa├žade so scaffolding is not necessary, they scaffold it anyway. When we design so components can be prefabricated off site, they make them on site. And this is as it should be. They are the experts at construction. There is no way we could predict what BIM an unknown contractor might require.
So the only alternative is to leave contractor requirements blank until one is appointed. The problem with this is all requirements are integrated in a single BIM plan. When you add things in later it is misleading. For example, 4D (construction sequencing) is left blank. A contractor is appointed and wants to use 4D, so the blank is filled in. Now the BIM plan reads as though 4D has always been a requirement, but of course no-one has modelled to suit 4D. You can't add requirements after the fact.
Which brings us back to IPD.
IPD is being heavily pushed as necessary for BIM because BIM plans (based on current BIM guides) only work if IPD is used as a delivery process.
Do we really have to completely re-engineer procurement processes to accommodate BIM? Why not just have BIM plans that reflect what is possible with current procurement practices. Let's use BIM now, not in some utopian future.
For more on my thoughts on IPD read my blog post Integrated Project Delivery: Bad News for Architects?


One thing I do agree on though, is that the contractor should be part of BIM planning. It can't be the overall project BIM plan because they are not around when the project starts. And it is pointless to totally rework a project BIM Plan done for design after the design is finished. Particularly when construction requirements are so different it would require restructuring the plan, not just 'tweaking' it.

My solution is to have a separate document, a contractor's BIM Execution Plan (BXP) to set out how the contractor intends to use BIM. This BXP would be part of a group of documents that form the BIM Management Plan (BMP).
Read my previous posts on the structure of a BMP, and the other plans, the Project BIM Brief (PBP), Participant BIM Plans (PBP), and the Design Collaboration Plan (DCP).

I've called it the BIM Execution Plan because most lay people, including owners, seem to assume a project starts when construction starts, not when design starts. So to most people the BXP is the BIM plan for the project. And in terms of concrete deliverables it is. The contractor delivers a building and information about that building for future management. How the information deliverable would be provided is covered by the BXP.


The contractor's BIM Execution Plan would use the pre-existing BIM plans as a starting point. These plans will provide information about what type and quality of BIM information is available, and in the case of the owners BPB, what is required. If a Contractor has a BIM manual for their own standard BIM processes this would also go into the mix.
Even if the contractual power exists to do so, there is little point forcing the design team to adopt the contractor's standard BIM processes. Most of their work is already done. Getting the design team to redo their work to the contractor's requirements will take extra time, be likely to introduce errors, and be met with demands for extra payments. It is far more realistic for the contractor to utilise what is available the best way they can. That said, there will be be areas the design team can do things differently, but they need to be assessed against what is realistically achievable and the what actual benefits will be attained.

The process to create a contractor's BXP might look like:
  • Refer to BPB to define owner deliverables.
  • Refer to PBPs and DCP to ascertain receivable BIM  data from designers.
  • Refer to contractors BIM Manual for desirable BIM construction practices.
  • Work out processes required to turn receivable BIM data into owner deliverables.
  • Work out processes that will utilise BIM receivables for BIM construction practices.
  • Negotiate changes to DCP, and possibly some PBPs, to help those processes.

The Contractor, or a BIM consultant engaged by the contractor.

As soon as the contractor is engaged for the project.
It could be requested as part of the bid process if all other BIM plans for the project were made available to all bidders.

How this BXP fits into the overall BIM Management Plan (BMP) as defined in the BIM Project Brief (BPB).
Purpose and uses of this BXP.
Who is author / responsible for this BXP and key people on the project.
Contact information for these people.
Record of revisions to this BXP.
Meeting & review timetable.

Contractor specific BIM objectives.
Contractor only specific BIM uses.
Sub-contractor BIM Plan requirements (for shop drawings).
Minimum modelling requirements for each discipline & sub-contract, either:
- general description;
- specific description;
- LOD table.
File deliverables and schedule.

Clash Detection.
Construction Sequencing.
Cost Control.
RFI and Variation (change order) management.
As-Built document creation.
FM data capture.

Like the design team's Participants BIM Plans (PBP), contractors should develop their own standard BIM Manual that can be used to inform BXPs they do for individual projects. It is always better to start with what you want, not what others demand.
But I think it unrealistic to believe this BIM Manual could be used to create every project BXP, as each project will have owners with different BIM deliverables, and design teams with different BIM capabilities.
Perhaps this BIM Manual is hierarchical. A series of stepped scenarios. If we get 'X' BIM information from the design team we can do 'A' construction BIM processes and deliverables, but if we get 'Y' we can only do 'B' processes and deliverables.

But I might be getting a little ahead of myself. I'm an architect, part of the design team, so I have to admit I'm guessing a little bit here about what are realistic construction BIM processes. I hope those better experienced in construction will get more involved in this BIM Plan debate, and not leave it up to us so called BIM experts, and certainly not to the BIM evangelists.

This was my last post on my take on the different plans that should make up an overall Project BIM Management Plan. After setting out the logic and philosophy behind this idea, now to see how it works in practice! If you are giving it a try, I'd be interested in how you get on.

23 November 2012

Collaboration or Coercion: The Design Collaboration Plan

There is a lot of talk about 'collaboration' in BIM guides. In my mind collaboration means voluntary co-operation. But the requirements of current BIM guides read as enforceable obligations, more like coercion than collaboration. You WILL provide a model suitable for 4D, you WILL use IFC to exchange data. Where's the love?

Until I started studying the BIM guides out there I assumed collaboration meant the team got together and negotiated mutually beneficial work practices.
We'll create some specific views the mechanical engineers can use to put our model into their Navisworks, if they create some reflected ceiling plan views in their model with the settings we want.
We'll ensure all structural elements are modelled separately (particularly walls) in our model, if the structural engineers will commit to accurately placing (within the millimetre) their structural components.

But I struggle to see where these types of arrangements fit into current BIM guides. If it is the intention to allow for them (and they say it is), why are things that are agreed indistinguishable from BIM requirements and deliverables? Part of the problem is deliverables are expressed as work methods rather than actual deliverables, a topic I explore elsewhere.

My solution is to have a separate document, a Design Collaboration Plan (DCP) to record these co-operative types of arrangements. This DCP would be part of a group of documents that form the BIM Management Plan (BMP).
Read my previous posts on the structure of a BMP, and other plans, the Project BIM Brief, and the Participant BIM Plans.


I call it the Design Collaboration Plan because this type of collaboration occurs during the design phase of a project. To be specific, it is about collaborating to create the Design Intent BIM.
During design a lot of changes happen to the model, and a lot of iteration happens. We start with no building and end up with a design for one.
During construction there are less changes to the model, and those changes are less dramatic. We start with a building design and end up with a record of what was built.
Even on Design and Construct projects where documentation and construction proceed closely together, it is still the design team that is doing all the investigative work in the BIM model. The contractor wants it when it is resolved, not before.
The extent of change during design, and the pace it proceeds at, requires a lot of cooperation amongst the design team. Anyone who has worked on a project where that cooperation was less than optimal will know what I mean.


Most BIM guides talk about the BIM process being run by a Project BIM Manager, usually assuming they are appointed by the client. Obviously there needs to be someone to take responsibility for things running smoothly. But an alternative approach is a BIM Panel, with a chairperson, or Leader.
The panel would be made up of project BIM managers from each of the design team firms. The BIM Leader  could be elected (or coerced), the idea being that person is the one with the best BIM knowledge and experience. So rather than a Project BIM Manager dictating to everyone what will happen, there is a group of experts making agreements.
A BIM Panel may not always be practical, but either way, dictator or democracy, the Design Collaboration Plan can still be created and enacted.


The idea behind the Design Collaboration Plan (DCP) is to coalesce the individual Participant BIM Plan (PBP) intentions into a single cohesive document. The DCP will obviously be different to a PBP because it won't contain information that is only relevant to one participant. In fact is should only contain information relevant to cooperation.

The process to create a DCP might go like:

  • Agree on project BIM Objectives by reviewing participant BIM Objectives from all the PBPs, along with the owner's from their BIM Project Brief (BPB).
  • Agree on project BIM Uses by reviewing participant BIM Uses from all the PBPs,  along with the owner's from their BPB.
  • Agree on project Level of Development by reviewing participant Level of Development from all the PBPs.
  • Agree on a project File Exchange Schedule by reviewing File Exchange Schedules from all the PBPs.
  • Negotiate software specific agreements.
  • Review the plan to ensure it aligns with the client's BIM Project Brief (BPB).

 It might take several meetings to get agreement on everything. It might be necessary to renegotiate or add further agreements as the project proceeds. Once a contractor is appointed further changes might be required to satisfy the contractor's BIM requirements. So the DCP is a live document that may be revised quite often.
I'd recommend the DCP be an item in regular project consultant meetings, even if restricted to just highlighting the need to make changes to it (so triggering a BIM meeting). On smaller projects all DCP issues could be resolved at regular project consultant meetings, particularly if people with other roles are moonlighting as BIM Managers.

As with my previous posts the description I offer below is not definitive. The contents and structure of Participant BIM plans and requirements of the BIM Project Brief will go a long way to inform what is required  for a particular project.

The appointed project BIM manager or BIM Leader of the BIM Collaboration Panel is responsible for creating the DCP, but the contents of it comes from the results of meetings.

Once all major consultants are engaged for the project. If project consultant meetings are being held then it should be possible to start the DCP.

How this DCP fits into the overall BIM Management Plan (BMP) as defined in the BIM Project Brief (BPB).
Purpose and uses of this DCP.
Referenced individual PBPs.
Who is author / responsible for this DCP and contributors from each consultant group.
Contact information for these people.
Record of revisions to this DCP.
Meeting & review timetable.

Project specific BIM objectives.
Project specific BIM uses.
Level of Development of overall Design Intent Model (i.e. all models combined) that matches BPB minimum modelling requirements, either:
- general description;
- specific description;
- LOD table.
File exchange schedule.
Project Base Coordinates.

Software Names & Versions used.
Sheet Naming Schema.
Agreed Categories and their uses.
Shared and/or common components.
Views for others to use.
Clash Detection Methodology.

Next post I'll look at the contractor's BIM Execution Plan, the last plan in my suggestion for a BIM Management Plan structure.

16 November 2012

Utilising Your Office BIM Manual: Participants BIM Plans

One of the problems with a single project BIM Execution Plan is that you end up with different BIM standards and requirements for every project in your office. Potentially different naming standards, shared parameters, modelling requirements. How is an office supposed to develop best practice and train staff under this scenario?

In a previous post, Single project BIM Execution Plan: a good idea? I set out my views on how BIM Execution plans should be split in to separate BIM plans to create an overall BIM Management Plan. My last post was about the owner's BIM Project Brief. This post is about how an essentially in-house BIM manual can be utilised to form a Participant BIM Plan (PBP), which becomes part of a project's overall BIM Management Plan (BMP).


The purpose of the Participant BIM Plan (PBP) is to explain how you are going to set your model up for the project. This is not only  important to those working on the project in your office, but also informs those outside members of the project team that will be receiving your model.
Providing this information:
- helps others navigate your model;
- allows others to assess what uses they can put your model to;
- makes explicit what BIM skills a participant actually has
   (as opposed to what was in their bid submission);
- exposes practices that can be discussed and negotiated between project team members.

Each team member's PBP informs what is possible when the Design Collaboration Plan (DCP) is created.
There is little point using the structural engineer's floor slabs in the architectural model if they will not model set downs. If the QS has no intention of using Revit to schedule costs why including costing parameters?

PBPs can also be used to verify that processes are in place to meet the deliverables and requirements of the owner's BIM Project Brief (BPB).

But perhaps the best purpose of PBPs is that it forces all participants to think about how they will do BIM on the project. I have sat in too many meetings trying to get a BIM Execution plan up and running with blank looks and no input from other players. Where things are agreed to when I know they have no idea how they can be fulfilled.


The PBP is a document that can be, and is expected to be, revised during the process of the project. Changes may be required because:
- the model needs restructuring for the next stage of the project
    (e.g. between Concept and DD);
- improved work processes are introduced;
- another team member's PBP exposes opportunities to improve work practices;
- negotiations during creation of the Design Collaboration Plan (DCP);
- changed requirements when the contractor's BIM Execution Plan (BXP) is created.

For this reason it is important a schedule of reviews are established as part of the plan, along with good record keeping of revisions. As one of the PBP purposes is to keep all team members informed it is important there are clear processes for informing everyone of revisions, and providing access to the latest revised PBP.


The idea is to create a standard office BIM manual that can be tailored to suit specific projects.
Set out how you would like to do things, then only make changes where forced to, or where it helps your office. That said, as with any in-house manual your standard BIM manual should be regularly reviewed and updated to introduce better practices. Don't be too rigid as sometimes the changes you make for a project may be worthy of permanently adding to your office BIM manual.
  1. First step is to align your standard PBP with the client's BIM Project Brief (BPB) and/or your consultant agreement with them.
  2. Next review how you will set the project up. As the PBP can be revised, you can start with general information. If you don't yet know the exact files you will be creating and using, put in a file naming schema in the PBP.
  3. As other team members are appointed and issue their PBP you may want to discuss issues with them that benefit both of you. There is no need to wait for a formal collaboration plan to start working together more efficiently.
  4. Once the Design Collaboration Plan (DCP) has been created further changes may be required to your PBP so they align.
  5. Further changes may be required if the DCP is revised, which may happen when the contractor produces their BIM Execution Plan (BXP).


As each PBP is based on different offices standard BIM manuals I would expect quite a variance between them. I don't see a problem with this. What is the point in forcing everyone to follow some graphic standard just so the BIM Management Plan looks nice. The end product is a building, not a BIM Management Plan (despite what some think).
Their contents may vary quite a bit as well, particularly if different softwares are being used. And there may be quite a bit of information that is not relevant to everyone, perhaps even no-one but the author. I also don't think this matters. I'd rather look through the actual document being used in-house by my consultants than some document just created for my (or the client's) benefit.

So the description I provide below is really just a sampler. There may be sections you consider vital that I've left out, there may be more sections than you think you need. But the idea it is YOUR document - make it to suit YOUR requirements.

Each project participant authoring BIM resources. Generally this will be the Design Consultants - Architect(s), Engineers, QS, etc.
Sub-contractors providing BIM shop drawings could also be required to create a PBP, although its structure and contents will be a little different from what I include here.

As soon as each is engaged for the project.
A draft PBP could be requested as part of bid processes for engagement (which would essentially be the office BIM Manual).

How this PBP fits into the overall BIM Management Plan (BMP) as defined in the BIM Project Brief (BPB).
Purpose and uses of this PBP.
Who is author / responsible for this PBP and key people on the project.
Contact information for these people.
Record of revisions to this PBP.
Meeting & review timetable.

Participant only specific BIM objectives.
Participant only specific BIM uses.
Level of Development of participant's model that matches BPB minimum modelling requirements, either:
- general description;
- specific description;
- LOD table.
File exchange schedule.
Project Base Coordinates.

SOFTWARE SPECIFIC (using Revit as an example)
Software Name & Version used.
Folder & File structure (incl. names of files).
Workset Naming.
Level Naming.
Grid Naming.
Phase Naming.
Project Parameters.
View Types description.
View Naming Schema.
Sheet Naming Schema.
View Templates.
View Filters.
Revit Categories and their uses.

There is no reason your office couldn't do a standard Participant BIM Plan now. If you are a lead consultant and the client demands a BIM Execution Plan (but is not specific about what that is), put your own and other consultant's PBPs together and call it the BIM Execution Plan (or call it a BIM Management Plan, different but equivalent to a BIM Execution Plan). That is a lot less work than creating one from scratch, and likely to create a much more realistic, and therefore usable, BIM plan.
If you are not usually a lead consultant do one anyway. You can use it to make clear to your client what you will and won't be doing for your fee, and use it to negotiate what you will and won't do at BIM Execution Plan meetings.

Next post I'll look at the Design Collaboration Plan, where participant's PBPs are used to negotiate where and how they can help each other.

08 November 2012

BIM for Owners: the BIM Project Brief

I have been critical in past posts about assumptions BIM evangelists make about owners and their role in the construction process. In a general way in A REVIEW: BIM IN PRACTICE -BIM Management Plans and specifically in the O1 - Educating Clients section of  A REVIEW: BIM IN PRACTICE - BIM Outreach.
But my criticisms relate to specific circumstances. Current BIM guides are all based on the premise the owner has expertise in construction and is willing to direct the construction process. This type of owner does exist; for example large government or statutory bodies like health facilities, educational providers and the military. Bodies that operate and manage their properties as well as have them constructed. And there will be more owners going down this path, but they will still be organisations that build and operate.
I don't believe BIM is only suited to these types of projects and clients. BIM has value for all projects, no matter how small, or how little direct use BIM might be to an owner. How can we manage BIM on these projects when owners have no or little interest in BIM? We need a way where an owner can put in as much or as little BIM requirements they feel comfortable with.


In my last post I described how a single BIM Execution Plan could be divided into separate BIM plans matching the stage and participants current involved in a project. The first BIM plan is the BIM Project Brief (BPB). The intention of this document is to set out the requirements of the owner or client, and set the parameters for subsequent BIM plans.

The reasons this is made a separate document is that it:
- can be done early in a project before everyone is engaged and at the table;
- can address the client organisation's specific requirements in a language they understand;
- can avoid unnecessarily interfering with how the construction professionals will deliver the project.


A BPB should only be about specific deliverables. Deliverables relevant to the owner. These may include the way information is provided to the owner (e.g. 3D walk throughs); demonstrations that criteria have been met (e.g. thermal performance); information required for operating the completed project (e.g. FM data).
The owner should never specifically specify what BIM processes are to be used, only the results of BIM processes. The software to be used should not be specified, but the software format of deliverables can be. Construction 4D should not be specified, but 3D visual representation of staging can be.
Timing of deliverables should be related to when it is required. If FM data is not required at design why specify its delivery? It is an unnecessary cost and delay to the project.
Delivery of BIM plans and/or files in acceptable format could have monetary implications. Some USA contracts link a percentage of the fee with satisfactory delivery of specific items.


Although it is inappropriate for an owner to direct how construction professionals go about their work, it is acceptable for them to ask for evidence that they have processes, and that they are being followed. A BPB should set BIM plans as deliverables. It should also set out the minimum topics those plans cover. And I mean minimum, not every possible conceivable item that pad out current BIM guides. If it is not important don't include it or over elaborate it, leave room for the authors to put some effort in. Consider a must have list and optional or suggested list.

 A BPB should also establish what evidence is acceptable to show compliance, and when that evidence is required. Things like BIM plans should be submitted for 'acceptance' rather than 'approval'. As owner you don't want to become responsible for the contents and consequences of other's BIM plans.


The overriding premise of a BPB is to provide a framework for construction professionals to show they are competently performing their work.
Once the owner starts telling professionals how they are to do their job not only will they have their hands out for extra money, liability can flow back to the owner. For example, if specific software the design team is not familiar with is forced on to them it reduces their individual efficiencies and opens the owner to be blamed for any deficiencies of that particular software.
Construction professionals are engaged because they are experts. Let them work out the best way to achieve owner deliverables.  For example forcing the whole team to carry FM data throughout the entire design and construction process will lead to inefficiencies in other processes that the owner is unaware of. Often the most efficient way for the project as a whole is to create that information out of the design intent and/or construction models at the end of the project.

So what might a BIM Project Brief look like? I can't show you a real one due to confidentiality (and they don't quite exactly follow my current thinking). But I can go through how I think a BPB should be constructed.

The owner or owner's agent. Owner's agent could be either of:
- Project Manager;
- BIM Consultant (possibly with FM expertise);
- Lead Consultant (e.g. Architect).

At a minimum it needs to be done before BIM software starts to be used on the project. If the intention is to use BIM for area calculations it needs to be before concept design. There is no reason it could not be done before any design professionals are engaged. Then it can form part of bid documents for consultancy engagements, so scope can be costed and if necessary negotiated during bid process.

Overall explanation of BIM Management Plan (BMP) structure:
- overall purpose;
- list each separate BIM plan and its purpose.
Who is author / responsible for this BPB.
Contact information for these people.
Process for revising this BPB.
Contractual Implications of this BPB, including sign off by relevant parties.

Owner only specific BIM objectives.
Owner only specific BIM uses.
Minimum modelling requirements, either:
- general description;
- specific description;
- table (e.g. like an LOD or USACE M3).
Method to validate that minimum modelling requirements met.
Party responsible for validating, which may be:
- owner (or agent);
- lead consultant;
- author / responsible party.

BIM plan requirements:
- list of BIM plans and authors / responsible parties;
- timetable (relative to other events);
- minimum requirements for process of revising BIM plans;
- minimum contents (headings) for each BIM plan.
Evidence BIM plan requirements met.
- draft to be provided of each;
- all revisions to be provided;
- submissions to include description of how compliance with BPB achieved;
- time frame for submissions;

Acceptable software formats for owner deliverables.
Other specific requirements for owner deliverables.

It looks like quite a long list, but my intention is that each may be as short or long as necessary. By judicious use of reference documents I'm sure it could be a one page document.
For example an owner may have no BIM objectives or BIM uses themselves, then the minimum modelling requirements could be a general description something like "Adequate to achieve the BIM uses listed in other BIM plans of the BIM Management Plan". Then a very short list of BIM plan requirements, perhaps offering one or more of the many BIM guides around for guidance (but not compliance). Like the NatSPEC National BIM GuideAEC (UK) BIM Protocol for Autodesk RevitUSACE BIM PxP Template to name a few.
Or an owner may have very specific FM requirements and a massive minimum modelling requirement table like the the NatSPEC National BIM Guide BIM Object/Element Matrix Manual, with very specific IFC deliverables, and very specific BIM plan requirements.

After writing this post I see an example BPB would be instructive (a picture is worth a thousand words). But I'll leave that for another post. Next post I'll explore what sort of document Participant BIM Plans (PBP) should be.


02 November 2012

Single project BIM Execution Plan: a good idea?

Construction projects always evolve over time. As it evolves the deliverables and personnel change. Not everything that needs to be done is known, nor the people who will do it. Yet BIM Execution Plans are structured as if all information is knowable at the beginning of a project.


For example the NatSPEC National BIM Guide (p2) says:
"After the requirements for using BIM on the project have been defined and before the project formally commences . . .".
When have all of the requirements (whether BIM or not) of a project ever been defined before it starts?

Most BIM Guides make lip service to this reality by stressing the BIM Execution Plan requires continual updating.

The Pennsylvania State University "Building Information Modelling Execution Planning Guide", (Chapter 1, section 2):
"The BIM Plan should be developed in the early stages of a project; continually developed as additional participants are added to the project; and monitored, updated and revised as needed throughout the implementation phase of the project."

The new draft AIA Document E203™ – 2012, Building Information Modelling and Digital Data Exhibit also makes this assumption, one of the many clauses this is mentioned:
"3.2.3 The Parties, together with the other Project Participants, shall review and, if necessary, revise the Digital Data protocols at appropriate intervals as required by the conditions of the Project."

Which creates a legal problem (p19, draft clause 102):
". . . enforcement of the protocols may ultimately turn on the ability of a Project Participant being able to prove that the other Project participants agreed to the protocols. Accordingly the Project participants should develop an acceptable process through which each project Participant can manifest their receipt and/or agreement to each version of the protocols. Such a process would then ensure against a Project Participant ultimately alleging that it never saw or agreed to the latest version of the relevant protocols and is therefore not bound by them."

Remember they are talking about a single plan covering everyone in the project. Any change requires the participation and agreement of everyone - even if the change doesn't materially effect them.

The RAIA/CA BIM in Practice document P3: How should you prepare & apply a BIM Management Plan? discusses this at length on page 4. In fact it states:
"You can no more formulate a detailed, definitive BIM Management Plan in the first week of the project than produce a set of working drawings before doing a sketch plan."
Which I wholeheartedly agree with. It then goes on to say:
"All of this suggests that the most sensible approach is to plan for a series of BIM Management Plans which represent progressive iterations of the initial plan."
A  "series of BIM Management Plans" is an interesting idea. But what they actually mean is the same plan revised multiple times. Like most other BIM guides they still treat the BIM Execution Plan as one document.

The NatSPEC National BIM Guide nearly gets there. It divides the BIM Execution Plan into two documents, the "Project BIM Brief" and the "BIM Management Plan". The Project BIM Brief is a short document (6 pages) that purports to only define client requirements. Yet it reference things in the BIM Management Plan, so can only be done if a BIM Management Plan has also been done.

The NatSPEC National BIM Guide also talks about a "Design BMP" and a "Construction BMP". Once again very sensible. Unlike many other BIM guides it recognises that during design, before a contractor is appointed, it is pointless to include BIM matters concerning construction in a BIM Execution Plan. The NatSPEC National BIM Guide has a good general description of what Design and Construction BIM Management Plans should have in them (p4-5). But then the rest of the guide ignores the specific requirements of these two different documents and reads as if it is talking about a single BIM Execution Plan that covers everything.


What's wrong with a single document that has all things BIM in it as the project BIM Execution Plan?

Because current BIM Execution Plans include everything, right up to FM, nobody takes them seriously at the start of a project. As an Architect I would like a usable  BIM Execution Plan when concept design starts. And before that I would like to know what BIM deliverables the client wants. Yet on most projects you are lucky if you are allowed to do one at the start of Design Development. Usually it is not until the client is considering the contractor's appointment that all hell breaks loose and and a BIM Execution Plan is demanded. Which is way too late.

The other side of the coin is the client who demands a BIM Execution Plan (usually based on some one else's BIM Execution Plan) be done that includes a whole lot of things unknowable at concept design. This is aggravated by the fact the client doesn't understand the BIM Execution Plan they demand we mimic because it is so complex and technical. We end up getting caught between a rock and a hard place. Either we leave it out and not get the BIM Execution Plan approved, or make something up that may or may not happen, and end up being held responsible when it doesn't.

And then there is the issue of who authors a BIM Execution Plan.
By having a single massive BIM Execution Plan it requires some one with a lot of expertise. From knowledge about every software used on the project to contract law. But those responsible for enforcing a  BIM Execution Plan rarely have even a small part of that expertise. So we end up with a situation where the  BIM Execution Plan is left in the drawer, either too hard to do, or done by an underling with no authority. Or even worse, a BIM Execution Plan done by an outside "BIM consultant" with no responsibility for its effects on the project (you know, the thing we are actually building), and ends up being a millstone around everyone's neck.


Wouldn't it be better to divide up the traditional single BIM Execution Plan into separate BIM plans that cover only the participants and material relevant to a stage of a project? That only talks about things relevant at that stage, in a language that the players at that stage understand?
A series of plans that get progressively more intricate and complex as the project progresses. A series where each plan sets up the parameters and requirements for following plans.

What might this series of plans look like? What would be the individual plans that make up the overall project BIM Management Plan (BMP).
As a start my suggestion is for the following BIM plans:

BIM Project Brief (BPB)
  • by client, or lead consultant (as a return brief). 
  • short, high level document. 
  • created before project starts (ideally included in consultancy bid documents)
  • sets out BIM deliverables only, avoids describing how. 
  • describes required content of DCP & CBP.
  • should never need to be revised (contractual implications if it is).

Participant BIM Plans (PBP)
  • by each member of design team.
  • created as part of consultant bids, or immediately after each consultant appointed.
  • describes methods that will be used to satisfy BPB.
  • software specific. Doubles as in-house project manual. 
  • describes how BIM model will be constructed, including what will be available to others & what is required from others.
  • provides basis for DCP.
  • may be revise due to agreements in DCP.

Design Intent Collaboration Plan (DCP)
  • by design team
  • created after design team appointed.  
  • similar structure to current BXP guides .
  • refers to, rather than duplicates individual consultant PBP content.
  • describes what will be available to CBP.
  • may be revised due to new participants, and requirements of CBP.

Construction BIM Plan (CBP)
  • by contractor.
  • created as part of contractor bid, or immediately after contractor appointed. 
  • similar structure to current BXP guides.
  • describes methods that will be used to satisfy BPB.
  • describes what is required from DCP.
  • describes what will be available to FM & As-Built. 
  • should not need to be revised, but could be if necessary.

For this series of plans to work as the project's overall BIM Management Plan all plans must be freely available to all project participants. If there is any information that is required to be controlled, it must appear only as a reference, available only on request where appropriate.


What are the advantages I see of this structure?
  • Direct users of each plan are responsible for its creation, so that each plan is in the hands of those best placed to create something meaningful to them, and to enforce it within their organisation.
  • The client can define their requirements without interfering with how they are delivered. Any (gasp) BIM consultant engaged will have their influence limited to the BPB. 
  • PBP can be based on each consultant's in-house office BIM manual, avoiding the situation where every project requires a custom written BIM plan (and manual).
  • Plans can be requested as part of bid processes and so become part of the selection process, or alternatively mandated as part of service delivery. 
  • Each informs the requirements of the next, but can stand alone as a useful document, and be enforceable in its own right.
  • Only the middle plans, PBP and DCP, may need revising to ensure they align with subsequent plans. And as these only involve the design team should be easier to revise.

What do you think?
I've listed the advantages, what are the disadvantages.
Have I left any BIM plans out?

I've purposely not talked about specifics in each BIM plan, but in my next post I'll have a go at the BIM Project Brief (BPB).