bim deployment plan final e artigos

1

AUTODESK BIM DEPLOYMENT PLAN: A PrAcTIcAL FrAMEwOrK FOr IMPLEMENTINg BIM

Autodesk BIM Deployment Plan:A Practical Framework forImplementing BIM

2


IMPORTANT — PLEASE READ

This document is being provided for informational purposes only. THE FrAMEwOrK AND gUIDANcE cONTAINED IN THIS DOcU-MENT ArE NOT SUBSTITUTES FOr YOUr PrOFESSIONAL JUDgMENT. THEY ArE INTENDED TO ASSIST YOU IN DEVELOPINg A FrAME-wOrK APrOPrIATE TO YOUr PrOJEcT NEEDS gIVEN THE LArgE VArIETY OF POTENTIAL APPLIcATIONS. THE FrAMEwOrK AND gUIDANcE SET FOrTH IN THIS DOcUMENT HAVE NOT BEEN TESTED IN ALL SITUATIONS UNDEr wHIcH THEY MAY BE USED AND MAY BE UPDATED FrOM TIME TO TIME, SO AUTODESK SHALL NOT BE LIABLE IN ANY MANNEr wHATSOEVEr FOr THE rESULTS OB-TAINED THrOUgH ITS USE. PErSONS DEPLOYINg THE FrAMEwOrK AND gUIDANcE SET FOrTH IN THIS DOcUMENT ArE rESPONSI-BLE FOr THE OUTcOME OF THEIr APPLIcATION. THIS rESPONSIBILITY INcLUDES, BUT IS NOT LIMITED TO, THE DETErMINATION OF APPrOPrIATE cHANgES AND IMPLEMENTATION TO AcHIEVE INTENDED rESULTS, IDENTIFYINg AND rEVIEwINg OTHEr cONSIDEr-ATIONS rELEVANT TO ITS DEPLOYMENT, AND SEEKINg APrOPrIATE PrOFESSIONAL cOUNSEL AS NEcESSArY.

NO WARRANTY. AUTODESK, INc. (“AUTODESK”) MAKES NO rEPrESENTATIONS ABOUT THE SUITABILITY OF THE cONTENT OF THIS DOcUMENT FOr ANY PUrPOSE. THIS PUBLIcATION AND THE INFOrMATION cONTAINED HErEIN IS MADE AVAILABLE BY AU-TODESK, INc. “AS IS.” AUTODESK HErEBY DIScLAIMS ALL wArrANTIES, EITHEr EXPrESS Or IMPLIED, INcLUDINg BUT NOT LIMITED TO ANY IMPLIED wArrANTIES OF MErcHANTABILITY Or FITNESS FOr A PArTIcULAr PUrPOSE, TITLE, AND NON-INFrINgEMENT, rEgArDINg THESE MATErIALS. IN NO EVENT SHALL AUTODESK BE LIABLE FOr ANY SPEcIAL, INDIrEcT, EXEMPLArY, Or cONSE-QUENTIAL DAMAgES Or ANY DAMAgES wHATSOEVEr, INcLUDINg BUT NOT LIMITED TO LOSS OF USE, DATA, Or PrOFITS, wITH-OUT rEgArD TO THE FOrM OF ANY AcTION, INcLUDINg BUT NOT LIMITED TO cONTrAcT, NEgLIgENcE, Or OTHEr TOrTS, ArIS-INg OUT OF Or IN cONNEcTION wITH THE USE, cOPYINg, Or DISPLAY OF THIS DOcUMENT.

None of the information contained herein should be construed as legal advice. If you need legal advice, please seek the advice of inde-pendent legal counsel. No attorney client-relationship is formed by virtue of the content or use of this document.

©2010 Autodesk, Inc. All rights reserved. Except as otherwise permitted by Autodesk, Inc., this publication, or parts thereof, may not be reproduced in any form, by any method, for any purpose.

certain materials included in this publication are reprinted with the permission of the copyright holder.

Autodesk, Navisworks, and revit are registered trademarks or trademarks of Autodesk, Inc. and/or its subsidiaries in the USA and/or other countries. All other brand names, product names, or trademarks belong to their respective holders.

Occasionally, Autodesk makes statements regarding planned or future development efforts for our existing or new products and services. These statements are not intended to be a promise or guarantee of future delivery of products, services, or features but merely reflect our current plans, which may change. The company assumes no obligation to update these forward-looking statements to reflect any change in circumstances, after the statements are made.

Published by: Autodesk, Inc. 111 Mclnnis Parkway San rafael, cA 94903, USA

3


Executive SummaryIn today’s architecture, engineering, and construction (AEc) industry, new technologies and practices are making a significant difference in how building projects get delivered. Owners, architects, engineers, and contractors are using collaborative communication platforms to manage and share information and standardize their business processes. Meanwhile, advanced model creation tools let stakeholders visual-ize, simulate, and analyze how a building might behave, perform, or appear—with more precision than ever before.

But the plethora of new tools, technologies, and practices may seem confusing. To help users navigate and take advantage of the savings in cost and time these tools can offer, we have created this document.

The Autodesk BIM Deployment Plan outlines practices and provides a framework for using building information modeling (BIM) technology and practices that can help to deliver projects faster, more cost-effectively, and more sustainably.

Filled with information and planning templates designed to streamline project communications, this plan focuses on helping you reduce design and construction costs through collaborative communication. By using this document as an adaptable template to establish organi-zational and project standards and responsibilities from the start, you’ll ensure that all stakeholders get the information they need during every phase of the building project. The accompanying supplement (in Microsoft word format) includes tables that you can fill in and edit as needed to create your own plan.

4


contentsSEcTION 1: OrgANIzATIONAL BIM DEPLOYMENT PLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.0.0.0 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.1.0.0 Organizational BIM Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.1.1.0 Alignment with Organizational Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.1.2.0 goals for BIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.2.0.0 Modeling Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2.1.0 Planned Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2.2.0 Modeling Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.2.2.1 Precision and Dimensioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2.2.2 Modeling Object Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2.2.3 Modeling Level of Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2.2.4 System of Measurement convention. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.2.3.0 Analysis Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2.3.1 Quantity Takeoff Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2.3.2 Scheduling Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2.3.3 clash Detection Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2.3.4 Visualization Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2.3.5 LEED rating/Energy Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2.3.6 Structural Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.2.4.0 Planned Analysis Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121.3.0.0 Staffing Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

1.3.1.0 Organizational Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121.3.1.1 current Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121.3.1.2 recommended Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

1.3.2.0 Personnel Skills . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121.3.2.1 current Skills. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121.3.2.2 required Skills . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.3.3.0 Staff Acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.3.4.0 Training requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.4.0.0 Systems Implementation Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.4.1.0 communication Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.4.2.0 Training Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.4.3.0 Support Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.5.0.0 corporate collaboration Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.5.1.0 Document Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.5.1.1 Permissions and Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.5.1.2 Folder Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.5.1.3 Folder Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.5.1.4 File Naming convention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.6.0.0 corporate Technology Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.6.1.0 Software Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.6.1.1 Model creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161.6.1.2 Model Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161.6.1.3 clash Detection/Model Mediation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161.6.1.4 Model Visualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161.6.1.5 Model Sequencing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161.6.1.6 Model Quantity Takeoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161.6.1.7 collaborative Project Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

1.6.2.0 Infrastructure requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.6.3.0 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5


SEcTION 2: PrOJEcT BIM DEPLOYMENT PLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182.0.0.0 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192.1.0.0 Project Initiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

2.1.1.0 Project Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192.1.2.0 core collaboration Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192.1.3.0 Project goals and Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.1.4.0 collaborative Process Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.1.5.0 Project Phases/Milestones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.2.0.0 Modeling Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.2.1.0. Model Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.2.2.0 Planned Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.2.3.0 Model components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.2.3.0a File Naming Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.2.3.0b Precision and Dimensioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.2.3.1 Modeling Object Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.2.3.2 Modeling Level of Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.2.3.3 Model reference coordination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.2.3.4 System of Measurement convention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.2.4.0 contract Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.2.5.0 Detailed Modeling Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.2.5.1 conceptualization/conceptual Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.2.5.2 criteria Design/Schematic Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.2.5.3 Detailed Design/Design Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.2.5.4 Implementation/construction Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.2.5.5 Agency coordination Bidding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.2.5.6 construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.2.5.7 Facility Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.3.0.0 Analysis Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.3.1.0 Analysis Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.3.1.1 Quantity Takeoff Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.3.1.2 Scheduling Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.3.1.3 clash Detection Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.3.1.4 Visualization Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.3.1.5 LEED rating/Energy Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.3.1.6 Structural Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.3.2.0 Detailed Analysis Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.3.2.1 Special Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6


2.4.0.0 Project collaboration and communication Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.4.1.0 communication Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.4.1.1 Messaging and communication Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.4.1.2 Meeting Minutes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.4.1.3 correspondence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

2.4.2.0 collaboration Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .332.4.2.1 Document Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

2.4.2.1a Permissions and Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .332.4.2.1b Folder Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.4.2.1c Folder Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.4.2.1d File Naming convention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.4.2.1e Design review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.4.2.2 Bid Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .352.4.2.3 construction Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35

2.4.2.3a rFIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .352.4.2.3b Submittals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .352.4.2.3c Daily reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .352.4.2.3d Other construction Management Business Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.4.2.4. cost Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.4.2.4a Budgeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.4.2.4b Purchasing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.4.2.4c change Order Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.4.2.4d Payment Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.4.2.5 Project closeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.4.2.5a As-Built Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.4.2.5b System Archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37

2.5.0.0 Project Technology Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .372.5.1.0 Software component Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37

2.5.1.1 Model creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .372.5.1.2 Model Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .372.5.1.3 clash Detection/Model Mediation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .372.5.1.4 Model Visualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .372.5.1.5 Model Sequencing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .372.5.1.6 Model Quantity Takeoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .372.5.1.7 collaborative Project Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.5.2.0 System requirements and Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.5.2.1 Model creation, clash Detection, Visualization, Sequencing, Simulation, and Quantity Takeoff Tools . . . . . . . . . . . . . . . . . . . . . 39

2.5.2.1a IT requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.5.2.1b Funding Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.5.2.1c Data Ownership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.5.2.1d Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.5.2.1e User requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.5.2.2 collaborative Project Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.5.2.2a System Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.5.2.2b IT requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.5.2.2c Funding Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.5.2.2d Data Ownership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.5.2.2e Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.5.2.2f User requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.5.2.2g Security requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41

Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Definitions of Terms Used in This Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

7


SEcTION 1: Organizational BIM Deployment Plan

8


1.0.0.0 OverviewIn recent years, new technologies and practices have fundamentally changed how building projects are delivered. These technologies range from new tools for model creation to the use of visualization, simulation, and analysis tools to better predict a building’s behavior, perfor-mance, or appearance. In addition, collaborative communication platforms are used to manage and share information and drive business process standardization.

The intent of this Autodesk BIM Deployment Plan document is to provide a framework that lets owners, architects, engineers and contrac-tors deploy building information modeling (BIM) technology and best practices to deliver projects faster and more cost-effectively. This document also makes suggestions on the roles and responsibilities of each party, the detail and scope of information to be shared, relevant business processes, and supporting software. The document is divided into two sections: The Organizational BIM Plan and The Project BIM Plan. The Organizational BIM Plan helps companies implement BIM technologies at the organizational level, while the Project BIM Plan helps project teams implement BIM technologies.

For stakeholders in building projects, the potential benefits of applying the framework and suggestions include:

Improved communication and collaboration among all project team members •

Fewer problems related to overruns in cost, schedule, and scope, or quality concerns•

The ability to reliably deliver projects faster, more economically, and with reduced environmental impact.• BIM technology helps builders ensure that project knowledge remains accessible continuously throughout the different phases—planning, bidding, building, and operating—of any construction project. But before they deploy BIM technology, builders need information on how to streamline their communications and select the right tools.

Autodesk created this BIM Deployment Plan to help guide companies like yours through the process. It helps you define project teams, indentify key processes and dependencies throughout your project, assign roles and responsibilities, and select software solutions that use collaborative communication to reduce your project costs.

1.1.0.0 Organizational BIM Vision In this section you’ll define your Organizational BIM Vision, including goals, objectives, and alignment with your overall organizational vi-sion.

1.1.1.0 Alignment with Organizational VisionThe implementation of BIM technologies can have a large impact on the operations of your organization. In the space provided below, list your organization’s vision statement and specify how the implementation of BIM technologies enhances and or alters that vision. The first lines show examples.

9


Organization Vision Statement

To be the premier general contractor for complex construction projects, in which meeting challenges through technology sets us apart from our competition.

BIM Enhances Vision

BIM tools enhance our company’s technology offering and help us provide superior service to our clients.

BIM Alters Vision

BIM technologies will allow us to compete in the IPD market.

1.1.2.0 goals for BIM Implementing collaborative project management and BIM technologies across your organization can offer tangible as well as intangible ben-efits. List your goals and objectives for using BIM and collaborative project management technologies and processes below. Also note how you will measure the achievement of these objectives and their targeted timeframes. The first row shows an example.

BIM Goal Measureable Objective Achieved If Projected Timeframe

Improve operations management on all new facilities

Obtain an as-built model on all new construction showing mechanical systems information

A model is collected or updated by the project team after each project or WO

April 2010

1.2.0.0 Modeling PlanIn this section you will evaluate the different types of models to be created as part of your organization’s service offerings. You will evaluate planned models, set modeling standards, and modeling analysis options.

1.2.1.0 Planned Models During the course of a project, the project team may generate multiple models. Typically the architect and architecture subconsultants generate a Design Intent model to depict the design intent of the building, and the contractor and contracting subcontractors generate a construction model to simulate construction and analyze the constructability of the building. The construction team should provide input for the Design Intent model, while the design team should provide input for the construction model.

10


Even when the team is committed to using integrated project delivery (IPD) methods, creating separate models is sometimes necessary due to contractual obligations, risk factors, and the functional intent of each model. For example, the Design Intent model—used to depict the design intent—may not include information on the means and method or sequencing of construction. Other models may be created spe-cifically for certain types of analysis, such as energy consumption or safety. These Analysis models are usually spinoffs of either the Design Intent model or the construction model. Analysis models will be specified further in section 2.2.3.0 of this document, which covers Analysis models and planning.

In the table below, outline the models that your organization may create in a typical project. List model name, model content, the project phase when the model will be delivered, and the model authoring tool to be used. For models that will not be created by your organization, leave the row blank; add rows for model types that you anticipate needing that are not already listed. The first row offers an example.

Model Name Model content Project Phase Authoring Tool

Coordination Model Architectural, structural, and MEP components of main build-ing and parking garage structure

Design development and con-struction documents

Autodesk® Revit® Architecture software

civil Model

Architectural Model

Structural Model

MEP Model

construction Model

coordination Model

As-Built Model

1.2.2.0 Modeling StandardsEstablishing modeling standards is a critical component of implementing BIM technologies. In this section, you will establish guidelines for precision and dimensioning, object properties, level of detail, and measurement convention.

1.2.2.1 Precision and Dimensioning Models should include all appropriate dimensioning as needed for design intent, analysis, and construction. with the exception of the exclu-sions listed below, the model will be considered complete. In the list below, enter which items’ placement will not be considered for com-pleteness of the model and should not be relied on for placement or assembly.

[List items that will not be considered for dimensioning or placement]

1.2.2.2 Modeling Object Properties Your organization must establish how much information will be stored in object properties. The amount of information needed is a function of what it will be used for. The standard objective property data must also take into consideration the types of analysis to be performed on the models. See section 2.2.3.0 for more details on model analysis.

