Monday, 4 June 2012

BIM Protocols - BIM Objectives

This is the third post in a series of posts on BIM Protocols and Standards. The second post and Section 2 is available here.

Comments and explanations are highlighted in green italics. Tables are included as links to Google Docs.

Now that we know who the stakeholders are, the Project BIM Coordinator is the person with overall responsibility for BIM related issues and there is a programme for BIM, Section 3 will define what are the high level BIM expectations required of each organization.


Section 3 - BIM Objectives
The BIM Objectives are high level objectives identifying each discipline’s participation in the BIM process of the project.

3.1 Model Ownership & Intellectual Property Rights 

The project will consist of a number of BIM models from various disciplines which when linked together will form the basis for which Design Deliverables can be extracted. To avoid liability for infringement of third party intellectual property rights, each discipline will hold the intellectual property rights over their contributions. Refer to Section 4 - Data Segregation and Linking for detailed guidance.

To ensure that there is a clear distinction of ownership, a model file shall contain data from one discipline only. By signing this protocol, each discipline will grant a non-exclusive license and sub-license where required to cover all members of the design team to allow access and use of each contribution for the purposes of the project.

If there is a case of joint authorship where two organisations make a distinctive contribution to a model, one of the organisations must take responsibility for being the Model Entity Author (MEA). The MEA must bear responsibility for the content and level of detail in that model and must notify the Project BIM Coordinator of the elements (part of the model) which are being modelled by each organisation. Both joint authors will still hold rights to the contribution as well as bear joint and separate liability for its errors.

Unless you have a very tightly knit agreement or contract, it is important that each file shall contain data from one discipline only in order to ensure distinctive ownership and therefore responsibility and intellectual property ownership. In cases where there are two or more contributions to a model, one organization must take responsibility as the Model Entity Author (MEA) and the MEA must inform the Project BIM Coordinator of the arrangement.

3.2 Reliance on Data

Each organization is responsible for errors in its contribution. Each organization is also responsible for ensuring that they have adequate systems in place to protect and secure their models from loss of data due to events such as disk failure, power failure, etc.

Things can and do go wrong sometimes and careful planning will ensure that there is no loss of information or negative impact on the project programme. Each organization must have systems in place to recover from system failures and errors. It is not within the scope of this protocol to define how an organization will recover from a failure or rectify errors in data. Each organizations BIM Standard should deal with BIM related failures and errors and other QA, IT and procedural documents should be in place to deal with non BIM related issues. The Project BIM Coordinator can require that some or all of these procedures or policies be submitted for review.

3.3 BIM & CAD Standards

Each organisation must operate within a BIM standard. The Project BIM Coordinator will be responsible for ensuring that each organisation has a BIM standard but each individual organisation is responsible for content and implementation.

BIM & CAD Standards table

The BIM Standard is an assurance to both the Project BIM Coordinator and the other organizations signing up to this protocol that each organization has standardized processes that will support this protocol. The Project BIM Coordinator is responsible for collecting, reviewing and commenting on BIM Standards.

3.4 Coordination

The primary objective of BIM is to assist with design team coordination. Each discipline with design authoring capabilities will produce a BIM model. The Project BIM Coordinator will generate clash detection reports which will form part of the BIM Coordination and Design Team meetings.

Coordination will not be impossible but will be more difficult and time consuming if there are organizations working outside the BIM environment. By signing up to this protocol, you are agreeing to provide your design contributions in BIM or BIM friendly formats. The Project BIM Coordinator will be responsible for coordinating and reporting clashes but not resolving them.

3.5 Software & Model Interoperability 

Table 2 - Software and Model Interoperability identifies the software packages to be used by each organisation for the appropriate production of information. Where interoperability with other BIM platforms is required, IFC 2x3 should be used.

Software & Model Interoperability table

