Is Your Contract Language Killing Your BIM Lifecycle Data?

The time for owners to get into BIM (building information modeling) appears to be now. Every day more specifications and guidelines are being released by owners stating their BIM requirements. But will these requirements get owners what they really want? In our experience the answer is no. Unfortunately, many owners kill their BIM lifecycle data the moment the contract is written. There are a number of possible issues in contract language that range from being too vague to being too specific. Even worse is contract language that focuses on items that have nothing to do with the actual end product. For the benefit of owners everywhere, this article will provide a quick review of what’s going wrong and what owners can do to make it right.

What’s going wrong:

  • Contract language that’s too vague
    BIM is not as complicated as it seems, but it is not exactly standardized either. Simply asking for BIM, encouraging BIM, or giving the contractor options for BIM electives is not going to bring any value to your project. You need to ask for something specific or you will not receive a deliverable of any value.
  • Contract language stew
    Be specific, but understand what you are requesting. It’s easy to get excited about the technology and start to ask for everything under the sun. But not all BIM processes or uses fit together nicely. By asking for too much, you may inadvertently be asking your contractors to achieve something that is not actually possible. You may also end up paying for a lot of work that will not benefit you in any way.
  • Contract language that interferes with means
    The worst thing you can do is get so specific you are dictating workflows to your contractors. Asking for a specific product is not the same as telling someone how to make a specific product. When you interfere with the work processes of professional organizations it is going to cost you more money, take more time, and likely be a lower quality product. Construction businesses make money by streamlining their workflows. When you interfere with this, the result is never good. Stick to asking for an end product and let the professionals you hire figure out how to give that end product to you.

Example of current contract language:
“XYZ Corp. will receive the BIM model in the format used by the winning firm. Once reviewed and approved, the BIM data will serve as the parent for versions applicable to projects that are BIM software specific.”

Cost estimating, project scheduling, and COBIE (Construction Operations Building Information Exchanges) initiatives are implementation electives. If one or more electives are accepted, then those criteria become a contract requirement.”

Does this language tell implementers how THE CLIENT will use the BIM upon completion of the project? Does the language need to be stringent and rigid where every screw, nut, and bolt is identified with what it will look like and what information it will contain? Additionally, should the language be flexible in nature, tying execution plans developed with all team members at all phases to the contract?

How to fix this issue:

  • Identify what the end user wants and needs.
    The first thing we recommend is to work with your end users and facilities-management groups. In this discovery process you can uncover what information is valuable to them. Ask them to tell you their hearts’ desire. Next meet with a firm or two, preferably both design and construction, in order to fine tune this ‘hearts-desire list’ into something that pushes for innovation, yet ensures the requirements are practical, fair, and reasonable within the existing state of the technology and standards.
  • Research existing contract language.
    In the United States alone there are more than 20 BIM requirements. How do you pick the right one? First, look for a common thread: Most are really derivatives of two standards, USACE (U.S. Army Corp of Engineers), www.usace.army.mil, Washington, D.C., and Penn State, www.psu.edu, University Park, Pa. Once you have established the core threads, see how they align with your team’s needs. During this discovery phase, you’ll determine if your requirements are practical, equitable, and reasonable considering the current state of technology and standards. This is a key item to identify. If you fail to align your needs with core threads, you more than likely will be paying for something you can’t use.
  • Get some professional help.
    So where does one seek professional help? No need to call a psychiatrist! Look to organizations such as the AIA (American Institute of Architects), www.aia.org, Washington, D.C., or the AGC (Associated General Contractors of America), www.agc.org, Arlington, Va. Eventually you may even look to the NBIMS (National Building Information Modeling Standard), www.nationalbimstandard.org, Washington, D.C., once it achieves a better maturity and broader adoption. Another source is providers with whom you already have an established working relationship. Both designers and contractors have valuable information that can help you in establishing your BIM requirements. By reaching out to these partner firms, you could be well on your way to creating requirements that are practical, equitable, and reasonable.
  • Only ask for what you need.
    This comes straight from the first bullet point. Once you have identified what is wanted/needed, then you need to ask for it. This is more difficult than it sounds, because in the world of BIM there is gray area here. How do you ask for your data to be structured a certain way without telling someone how to achieve the structure? Don’t fall into the trap of trying to be an expert in all parts of the process in order to ensure you get the product you envision. Focus on your end-goal. As you develop your requirements, regularly ask yourself if what you are asking for is an end product, not a workflow process. It also does not hurt to get guidance from the resources mentioned in the last two bullet points. Most of the current guidelines were developed with this goal in mind.

With contract language in BIM still relatively new in its development, it is hard to put together a specification that gets you what you want. To do so means you have to ask for something not too vague, not too specific, and something that is actually able to be accomplished.

You may find it comforting to know no one has gotten this right yet. Everyone is still looking for that specific sweet spot that just seems to work. But the ones that have come the closest do so by using the resources already available to them. The most important thing to remember about BIM is it is a process, which gains strength from collaboration. Don’t try to figure it all out on your own.

The most successful BIM workflows we know of were all achieved from sharing ideas and learning together. The greatest failures we have seen have, without exception, had workflows built in isolation.

Here at Epic BIM, we have taken to telling each other “you’re not that special.” We use the phrase as a reminder that whatever we try to achieve on our own is just not good enough.

So if you want to get what you need for your facility out of a BIM process, reach out to all of the team members you would like to achieve success with and build a plan that gets you what you want and allows your team to give it to you.


John Grady and Connor Christian cofounded EpicBIM with the goal of helping the construction industry see BIM for what it is and not through rose-colored glasses. John can be reached at jgrady@epicbim.com and Connor can be reached at cmchristian@epicbim.com