[Define the amount of object property information here.]

1.2.2.3 Modeling Level of DetailA detailed Level of Detail (LOD) Analysis can be performed using the Exhibit A spreadsheet, which will help your organization identify which components will be modeled, by whom, during which project phase or milestone, and at what level of detail. The LOD is broken down into four levels: L1, L2, L3, and cD. In L1, the model will include basic shapes that represent approximate size, shape, and orientation of objects. These objects may be in 2D or 3D. In L2, the model will include object assemblies with approximate size, shape, orientation, and object data.

11


In L3, the model will include data-rich assemblies with actual size, shape, and orientation. In cD (construction Documents), the model will include detailed assemblies with final size, shape, and orientation used for construction and fabrication. Proceed to Exhibit A for further details and instructions.

certain items may be excluded from the model, and can be defined by expressed exclusion and/or object size.

1.2.2.3a Exclusions: List any objects that will be excluded from the model in the space below.

[List exclusions here]

1.2.2.3b Size: Any object smaller than [_________] (Fill in item size, for example, 6”x6”x6”) will not be included in the model.

1.2.2.4 System of Measurement conventionSpecify the standard units convention for the organization. [___________] (Metric or English)

1.2.3.0 Analysis ModelsA number of analysis tools allow you to leverage BIM technologies for superior foresight on your design and construction. This section out-lines the major types of analysis tools.

1.2.3.1 Quantity Takeoff AnalysisThe objective of quantity takeoff analysis is to use modeling property data to automate or simplify the quantity takeoff process. The infor-mation from the quantity takeoff tool can then be imported or tied to cost-estimating software. For the quantity takeoff process to work seamlessly, the original modeling author must include the relevant property information in the design.

1.2.3.2 Scheduling AnalysisScheduling analysis lets the project team use the project model to analyze the timeline and sequencing for construction. This information can then be used to modify or adjust the construction schedule. while tools do exist that allow project team members to visualize construc-tion over time, no such systems yet interact automatically with scheduling tools.

1.2.3.3 clash Detection Analysis clash detection analysis is done to check for interferences between the designs of one or many models. To reduce change orders during construction, clash detection should be performed early and continue throughout the design process. For clash detection to work properly, your project’s models must have a common reference point and must be compatible with the clash detection tool.

1.2.3.4 Visualization AnalysisVisualization tools let the project team view the design or construction of the project in 3D, giving a more accurate perspective on the end product.

1.2.3.5 LEED rating/Energy Analysis LEED (Leadership in Energy and Environmental Design) rating/energy analysis tools help the project team evaluate the impact of design de-cisions on sustainability and energy consumption. This analysis model is usually based on the main Architectural model, after which material and building system inputs can be used to evaluate the project’s sustainability and energy consumption.

1.2.3.6 Structural Analysis Structural analysis tools use the model to analyze the building’s structural properties. Structural analysis programs typically use the finite element method (FEM) to measure the stresses on all structural elements of the design. For structural analysis to work seamlessly, the original structural modeling tool must be compatible with the structural analysis tool, and the original structural model property data must include information about the structural elements.

12


1.2.4.0 Planned Analysis ToolsList the types of analysis tools that your organization plans on implementing. Select the checkbox and list the name of the tool if known.

Analysis checkbox Analysis Tool

Visualization o

Structural o

clash Detection o

Quantity Takeoff o

Scheduling/4D o

cost Analysis/5D o

Energy/LEED o

Daylight/Lighting o

1.3.0.0 Staffing PlanIn this section you’ll define your organization’s staffing plan, which includes analysis of organizational structure, personnel skills, and staff acquisition and training requirements.

1.3.1.0 Organizational StructureThe implementation of BIM technologies may change the structure of your organization. Some organizations form new departments and/or new positions to handle the management of BIM technologies or services. In this section, you’ll outline your current organizational struc-ture, and recommendations will be made for your future organizational structure as it relates to BIM technologies and services.

1.3.1.1 current Structure[List your company’s current organization structure. Include an org chart if needed.]

1.3.1.2 recommended Structure[List the recommended organization structure. Include an org chart if needed.]

1.3.2.0 Personnel SkillsThe implementation of BIM technologies may require new skills. In this section, you’ll outline your organization’s current skills, and recom-mendations will be made for skills your organization will need to implement BIM technologies.

1.3.2.1 current SkillsIn the space below, fill in your organization’s current skills by listing personnel type, number of employees of each type, and average skill level. The first row shows an example.

13


Skill Personnel Type No. Average Skill Level

2D CAD Design Administrative assistantAssociate architectProject managerExecutive

53783

NoneExpertNoviceNone

1.3.2.2 required SkillsIn the space below, fill in desired skills by listing personnel type, number of total employees, the desired average skill level, and the number of employees with the desired skill level. The first row shows an example.

Skill Personnel Type Total No. Desired Skill LevelDesired No. w/Skill Level

3D BIM Design Administrative assistantAssociate architectProject managerExecutive

53783

NoneExpertIntermediateNone

01020

1.3.3.0 Staff AcquisitionIn some situations, additional staff will be needed to implement BIM technologies. In the space below, list staffing requirements including type, number of current type, number of new staff needed, location or region, and hiring timeframe. The first row shows an example.

Staff Type current No. Needed No. Location/Region Timeframe

Project BIM Coordinator 01

35

Atlanta officeTampa office

February 2010December 2009

1.3.4.0 Training requirementscurrent and acquired staff will need to be trained on new BIM technologies. A detailed Training Plan is outlined in section 1.4.2.0 of this document. In the space below, list training requirements including skill, personnel type, number of personnel to be trained, and number of training hours required per individual. The first row shows an example.

14


Skill Personnel Type No. of Staff Training Hours

Autodesk® Revit® Structure Associate architectProject manager

102

408

1.4.0.0 Systems Implementation PlanIn most cases, consultants will guide your organization through the implementation of new BIM technologies. consultants may provide your organization with additional implementation documents including a project schedule, project plan, and other deliverables. In this sec-tion you’ll define your organization’s implementation plan, which includes a communication Plan, Training Plan, and Support Plan.

1.4.1.0 communication PlanImplementing BIM technologies can create a significant shift in your organization’s operations. It is important to have effective communica-tion regarding implementation, to ensure a smooth transition and avoid confusion or misinformation. List your organization’s communica-tion Plan below.

[List your organization’s Communication Plan here.]

1.4.2.0 Training PlanTraining is needed to effectively implement BIM technologies. In the space below, list the training courses to be provided to staff and orga-nizational partners. Include the systems they will be trained on, intended audience, class length in hours, number of people to be trained, and timeframe. The first row shows an example.

System Audience class Length No. to be Trained Timeframe

Autodesk® Quantity Takeoff

Project engineerEstimating managerProject manager

16164

10215

February 2010February 2010February 2010

1.4.3.0 Support PlanYour organization will need support throughout the implementation process, and especially after training. In many cases, software vendors offer various levels of support. Your organization may also have internal support. In the space below, list your support options including system, support type, contact information, and hours of support. The first row shows an example.

15


System Support Type contact Information Support Hours

Autodesk® Revit® Architecture Autodesk Premium Support 1-800-555-5555 8 AM–6 PM EST

1.5.0.0 corporate collaboration Plancreating a corporate collaboration plan will help your staff efficiently communicate, share, and retrieve information created from your new BIM technologies. In some cases your organization will be able to leverage existing collaboration and communication protocols. In other cases, BIM technologies may force you reevaluate how your organization communicates, shares, and retrieves information.

1.5.1.0 Document Management You can create a file folder structure on your network or in your organization’s document management system, and give staff the ability to upload, download, edit, mark up, and view documents in the folder structure, based on permissions assigned by the network administrator.

1.5.1.1 Permissions and Access Your company’s network administrator should control permissions for the network or document management file folder structure.

1.5.1.2 Folder Maintenance Although file folder structure and permissions should be defined, the network administrator is responsible for setting up the structure and maintaining the system.

1.5.1.3 Folder Notifications Select groups, individuals, or the entire staff can be notified based on activities in the file folder structure. Notification messages should include information about the file(s) updated and who updated them.

1.5.1.4 File Naming convention All files should be accurately and descriptively named. Avoid using the date in file names, as the collaborative project management system or network will control the dates and versions.

[If there are files with special naming requirements, list them here.]

1.6.0.0 corporate Technology PlanIn this section, you’ll define your organization’s corporate technology plan. You will evaluate your current technology capability and access the requirements needed to implement new BIM technologies—including software, infrastructure, and hardware requirements.

1.6.1.0 Software SelectionTo get optimal results from your BIM tools, we recommend using tools that meet the following criteria.

16


1.6.1.1 Model creation The model creation tool should be built on a database platform that allows the creation of parametric and information-rich objects. Para-metric modeling dependencies should be automatically updated whenever changes are made. Since a design may come from multiple parties, the BIM tool should accommodate file linking, sharing, or referencing. The BIM technology must be capable of producing 2D plans to fulfill contract document deliverable requirements. The system should be able to create and output files that conform to the IFc (Industry Foundation classes) file type standards developed by the International Alliance for Interoperability (IAI).

1.6.1.2 Model Integration The model integrator will be used to combine multiple design files from different software platforms. The tool will also be used for model simulations. The simulation tool must allow the user to simulate construction processes over time and allow for real-time walkthroughs. The model integrator should be able to open and combine at least .dwg, .dwf, .dxf, .sat, .ifc, .dgn, .prp, .prw, .ipt, .iam, and .ipf file types.

1.6.1.3 clash Detection/Model Mediation The clash detection tool should be able to perform clash detection analysis on one or more design files. The system should be able to gener-ate clash detection reports, which can be exported into either .xls, .csv, or .xml file formats. The clash detection reports should include a list of clashes along with visual evidence.

1.6.1.4 Model Visualization The model visualization software will be used by project team members who do not need the full functionality of the BIM model creation, in-tegration, or simulation tools. The visualization tool must allow users to look around, zoom, pan, orbit, examine, and fly through the model.

1.6.1.5 Model Sequencing The 4D model sequencing tool will be used to visualize the scheduled assembly of the building. The tool should allow users to visualize the assembly of the building based on scheduling input. It should also integrate with standard scheduling systems such as Microsoft Project or Primavera.

1.6.1.6 Model Quantity Takeoff The quantity takeoff tool will be used to extract quantities from BIM models for cost-estimating and purchasing purposes. The tool must be able to extract quantities automatically both from 3D and 2D design files. The quantity takeoff software must be able to integrate with esti-mating programs, or the information from the system must be exportable to an .xls, .csv, or .xml file format. The quantity takeoff tool must be compatible with the model creation tool listed below in section 1.6.1.7.

1.6.1.7 collaborative Project Management The collaborative project management system may be made up of one or more software packages. However, for best results, the complete collaborative project management system should:

Be web-based or web-enabled—so all relevant, authorized project team members can access it remotely•

Accommodate different permissions profiles for different project team members •

Allow communication through either internal messaging or system-generated email •

Include document management capability that lets the project team create a customized and permission-based folder structure that of-•fers upload, download, and version control capabilities

Include a viewer that allows the project team to view .dwg, .dgn, .plt, .dwf, .pdf, .tif, .jpg, .doc, and .xls files •

Include construction management capabilities for tracking requests for information (rFIs), submittals, design review, meeting minutes, •daily reports, issues, correspondence, and transmittals

Be able to interact with the file folder structure in the document management section•

Include bid management capability, and allow the project team to post contract drawings and specifications for viewing in the form of a •Plan room

Allow for cost management controls including budgeting, contracting, change orders processing, and payments applications tracking.•

Allow the project team to run reports based on the information in the system •

Allow for workflow and routing throughout the documentation, construction, and cost management components of the solution •

17


Select the components and specific software you will use and list them below for easy reference.

Software component Model Software System Version

o Model creation Architectural Design

o Model creation civil Design

o Model creation Structural Design

o Model creation MEP Design

o Model creation coordination

o Model creation construction

o Model creation As-Built

o Model Integration

o Model Mediation

o Model Visualization

o Model Sequencing

o Model Quantity Takeoff

o collaborative Messaging and communication

o Document Management

o Design Management

o Bid Management

o construction Management

o cost Management

o Facility/Operations Management As-Built

1.6.2.0 Infrastructure requirementsInfrastructure requirements will differ based on current capabilities and intended BIM technologies outlined above. Analysis must be done based on your organization’s current technology infrastructure and on the requirements of the software systems selected above. In the space below, list infrastructure additions that must be made to accommodate the new BIM technologies.

[List infrastructure additions needed to accommodate BIM technologies.]

1.6.3.0 Hardware requirementsHardware requirements will be different based on current capabilities and intended BIM technologies outlined above. Analysis must be done on your organization’s current hardware and software requirements as selected above. In the space below, list the hardware additions that must be made to accommodate the new BIM technologies.

[List hardware additions needed to accommodate BIM technologies.]

18


SEcTION 2:

Project BIM Deployment Plan

19


2.0.0.0 OverviewIn this section of the BIM Deployment plan, you’ll learn how to establish a planning framework for your building projects, and discover infor-mation about different kinds of technology that can help you work more efficiently:

Solutions that help project teams create, adapt, and reuse information-rich digital models during every stage of the project, including •design, construction, and operations.

Analysis tools that deliver insight into the constructability and potential performance of buildings before they are built. Using this analy-•sis, your project teams can make more informed decisions about building materials, energy, and sustainability—and detect and prevent costly clashes among elements such as pipes and beams.

A collaborative communication platform that helps reinforce business processes while ensuring that all team members share project •information in a structured manner.

with these solutions, you can help keep BIM data intact throughout all phases of development. At the beginning of a project, the team can work together to resolve design problems before breaking ground. when a project is completed, instead of delivering unwieldy rolls and boxes of paper documentation, the team can present the building owner with a complete digital model that provides all information neces-sary to manage and operate the building.

Project teams can use the BIM Deployment Plan as a collaborative, working template for establishing project standards and alignment early in a project. The BIM Deployment Plan will also help your teams define the roles and responsibilities for each team member, what types of information to create and share, and what kind of software systems to use and how to use them. Your project teams will be able to stream-line communications and plan more effectively—reducing costs as well as concerns about quality, scope, and schedule across all phases of construction.

2.1.0.0 Project Initiation To start the process, you’ll define your core collaboration Team, as well as your project objectives, project phases, and overall communica-tion plan throughout the project’s phases.

2.1.1.0 Project Description Enter key information about the project below. Include the project name, owner’s project number, address, project description, and areas of the project that will and will not be modeled.

Project Name

Owner’s Project Number

Project Address

Project Description

Areas Modeled

2.1.2.0 core collaboration Team Your project’s core collaboration Team ideally should include at least one person from each stakeholder involved in the project, such as the owner, architect, contractor, subconsultants, suppliers, and trade contractors. This team is responsible for:

completing this BIM Deployment Plan •

creating the document management file folder structure and permission levels in the collaborative project management system •

Enforcing the action plan set out in this document throughout design and construction of the project •

20


To complete this BIM Deployment Plan, the core collaboration Team will:

List the goals and objectives of using BIM and collaborative project management technologies on your project•

Specify project phases/milestones•

Map out communication among project team members for each project phase.•

List the core collaboration Team members for your project below.

contact Name Role/Title company Email Phone