The degree of interoperability or compatibility between BIM models from various vendors and their versions can be less than ideal. BIM is rapidly developing and improving and standards are running to catch up. The ideal scenario is that each organization will use the same BIM software and the latest version. The second best scenario is that organizations agree to work on the next most recent version. If there is other BIM software being used, IFC should be used as the common format for exchange of models. Most BIM applications support a version of IFC. IFC is the lowest common denominator between applications so there will be some data loss when converting to IFC for transmission. The model data is usually affected but complex data such as parametric information can be lost. This may not be significant for exchange of readonly information but should be unserstood. IFC 2x3 is the latest version.

3.6 Design Deliverables & Contract Documents

The BIM model will not be issued as Design Deliverables or Contract Documents. Each discipline will deliver the project using extracts from the model. Design Deliverables and Contract Documents will consist of traditional 2D drawings, schedules, room data sheets and specifications. DWFx will be the standard format for drawing design deliverables. PDF will be the format for all other documents. Exchange of CAD files should be the exception rather than the norm.

Design Deliverables File Format table

While there is some progress towards using the BIM model as a design deliverable or contract document, there is limited legal precedence to date. This is not to say that using a BIM model is inferior to paper or electronic paper, the opposite is likely to be the case once organizations have experienced BIM staff working to protocols and standards. It will be baby steps for a while, and until then the BIM models will excluded from design deliverables or contract documentation in lieu of the drawings and schedules output from the model. DWF and/or PDF should be used as the electronic format for design deliverables and contract documentation. 2D CAD should be avoided as an output from BIM where possible in the interest of promoting coordination and reducing errors.

3.7 BIM Deliverables

Once it has been established that BIM will be used for a particular objective, the BIM Deliverables should define a detailed breakdown of what will be delivered in BIM and each discipline’s responsibility to that BIM deliverable. Each organization should either Lead & Coordinate, Coordinate or Review BIM models and data.

Although this protocol has excluded the BIM model from being a legal document, a significant amount of design output that will be included in design deliverables and contract documentation will be generated from the BIM model, so it is important to define what outputs BIM will be used for. For example if a CGI (Computer Generated Image) is required and BIM will be used as the basis for the CGI, the design team may want to have control over materials and lighting and require that the data be imported without loss into the rendering application. Otherwise this information will need to be communicated by other means. 

The BIM Deliverables table should not be confused with the Responsibility Matrix which is often used to identify design responsibility e.g. who is responsible for underground drainage, concrete finishes, builders work in clockwork, etc. Care should be taken also not to contradict the Responsibilities Matrix.

3.8 Level of Development (LOD)

Up to Stage E, the models will generally be created in 3D to a printed scale of 1:50. As a general rule, other large scale information will be created in 2D as lines. Appendix 1 – Level of Development sets out the agreed level of detail required for BIM.

The level of development is often an overlooked aspect of BIM and BIM Specifications for projects. This is reasonably well understood for 2D drawings but is often not well understood for BIM modelling. The amount of detail required for a sketch design at the early stages of a project will be significantly lower than that at construction stages. The ability to effect change is determined by both the timeline of the project and the level of development. BIM is more flexible than 2D CAD as changes dynamically ripple throughout the model and data but as more information is layered on the model, change will cost more time and money to implement.

3.9 Model and Data Handover

The Project BIM Coordinator will arrange for the individual design team to provide the required handover data at the key project stages as defined in the BIM Coordination Programme.

If it is agreed that the BIM model is to be handed over at the end of a stage or at the end of the design teams involvement in the project, this should be done in conjunction with matching design deliverables and/or contract documents.


The protocol so far has been laying down the foundations for successful collaboration. The next sections will get a little more technical but will avoid being too technical to be specific to any BIM software application. Section 4 - Deliverables and Level of Development will expand on sections 3.7 and 3.8.

Necessary Disclaimer:
While I strive to make the content as accurate as possible, I make no claims, promises, or guarantees about the accuracy, completeness, or adequacy of the contents of the information in this post. Following any advice here is done entirely at your own risk, with no liability to this site, or the site owner.


Michael Earley is a Computer Applications Developer and an Architectural Technologist. I currently maintain blogs on both of my professional interests, and


Note: only a member of this blog may post a comment.