Case Studies – BIM Academy: Learning and Development

This is all part of the theory of how information is managed on projects – but you might be wondering how all that works in practice.

A good way to show how COBie works in practice is by telling you how it has worked on some of our current projects.

Learning from case studies can be very helpful as we can spot the things that worked really well and the things that could be improved.

Then we can apply or improve it on the next project.

So now we are going to see three case studies where COBie was requested as a deliverable.

The first case study I would like to show you is an auditing work we did for a big contractor.

In the process of establishing which information is going to be captured by COBie, the Appointing party, that is, the clients need to establish their information requirements in a document called Exchange Information Requirements – EIR.

This document is part of the tendering documents and gives a high-level specification of how the models should be structured.

The Lead appointed party will then answer these requirements in a document called BIM execution plan – BEP – confirming what exactly will be delivered.

The BEP is the document that ultimately dictates how the models are going to be produced and what pieces of information will be added to them.

This means that if we are checking whether COBie has been delivered and how it has been formatted, we need to check it against what has been specified in the BEP.

For example, the BEP will usually specify the COBie fields that should be filled in and who needs to insert this information in the model.

The dates should also be included. The BEP will also specify which model objects are considered a maintainable asset on the project.

We can see in this table that the greyed out fields are not required for this project. All the other fields are required.

We can see that there is a section that specifies when COBie should be submitted and that some fields should be filled in by some teams but not by others.

When we get the COBie files that have been issued by the specialists, we check this information using an automated tool, so that we eliminate the likelihood of human mistakes in the checking process.

We configure the tool based on the requirements that were specified in the BEP and we get the results file.

We then read this file and translate the results into a series of measurements that show how complete the model is in terms of COBie information.

We also point out the gaps and make recommendations on how the consultants can improve their models.

The last stage is to communicate these results to the client and to the delivery teams involved with the project, to make sure that they understand the state of the information and what are the steps required to make the information complete.

In this case, we do more than one audit on the project we make sure that we show how a comparison of the results, so that people can understand how information has progressed.

The second project I would like to show you is what we call SIMP.

SIMP stands for Standard Management Information Plan, and it is a way that the Scottish Futures Trust found to standardise the way information is required and delivered on school projects in Scotland.

On these projects, BIM Academy was appointed to an Information Management role, too:

• Support councils to specify what information they need on their projects,
• Specify how this information needs to be structured and at what key dates this information needs to be delivered.

Scottish Futures Trust provides a template for city councils so that they can structure their requirements under the same basic headings.

We then use these templates to specify which COBie information should be handed in.

In section three, for example, we establish the goals to be achieved with the implementation of BIM on the project.

As we have seen previously, one of the goals with COBie is to support the production, storage and sharing of information that will be used to operate and maintain the building. So this should be stated here.

In Appendix 1 we specify the documents that will contain this information.

Here we can see a list of the documents required for a school project.

We can see that they have been assigned a Uniclass 2015 PM code so that we can later search these documents independently from where it is stored.

The COBie file is displayed in this row. We then need to specify the format we want this file to be issued.

As we have seen, the most common file format for COBie is an excel spreadsheet, so this has been specified here.

Next, we need to specify the date the files need to be issued. We can see the dates here.

As we have discussed previously, more than one date is being specified here because we will need to check whether requirements are being met throughout the project rather than at one point near the finish.

In Appendix A2 we specify the assets that should be considered maintainable and specify whether some COBie information on them will be collected.

For example, we can see that roof lights and opening gear are considered maintainable assets and COBie information is required for these assets.

However, we do not record any data on the sun pipes as they are not classified as a maintainable asset.

Finally, in appendix 3 we specify COBie in more granular terms. Here is where we specify which attributes should be included in the COBie spreadsheet.

This is the place where we can check whether the ‘Contact’, ‘Facility’, ‘Floor’, ‘Space’, ‘Type’, ‘Component’ and ‘System’ have been required.

Also, we can see the attributes that have been required within each tab.

For example, in the ‘Contact’ tab the ‘Email’, ‘Company’ and ‘Phone’ attributes have been required.

‘GivenName’ and ‘FamilyName’ attributes do not need to be included.