2.1.3.0 Project goals and Objectives Using collaborative project management and BIM technologies on projects can offer tangible as well as intangible benefits. Below, list your objectives for using BIM and collaborative project management technology and processes on this project. Also note how you will measure the achievement of each objective, and its target time frame. The first row shows an example.

Project Goal Objective Achieved If Projected Timeframe

Streamline structural steel pro-curement

Include the steel supplier in the modeling process in order to start fabrication earlier

Steel is ready and delivered to site when needed

April 2010

2.1.4.0 collaborative Process MappingTo get the most out of collaborative project management and BIM initiatives during your project, invest a bit of time up front to map out planned collaboration among team members at each phase of the project.

Below is a sample collaboration plan for three different project delivery methods—integrated project delivery, design-build project delivery, and design-bid-build project delivery. Use the blank chart following the example to enter your project’s delivery method and collaboration plan. The resulting process map should show the phases of your project along the y axis, stakeholders involved in each phase along the x axis, the anticipated collaboration among team members in the text boxes, and software to be used in the last column.

Definitions for each project delivery method:

Integrated Project Delivery:• This method calls for integration at the onset of a project, and utilizes up-to-date technology to foster flex-ibility and successful project outcomes. This method collaboratively harnesses the talents and insights of all participants, fosters a great degree of communication, and promotes intense collaboration among the project team.

21


Design-Build Project Delivery: • with this method, one entity performs both architectural/engineering and construction under a single contract. The design-builder warrants to the contracting agency that it will produce documents that are complete and free from error.

Design-Bid-Build Project Delivery: • with this method, documents are fully developed by a designer paid by the owner before bidding by multiple contractors. This method limits a contractor’s ability to use BIM to its full potential as a coordination tool.

22


23


24


Use the blank chart below to create your project’s collaboration plan. The process map should show the phases along the y axis, the stake-holders involved in each phase along the x axis, the anticipated collaboration between project team members in the text boxes, and soft-ware to be used in the final column.

25


2.1.5.0 Project Phases/Milestones Traditional project delivery includes phases of schematic design, design development, construction documents, construction operations, etc. Integrated project delivery (IPD) phases may include conceptualization, criteria design, detailed design, implementation documents, and others. For more information on IPD project phases, see the American Institute of Architects 2007 publication Integrated Project Deliv-ery: A Guide (available at www.aia.org/ipdg).

In the table below, outline the phases of your project, their estimated start dates, and the stakeholders involved. The first row shows an example.

Project Phase/Milestone Estimated Start Date Estimated completion Date Project Stakeholders Involved

Conceptualization 2/1/2008 4/1/2008 Owner, A/E, subconsultants, CM

2.2.0.0 Modeling PlanTo help your project run more efficiently and cost-effectively during every phase, do as much advance planning as possible. Decide which models will be created during the different phases of the project and who will be responsible for updating models and distributing them. content and format of models should also be predetermined as much as possible.

2.2.1.0. Model Managers Each party—owner, architect, contractor, or subconsultant—responsible for contributing modeling content should assign a model manager to the project. Each model manager has a number of responsibilities that include but are not limited to:

Transferring modeling content from one party to another •

Validating the level of detail and controls as defined for each project phase •

Validating modeling content during each phase •

combining or linking multiple models •

Participating in design review and model coordination sessions •

communicating issues back to internal and cross-company teams •

Keeping file naming accurate •

Managing version control•

Properly storing models in the collaborative project management system •

List the model managers for the project in the table below.

http://www.aia.org/ipdg

26


Stakeholder company Name Model Manager Name Email Phone

2.2.2.0 Planned Models During the course of your project, the project team may generate multiple models. Typically the architect and any subconsultants gener-ate a Design Intent model to depict the design intent of the building, while the contractor and any subcontractors generate a construction model to simulate construction and analyze the constructability of the project. The construction team should provide input for the Design Intent model, while the design team should provide input for the construction model.

Even when the team is committed to using integrated project delivery (IPD) methods, it is sometimes necessary to create separate models due to contractual obligations, risk factors, and the functional intent of each model. For example, the Design Intent model—used to depict the design intent—may not include information on the means and method or sequencing of construction. Other models may be created spe-cifically for certain types of analysis, such as energy consumption or safety. These Analysis models are usually spinoffs of either the Design Intent model or the construction model. Analysis models will be specified further in section 2.3.0.0 of this document, which covers Analysis models and planning.

In the table below, outline the models that will be created for the project. List the model name, model content, project phase at which the model will be delivered, the model’s authoring company, and the model authoring tool to be used. For models that will not be used or cre-ated in your project, just leave the row blank; add rows for any model types you anticipate a need for that are not already listed. The first row offers an example.

Model Name Model content Project Phase Authoring company Authoring Tool

Coordination Model Architectural, structural, and MEP components of main building and parking garage structure

Design development and construction documents

ABC Designers Autodesk® Revit® Architecture software

civil Model

Architectural Model

Structural Model

MEP Model

construction Model

coordination Model

As-Built Model

27


2.2.3.0 Model components As an aid to usability during later phases of your project, specify what the content, level of detail, and file naming structure of your models should look like.

2.2.3.0a File Naming Structure Determine and list the structure for model file names. The first line offers an example.

Formatting for Model File Names

model type, hyphen, date—e.g., DESIGN-011208

2.2.3.0b Precision and Dimensioning Models should include all appropriate dimensioning as needed for design intent, analysis, and construction. with the exception of the exclu-sions listed below, the model will be considered accurate and complete. In the table below, enter which items’ placement will not be consid-ered entirely accurate and should not be relied on for placement or assembly.

Items Not to be considered Accurate for Dimensioning or Placement

2.2.3.1 Modeling Object Properties The level of property information in the modeling objects and assemblies depends on the types of analysis to be performed on the model. See section 2.3.2.0 for the types of analysis that will be performed.

2.2.3.2 Modeling Level of Detail A detailed Level of Detail (LOD) Analysis will be performed using Exhibit A. The exhibit will help the team identify which components will be modeled, by whom, the level of detail, and during which project phase or milestone they will be modeled. The LOD is broken down into four levels: L1, L2, L3, and cD. In L1, the model will include basic shapes that represent approximate size, shape, and orientation of objects. These objects may be in 2D or 3D. In L2 the model will include object assemblies with approximate size, shape, orientation, and object data. In L3, the model will include data-rich assemblies with actual size, shape, and orientation. In cD (construction Documents), the model will include detailed assemblies with final size, shape, and orientation used for construction and fabrication. Proceed to Exhibit A for further details and instructions.

certain items will be excluded from the model. These items can be defined by expressed exclusion and/or by object size.

2.2.3.2a Exclusions: List the objects to be excluded from the model in the table below. The first row offers an example.

28


Items to be Excluded from the Model

Door hardware

2.2.3.2b Size: Any object smaller than [_________] (fill in item size, for example 6”x6”x6”) will not be included in the model.

2.2.3.3 Model reference coordination Models may be linked or combined. In order for the referencing to work properly, a (0,0,0) reference point must be established. Fill in the (0,0,0) reference point for this project in the table below.

Project (0,0,0) Reference Point

2.2.3.4 System of Measurement conventionSpecify the units convention for the project. The following project will utilize the [___________] (Metric or English) measurement system.

2.2.4.0 contract Document Deliverable requirementsTwo-dimensional paper drawings or documents may be generated from certain models to fulfill contract document deliverable require-ments. certain models will be used for analysis purposes only and will not be included as part of the contract document deliverable require-ments. List the models that will be considered part of the contract documents in the table below.

Models to be considered Part of Project contract Document Deliverables

2.2.5.0 Detailed Modeling Plan For each phase of the project, the project team should create a detailed modeling plan, which should include modeling objectives, models included, and the roles and responsibilities of model contributors. Model objectives and model manager roles and responsibilities by phase are outlined below.

29


2.2.5.1 conceptualization/conceptual Design 2.2.5.1a Objectives: Provide initial design based on conceptual parameters established by the owner, ensure that code and zoning require-ments meet project objectives, and establish a 3D reference point of model coordination. [List further objectives if needed.]

2.2.5.1b Model Roles: A model may or may not take shape during the conceptualization/conceptual Design phase. If a model is created, its role will be to depict the visual concept and general layout of the project. [List further roles if needed.]

2.2.5.1c Responsibilities: The architect’s designated model manager will establish a baseline model to be used as the basis for other models. During the conceptualization phase, model managers from all parties will establish modeling standards and guidelines. [List further responsi-bilities if needed.]

2.2.5.2 criteria Design/Schematic Design 2.2.5.2a Objectives: Provide spatial design based on input from the conceptualization/conceptual Design phase; provide initial design for building system and attributes including architectural, structural, and MEP; identify initial coordination issues among building systems; receive input from suppliers and fabricators regarding system cost, placement, fabrication, and scheduling. [List further objectives if needed.]

2.2.5.2b Model Roles: The Architectural model will show the general design and layout of the building structure and act as the baseline for all other subsystem designs, such as MEP and Structural models. The subsystem designs will be used to show initial selection and layout of building components. The combined coordination model will show the spatial relationship of the Architectural model and subsystem design models. [List further roles if needed.]

2.2.5.2c Responsibilities: Once the baseline conceptual structure has been created, the architect’s model manager will send the model to the subconsultants so they can develop their designs. The subconsultants’ designated model managers will audit and deliver the com-pleted models to the architect’s model manager. The architect’s model manager will review the models to ensure compliance with the phase requirements. Once the models meet the requirements, the architect’s model manager will link or combine cross-disciplinary models. The architect’s model manager should also eliminate duplicate or redundant objects, and accurately name the coordination model and store it in the collaborative project management system. [List further responsibilities if needed.]

2.2.5.3 Detailed Design/Design Development 2.2.5.3a Objectives: Provide final design of building and building systems; resolve coordination issues between building systems; provide a construction model capable of analyzing schedule, cost, and constructability; provide Fabrication models to analyze the coordination of trades. Once the final design decisions have been made, the architect’s model manager will send the coordination model to the subconsul-tants so they can finalize their designs. [List further objectives if needed.]

2.2.5.3b Model Roles: The Architectural model will continue to act as the baseline for all other subsystem designs. The subsystem designs will be modified accordingly to represent the enhanced design. The combined coordination model will continue to show the spatial relation-ship of the Architectural model and subsystem models. [List further roles if needed.]

2.2.5.3c Responsibilities: The subconsultants’ model managers will use the coordination model to revise and complete their designs. Once the models are complete, the subconsultants’ model managers will deliver their models to the architect’s model manager. The architect’s model manager will review the models to ensure compliance with the phase requirements. Once the models meet the requirements, the architect’s model manager will link or combine the multiple models to update a new coordination model. The model manager should also eliminate duplicate or redundant objects. The architect’s model manager will deliver the coordination model to the contractor’s desig-nated model manager. The contractor will use the coordination model for the basis of the construction model. [List further responsibilities if needed.]

2.2.5.4 Implementation/construction Documents2.2.5.4a Objectives: Finalize design of the building and all building systems, prepare documentation for agency review, and provide con-struction modeling that highlights constructability, trade coordination, and fabrication. [List further objectives if needed.]

2.2.5.4b Model Roles: All design models will be used to reflect the final design. The models will then be used to generate the contract docu-ments. The construction model will be used primarily for estimating, scheduling, and constructability analysis. [List further roles if needed.]

30


2.2.5.4c Responsibilities: The architect’s and subconsultants’ model managers will prepare contract documents for agency review based on the coordination model. The contractor’s model managers will send the baseline construction model to the suppliers and subcontractors. The suppliers and subcontractors will submit Fabrication models, which replace traditional “shop drawings.” The contractor’s model man-ager will incorporate these models into the construction model. [List further responsibilities if needed.]

2.2.5.5 Agency coordination Bidding2.2.5.5a Objective: revise coordination model based on agency feedback and finalize construction model. [List further objectives if needed.]

2.2.5.5b Model Roles: The design models will be adjusted to reflect agency feedback. The construction model will be enhanced and further used for estimating, scheduling, construction sequencing, trade coordination, and constructability analysis. [List further roles if needed.]

2.2.5.5c Responsibilities: The architect’s model manager will communicate agency comments back to the design team. The subconsultants’ model managers will revise their design models accordingly and submit them back to the architect. The architect’s model manager will up-date the final coordination model. [List further responsibilities if needed.]

2.2.5.6 construction2.2.5.6a Objectives: Update coordination model based on submittals, rFIs, or owner-directed changes; maintain the construction model based on construction activities; develop an As-Built model to reflect the actual fabrication of the building. The construction team will sub-mit rFIs and submittals through the collaborative project management system. [List further objectives if needed.]

2.2.5.6b Model Roles: The coordination model will be revised throughout construction, based on owner directives and unforeseen condi-tions. The model will always reflect the revised contract documents. The construction model will be used for scheduling analysis, construc-tion sequencing, and trade coordination. The As-Built model will be used to represent the actual assembly of the building(s). [List further roles if needed.]

2.2.5.6c Responsibilities: The architect’s model manager will work with the architect’s consultants to answer the rFIs and submittals and adjust the coordination model accordingly. The contractor’s model manager will update the construction model and will work with the sup-pliers and subcontractors to develop an As-Built model. [List further responsibilities if needed.]

2.2.5.7 Facility Management2.2.5.7a Objective: Use the As-Built model for facility management, and update the model based on ongoing operations. [List further objec-tives if needed.]

2.2.5.7b Model Roles: The As-Built model will be used to represent the actual assembly of the building(s) from construction. The model can be updated further and used to show construction changes and facilitate the operation of the facility. [List further roles if needed.]

2.2.5.7c Responsibilities: The facilities management model manager will update the model based on ongoing operations. [List further responsibilities if needed.]

2.3.0.0 Analysis PlanBy listing and specifying what types of analysis your project is likely to require at its inception, you can ensure that key models will include relevant information, making analysis easier and more efficient.

2.3.1.0 Analysis ModelsYour project’s scope of work may require certain kinds of analysis, such as those listed below, based on existing or specially created model(s). In most cases the quality of analysis depends on the quality of the original model from which the analysis is derived. Therefore the project team member performing the analysis should clearly communicate the analysis requirements to the original model authoring team member.

31


2.3.1.1 Quantity Takeoff AnalysisThe objective of quantity takeoff analysis is to use modeling property data to automate or simplify the quantity takeoff process. This in-formation from the quantity takeoff tool can then be imported into or tied to cost-estimating software. For the quantity takeoff process to work seamlessly, the original modeling author must include the relevant property information in the design.

2.3.1.2 Scheduling AnalysisScheduling analysis lets the project team use the project model to analyze the timeline and sequencing for construction. This information can then be used to modify or adjust the construction schedule. while tools do exist that allow project team members to visualize construc-tion over time, no such systems yet interact automatically with scheduling tools.

2.3.1.3 clash Detection Analysis clash detection analysis is done to check for interferences among the designs of one or many models. To reduce change orders during con-struction, clash detection should be performed early and continue throughout the design process. For clash detection to work properly, your project’s models must have a common reference point and must be compatible with the clash detection tool.

2.3.1.4 Visualization AnalysisVisualization tools let the project team view the design or construction of a project in 3D, giving a more accurate perspective on the end product.

2.3.1.5 LEED rating/Energy Analysis LEED (Leadership in Energy and Environmental Design) rating/Energy Analysis tools help the project team evaluate the impact of design decisions on sustainability and energy consumption. This analysis model is usually based on the main Architectural model, after which mate-rial and building system inputs can be used to evaluate the project’s sustainability and energy consumption.

