One of the many questions I receive via email has to do with building information models and construction. "Jeff, what are contractors looking for when we hand them our Revit models?". I had an idea of what the answer should be but this past year (working at Turner Construction) has opened my eyes to the truth. When I started at Turner earlier this year I got the same questions from architects we are working with. I took the time to make a simple guide that helps explain what we are looking for... Here is an excerpt from the guide for your information and use...
Full disclosure: this guide was more for how we use the models for quantity takeoff but the principles are similar for other uses...
"...We understand that every company will deploy different standards, view setups, modeling practices, and naming conventions when creating their building information models. We will work with and adapt our process to your model standards and conventions when extracting information.
Generally speaking, a building information model that can be utilized for takeoffs will contain the ability to schedule specific model elements and sort them by a specific unit. For example, all of the lights fixtures can be scheduled, sorted by type mark, and then counted. Another example would be windows that can be scheduled, sorted by type, length, width, and/or areas.
The following are some common modeling practices that can assist the project team in creating a more usable building information model:
1. Using proper Revit “Assembly Code” to match Turner’s BIM Content Plan for all elements helps immensely.
2. When a model author creates custom door and/or window families add the width and height parameter even if the family is not going to be parametric.
3. Confirm that all wall offsets (top and bottom) are correct per the design intent. For example, extending a wall to underside of deck versus 6” passed the ceiling.
4. Don’t use generic walls. Even if the wall is not going to be tagged. At the very least give it a type name, designation, or some piece of information that separates it from other wall types.
5. A basic family is better than no family. For example, instead of drafting a piece of specialty equipment (which may need to be counted for an estimate) a simple box family (3D) with the correct category and a descriptive type name with symbolic details (2D) is preferred.
6. Try to use Revit beams for custom beam situations. For example, arched hollow tube steel can be modeled using Revit’s beam families. If a custom beam is modeled with an extrusion it can’t report the length and can be missed.
7. We understand it is unreasonable to model all MEP penetrations but very large ones should be modeled. For example, a very large duct penetrating a wall or floor.
Refer to “BIMForum - LOD 2014 – Turner Estimating Markup” for desired level of development per model element. This document can act as guideline to help teams communicate expectations within a model. On page 9, the document expands on how important these expectations can be:
The Level of Development (LOD) framework addresses several issues that arise when a BIM is used as a communication or collaboration tool, i.e., when someone other than the author extracts information from it:
During the design process, building systems and components progress from a vague conceptual idea to a precise description. In the past there has been no simple way to designate where a model element is along this path. The author knows, but others often don’t.
It’s easy to misinterpret the precision at which an element is modeled. Hand drawings range from pen strokes on a napkin to hard lines with dimensions called out, and it’s easy to infer the precision of the drawing from its appearance. In a model though, a generic component placed approximately can look exactly the same as a specific component located precisely, so we need something besides appearance to tell the difference.
It is possible to infer information from a BIM that the author doesn’t intend – unstated dimensions can be measured with precision, assembly information often exists before it’s been finalized, etc. In the past, this issue has been sidestepped with all-encompassing disclaimers that basically say, “Since some of the information in the model is unreliable, you may not rely on any of it.” The LOD framework allows model authors to clearly state the reliability of given model elements, so the concept becomes “Since some of the information in the model is unreliable, you may only rely on it for what I specifically say you can.”
In a collaborative environment, where people other than the model author are depending on information from the model in order to move their own work forward, the design work plan takes on high importance – it is necessary for the model users to know when information will be available in order to plan their work. The LOD framework facilitates this..." BIMForum, 2015