Developing a comprehensive BIM brief before a project begins is the key to harnessing BIM’s power to transform how we build and maintain assets. Thinking why, what and how will help get the necessary information.
BUILDING INFORMATION MODELLING (BIM) promises to reduce risk, deliver efficiencies and add value in the way we design, construct and operate our built assets. However, this Holy Grail is often not realised due to ambiguous requirements that result in inconsistencies and misaligned expectations. To mitigate these risks and realise the true value of BIM, start with the end goal in mind.
How to begin
Developing a comprehensive BIM brief before beginning any project that requires BIM deliverables is the best-practice approach. While this article focuses primarily on the information requirements, there are many other key inputs that need to go into the BIM brief and broader request for proposal (RFP) process to increase the chances of success.
Consideration should be given to key inputs such as:
- the way model objects are classified
- as-built model requirements
- integration with existing systems
- technology and software requirements
- common data environment requirements
- data security requirements
- procurement requirements
- additional contract clauses and much more.
Where it can go wrong – poor inputs
BIM has gained currency over the last decade in the New Zealand construction industry, although its processes have not always been implemented with consistency.
When things go wrong, it’s generally due to BIM being overlooked as part of the RFP process, often due to a lack of understanding of the process.
As a consultant who regularly responds to RFPs, I rarely see a why, what and how approach. In some instances, BIM requirements for a project are detailed in little more than a paragraph of text or even just simple statements, as shown in these real-world examples:
- Provide a description of your approach to BIM integration.
- Please confirm that you model in BIM.
- Provide BIM to LOD 500.
The ambiguity of these approaches to defining requirements for something as complex as BIM, while often not intentional, does cause problems that impact the overall success of a project.
If you’re trying to establish BIM requirements on a project or programme of work, you’re undeniably doing the right thing. The problem is you don’t know what you don’t know.
Involving trusted advisors throughout the supply chain and procurement process is essential to help clearly define requirements and not lose sight of the end goal.
Information requirements for a project brief
Good BIM outcomes are based on accurate, relevant information. To meet your objectives for a project across the asset life cycle, it’s important to keep the following three components in mind (Figure 1):
- Organisational information requirements – why do you want the information? For example, perhaps you’d like to access an asset’s data for maintenance purposes or to deal with a recall notice.
- Asset information requirements – what information do you want? For example, perhaps your building contains an extensive air conditioning system, and for each unit, you’d like to know the manufacturer, product type and serial number.
- Project information requirements – how would you like the information to be delivered. For example, you require 2D or 3D models to support wayfinding. In this case, 2D or 3D graphics would be the medium of delivering the requested information.
Whatever the specific requirements for your project brief, quality information is a fundamental aspect of using BIM effectively. The briefing process should not be under-estimated or undervalued, as unclear requirements can result in unwanted consequences.
Developing BIM requirements
So, how can you develop your BIM requirements to achieve the desired outcomes?
Organisational information requirements – Why?
Data is fast becoming the most powerful asset of the 21st century, with the wealth and power of companies such as Amazon, Facebook and Google evidence of this. Scaled back to an operational and maintenance viewpoint, the ability to leverage BIM data to inform scheduled maintenance, predict asset failure and inform renewals and replacement forecasting stands to add significant value to operations.
In a world of big data, it’s also worthwhile erring on the side of caution when it comes to the amount of data you collect. Data is an asset and should be treated that way. I’m of the view that, once data becomes inaccurate, the whole process that’s underpinned by it becomes compromised, making any related activities inefficient and costly. As a result, we encourage our clients to focus on proportionate data that has real value and purpose.
Organisational information requirements provide justification for collecting data to ensure it has value. This could include:
- financial requirements – such as asset valuation and planning
- strategic requirements – such as business performance
- asset information requirements – such as asset classification.
Whatever the organisation, it’s important these requirements are clearly defined and understood before defining the asset information requirements.
Asset information requirements – What?
The requirements for asset information deliverables are often not articulated at a granular level. Hence, the delivery of this information is generally an afterthought and at times is expected of parties who are not always best placed to create and deliver it. This results in information either being delivered late, not being delivered at all or not being compatible with existing systems.
Figure 2 provides steps to BIM asset management requirements.
Project information requirements – How?
How information is delivered is as important as what information is required and who is responsible for delivering it. As part of defining the BIM requirements for any project, consider whether the information deliverable is a drawing, an electrical schematic, a graphical model or data to be fed into an asset management system.
These requirements should be further broken down to specify specific file formats. A P&ID diagram might be required as a static PDF file to record a point in time but also in its native file format so it can be maintained over the life of the built asset.
A graphical model file might be required as a 3D PDF file to record a point in time but also several other file formats such as IFC, a lightweight viewer file such as Autodesk Navisworks and the native model file format for future modification and maintenance. Asset data will most likely be required in a tabular format such as Excel, but the requirements could also be that the data is populated using proprietary integration software.
Not specifying the how will leave this open to interpretation by the supply chain. This could result in additional project risk and inefficiencies due to reworking information to suit requirements, which in turn results in lost value.
Articles are correct at the time of publication but may have since become outdated.