2.3.1.6 Structural Analysis Structural analysis tools use the model to analyze a building’s structural properties. Structural analysis programs typically use the finite ele-ment method (FEM) to measure the stresses on all structural elements of the design. For structural analysis to work seamlessly, the original structural modeling tool must be compatible with the structural analysis tool, and the original structural model property data must include information about the structural elements.

2.3.2.0 Detailed Analysis PlanFor each type of analysis that may be performed for your project, list the models used for the analysis, which company will perform the analysis, the file format required, the estimated project phase, and the tool to be used for analysis. If there are other instructions associated with the analysis, mark the Special Instructions column and list the details in the Special Instructions table in the next section.

32


Analysis Analysis Tool ModelAnalyzing company

Project Phase(s)

File Format Required

Special Instructions

Visualization

Structural

clash Detection

Quantity Takeoff

Scheduling/4D

cost Analysis/5D

Energy/LEED

Daylight/Lighting

2.3.2.1 Special Instructions certain types of analysis may call for specific requirements or instructions. The company performing the analysis should communicate these to the original model authoring company. List specific requirements in the table below.

Analysis Requiring Special Instructions Detailed Special Instructions

2.4.0.0 Project collaboration and communication Plancreating a collaboration and communication plan early on will help team members efficiently communicate, share, and retrieve information throughout the project. Such a plan helps you get the most out of your collaborative project management system, saving time and increas-ing rOI.

2.4.1.0 communication Plan2.4.1.1 Messaging and communication Protocol All electronic communication on the project should be captured and stored as part of the project record. Many collaborative project man-agement systems have internal messaging functionality. All electronic communication between core collaboration Team companies on the project should be uploaded or sent through the collaborative project management system. A copy of all project-related emails sent from outside the collaborative project management system should be uploaded to a folder in the document management file folder structure, or uploaded to the correspondence module. List your project’s electronic messaging protocol below.

[List the project electronic messaging protocol here]

2.4.1.2 Meeting Minutes Meeting minutes and agendas can be created in the collaborative project management system. The minutes and agendas should include general information such as time, date, and location of meeting, attendance, and discussion details. The discussion details should include information such as issue origination date, responsible parties, and required completion date. Meeting minutes should be posted to the sys-tem no later than [__] business days after completion of the meeting and should be electronically sent to all attendees. The attendees have [__] business days to dispute the content of the minutes, and all disputes must be resolved by the following meeting.

33


There will be different types of meetings on the project, including general progress meetings, design coordination meetings, safety meet-ings, etc. In the space below, list the types of meetings necessary for the project, meeting host(s), required attendees, and required technol-ogy. The first row shows an example.

Meeting Type Host Required Attendees Required Technology

BIM Design Coordination Architect Owner, Architect, GC, Subconsultants, Suppliers

Internet, Autodesk® Navisworks® software, Projection, Whiteboard, NetMeeting

2.4.1.3 correspondence All formal correspondence among core collaboration Team companies should be generated in, or scanned and uploaded to, the collabora-tive project management system. Important correspondence received from non-core collaboration Team companies can also be scanned and uploaded to the system in the correspondence module.

2.4.2.0 collaboration Plan2.4.2.1 Document Management You can create a file folder structure in your collaborative project management system, then give project team members the ability to up-load, download, edit, mark up, and view documents in the folder structure, based on permissions assigned by the core collaboration Team.

2.4.2.1a Permissions and Access The core collaboration Team for your project should decide on permissions for the document management file folder structure. In the table below, list the folder or subfolder, intended file content, and permission levels. Examples are shown below.

Folder content Permissions

Drawings All project drawings in subfolders Upload: A/EView: Contractor, OwnerNone: Sub

Schematic Design Schematic drawings Upload: A/EView: Contractor, Owner None: Sub

34


2.4.2.1b Folder Maintenance Although file folder structure and permissions should be defined by the core collaboration Team, the project system administrator (PSA) is responsible for setting up the structure and maintaining the system.

2.4.2.1c Folder Notifications Select groups, individuals, or the entire project team can be notified based on activities in the file folder structure. Notification messages should include information about the file(s) updated and who updated them. List the people and groups to be notified for different activities in various folders in the table below. The first row shows an example.

Folder Activity Group to Notify

Drawings Upload and revise Entire project team

2.4.2.1d File Naming convention Earlier in this document (see section 2.2.3.0a, Model Components File Naming Structure), you specified the file naming convention for model files for this project. All other files should be accurately and descriptively named. Avoid using the date in file names, as the collaborative project management system will control the dates and versions. If there are files with special naming requirements, list them in the table below. The first row shows an example.

File Type Naming convention

Progress Photos Location, hyphen, Authoring Company Initials, hyphen, Description (e.g., Parking Deck-ABC-Cracking)

2.4.2.1e Design Review The collaborative project management system lets you efficiently manage your design review process, enabling the appropriate parties to efficiently log and update their design review comments, issues, and clash detection reports. Your collaborative project management system should allow users to log design review comments. The system will also track progress and resolution of the design review comments. In the table below, list the model(s) being reviewed, the reviewers, estimated design review start and completion dates, and how many days the authoring company has to respond to the design review comments. An example has been provided.

35


Model Reviewing companiesEstimated Review Start Date

Estimated Review completion Date

Days to Respond by Authoring company

Schematic Design Model ABC OwnersAcme Contractors

1/21/2008 2/11/2008 14 days

2.4.2.2 Bid Management For faster, more efficient bids, all bid documentation—including drawings and specifications—can be made available in a Plan room on the collaborative project management system. The potential bidders can be given access to this Plan room by the PSA, and may access the documents, download them, or have them printed at a reprographics firm. when there are changes to the plans in the form of addenda, the collaborative project management system will automatically notify all bidders.

2.4.2.3 construction Management The collaborative project management system supports your construction management process by managing requests for information (rFIs), submittals, meeting minutes, daily reports, and other modules selected by the core collaboration Team. The core collaboration Team will also define permission levels and access to the construction management modules.

2.4.2.3a RFIs rFIs will be created in the collaborative project management system by the [______________] (specify role). The rFIs will be issued to the [______________] (specify role) for a response, and copied to the [______________] (specify role). The primary reviewer will have [___] days to respond to the rFI. The rFI will include all appropriate information that describes the issue, along with electronic attachments that may include photos, specifications, and marked-up drawings.

2.4.2.3b Submittals Submittals will be organized and electronically submitted through the collaborative project management system. The [______________] (specify role) will organize and submit the submittal packages. The packages will be organized by specification section and should be numbered with the following format: [______________________] (Fill in submittal package numbering format, e.g., spec section-package number within spec section 09900-01). The packages will consist of one or more items. The items should be numbered with the following format: [______________________] (Fill in submittal item numbering format, e.g., auto-number 001,002). The submittal packages will be issued to the [______________] (specify role) for a response and copied to the [______________] (specify role). The submittal packages will include all appropri-ate information along with electronic attachments of the submittal items whenever possible. The submittal packages will be issued with an electronic transmittal. The primary reviewer will have [___] days to respond to the submittal package. Each item within the package will receive a response. The possible responses include [__________] (list responses). All revised submittal items will be resubmitted through a package revision, as opposed to a new package.

2.4.2.3c Daily Reports Daily reports can be entered in the collaborative project management system. The following parties are responsible for creating daily reports: [______________] (specify role). The daily reports will include the date, general information, weather conditions, activities, manpower, major equipment used, major material deliveries, safety incidences, and quality control issues. In addition, progress photos and other elec-tronic files should be attached to the daily reports when necessary. Daily reports should be entered into the system no later than [___] day(s) after the day of the report.

36


2.4.2.3d Other construction Management Business Processes Most collaborative project management systems have a number of modules not listed above. List the modules the project team plans to use, including any special instructions and processes, in the table below.

Additional Business Process Modules to be Used Special Instructions or Processes

2.4.2.4. cost Management The collaborative project management system will facilitate cost management by managing budgeting, purchasing, the change order pro-cess, and the payment application process, as well as cost reporting. The core collaboration Team for your project will define permission levels and access to the cost management modules.

2.4.2.4a Budgeting The [_____________]’s (specify role) budget will entered and tracked in the collaborative project management system. The [______________] (specify role) will be responsible for entering and tracking the budget in the system.

2.4.2.4b Purchasing The [____________]’s (specify role) contracting documents will entered and tracked in the collaborative project management system. The [______________] (specify role) will be responsible for entering and tracking the contract documentation in the system. The executed docu-ments may, if needed, be scanned and attached to the contract records.

2.4.2.4c change Order Process requests for change orders (rcOs) will be created and tracked in the collaboration project management system. rcOs will be created by the [______________] (specify role). Each rcO will include all appropriate information that supports the change. Electronic backup can be attached the rcO document. rcOs should be sent to the [______________] (specify role) for review. Once an rcO is approved, the [______________] (specify role) will issue the [______________] (specify role) a formal owner change order (OcO).

2.4.2.4d Payment Applications Payment applications can be created in the collaborative project management system. The [______________] (specify role) is responsible for creating a payment application in the system based on an approved schedule of values (SOV). A signed copy of the payment application must be submitted to [______________] (specify role) and copied to [______________] (specify role) by the [___] day of the month.

2.4.2.5 Project closeoutThe collaborative project management system can ease your closeout process. The punch list process will be managed in the system either through system functionality or by uploading the documentation to the file folder structure. A number of documents, such as As-Builts, commissioning documents, warranties, and O&M Manuals, will need to be submitted to the owner. These documents can be uploaded in the file folder structure.

2.4.2.5a As-Built Model An As-Built model [_______] (fill in: will/will not) be delivered to the owner at the end of the project by the [______________] (specify role). The As-Built model should represent the actual built conditions. The level of detail in the As-Built model will be governed by section 2.2.3.2, Mod-eling Level of Detail. List any inclusions or exclusions from the As-Built model content in the table below.

37


As-Built Model Inclusions As-Built Model Exclusions

[List special items that will be included in the model above and beyond the Level of Detail specified in section 2.2.3.2.]

[List items that will be excluded from the model above and beyond the Level of Detail specified in section 2.2.3.2.]

2.4.2.5b System ArchivingAt the end of the project, core collaboration Team companies can request an electronic copy of the project documents that were created and stored in the collaborative project management system. This information will be provided by the system owner at the requester’s ex-pense. Each company will have access to the project documents to which it had access while the project was active.

2.5.0.0 Project Technology PlanIn this section you’ll define your project’s corporate technology plan. You will select the software systems to be used and define require-ments and administrative responsibilities.

2.5.1.0 Software component SelectionSo you may get optimal results from your BIM tools, we recommend using tools that meet the following criteria.

2.5.1.1 Model creationThe model creation tool should be built on a database platform that allows the creation of parametric and information-rich objects. Para-metric modeling dependencies should be automatically updated whenever changes are made. Since the design may come from multiple parties, the BIM tool should accommodate file linking, sharing, and referencing. The BIM technology must be capable of producing 2D plans to fulfill contract document deliverable requirements. The system should be able to create and output files that conform to the IFc (Industry Foundation classes) file type standards developed by the International Alliance for Interoperability (IAI).

2.5.1.2 Model Integration The model integrator will be used to combine multiple design files from different software platforms. The tool will also be used for model simulations. The simulation tool must allow the user to simulate construction processes over time and allow for real-time walkthroughs. The model integrator should be able to open and combine at least .dwg, .dwf, .dxf, .sat, .ifc, .dgn, .prp, .prw, .ipt, .iam, and .ipf file types.

2.5.1.3 clash Detection/Model Mediation The clash detection tool should be able to perform clash detection analysis on one or multiple design files. The system should be able to generate clash detection reports, which can be exported into either .xls, .csv, or .xml file formats. The clash detection reports should include a list of clashes along with visual evidence.

2.5.1.4 Model Visualization The model visualization software will be used by project team members who do not need the full functionality of the BIM model creation, in-tegration, or simulation tools. The visualization tool must allow users to look around, zoom, pan, orbit, examine, and fly through the model.

2.5.1.5 Model Sequencing The 4D model sequencing tool will be used to visualize the scheduled assembly of the building. The tool should allow users to visualize the assembly of the building based on scheduling input. It should also integrate with standard scheduling systems such as Microsoft Project or Primavera.

2.5.1.6 Model Quantity Takeoff The quantity takeoff tool will be used to extract quantities from BIM models for cost-estimating and purchasing purposes. The tool must be able to extract quantities automatically from both 3D and 2D design files. The quantity takeoff software must be able to integrate with esti-

38


mating programs, or the information from the system must be exportable to an .xls, .csv, or .xml file format. The quantity takeoff tool must be compatible with the model creation tool listed below in section 2.5.1.7.

2.5.1.7 collaborative Project Management The collaborative project management system may be made up of one or more software packages. However, for best results, the complete collaborative project management system should:

Be web-based or web-enabled—so all relevant, authorized project team members can access it remotely•

Accommodate different permissions profiles for different project team members •

Allow communication through either internal messaging or system-generated email •

Include document management capability that lets the project team create a customized and permission-based folder structure that of-•fers upload, download, and version control capabilities

Include a viewer that allows the project team to view .dwg, .dgn, .plt, .dwf, .pdf, .tif, .jpg, .doc, and .xls files•

Include construction management capabilities for tracking requests for information (rFIs), submittals, design review, meeting minutes, •daily reports, issues, correspondence, and transmittals

Be able to interact with the file folder structure in the document management section •

Include bid management capability, and allow the project team to post contract drawings and specifications for viewing in the form of a •Plan room

Allow for cost management controls including budgeting, contracting, change orders processing, and payments applications tracking•

Allow the project team to run reports based on information in the system •

Allow for workflow and routing throughout the documentation, construction, and cost management components of the solution •

Select the components and specific software you will use and list them below for easy reference.

39


Software component Model Software System Version

o Model creation Architectural Design

o Model creation civil Design

o Model creation Structural Design

o Model creation MEP Design

o Model creation coordination

o Model creation construction

o Model creation As-Built

o Model Integration

o Model Mediation

o Model Visualization

o Model Sequencing

o Model Quantity Takeoff

o collaborative Messaging and communica-tion

o Document Management

o Design Management

o Bid Management

o construction Management

o cost Management

o Facility/Operations Management As-Built

2.5.2.0 System requirements and Administration2.5.2.1 Model creation, clash Detection, Visualization, Sequencing, Simulation, and Quantity Takeoff Tools

2.5.2.1a IT Requirements The BIM tools should meet the criteria and perform the functionalities outlined in section 2.5.1.0, Software Component Selection. All project team members who use the tool should have the hardware and software to use the system properly; refer to the vendor’s system require-ments for more details. we recommend running BIM software on Intel core® 2 Duo 2.40 gHz or equivalent AMD Athlon™ processors, win-dows® XP Professional (SP2 or later) with 4 gB rAM, 5 gB free disk space, and a dedicated video card with hardware support for OpengL® spec 1.3 or later.

40


2.5.2.1b Funding Source Acquisition and access to the BIM systems will be funded by [_____________] (specify role).

2.5.2.1c Data Ownership For language or information on electronic information and model ownership, see AIA® c106™-2007 Digital Data Licensing Agreement or consensusDOcS™ 200.2 Electronic communications Protocol Addendum.

