Trades should not be financing the project by absorbing the cost of information requirements that provide no value to the trade.
For trades, BIM has one central purpose: helping streamline the production and delivery of their installations.
Modelling and coordination are activities that support that purpose. The installation is the result the trade is there to deliver.
When BIM requirements go beyond supporting the installation, we need to ask whose needs they serve, who benefits and who pays.
If BIM is required, why?
Can trades use AutoCAD drawings to communicate what field personnel need to install their services? Yes, where those drawings meet the installation and project requirements.
If a BIM model is also required, why? What does it provide that the installation drawings do not? Does it help the trade deliver its installation, or is it being produced for another stakeholder’s use?
Those questions need answers before the work is priced.
An owner may need asset information. A construction manager may need reporting data. Another stakeholder may need information structured for their own systems.
Those requirements may have value to their consumers. Producing them still takes time and money.
The stakeholder requesting that information should account for and fund the work. The trade should not absorb the cost simply because it produces the information.
Hard pipe. Hard equipment. Hard conduit. Now a database?
Trades have to communicate with their field personnel and deliver physical installations.
Now they may also be required to populate a database. Add parameters they do not use. Find the information. Enter it. Track it. Update it. Then have someone run a quality check and mark the submission as a pass or fail.
A request to “just add a few parameters” can create work across thousands of objects. Each change may require another update, another check and another submission.
If the trade does not need that information for its installation, who is it for? Why should the trade finance its production?
Information required by another stakeholder should be treated as a defined deliverable with an identifiable cost.
Multiple platforms, multiple costs
Why should a trade carry the cost of multiple platforms, software packages and hardware to supply information that provides no value to its installation?
Each system can require licences, training, setup, administration, uploads, conversion and support. The same information may have to be entered and checked in several places.
These costs need to be visible when requirements are established. They should not become an unpriced obligation passed down to the trade.
If a stakeholder requires a particular system, identify what it is for, what the trade must do in it and how that effort will be paid for.
Make the scope clear before the work starts
Separate what the trade needs for its installation from what other stakeholders need for their own use.
For every required model, dataset or submission, establish:
- Purpose: how it supports installation or whose information needs it serves.
- Deliverable: exactly what must be supplied, in which format and by when.
- Responsibility: who provides the source information, produces the deliverable and accepts it.
- Effort and cost: the labour, software, hardware, training and checking required.
- Limits: the included submissions, review cycles and updates.
- Changes: how additional requirements will be identified, priced and authorised.
Identify what is included, what is excluded and what remains unresolved. Raise unclear requirements through the permitted tender or contract process.
A requirement serving someone else may already be included in the contract. Understand that before pricing and signing. BIMTA’s position remains that the effort should be identified and properly funded.
Agree the checking rules before producing the information
Trades should know what a submission will be checked against before they build it.
Which parameters are required? What values are acceptable? Who supplies missing information? Who resolves conflicting instructions? What happens when the checking rules change?
Test a small sample with the receiving team before applying the requirement across the project. Confirm that the information can actually be used for its stated purpose.
A pass-or-fail result can assess agreed requirements. It does not explain who should pay for additional requirements introduced later.
Where does design assist begin?
Trades bring practical knowledge about how their installations are assembled, accessed and delivered.
But are they being asked to plan their installation, or to work through unresolved design and explain how the building can be built?
Where does their responsibility begin and end? How much of that contribution was included in the price?
If that knowledge is required, define the contribution, decision-making responsibility and cost. It should not disappear into an open-ended expectation that the trade will resolve whatever reaches the coordination meeting.
Interoperability for what purpose?
If a trade must receive a file format it has never used, what assurance is there that the information needed for installation is actually in it?
Who checks the exchange? Who pays for the software and training? Who repairs missing or unusable information?
Drawings have traditionally communicated what needs to be built. If another method is required, it should clearly explain how the necessary information reaches the people doing the installation.
Opening a file is only one step. The information must be understandable and usable for the intended work.
The trade should not finance everyone else’s information needs
Trades are increasingly expected to produce information that downstream consumers need, alongside the physical installations they are engaged to deliver.
Continually adding tasks that provide no value to the trade creates a gap between what the trade must spend and what it has been paid to deliver.
That gap needs to be accounted for.
If another stakeholder needs additional models, data, parameters or reports for their own use, the cost and level of effort should be accounted for and paid for by that stakeholder.
Trades should not be financing the project through unpriced work that provides no value to their installation.
That is BIMTA’s position: installation is the purpose. Additional information requirements need a clear customer, a clear scope and a clear price.
This brief expresses BIMTA’s position on fair scope and cost allocation. Actual obligations and payment entitlements depend on the applicable agreements.
Supporting references
These references support purposeful information requirements, planned exchanges and defined responsibilities. They do not establish BIMTA’s proposed allocation of costs as a contractual rule.
- Penn State BIM Planning ↗
Planning BIM uses and information exchanges around defined project purposes. This brief presents installation as the central trade business purpose, not a claim that BIM has only one recognised use.
- UK BIM Framework, Guidance Part D, February 2021 ↗
Defining information requirements and acceptance criteria. International guidance, not an automatic Canadian contract requirement.
- Metrolinx Exchange Information Requirements, June 2025 ↗
A Canadian example of documented information delivery requirements.