Moving to a model based deliverable as the industry standard has many benefits. The model allows better communication to the client and better collaboration among the various stakeholders. Changes and preferences can be easily incorporated and drawings updated – and various options and scenarios can be analyzed to determine the cost impact with much less time and effort. Material usage is more easily tracked, and contractors can automatically extract quantities.
However, with those benefits come risks that are inherently new and different from the traditional risks associated with paper (or PDF) plans. The risks of signed and sealed deliverables, and possible mitigation strategies for those risks, are the subject of this article.
Risk 1: Data Misuse
To recognize the benefits of a signed and sealed model, the end user must understand what the model contains, and – perhaps more importantly – what the model does not contain. There must be some common understanding of what the A/E firm is attempting to convey, otherwise the model could leave owners and contractors with a mistaken understanding of the A/E’s intent. Delivering information in the form of a model also has the potential for the unintended use of data. For instance, if the level of effort is not clearly defined in the contractual deliverables, the contractor may assume a certain model is intended for construction, when it was only intended to be a preliminary deliverable for the owner. Finally, data can be lost or accidentally erased if multiple shareholders are provided with access to the model.
Risk 2: Data Security
Using a model as the official contractual submittal increases the risk of cyber theft and hacking. Critical infrastructure designs for structures such as dams, subways, airports, or water treatment plants are prime grounds for political and environmental terrorism, espionage, and other criminal elements. Obviously, the threat of a mal-intentioned third party manipulating a certain design can increase dramatically when the final design is in the form of a model, as opposed to paper (or PDF) drawings.
Risk 3: Roles and Participants of Design May Not Be Defined
The very beauty and collaborative nature of the signed and sealed model opens the A/E firm to risk as it relates to the rights and abilities of the other collaborators. Changes may not be authorized, apparent, or tracked. The A/E firm must find a way to “lock” the design so that it is not held liable or professionally responsible for later changes or manipulations by other parties.
Risk 4: Subcontractors or Small Firms May Lack Technology
The software for this technology is not cheap, and may not be widely used by subcontractors or small firms. Requiring the use of a signed/sealed 3D model as the final deliverable may preclude smaller and DBE type firms from bidding on projects. Larger A/E firms will need to confirm that their subcontractors have adequate licenses for the software before they are engaged.
Risk 5: Insurance
With third parties having the ability to manipulate the model/deliverable, questions may arise regarding professional liability coverage. Which firm’s policy will respond if the origination of the error is not clear? In addition, there is currently no well-defined standard of care for BIM deliverables. Insurance carriers may deny coverage based on a failure to prove a breach of the standard of care.
Risk 6: QA/QC and “Responsible Charge”
Professional engineering codes, as well as most A/E firms’ best practices, require oversight of Engineers in Training (“E.I.T.”) by professional engineers (“P.E.”). In many cases, the E.I.T. may be of a younger generation, more comfortable with technology and the use of models in general. Nonetheless, her work must still be quality checked or performed under the “responsible charge” of a P.E. If a firm’s P.E.s do not have the same level of experience and comfort with the technology, errors could go unchecked.
Risk 7: Software Defects
Software purchase agreements are some of the strictest, one-sided contracts we see. Most software agreements expressly disclaim liability for errors and do not allow the purchaser to come after the software company for lost damages such as profits, indirect damages, etc. If there is a “glitch” in the software itself, leading to an error in the design, an A/E firm may find itself unable to recover against the software company.
Because the technology and use of the models in this way is so new, many of these risks are untested in the courts. Nonetheless, prudent A/E firms will incorporate language in their contracts to address the risks. In addition, both ACEC and AASHTO are working with various agencies to address these risks in their contracts and get away from a “one size fits all” type of contracting.
The AIA E-203 2013, G-202 and ConsensusDOCS BIM 301 Addendum all provide a good starting point for suggested contractual language. In addition, attorneys reviewing and editing these contracts should determine whether the contract language adequately defines what the owner is requiring of the designer as a deliverable and to a defined level of detail (also known as “level of effort”). The following diagrams illustrate different levels of development, showing why it is important to make sure that the contract identifies what level of development is being contracted for and provided:
The contract should also define whether the BIM elements will be relied upon or shared with the construction team or others not under the designer’s direction and control. If electronic data will be transmitted to parties not in contractual privity, the A/E firm should require an Electronic Media Release. This type of media release defines the rights and responsibilities between parties governing the use, and misuse, of electronic data. When used with third parties receiving A/E firm data, the Electronic Media Release should bind the third party to the terms and conditions in the design contract governing use of the data.
Finally, A/E firms need to work with software companies marketing this technology to find a way to “lock down” the final deliverable, track subsequent changes, and identify who is making each change. While there are currently some very basic ways to do this, software companies need to understand that this is the primary risk when it comes to pushing the models as mandatory contract deliverables.