2.5.2.1d Administration Each party is responsible for access, licensing, and administration of the BIM software systems used.

2.5.2.1e User Requirements All parties are responsible for obtaining training in the use of the BIM tools. [_____________] (specify role) is responsible for expenses related to training.

2.5.2.2 collaborative Project Management

2.5.2.2a System Owner The [_____________] (specify role) will provide access to the collaborative project management system. System licenses will be provided to all project team members who need to access the information.

2.5.2.2b IT Requirements The collaborative project management system should perform all functionality outlined in section 2.5.1.7, Software Component Selection, Collaborative Project Management. All project team members who use the tool should have the hardware and software to use the system properly. Most systems operate efficiently on Intel® Pentium®-based or equivalent processors, windows XP Professional (SP2 or later), 256 MB rAM, and a broadband Internet connection. refer to the vendor’s system requirements for more details.

2.5.2.2c Funding Source Acquisition and access to the collaborative project management systems will be funded by [_____________] (specify role).

2.5.2.2d Data Ownership Each core collaboration Team company can, at its own cost, request an electronic copy of the project documents that were created and stored in the collaborative project management system at the end of the project, as outlined in section 2.4.2.5b, System Archiving. For more information on digital data ownership, see AIA® c106™-2007 Digital Data Licensing Agreement or consensusDOcS™ 200.2 Electronic com-munications Protocol Addendum.

2.5.2.2e Administration The system owner should designate a Project System Administrator (PSA) to manage the administration of the system. The PSA will be responsible for managing and creating all new user accounts. The PSA will also be responsible for managing the company and contact infor-mation in the database.

2.5.2.2f User Requirements

High-speed Internet access is required at all locations where the system will be accessed. •

Each user should have a unique and valid email address. •

System licenses to use the database will be provided by the system owner for all users who require access. •

Licenses will be granted for current projects only, and in accordance with permission levels defined by the core collaboration Team. •

requests for new user licenses should be submitted to the PSA. •

company and contact information will be managed in the database by the PSA. •

All parties should submit company and contact information and revisions to the PSA; each party is responsible for ensuring that his or her •information is accurate.

Each project team member will have his or her own license and access to the system. •

41


Licenses should not be shared by two or more persons; passwords should be confidential. •

Users will be prompted to change their passwords no less than every [___] days. •

All users will log into the system no less than once a week (unless otherwise dictated by project requirements) while the project is ongo-•ing, to check for messages and outstanding items.

All parties should notify the PSA immediately when an employee with access to the system has been terminated, in order to deactivate •that employee’s user account.

All parties are responsible for obtaining training in the use of the collaborative project management system. •

2.5.2.2g Security Requirements The security of the collaboration project management system should include 24/7/365 system monitoring, perimeter security with desig-nated access only, mirror data storage with a secondary facility in a separate location, daily backups of the information saved for the life of the project, an Intrusion Detection System (IDS), and at least 128-bit Secure Socket Layer (SSL) technology.

42


Appendix

Definitions of Terms Used in This Document

As-Built Model—The final model that shows how a building was actually delivered and assembled. Sometimes referred to as the record Model. Building Information Modeling (BIM)—An integrated process aimed at providing coordinated, reliable information about a building proj-ect throughout different project phases—from design through construction and into operations. BIM gives architects, engineers, builders, and owners a clear overall vision of the project—to help them make better decisions faster, improve quality, and increase profitability of the project.

clash Detection—The process of checking for clashes and interferences in the design of one or more BIM models. Also referred to as model mediation. collaborative Project Management—A software solution that enables effective management of and collaboration on all project-related communication, information, and business processes across the plan, build, and operate phases of the building lifecycle. The most common processes include collaborative documentation, design, bid, construction, cost, and operations management. construction Model—The model used to simulate and analyze the construction of a building. coordination Model—A model created from two or more models, used to show the relationship of multiple building disciplines such as architectural, civil, structural, and MEP (mechanical, electrical, and plumbing). core collaboration Team—The group of people—which should include someone from each party working on the project, such as the owner, architect, contractor, subconsultants, suppliers, and trade contractors—responsible for completing a BIM Deployment Plan, creating the document management file folder structure and permission levels in the collaborative project management system, and enforcing the action plan set out in that document throughout design and construction of the project. Design Intent Model—The model used to communicate the design intent of a building. Industry Foundation classes (IFc)—A neutral and open file format structure developed by the International Alliance for Interoperability (IAI) to enable interoperability between modeling software systems. Integrated Project Delivery (IPD)—A project delivery process that integrates people, systems, business structures, and practices to collab-oratively harness the talents and insights of all participants in order to optimize project results, increase value to the owner, reduce waste, and maximize efficiency throughout all phases of design, fabrication, and construction (AIA, Integrated Project Delivery: A Guide, 2007, avail-able at www.aia.org/ipdg). Model Integrator—A tool used to combine and/or link design files from different software platforms. Model Manager(s)—The project team member(s) responsible for managing the collaboration and sharing of electronic files during the proj-ect. Model managers are also responsible for maintaining the integrity of BIM models, which can include gathering, linking, and uploading updated models.

Parametric—The relationships among and between all elements of a model that enable coordination and change management. These rela-tionships are created either automatically by the software or manually by users as they work.

Project System Administrator (PSA)—The person who administers, and sets up folders for, the collaborative project management system. responsible for managing and creating new user accounts, as well as contact and company information.

REVIT® BUILDING INFORMATION MODELING

BIM and Project Planning

This white paper explores how the Revit® building information model (BIM) can be linked with project planning systems to enable 4D construction planning.

Gantt charts have long been a staple of project planning, but they leave something to be desired when it comes to visualizing a project schedule.

Most builders invested in their first project planning system more than a decade ago and they’ve become a vital tool for project management services. BIM solutions on the other hand are relatively new. Rich with information, building information models provide architects a wealth of design-centric tasks – energy analysis, sun studies, and specification management, to name a few.

Given the success of BIM in the design realm, building firms are now turning to building information models for their own uses – constructability analysis, trade coordination, quantification, cost estimating, and so on. One of the most obvious building applications for BIM is where design and construction first come together: construction planning. This white paper focuses on how BIM and project planning solutions can be linked to better present and analyze a building design throughout its construction.

4D Construction Phasing

Construction planning is an ongoing effort to manage the progress of a construction project and react accordingly – dynamically adjusting to the “situation on the ground.” Of course, a building’s design is at the core of its project plan, and by adding schedule data to a 3D building information model (i.e., the building design) you can create a 4D building information model, where time is the 4th dimension.

4D models include planning data such as the start and end date of a component and their criticality or slack. As a result, a 4D building information model provides an intuitive interface for project team and other stakeholders to easily visualize the assembling of a building over time. It enables 4D construction simulation, a key planning tool during pre-construction to evaluate various options. 4D storyboards and animations make BIM a powerful communication tool – giving architects, builders, and their clients a shared understanding of project status, milestones, responsibilities, and construction plans.

Teams usually start out developing 4D models by manually mapping the schedule dates from the project plan to the model components. That effort helps them improve the plan and improve how they communicate the plan to the whole team. Later, as they advance their skills, they programmatically link the schedule to the model, to save time and increase their ability to evaluate various construction sequence options.


2

Below are two representative approaches for linking a building information model to a project plan. The first example features a direct link between Revit and Microsoft® Project (MS Project), developed by Autodesk Consulting. The second example is a tool from Innovaya that exports a Revit building information model and displays it in a specialized 3D/4D visualization environment linked to a project plan from either MS Project or Primavera® technology.

Direct to MS Project Our first example features a software tool, developed by and available from Autodesk Consulting, that uses a bidirectional link between Revit and MS Project to keep the project up-to-date when changes are made in either program.

The tool includes a new “Export to MS Project” Revit function that exports applicable building components to a MS Project file, pre-sorted by level (e.g., floor) and category (e.g., wall, window, column, etc.) for rapid project scheduling and resource tasking.

In turn the MS Project plan can be saved (as a standard MS Project “.mpp” file) and used to update the building information model via a new “Import from MS Project” Revit function. This updates the attributes of affected Revit components with the start dates and finish dates from the MS Project plan. [Note: the tool can be customized by Autodesk Consulting to include any other MS Project variable as need]. Planning information can then be visualized in Revit by filtering on this attribute data. For instance, a user can ask Revit to show all the building components which are scheduled to be installed by June 1st, or all components that will be worked on in October.

In addition, the phase information of Revit model components can be updated from the MS Project file, allowing Revit phase assignments to be automated via MS Project. For those readers unfamiliar with Revit phases, they represent distinct time periods in a project's life: “existing conditions”, “first floor new construction, Phase 1”, and “first floor new construction, Phase 2”, for example. Each building component can be assigned to a phase. To have a visual of how a project appears during the various stages of work, a

Figure 1: Autodesk Consulting’s “Bidirectional Link with MS Project” tool links Revit Building components to a MS Project for schedule creation and resource assignments.


3

user toggles phases on or off. For example, the user could ask Revit to show only “existing conditions” and “first floor new construction, Phase 1” components. Or show all components in all phases, but highlight in red “first floor new construction, Phase 2” components. A component’s phase is passed to MS Project during the export process, and if that phase is changed (or added, if the original phase was blank) in MS Project, the

Revit model is updated during “Import from MS Project”.

Project Planning for an Integrated Workforce Not surprisingly, one of the first customers to use the Revit/MS Project tool was a firm with a keen interest in planning and scheduling for their integrated design/build workforce.

Dal Pos (www.dalpos.com) is 30-person architectural firm located in Syracuse, NY. An experienced Revit user, Dal Pos began using the Revit/MS Project link on a high-end multi-million dollar custom home slated for construction in 2007 – both for the benefits it would bring to that project and as a test bed for future high-profile commercial projects.

According to Scott Bloss, Senior BIM Technologist at Dal Pos, “We began by exporting our Revit design model to MS Project and developing an initial project schedule. Now we regularly update the project plan from our design model, and in turn push our planning data from MS Project back to Revit.” The bidirectional integration between design and planning has improved communication for the whole team. This is particularly evident at their weekly project meetings, where the team can now ‘see’ their upcoming construction tasks. “We use scope of work filtering techniques within Revit to visualize the project plan,” explains Bloss. “For example – I’ll display all work items scheduled to be installed next week, or all components in a tight area color coded by trade, or highlight in blue all the items that are scheduled to be installed by a particular fabricator.”

Dal Pos’ use of the Revit/MS Project link has certainly improved their design and construction coordination, but it’s just one piece of a bigger strategy – to create a

Figure 2: The bidirectional Revit to MS Project link enables Revit components to be updated with MS Project details.


4

completely digital job site with a building information model as the centerpiece. As Bloss puts it, “4D BIM is a must-have tool in our digital gangbox.”

4D Visualization Our second example features a product from Innovaya (www.innovaya.com) called Visual Simulation, a 4D planning and constructability analysis tool that allows a building information model created in Revit to be integrated with either a MS Project or Primavera project plan. Visual Simulation uses the Revit application programming interface (API) to export the Revit model to the Innovaya file format. The model can then be imported into Visual Simulation. The product includes a specialized 3D/4D environment for both standard 3D building model navigation as well as 4D visualization.

Early project plans can be developed directly in Visual Simulation by using Revit phases to generate construction-sequenced tasks based on hierarchical building components. Tasks created by this approach are automatically linked with the building information model components, and this process can be completed very easily and quickly without requiring a schedule. This is particularly useful in the early stages of design, when project planning is rudimentary with perhaps just a few key milestones established.

As the project moves forward and the need for detailed project planning arises, the product also features a link to both MS Project and Primavera, with import, export and synchronize functions. When a project plan is established in Visual Simulation, a user can visually associate model objects and scheduled tasks. For example, a user can click on a building object in the 4D visual environment, and see its associated task highlighted in the

Figure 3: Visual Simulation from Innovaya is a 4D planning and constructability analysis tool that allows a Revit building information model to be integrated with either a MS Project or Primavera project plan.


5

Gantt chart or vice versa. Users can explore scheduling “what-ifs” by changing the start date of a task in the Gantt chart and see the ripple effect in the 4D model.

The 4D visual environment includes a variety of time/schedule filters for viewing building components based on construction type (e.g., new, temporary, existing, etc.), resources, start/finish dates, criticality, linked/unlinked tasks, and so on. This allows users to do things such as highlight potential installation issues (“show in red any building objects that are linked with two tasks on the same day”) or create installation sequences of building components that can be animated and saved, then played back like a movie to show project teams or clients how the project or a particular area will be built.

Summary When firms begin to use 4D BIM, they usually start with the phasing capability inside of Revit – which can be used quite effectively for broadbrush construction visualization. As their expertise with 4D modeling grows, they tend towards direct links between the building information model and their scheduling system, using some variation of the approaches presented above.

Whatever the path taken or technology implemented, 4D building information models containing detailed schedule and resource data from the native project planning software are now a reality – and can lead to a more engaged team, more informed decision making, and better coordination between designers and builders.

Figure 4: Visual Simulation’s 4D environment allows users to visually associate building model objects and tasks.


6

About Revit The Revit platform is Autodesk’s purpose-built solution for building information modeling. Applications such as Revit® Architecture, Revit® Structure, and Revit® MEP software products built on the Revit platform are complete, discipline-specific building design and documentation systems supporting all phases of design and construction documentation. From conceptual studies through the most detailed construction drawings and schedules, applications built on Revit help provide immediate competitive advantage, better coordination and quality, and can contribute to higher profitability for architects and the rest of the building team.

At the heart of the Revit platform is the Revit parametric change engine, which automatically coordinates changes made anywhere — in model views or drawing sheets, schedules, sections, plans… you name it.

For more information about building information modeling please visit us at http://www.autodesk.com/bim. For more information about Revit and the discipline-specific applications built on Revit please visit us at http://www.autodesk.com/revit.

Autodesk and Revit are registered trademarks or trademarks of Autodesk, Inc., in the USA and other countries. All other brand names, product names, or trademarks belong to their respective holders. Autodesk reserves the right to alter product offerings and specifications at any time without notice, and is not responsible for typographical or graphical errors that may appear in this document. Computer aided design software and other technical software products are tools intended to be used by trained professionals and are not substitutes for your professional judgment. © 2007 Autodesk, Inc. All rights reserved

REVIT® BUILDING INFORMATION MODELING

Transitioning to BIM

This paper profiles best practices for implementing building information modeling (BIM) solutions, exploring the key success factors for a successful BIM deployment, the process and staffing changes that can be expected, and the requisite training needs for BIM.

Key Success Factors Let’s begin by focusing on the key success factors for a successful BIM deployment and what firms can expect as they transition from 2D or object CAD systems (sometimes called single-building modelers or virtual building modelers) to a purpose-built BIM solution like Revit® Architecture software.

“A New Order of Things” At the end of 2003, Autodesk commissioned an independent research study1 that looked at the process changes, benefits, and challenges being experienced by firms implementing Revit Architecture. A key finding of the research is that practically all of the participants in the study were grappling with issues of change. To supplement the study, Autodesk conducted an online survey of their Revit Architecture customers, which included questions relating to change. In the survey, 82% of the respondents noted their design process was changing as a result of using Revit Architecture, and 80% reported that their deliverables were changing as well.

"There is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success, than to take the lead in the introduction of a new order of things. Because the innovator has for enemies all those who have done well under the old conditions, and lukewarm (indifferent, uninterested) defenders in those who may do well under the new."

Niccolo Machiavelli, The Prince

Think back on the resistance there was to the first 2D CAD systems. Then came 3D modeling systems and even more grumbling. This same resistance to change holds true for BIM solutions.

A purpose-built BIM solution like Revit Architecture provides architects a distinct, intuitive, and powerful means for building design. Its parametric approach to modeling is

1 Implementation in Practice, by Dr. Lachmi Khemlani (available at www.autodesk.com/revit)


2

the essence of true architectural design, but it also represents a groundbreaking new way of using a computer to design. Transitioning from CAD-based technology to object CAD technology is an incremental change. Moving to parametric building modeling is a bigger change, but one that’s particularly attractive to firms that want to use technology as effectively as possible. Education and awareness about BIM - the dramatic benefits it can bring as well as the work flow changes it requires - are key weapons when tackling this natural resistance to change.

Implementation Strategy for BIM A formal implementation strategy is an essential component of any successful BIM deployment and must go well beyond a simple training & rollout schedule. It should address head-on the workflow and organizational changes inherent to BIM.

The implementation strategy also needs to address how the new solution will initially co-exist with existing 2D drafting or 3D modeling applications. Wholesale abandonment of these legacy design applications is impractical and often ill advised, but as the implementation expands, the strategy may also include plans for the phased retirement of legacy systems if applicable.

Firms should look at how the building information model can be accessed by related applications such as energy analysis, cost estimating, and specifications. Specifically, look at the work you need to accomplish today, and match that to the tools you put in place today.

For firms that handle very large projects, your implementation strategy should include guidelines for creating and working with large models (additional hardware requirements, techniques for reducing model complexity, etc).

The Right Stuff Because BIM represents a new approach to building design – not just the implementation of new supporting technology - firms should pay close attention to the makeup of the transition team. The team should be comprised of agile, progressive individuals who understand the big picture and will act as evangelists for BIM.

Your team needs to come from the entire organization - reflecting the underlying process changes that come with BIM. And your user community should extend beyond your core group of CAD operators. In fact, don’t put your best CAD operators on a solution like Revit Architecture—put your best building designers and architects on it!

Bread & Butter Projects Starting Out Select the right project to start with; something your firm already knows how to do, so there’s only a single dimension of learning.

If possible, select a project type with known metrics, so you can accurately gauge the benefits of the new solution. Some of the most important benefits of BIM are difficult to quantify: more time for up-front design, clearer presentation of the design to the client, etc. But some benefits, such as increased documentation productivity, are more immediate and relatively easy to measure. Gathering these statistics can substantiate the promised ROI of the system and help garner support amongst the “show-me” members of the firm.


3

The Way Forward RTKL Associates (www.rtkl.com) is one of the world's foremost architectural, engineering, and planning firms, with over 700 employees in 10 offices worldwide. The company's portfolio of large-scale projects include the U.S. Capitol Visitor Center in Washington D.C., the Chinese Museum of Film in Beijing, and the Maryland Museum of African-American History and Culture in Baltimore, Maryland.

RTKL is currently in the process of converting to Revit Architecture after experiencing the benefits of BIM on four major projects. "Our implementation of Revit reflects our belief that its database concept is the future of architectural design and document software,” reports Douglas Palladino, AIA, a principal at RTKL’s Washington DC office. “We know that the transition to Revit will change how we do business. We can’t send everyone off to a class for a couple of days and just expect everything to fall into place. Revit is much more than a new design tool; it changes everything!”

Checklist for Success At the top of the checklist for a smooth deployment of a BIM solution are these critical success factors:

Develop a sound, comprehensive implementation strategy,

Assemble the right team, and

Select a suitable starting project.

And be prepared for the inevitable resistance to change that a revolutionary approach like BIM will provoke. But after the tedious error-prone world of systems that the architectural profession has tolerated up until now, they’ll soon realize that the parametric building modeling technology of Revit Architecture is like a dream come true. As stated in the conclusion of the third-party implementation study referenced above, “Those who have persevered in their learning and use of Revit have come to love the application and find it anathema to go back to traditional CAD. For them, the practice of architecture will never be the same again.”

Figure 1

RTKL Associates is converting its offices to Revit after experiencing the benefits of building information modeling on major projects such as this Washington DC Union Station Garage addition.


4

Getting Ready for BIM BIM represents a novel approach to building design that will change the functional dynamics of a design firm. Therefore the transition to BIM requires a thorough examination of how best to organize an office around BIM – identifying potential process changes that BIM will bring about and how to apply the right mix of people and skills to those new processes.

A New Way of Working In the Autodesk survey referenced earlier, 82% of the respondents noted that BIM was changing their design process - forcing them to re-evaluate their existing ways of working. As a result, Autodesk's consulting team often begins a BIM implementation with a process assessment. Over the past several years these assessments have produced some key learnings that can be leveraged by any firm adopting BIM. Here are the four most important ones:

1) Re-balance team effort to design phases: Perhaps the most significant change resulting from BIM is the luxury of being able to increase the amount of time spent in the design phase. Revit creates and coordinates drawings dynamically, directly in the building information model, so the documentation effort is dramatically reduced. Therefore, firms should plan on budgeting much less time (and staff) on documentation and coordination, and more time in early design - resulting in better decisions early on.

2) Avoid over-documenting: Revit produces drawings so easily it can lure a firm into “over-documenting”. At the beginning of a project, it’s a good idea to create a cartoon set of drawings (which is also part of the building information model) to serve as a guideline and scoping mechanism for documentation as the design progresses.

3) Use more visualizations for client communication: Revit produces high-quality renderings and walk-throughs on-demand, which facilitates communication with the client and enables a firm to be much more responsive in the design process – at little or no additional expense. As a result, firms may want to revisit their policies and procedures surrounding client deliverables and the provision of renderings.

4) Consider some expanded services: Finally, the Revit building information model can interface with and drive certain analyses and tasks such daylighting, energy usage, quantity takeoffs, and specification coordination. By taking advantage of some of these capabilities of the building information model, firms can offer expanded services to their customers.

The BIM Team These process changes also affect project staffing and the distribution of skill sets, which should be taken into account when establishing your BIM team.

The makeup of a traditional architectural project team is governed by the huge effort required to produce a construction document set, with roles corresponding to drawing types: plans, elevations, sections, details, etc. As described earlier, Revit Architecture significantly reduces the documentation effort - thus rendering this traditional project structure obsolete. Instead, a Revit Architecture BIM team should be organized around functions such as project management, content creation, building design, and documentation.

Firms will also find that they can budget for much smaller project teams as the overhead of documentation and traditional CAD tools is reduced. In some cases, as few as half as


5

many people are required to complete a BIM project compared to traditional ways of working. The smaller team (3 to 5 people is a typical size) encourages agility during the implementation period and sets the right expectations for the rest of the firm that BIM doesn’t require resources beyond conventional methods to succeed. As the implementation expands, let the BIM team grow organically – adding new staff as needed.

Investing for Productivity One firm that has experienced these transition learnings directly is URS. The URS Corporation (www.urscorp.com), a global architecture, planning, and engineering firm, provides consulting services in planning, design, and construction management for architectural and engineering projects as well as planning and environmental consulting services to both public and private sector clients. Ranked number one in Engineering News-Record’s list of the top 500 design firms, the firm is one of the nation’s largest professional service organizations whose total staff of more than 26,000 includes some of the most distinguished and experienced representatives of the architectural and engineering professions.

In the fall of 2003, URS was mid-design for a prominent corporate college conference and training center in northwestern Ohio when their client came to them with additional budget and a request to add features to the project. Using Revit Architecture, URS was able to swiftly redesign the building (in about 40% less time than would have been required if they had been using a traditional CAD program) and meet the project’s first fast-track construction deadline. Following this success, URS decided to implement the software on two additional projects and continues to expand their use of Revit Architecture.

URS recognized at the outset that implementing Revit Architecture software would require a new way of working. To ensure that the staff of the Cleveland office, where the software was first being rolled out, would experience rapid success, the firm engaged our Autodesk Consulting team for a comprehensive training and implementation program. This program included an initial two-day process assessment, a week of product training, and subsequent, staged implementation and evaluation services.

“By investing in implementation services, we were able to quickly become productive in using the software,” said Laura Rees, director of architecture for URS Cleveland, a division of the URS Corporation. “We had no idea then how much time we would eventually save by making this crucial initial technology decision.”

Ready, Set, Go BIM can radically transform the process of designing, constructing, and operating a building. But take a cue from the experiences of forward-looking firms like URS who have

Figure 2

URS Corporation used Revit to design this 107,000 square foot, $14 million dollar, middle school located in Ohio.


6

experienced the transition – invest the time and energy up front to carefully plan for that transformation. Know what you’re trying to do before you do it!

Training for BIM System training tends to be a balancing act for most firms - teaching the right skills to the right set of people with minimal disruption. There's no magic formula or right answer for BIM training. Size of a firm, existing expertise, rollout strategy - all of these need to be factored into your BIM training plan. But here are three training takeaways to consider.

Training for Change BIM means changes - changes in way of working, changes in staffing needs and project organization, and changes in how a firm uses of the information contained within the building model.

Because change is potentially disruptive to ongoing operations, it needs to be addressed head-on, prior to implementation. Education and awareness about BIM are key tools when tackling the natural resistance to change, particularly in large firms where organizational structure and disparate locations make communication more complicated. Large firms should preface their launch of BIM with a series of corporate presentations, (tailored for different levels of staff) explaining the reasons to consider transitioning to BIM, its potential benefits, and the changes that it may bring about.

Productivity Payback When an application seems fairly easy to learn, like Revit Architecture, it may be tempting to just skip training altogether. Avoid that trap. BIM is very different from CAD and without some sort of training, users will try to force the BIM solution to work like their CAD system did - with poor results.

The loss of billable hours during training is always a concern. But keep in mind that short-term productivity paybacks will quickly offset that loss. A recent online survey of Revit customers reported that although there was an average productivity loss of 25–50% during the initial training period, it took most customers only 3–4 months to achieve the same level of productivity using Revit as with the previous design tool. Building on that statistic, the estimated increase in productivity (as a result of migrating to Revit) ranged from 10% to over 100%, with more than half the respondents experienced productivity gains of over 50% and close to 20% experienced productivity gains of over 100%.

Just-in-Time Training When introducing software, time constraints often force firms and staff to keep moving ahead on productive project work while learning the new system. In these circumstances, on-the-job training (the ultimate just-in-time training!) is a good answer - and it also happens to be a very good learning environment.

For small firms, this may mean that your user(s) spend a day or so running through the "getting started" self-paced tutorials or web-based classes that software vendors usually provide with the software. Then, complete your training by working on an existing project. Think about starting with a project that your firm already knows how to do, so there’s only a single dimension of learning.

Larger firms may want to combine the self-paced training with instructor-led training for some percentage of users, and then let them dig into a live project to complete their training. Another training option is role-based classes (where users receive training content that targets their specific project role). Most firms don't try to implement the entire


7

spectrum of software functionality - they role out functionality as needed. The same theory should be applied to training - not everyone needs to know everything. Focus your initial training efforts on must-have functionality, then handle the rest on an ad hoc basis.

It's also a good idea for larger firms to have dedicated solution experts providing over-the-shoulder product support and coaching during this period. These "super users" will need to be specially pre-trained for this mentoring role, usually by sending them to classes offered by your BIM software vendor or reseller. Although these experts will most likely be assigned to project work of their own, having ready access to this expertise can be essential during the ramp-up period, preventing the design team from getting stuck on some software feature during a critical phase of the training project.

TIP: Set aside time to produce project templates based on your office standards and have them available for your project training. This allows your users to learn the software in a familiar context.

Training Case Study The Stubbins Associates (www.stubbins.us) is a 100-person design firm located in Cambridge, Massachusetts, and Las Vegas, Nevada. The firm's projects tend to be large and fast paced within six building market sectors; hospitality, healthcare, laboratory, corporate commercial, college & university, and government & institutional. As a rule, the firm utilizes advanced technology, including 3D modeling, on all projects. For several years, Stubbins has been investigating BIM solutions. In the spring of 2004 they rolled out Revit Architecture on 2 initial projects: a 200,000-square-foot tenant fit-out for a high-end advertising agency, and a 360,000-square-foot hotel.

Stubbins used a combination of classroom and on-the-job practice during their Revit Architecture implementation, immersing their new users in two weeks of training. Users received classroom training in the morning and then applied their training on project work during the afternoon. "Software training is a catch-22," reflects Jeff Millett, AIA, Director of Information and Communications Technologies for Stubbins. "You can't learn it without using it but you can't use it without learning it. We felt this half-day split of just-in-time training was a good balance for us. Although the hours weren't billable, we were able to

Figure 3 During their implementation of Revit, The Stubbins Associates used just-in-time training on this 200,000-square-foot tenant fit-out project.


8

move the project forward and our staff could immediately apply the concepts they learned on a real project. The key is to get people using the software straight away."

What NOT To Do Don’t forgo BIM training. There are a variety of training options that can mitigate its cost. Your dip in productivity will be short-lived. On-the-job training will keep your firm productive while learning the new system. And there's light at the end of the tunnel. "Now that we've got a couple of projects under our belt, we plan on starting our new projects in Revit," reports Millett. "It's sad to see an architect drafting in CAD - such a waste of talent and energy. Revit is an exciting tool and we're looking forward to having our staff designing in a whole new dimension."

Summary BIM can deliver tremendous business benefits, but doing so requires a departure from traditional ways of working. Moving from CAD-based technology to object-CAD technology can be an incremental or evolutionary change. Moving to building information modeling technology is a much larger change, and thus requires careful implementation planning, staffing- and training.

About Revit The Revit platform is Autodesk’s purpose-built solution for building information modeling. Applications such as Revit Architecture, Revit® Structure, and Revit® MEP built on the Revit platform are complete, discipline-specific building design and documentation systems supporting all phases of design and construction documentation. From conceptual studies through the most detailed construction drawings and schedules, applications built on Revit help provide immediate competitive advantage, better coordination and quality, and can contribute to higher profitability for architects and the rest of the building team.

At the heart of the Revit platform is the Revit parametric change engine, which automatically coordinates changes made anywhere — in model views or drawing sheets, schedules, sections, plans… you name it.

For more information about building information modeling please visit us at http://www.autodesk.com/bim. For more information about Revit and the discipline-specific applications built on Revit please visit us at http://www.autodesk.com/revit.

Autodesk and Revit are registered trademarks of Autodesk, Inc., in the USA and other countries. All other brand names, product names, or trademarks belong to their respective holders. Autodesk reserves the right to alter product offerings and specifications at any time without notice, and is not responsible for typographical or graphical errors that may appear in this document. Computer aided design software and other technical software products are tools intended to be used by trained professionals and are not substitutes for your professional judgment. © 2007 Autodesk, Inc. All rights reserved.

1

AUTODESK BUILDING SOLUTIONS

WHITE PAPER

Barriers to the Adoption of Building Information Modeling in the Building Industry November 2004

Phillip G. Bernstein FAIA Jon H. Pittman AIA Vice President, Building Solutions Senior Director, Strategic Research Autodesk, Inc. Autodesk, Inc.

Abstract The productivity and economic benefits of building information modeling (BIM) to the global building industry are widely acknowledged and increasingly well understood. Further, the technology to implement BIM is readily available and rapidly maturing. Yet despite the obvious benefits and readiness of BIM software, BIM adoption has been slower than anticipated. Why?

Fragmentation and calcified processes inhibit widespread change in the building industry. Digital technology, and particularly the integrative use of BIM during the building lifecycle, can catalyze change as the industry moves towards new approaches. However, technology alone is insufficient.

This paper suggests that the barriers to wider adoption of BIM in the building industry extend well beyond the oft-cited relationships between software applications. Data interoperability between applications is frequently heralded as the prescription to many building industry ills and we agree that lack of interoperability is one significant point of friction. However, interoperability is neither the singular nor most important factor impeding BIM adoption and the general use of digital tools in design and construction. Here we posit three interrelated barriers to BIM adoption:

(1) The need for well-defined transactional business process models;

(2) the requirement that digital design data be computable; and, finally,

(3) the need for well-developed practical strategies for the purposeful exchange of meaningful information between the many tools applied to industry processes today.

We conclude with suggestions for how the industry will be influenced to adopt building information modeling.

BARRIERS TO THE ADOPTION OF BUILDING INFORMATION MODELING IN THE

BUILDING INDUSTRY

2

Table of Contents Abstract ................................................................................................................. 1

Table of Contents .................................................................................................. 2 Background............................................................................................................. 2 Three Barriers to Building Information Modeling ........................................................... 4

1. Transactional Business Process Evolution........................................................... 4 Digital backgrounds ............................................................................................ 4 Discipline coordination ........................................................................................ 5 Digital basis for shop drawings ............................................................................. 5 Design delegation and fabrication ......................................................................... 5 Digital record drawings........................................................................................ 5 Obligations ........................................................................................................ 6 Risks ................................................................................................................ 6 Rewards............................................................................................................ 7

2. Computability of Digital Design Information ....................................................... 7 3. Meaningful Data Interoperability ...................................................................... 9

Breaking Adoption Barriers...................................................................................... 10 Horizontal influences and strategies .................................................................... 11 Vertical influences and strategies........................................................................ 12

Conclusion ............................................................................................................ 12 About the Authors ............................................................................................... 14

Background The building industry is a well-known latecomer to the productivity advantages offered by technology. Manufacturing, agriculture, and finance, like most modern enterprises, have embraced information technology for competitive gain, efficiency, and new approaches. The construction enterprise has yet to fully realize similar benefits, and the results are discouraging. The diagram below, from Stanford University’s Center for Integrated Facility Engineering (CIFE) illustrates the productivity of U.S. construction relative to all non-farm industries over a period of thirty-four years. Productivity in all other industries has almost doubled in the period while construction productivity has declined slightly. Thus, construction has not only lagged other sectors of the U.S. economy in productivity, it has deteriorated over a thirty-four year period. Although the data presented is for the United States, we believe a similar analysis of construction productivity on a global basis would show similar trends.


BUILDING INDUSTRY

3

A typical building project today, produced in silos of design, fabrication, construction, and operation, consumes vast resources with extraordinary inefficiency.1 Investment in technology in the worldwide building economy lags the similarly sized manufacturing industry by almost six-fold.2 The diagram above vividly illustrates the results and their consequences for growth in the construction industry. Facing global competitive pressures on every front, automobile, airplane, electronics, and consumer goods manufacturers turned long ago to model-based digital design processes based on data that supported engineering analysis, bill-of-material generation, cost modeling, production planning, supply-chain integration, and eventually computer-driven fabrication on the factory floor. As globalization and economic integration increases, the construction industry will soon be faced with similar competitive pressures.3

These lessons from manufacturing are gaining currency with today’s architects, engineers and contractors, but very slowly.4 Unlike the integrated supply chain of the manufacturing industry —a continuous team of designers, suppliers, fabricators and distributors (think of the array of companies that seamlessly work together to bring you your automobile)—building project teams rarely work together more than once. Their efforts are focused on the realization of a single, unique product: a building that will only be produced once.5 And most

1 For further info, see www.m4i.org 2 These computations were based on 2000 data. 3 Early indications of trends toward globalization include recent increases in the number U.S. architectural and engineering firms sending construction document drafting offshore, as well as the steel and cement pricing crises precipitated by the Chinese construction boom of 2004. 4 Stephen Kiernan and James Timberlake, in their book Refabricating Architecture, describe some of these lessons and their application. 5 Buildings are often constructed with a high (and increasing) percentage of manufactured components. Further, some studies show that up to 75% of the “content” going into a typical building design is identical, according to research done by the Movement for Innovation (www.m4i.org). While each


BUILDING INDUSTRY

4

methods of building project delivery are optimized for least cost and least exposure to each player in the process, to the detriment of the overall result. Legal, insurance, and financial systems have reinforced this focus on least cost and exposure and calcified inefficient delivery practices. Ultimately, building owners bear the brunt of these inefficiencies as the party most impacted by construction errors, broken schedules, and budgets, as well as high long-term operational and maintenance costs.

The use of digital tools within the building process has been focused on discrete, disjoint, and unrelated tasks such as drawing generation, visualization, cost estimating, or construction administration bookkeeping.6 “Episodic implementation” of this array of tools is a result of the disconnected nature of the design-to-build process, and its traditional reliance on paper-based data transactions. While discrete analog elements of this process are being replaced by digital data exchange—accelerated by the ever-increasing speed of desktop processors, networks, and the Internet—there are few protocols that establish the inherent relationship of digital information between adjacent processes in the industry. The array and deployment of digital tools is thus considered to be fragmentary, and users demand tighter connections, generally under the rubric of “seamless data interoperability.”

To remedy poor productivity and anemic growth, the building industry must address the underlying issues described above. The solutions are not purely technical problems that will be achieved by a broad consensus among software vendors (like the employer of the authors), imposition by standards making bodies, or use of a single set of tools to support design/build/operate. The desire for deeply interoperable tools with completely exchangeable data is a consequence of more important issues that are precedent to achieving good interoperability. In fact the technical hurdles to achieving these process relationships are far lower than the related business process integration goals.

Three Barriers to Building Information Modeling The three barriers to BIM adoption that we posit must be addressed directly and in balance are transactional business process evolution, computability of digital design information, and meaningful data interoperability. Solving the challenge to one barrier alone will not accelerate BIM adoption. The following analysis addresses each such barrier, in order of priority, and suggests paths to resolution.

1. Transactional Business Process Evolution The array of technologies available to today’s designer or constructor creates process possibilities that far exceed norms of practice and well-understood business protocols. Not unlike today’s doctors, whose tools create circumstances that exceed ethical definitions of care, few players in today’s partially digital design-to-build process are on sure footing. Consider the following examples:

Digital backgrounds

During the contract negotiation between a design architect and an architect of record on a large project, the architect of record insists that her fee structure (and profit) depend entirely on receiving coordinated digital schematic and design development background files from the design firm, which will be used as backgrounds for the construction and permitting documents.

building is unique, the underlying components, design methodologies, and construction processes are often replicated from project to project. 6 Tools such as AutoCAD®, Autodesk® VIZ, Microsoft® Excel, or Primavera® Expedition are typical examples.


BUILDING INDUSTRY

5

Discipline coordination

The mechanical engineer on a small office building project receives DWG-based backgrounds from the architect for his construction documents. Finding insufficient headroom on the lobby level for air distribution, he increases the floor-to-floor height between Floors 1 and 2 on the architectural backgrounds, failing to notify the architect that this was required. During construction, the successful MEP sub-contractor submits a change order citing increased costs of coordinating vertical ducts runs sized on the erroneous sections that do not connect between architectural and MEP drawing sets.

Digital basis for shop drawings

After award of the construction contract during a hard-bid “design-bid-build” project, the structural engineer receives an RFI from the steel fabricator requesting digital structural drawings. After she refuses to submit the drawings, citing lack of payment and any liability protection, she receives a demand letter from the project owner accusing her of “being uncooperative” and insisting that she transmit “all of the drawings immediately without further delay to the project.”

Design delegation and fabrication

In order to construct a complex curtainwall that will enclose the lobby of a project, the architect provides his digital construction documents, including extensive 3D data that was used to create the resulting documents (not represented in the permit set), to the fabricator, who, after engineering verification of the performance specification provided by the design team and shop drawings, proceeds to fabrication and installation. The curtainwall is completed at 75% of the original target budget. Immediately after occupancy a strong wind storm destroys a large portion of the wall, and several people are injured.

Digital record drawings

At the conclusion of construction, and in accordance with the Owner-Architect agreement, the owner receives copies of the architect’s conformed, digital record drawings and incorporates them into his campus-wide facilities management system. Years later during the bidding of a routine maintenance construction project (and before the expiration of the statute of limitations) a serious dimensional error is discovered resulting in a large cost overrun on the maintenance project. The owner files an E&O claim against the architect.

These imaginary examples begin to describe the uncharted territory that lies ahead for the building industry. In the near future, we will have to answer the following:

• What is the relationship between design intent represented in preliminary design and the responsibility for signing and sealing the final design “documents”? Will the “signed and sealed” documents of today be replaced by their digital equivalents at the building department?

• What is the design team’s additional obligation for coordination when integrated information—such as a set of construction documents—becomes fluid and malleable as a natural result of design document production?

• What is the definition of AE instruments of service as digital expectations rise? How do designers reach a professional standard when that standard is defined by analog-based processes historically memorialized on paper? When designers are traditionally compensated (and insured) for


BUILDING INDUSTRY

6

“rendering professional judgment” how is value assigned to (and payment received for) data, and for how long?

• When design and fabrication data are inextricably intertwined, how are the duties and responsibilities of the parties allocated? The risks and associated rewards?

• What is the predicted lifespan of digital design information? How are its downstream uses anticipated, and how are its creators compensated? Are there parallels in the ongoing responsibility for building performance and the underlying data that created the design?

In each of the examples, BIM would ease the flow of information and connect processes, but not solve the business challenges. The inherent integration of design data in a model-based design-to-build process eliminates numerous potential conflicts, but addresses none of the underlying lack of basic business process integration. Without such integration, the processes themselves (and therefore the supporting tools and their data) will fail to properly mature; they lack clearly delineated work flow and data interactions.7 Ironically, paper-based protocols provided clear lines of business process that are now blurred by fluid digital information.

Each relationship in the building supply chain is defined by a set of obligations, risks, and rewards. Before the digital future can be fully realized and true process integration (including interoperability) achieved, these basic business terms must be defined across the enterprise:

Obligations

What tasks will each participant perform? What deliverables are required to achieve those tasks? What information must be generated and specifically exchanged in order to meet these responsibilities?8 Defining the specific data exchanges will both circumscribe responsibilities and reduce the enormous task of allowing all participants in the design to “interoperate” with all the data.

Risks

As data relationships are established, the discrete boundaries of responsibility are also going to blur, and this will require new ways to allocate risk. When the originator of a given piece of design information can not be definitively determined, how is risk assigned? A more pointed question might be, how is it fairly shared? Should design decisions be tracked to their precise originators in order to assign risk, or does an “open information project”9 imply equally shared responsibility?

7 The most successful software applications both support and augment well-defined work processes and deliverables. Better definitions of both will accelerate correct development by vendors of these solutions. The recent efforts of the AIA’s Large Firm Roundtable CIO Group to create such definitions are a good example of such an approach. 8 A key characteristic of the definition of obligations includes defining the excerpted data that one information author owes another user of design data. Each process does not require the complete subset of all information created by every other process. For example, the electrical engineer, when designing the emergency lighting system, need not know the color or type of the carpets within the same room. 9 “Open information project” is a term originated by Carl Galiota, FAIA, the technical leader for SOM’s Freedom Tower project. He uses it to describe an approach to data integration where all design information produced on the project—irrespective of origin—is depicted in the building information model that is the central design document.


BUILDING INDUSTRY

7

Rewards

With shared risks, shared rewards must follow. If a BIM-based construction process is inherently more efficient and productive, the incentives for integrating data and risk must be driven by compensation. Some of the savings realized by the owner must be spent during design and construction to achieve the more cost-effective end. Eventually, market forces will establish new baselines of compensation, and likely new models for payment.10 Until then, how are digital deliverables to be valued as instruments of service that persist through the building’s lifecycle? Rewards are, in our view, the primary driver in the adoption of any technology; effectiveness, in and of itself, does not drive business behavior.

Each of these key business issues, defined in parallel, must be connected to the proposition of BIM before widespread adoption will occur.

Early adopters of BIM approaches suggest how some, but not all, of the questions posed above will be answered. Model-based technologies today are frequently deployed in projects that are highly collaborative, and where the design team has agreed to fully integrate information from all sources during design including the constructor who is frequently at the table at the onset of the project. In such situations, risk is by definition distributed across the entire design team.11 And that team frequently includes the Owner, who joins the fray by using the model as a design decision-making tool. As the value of such approaches becomes apparent by more coordinated design and projects constructed on schedule and below budget, designers who offer BIM-based design strategies will command larger fees and commensurate risk distribution in their contracts.

2. Computability of Digital Design Information Digital design data exist in a variety of forms, many of which are not computable. At first glance, this seems like a nonsensical statement. How can data be both digital and non-computable? If data is digital, is it not by definition “computable”? The answer is yes and no. A computer can operate on any digital data – but the kind of computations the computer can do depend upon the semantic information expressed by that data.

Consider building a financial model as an illuminating example. One could create the financial model using a word processor, incorporating its table functions. This would involve creating tabular entries for all of the financial items – neatly aligning rows and columns. However, most word processing applications do not do computations within tables, requiring the author to do all of the calculations manually. If a number is changed, all affected cells would need to be manually recalculated and their new values re-entered in the table. This would be an extremely laborious and error-prone approach.

In contrast, one could create the financial model using a spreadsheet. The spreadsheet version might look identical to the word processor version, but the spreadsheet model contains numerical values, relationships, and sophisticated calculations. A changed value creates automatically recomputed results. Iterations are easy, and desirable. The spreadsheet maintains the integrity of the model and the relationships contained therein. While both the word processor table and the spreadsheet model have similar presentations,

10 For example, traditional fixed fee arrangements, where all players in the construction process are driven by considerations of least cost, might be replaced with performance-based compensation from baseline objectives. In Australia, the Project Alliance delivery method uses this, amongst other methods, to change behavior. 11 For example, SOM’s Freedom Tower project is characterized by both an Autodesk Revit®-based BIM design process and as an “open information project” by the designers involved.


BUILDING INDUSTRY

8

there is a fundamental difference between the two. The spreadsheet model is computable whereas the word processor representation is not, even though both are digital data.

The building industry, for the most part, has adopted the word processor approach to documenting building designs over the past 20 years. Computer-aided design (CAD) tools have been primarily used to create electronic drawings of buildings. In these drawings, buildings are depicted by abstract graphical representations such as lines, arcs, circles, and polygons. These representations are meaningful when read by humans, but contain little information that can be used for purposes other than plotting a drawing.12 Even the 3D models some have used for visualization purposes are little more than three-dimensional drawings. In most of these applications the computer has no implicit knowledge of building elements such as doors, walls, windows, roofs, HVAC equipment, furnishings, and columns. These are represented by graphical elements that, at best, are tagged with a label indicating their type. Further, complex systems such as structural grids, HVAC networks, and plumbing, are represented by graphical elements and their fundamental relationships, topology, and functions are unknown to the computer. Design information that flows through the building process for most buildings today is documented using pictorial data, not computable information.

The historical reasons for this situation are partially technological. Early computer applications that mimicked the drafting process were enormously successful in improving productivity for architects and engineers. Sophisticated building information modeling systems – the building industry’s version of the spreadsheet – were rare. However, now technology is no longer the issue. Sophisticated building information modeling systems are available, but their adoption has been slow. Why?

One easy explanation is simply inertia and resistance to changing process, but we believe there is a more fundamental issue – designers and decision-makers do not fully grasp this notion of computable data and the limitations of the data created by their present systems and approaches.13

The state of practice in most firms is to create pictorial, non-computable data. However, the presumption is that the data is computable. It is quite common to attempt to use design data for analysis, cost estimating, or even visualization and find that the data – although it looks computable, is actually a collection of pictorial elements. For the most part, humans look at the data, interpret it, and transfer it to new applications for additional analysis. This process is both wasteful and error prone.14

12 While it may be technically possible to imbue such graphical information with computable characteristics (such as calculating area from the geometry of an enclosure) the graphics themselves carry no inferable information and are thus not computable. 13 One of the authors recalls a meeting with a large retail client 20 years ago. Our firm was designing a new headquarters for the client and a senior executive met with us to describe his vision for use of computer-aided design in the new building. He spoke of moving people, furniture, and equipment around his building and having the databases automatically update. He told us of his plans for retail stores in which we could move displays in the computer and have inventory databases update automatically. The retailers own IT staff was present and they kept giving us sidelong glances. They understood that we were producing pictures that lacked the computable information that was necessary to implement the executive’s vision. 14 The U.S. National Institute of Standards and Technology (NIST) recently published a report titled Cost Analysis of Inadequate Interoperability in the U.S. Capital Facilities Industry. This report rigorously identifies $15.8B in waste in the U.S. building industry”. The symptoms identified in the report are absolutely correct. It is a useful contribution to understanding where waste and inefficiency occur in the US building industry. However, the report attributes all of this waste and inefficiency to


BUILDING INDUSTRY

9

This phenomenon is not unique to the building industry. For all of its documented productivity gains, only about 10% of the manufacturing industry has moved from pictorial to computable models of products. In manufacturing, computable product models are used for structural and thermal analysis, machining, and resource planning. However, the benefits of these uses are only realized in a minority of firms. In our industry the number is far less – we estimate only 2-3% of practitioners really understand this issue and have embraced BIM as a path to computable design information. Further, this issue is precisely the issue facing developers of the world wide web. While much of the information on the web presently is representational in nature, there is now a great deal of work underway to create a “semantic web” using techniques such as XML in which the information on the web becomes computable.

Before the industry can move to meaningful BIM adoption, the need for computable information must be understood and the industry’s mindset must shift from pictures to information models. This is a shift that all industries experience. Once the value of a computable database is recognized – and computable databases are created for buildings – new forms of value can be unleashed.

3. Meaningful Data Interoperability Once business process and computability are resolved, the final prerequisite for BIM adoption is making the resulting data accessible to the relevant parties involved in the building process. There are a great many design tools, and more importantly, other applications that operate on design data and provide analytical insight. This is not necessarily a bad thing, since it is both unhealthy and unlikely that any one BIM system can or should provide all of the capabilities necessary to address and solve the diversity and breadth of design and analysis problems in the building industry. Monolithic data models and software applications that try to do everything often fail to do anything well, and we find that purpose-built and focused data models and applications often meet customer needs far better. Innovation is likely to proceed more quickly with purpose-built and loosely coupled applications than with large, interconnected, and interdependent applications. To facilitate this progression, sharing meaningful design information between applications is essential.

This idea of sharing design information is often called “interoperability,” an imprecise term used in several different and ambiguous ways. Some proponents of interoperability suggest creating a master database15 that contains all knowledge about the building. Applications will operate upon the resulting model and extract and deposit information meaningful to them. This is the way many transaction-oriented business information IT applications such as accounting systems, airline reservation systems, and inventory control systems work. The approach works well when the data is well-defined, repetitious, and transactional in nature. However it has not proven to be a practical strategy for computable design information for two important reasons, one technical in nature, and the other connected to our earlier comments about lack of underlying business protocols.

Technically, because there are so few computable building design models in existence, it is difficult to create one representation that works for every application. Further, the level of complexity of such model-based data is much higher than in a transaction-focused database system. Attempts to define data models up front often fail because they do not account for the ways applications actually use information, and the diversity of applications often makes it difficult to define the needed data. So attempting to define a universal building model prior to implementation within real applications will likely result in a “least common denominator” that fails to satisfy anybody’s needs, or a model schema that is so complex as to be impossible to

only one of the causal factors “poor interoperability”. Unfortunately the diagnosis is incomplete and fails to address either business processes or the lack of computable design information. 15 Sometimes called a “model-server”


BUILDING INDUSTRY

10

implement. Finally, the process of developing such models is long, arduous, and political – thus making it costly and ultimately suboptimal.

Second, the discontinuities of obligation, risk, and reward discussed earlier suggest that one large database with unfettered access is incompatible with current fragmented building industry structure. Controls on the kind of information flowing from one participant to another are needed to address the business realities of the industry, and these controls will evolve carefully over time. Further, the technical mechanisms to support these controls will need to evolve in parallel. For these reasons, the technical issues in managing controls on design information are far more daunting than those found in managing transactional databases.

A second strategy can be found in the work of the International Alliance for Interoperability (IAI), and in particular the “Industry Foundation Classes” (IFC).16 IFCs are intended to be a platform-independent geometric and data definition for the exchange of information across various AEC applications. As such, they are a “top down” attempt to create a holistic computable standard for AEC information. Their early success can be found in the most clearly defined computable problem—the exchange of graphical information between adjacent authoring applications. The IFC model may, over time, evolve to the point where it will transmit defined computable information. But presently, both transactional business processes and lack of defined computable data in the building industry limit their utility for this purpose. We believe that such efforts would be enhanced by emphasis on establishing standard business protocols as well as computable information, in addition to interoperable data standards.

Thus, a more practical strategy is one we call meaningful interoperability, comprised of purpose-built conduits from one application to another that achieve a particular task. A good example is Green Building XML (gbXML). gbXML is a simple XML-based protocol to transfer building model data from a BIM application to an energy analysis application. It represents precisely the information that needs to be transferred in a way that is both easy for the BIM application to produce and for the analysis application to consume. Because the data moves on demand, for a specific purpose, the owners of the data are assured that it meets their obligation/risk/reward criteria.

Interoperability is best achieved when there is a demonstrated need and a specific transactional problem to be solved. gbXML was developed using a simple data transfer protocol, purpose-built for a particular use, to meet a specific business need. As such, it was developed quickly and inexpensively. We believe this is the prototype for one type of meaningful data interoperability and a process that is more likely to lead to the ability to share information widely amongst a variety of design and analysis applications.

In the world of e-commerce on the Web, the emerging concept of web services takes this approach. It uses very lightweight, purpose-built XML protocols allow two collaborating web sites to communicate, creating essentially a “loose coalition” of applications that communicate efficiently. This approach clearly demonstrates our concept of “meaningful interoperability.”

Breaking Adoption Barriers The fragmented nature of the construction industry precludes widespread change of any kind, particularly to design tools that are based on the traditions of paper. The transition to BIM-based paradigms will be a greater shift than that of paper to computer-aided drafting, as it 16 Autodesk, the employer of the authors, was a founding member of the IAI and continues to participate today in their activities, as well as produce IFC-compliant software. For more information, see www.iai.org.


BUILDING INDUSTRY

11

entails a change in both tools and process, as described above. The broad range of industry practice, local customs, varied standards of care and product performance combined with the disaggregated building supply chain suggest that a broad change to business practices that support computable, interoperable models is a long way away. Having identified the barriers, what are the accelerators?

While the efficacy of BIM solutions to increase productivity and accuracy while reducing design cycles is acknowledged, we believe none of these characteristics will, in and of themselves, move the industry to model-based design. As with the change to CAD decades ago, external influences like owner demand and changes to risk/reward ratios will be the primary factors. A small number of firms, seeing a potential competitive differentiation, will drive early adoption. Getting BIM to the mainstream will be the result of these bigger forces.

We thus see the problem in two dimensions, which we will characterize here as “horizontal”—changes or influences to the building industry as a whole, and “vertical” – changes that are focused on solving particular problems in the design-to-operate continuum. Some combination of factors affecting each will begin to dissolve current barriers to BIM adoption. We summarize below some of the more important approaches affecting this change.

Horizontal influences and strategies Reducing waste

Recognizing the inherent waste and inefficiency of the construction process today, owners will insist that traditional design/fabricate/build/operate silos break down. Globalization may bring new competitors into the building industry thus providing an impetus for change. Approaches for delivery of projects will become more integrated, and design information will flow more freely across process barriers. BIM is the most effective source of such information.

A current example: use of “design-assist” delivery, where design documents are considered “complete” after design development, and detailed technical design occurs during shop drawing preparation in collaboration with fabricators and suppliers.

Balancing risk and reward

Acknowledging that traditional allocations of risk in construction create both waste and an ineffective process ultimately reflected in the cost of the resulting building, owners will demand new, shared risk models where multiple disciplines contribute to the creation of design data that is the genesis of construction. Risk will be ascribed to the design-to-construct team as a whole, and its members will be compensated accordingly. Sharing information thus becomes the best risk management strategy, and BIM authoring offers the highest quality, sharable data.

A current example: complex infrastructure projects, where risks are unknown and high, are being built in Australia using a delivery approach called “project alliance,” where all design and construction team members share equally the risks and rewards of success (and failure) with the owner.

Constructing complex buildings

Obligated to construct increasingly complex, intricate, and customized buildings whose genesis is based on digital design strategies, contractors and fabricators will devise ever-more effective means to meet schedule and budget objectives of owners. Construction planning and management will be supported by digital tools that simulate, track and evaluate construction progress. Central to such analysis is the representation of the building itself, the building information model.


BUILDING INDUSTRY

12

A current example: in order to construct the enormously complex Disney Concert Hall in Los Angeles, the construction team used a virtual simulation of the construction project, studying installation sequence and construction inside a video “cave” that projected images from a digital model of the project.

Vertical influences and strategies Creating a sustainable environment

Determined to reduce the deleterious effect of construction and building operation on the environment, all participants in the building industry will strive towards sustainable projects. Evaluating sustainable design strategies is heavily dependent on analysis, simulation of alternatives, and detailed quantitative evaluation of building materials, components and performance.

A current example: designers using modeling tools that generate gbXML can quickly evaluate the energy performance of their projects by posting the XML file to an Internet-based analysis engine which reports immediately on energy consumption and other characteristics. The analysis can iterate with the design.

Fabricating from digital information

Leveraging the inherent advantages of computer-driven fabrication, constructors will consume digital design information that will supplant traditional paper-based drawings and consume a version of that information from its original source, the building information model at the core of the design process itself.

A current example: most exterior curtainwall systems today are being constructed from computer controlled fabrication systems driven by digital information. In the case of complex, curved walls featured on modern skyscrapers, the source of the generative geometry is the original designer’s CAD model.

Managing the building through its lifecycle

Working to manage the cost of building operation through the building lifecycle,17

owners will demand that information created during design persist through construction into facilities management. Performance criteria for design deliverable will include their use during facilities operation. BIM-based building descriptions are the most robust, the most data-rich, and the most adaptable to FM solutions.

A current example: a large corporation, after discovering that it had constructed additional office space despite having vacancy factors of 30% or more in other locations on its corporate campus, created a digital facilities management database that tracks occupancy, space allocation, and assets.

There is no single factor that will drive the industry to new BIM approaches. But each of the factors above, influencing individual decisions as each building project coalesces, will gradually push construction to truly modern processes based on BIM. Individual firms or projects, wishing to attack one of the problems described below, will turn to BIM as its best hope for addressing them effectively.

Conclusion

17 Building operation cost to its owner is generally acknowledged to be between four and ten times the total original construction cost of the building.


BUILDING INDUSTRY

13

We believe that a combination of factors are currently inhibiting the building industry from more productive, efficient uses of technology in the form of building information modeling, and we have described here the conditions under which we believe that change will commence. If we are to make progress in BIM adoption, the dialog around productivity in the building industry must encompass all three of the barriers to adoption we have identified.

We conclude here with some final observations and predictions about the changes to occur over the next five to ten years:

• It is unlikely that building information will reside in a single, consolidated source information model. Industry process will commence from a loosely connected coalition of information models that support various processes, governed by the principles of computable interoperability defined here.

• Risk and responsibility will be managed and filtered by connection protocols between these models, whose authors will maintain ownership, and whose data will be distributed via interoperable conduits that support specific transactions and filter unnecessary information from transmission. The architect’s BIM will be the central, control model at the core of design decision-making, but it will not contain all project information. It will be surrounded by review, approval, and control data transactions. Crude risk-management mechanisms like practice-based liability insurance policies will be replaced with custom-designed, project-based mechanisms that more closely resemble construction bonding.

• Data interaction protocols will define business relationships, and data structures will reflect transactional obligations. These approaches, and the connections between adjacent digital tools, will be systematically refined by repeated use over time.

• Carrier mechanisms—the methods for carrying computable information between applications and processes—may become more important than the data itself, since they will be the basis for risk and reward.

These observations are not a prescription for the future, but rather what we believe will be likely outcomes of the full integration of digital tools, through the use of building information models, in the building industry in years to come.


BUILDING INDUSTRY

14

About the Authors Phillip G. Bernstein, FAIA is Vice President of Autodesk’s Building Solutions Division, the leading provider of technology to the building industry. Prior to joining Autodesk, Bernstein spent 20 years as a practicing architect, most recently as Associate Principal at Cesar Pelli & Associates, where he managed many of the firm’s most complex commissions. Bernstein has taught at the Yale School of Architecture as a Lecturer in Professional Practice since 1988. He writes and lectures extensively about practice and technology issues. He received a Bachelor of Arts magna cum laude with Distinction in Architecture in 1979 from Yale University and a Master of Architecture in 1983, also from Yale University. He is a Senior Fellow of the Design Futures Council, a Fellow of the American Institute of Architects, and a member of the AIA National Documents Committee since 1998, where he becomes Chair in 2005.

Jon H. Pittman, AIA is Senior Director of Strategic Research for Autodesk. Pittman is responsible for researching and facilitating the development and integration of external sources of long-term competitive advantage, participating in the development of overall technology strategy, and representing Autodesk externally from a technology and strategy perspective. With over 25 years of experience in the computer-aided design, computer graphics, and internet industries, Pittman has held a variety of business development, product development, and strategy positions at Autodesk, Structural Dynamics Research Corporation (SDRC), Alias|Wavefront, and Hellmuth, Obata, and Kassabaum (HOK) Architects. In addition to the work in the corporate world, Pittman has been an Assistant Professor at Cornell University's Program of Computer Graphics and an instructor in user interface design at Art Center College of Design. Mr. Pittman holds a Bachelor of Architecture and MBA from the University of Cincinnati. He also holds a M.S. in Computer Graphics from Cornell University.

Autodesk [and other products] are either registered trademarks or trademarks of Autodesk, Inc., in the USA and/or other countries. All other brand names, product names, or trademarks belong to their respective holders. Autodesk reserves the right to alter product offerings and specifications at any time without notice, and is not responsible for typographical or graphical errors that may appear in this document.

© 2005 Autodesk, Inc. All rights reserved.