UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Understanding the transition to BIM for facility owners Cavka, Hasan Burak 2017

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
24-ubc_2017_september_cavka_hasan.pdf [ 5.91MB ]
Metadata
JSON: 24-1.0354549.json
JSON-LD: 24-1.0354549-ld.json
RDF/XML (Pretty): 24-1.0354549-rdf.xml
RDF/JSON: 24-1.0354549-rdf.json
Turtle: 24-1.0354549-turtle.txt
N-Triples: 24-1.0354549-rdf-ntriples.txt
Original Record: 24-1.0354549-source.json
Full Text
24-1.0354549-fulltext.txt
Citation
24-1.0354549.ris

Full Text

UNDERSTANDING THE TRANSITION TO BIM FOR FACILITY OWNERS  by  Hasan Burak Cavka  MASc., The University of British Columbia, 2010 B.Arch., Dokuz Eylul University, 1999  A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF  DOCTOR OF PHILOSOPHY  in  THE FACULTY OF GRADUATE AND POSTDOCTORAL STUDIES  (Civil Engineering)   THE UNIVERSITY OF BRITISH COLUMBIA (Vancouver)  August 2017  © Hasan Burak Cavka, 2017  ii  Abstract Building information modeling (BIM) is emerging as a potential solution for facility owners to address the challenges of poor information quality and interoperability during project handover and inadequate facilities management during building operations. However, implementing BIM in an owner organization is a complex challenge that necessitates reconfiguration of work practices and internal structures to fully realize the benefits. Although previous studies have documented the potential benefits of BIM adoption for owners, such as improvements in work order processing, very little research has specifically looked at the transition to BIM and the scale of the effort required for large and diverse owner organizations.  This dissertation investigates the transition to BIM through the lens of two large public owner organizations in Canada. Specifically, the research involved embedded case study analyses to investigate the alignment of facilities management (FM) practices across the organizational and project contexts in relation to owner requirements. The resulting case study analysis is unique in terms of the richness of the data collection and analysis methods used, the research approach investigating alignment across two interrelated contexts at the organizational and project level, and the focus on information in terms of understanding how facility information is affected by the organizational processes, technologies and requirements. The investigation of current owner practices enabled a better understanding of the gap between available and required information, processes and technology, and the challenges owners face when considering the transition to BIM. A significant contribution resulting from these studies is the framework I developed to characterize the alignment between organizational constructs, available technology, project artifacts and owner information requirements.  The research into iii  two different owners provided a rich understanding of owners’ information requirements and led to the formalization of computable requirements in relation to BIM, and the development of a 3-stage methodology to help owners develop and deploy BIM requirements.  This research demonstrates that the transition to BIM for facility owners necessitates the development of explicit and computable BIM requirements, the reconfiguration of internal work practices, and the formalization of stages of compliance to support BIM-enabled project delivery.  iv  Lay Summary BIM provides a data-rich, non-redundant information repository of facility information that is capable of supporting a broad range of FM functions. However BIM use for FM remains significantly limited. The reality is that implementing BIM in large owner organizations is a complex challenge. This dissertation investigated two large public owner organizations in Canada to better understand what is involved in the transition to BIM for facility owners. I benchmarked the current state of project handover and FM practices and developed a framework to characterize the alignment between an owner organisation and BIM. Next, I identified and formalized the information required by facility owners and developed a 3-stage process to develop and deploy BIM requirements. Finally, I identified the layers of reasoning for evaluating the compliance of BIMs with owner requirements.  These contributions will help owners to better understand and prepare for the digital delivery and operation of their facilities.   v  Preface  The core focus of this research work is on understanding the transition to BIM for facility owners. The research included analysis on three levels; organizational, owner requirements, and BIM. The author of this research work is solely responsible for all the content presented in this manuscript-based thesis that relates to the literature review, research framework, case study, interviews, model and document analyses, development of alignment framework, development of methodology to support a rigorous and detailed analysis of BIM requirements, development of a 3-stage approached to develop and deploy BIM requirements, and the development of  methods for evaluating compliance with owner requirements.  Much of the content of this dissertation is in the form of manuscripts prepared for publication. For each of these, the dissertation author (Cavka) was the primary manuscript author, while the other co-authors provided guidance on the development and application of various aspects of the research as well as manuscript review and editing.  The following three journal papers have either been submitted or published:    A version of Chapter 2 has been published: Cavka, H., Staub-French, S., & Pottinger, R. (2015). Evaluating the alignment of organizational and project contexts for BIM adoption: A case study of a large owner organization. Buildings, 5(4), 1265-1300. doi:10.3390/buildings5041265 A version of Chapter 3 has been accepted for publication Automation in Construction: Cavka, H., Staub-French, S., & Poirier, E. A. (2016). Developing Owner Information vi  Requirements for BIM-enabled Project Delivery and Asset Lifecycle Management.  A version of Chapter 4 has been submitted to Built Environment Project and Asset Management: Cavka, H., Staub-French, S., & Poirier, E. A. (2017). Compliance Review for Model-based Project Delivery.  The following peer-reviewed conference papers have been published in conference proceedings: Cavka, H. B., Staub-French, S., & Pottinger, R. (2015). Evaluation of organizational context and requirements for leveraging building information models to support handover and operations & maintenance. CSCE, 5th International/11th Construction Specialty Conference, Vancouver, British Columbia. Cavka, H. B., Staub-French, S., & Pottinger, R. (2013). Case study of BIM handover to support building operations.  CSCE, 4th Construction Specialty Conference, Montréal, Québec.  The research has been carried out under the certificate obtained, and renewed, from the University of British Columbia, Behavioral Research Ethics Board, with the certificate number H12-01745. vii  Table of Contents  Abstract ........................................................................................................................................... ii Lay Summary ................................................................................................................................. iv Preface..............................................................................................................................................v Table of Contents .......................................................................................................................... vii List of Tables ................................................................................................................................ xii Table of Figures .............................................................................................................................xv Glossary ....................................................................................................................................... xix List of Abbreviations .................................................................................................................. xxii Acknowledgements .................................................................................................................... xxiv Dedication ....................................................................................................................................xxv Chapter 1: Introduction ............................................................................................................... 1 1.1 Thesis Scope and Outline ............................................................................................ 4 1.2 Research Questions ..................................................................................................... 6 1.3 Research Contributions ............................................................................................. 18 1.4 Methodology ............................................................................................................. 19 1.4.1 Organizational Context ......................................................................................... 24 1.4.2 Requirements Analysis: Owner Requirements, O&M Personnel Requirements, Handover Documents........................................................................................................ 26 1.4.3 Project Context...................................................................................................... 26 1.5 Validation Through Expert Reviews ........................................................................ 27 viii  1.6 Reader’s Guide.......................................................................................................... 35 Chapter 2: Evaluating the Alignment of Organizational and Project Contexts for BIM Adoption: A Case Study of a Large Owner Organization ........................................................ 37 2.1 Introduction ............................................................................................................... 37 2.2 Methodology ............................................................................................................. 41 2.2.1 Organizational Context ......................................................................................... 43 2.2.2 Requirements ........................................................................................................ 43 2.2.2.1 Owner Requirements .................................................................................... 43 2.2.2.2 O&M Personnel Requirements ..................................................................... 44 2.2.3 Project Context...................................................................................................... 44 2.2.3.1 Handover Documents.................................................................................... 44 2.2.3.2 Building Information Model ......................................................................... 45 2.3 Literature Review...................................................................................................... 45 2.3.1 Organization .......................................................................................................... 45 2.3.2 Requirements ........................................................................................................ 48 2.3.3 Handover Artifacts ................................................................................................ 49 2.4 Data Collection Across Organizational and Project Contexts .................................. 52 2.4.1 Organizational Context ......................................................................................... 52 2.4.1.1 Building and Information Handover Process ................................................ 54 2.4.1.2 Records Management Process and Technology ........................................... 56 2.4.1.3 Asset Management Process and Technology ................................................ 60 2.4.1.4 Maintenance Management Process and Technology .................................... 62 2.4.2 Requirements ........................................................................................................ 66 ix  2.4.2.1 Owner Requirements .................................................................................... 66 2.4.2.2 O&M Personnel Requirements ..................................................................... 68 2.4.3 Project Context...................................................................................................... 72 2.4.3.1 Artifacts—Handover Documents .................................................................. 72 2.4.3.2 Artifacts—Building Information Models ..................................................... 74 2.5 Framework for Investigating Organizational Alignment .......................................... 81 2.6 Summary and Conclusions ....................................................................................... 91 Chapter 3: Developing Owner Information Requirements for BIM-enabled Project Delivery and Asset Lifecycle Management ............................................................................................. 94 3.1 Introduction ............................................................................................................... 94 3.2 Background on BIM for Owners ............................................................................ 100 3.2.1 Owner requirements for project lifecycle phases................................................ 100 3.2.1.1 Design and Construction ............................................................................. 100 3.2.1.2 Handover ..................................................................................................... 102 3.2.1.3 Facilities Management and Operations ....................................................... 105 3.2.2 Owners BIM Requirements ................................................................................ 106 3.3 Research Methodology ........................................................................................... 111 3.4 The formalization Process: An Iterative Approach ................................................ 114 3.4.1 Step 1: Identify Sources and Collect Data .......................................................... 115 3.4.2 Step 2: Identify Types of Owner Requirements ................................................. 119 3.4.2.1 Codes and Standards ................................................................................... 120 3.4.2.2 Organisational BIM requirements ............................................................... 121 3.4.2.3 Project Requirements .................................................................................. 123 x  3.4.2.4 Personnel Requirements.............................................................................. 124 3.4.2.5 BIM Requirements ...................................................................................... 126 3.4.3 Step 3: Identify Required Information ................................................................ 128 3.4.4 Step 4: Relate Digital and Physical Project Products with Owner Requirements and Organizational Processes and Technology ............................................................... 134 3.5 Discussion ............................................................................................................... 140 3.6 Conclusion .............................................................................................................. 142 Chapter 4: Compliance Review for Model-based Project Delivery ....................................... 145 4.1 Introduction ............................................................................................................. 145 4.2 Background ............................................................................................................. 148 4.3 Research Methodology ........................................................................................... 152 4.3.1 Current Practice .................................................................................................. 160 4.3.2 Model Structure and Content Analysis ............................................................... 163 4.4 Model–based Compliance Review ......................................................................... 165 4.4.1 Model Structure Compliance Verification .......................................................... 167 4.4.2 Model Content Compliance Verification ............................................................ 170 4.4.3 Design Compliance Review ................................................................................ 172 4.5 Validation of Identified and Used Model Queries .................................................. 177 4.6 Conclusion .............................................................................................................. 179 Chapter 5: Conclusion............................................................................................................. 181 5.1 Research Contributions ........................................................................................... 182 5.2 Validation ................................................................................................................ 186 5.2.1 Expert Reviews of Model Queries ...................................................................... 186 xi  5.2.2 Evaluation of Survey Results .............................................................................. 191 5.2.3 Application of Three-stage Approach for Model Evaluation ............................. 193 5.3 Practical Implications.............................................................................................. 196 5.4 Limitations of the Current Research and Future Research Directions ................... 197 Bibliography ........................................................................................................................... 199 Appendix A: Analysis of Expert Reviewers’ Responses ........................................................ 206 Appendix B: Experts’ Evaluation of Representativeness of Identified Queries ..................... 218   xii  List of Tables Table 1: Owner organizations investigated in this research vary in preferred FM strategies, and the scale of infrastructure they operate and maintain ............................................................ 22 Table 2: Three out of the four analyzed project BIMs analyzed were not required as BIMs for FM use by the project owners ................................................................................................ 23 Table 3: A total of eighty-seven queries were evaluated for representativeness by five experts . 32 Table 4: Facilities management (FM), and operation and maintenance (O&M) information requirements from the literature ............................................................................................ 51 Table 5: Examples from the technical guidelines regarding mechanical room and plumbing designs, and requirements for records drawings submission ................................................. 67 Table 6: Breakdown of interviewed personnel according to departments and FM functions ...... 69 Table 7: Information required by O&M personnel to perform maintenance, building systems monitoring, and manage assets .............................................................................................. 70 Table 8: Comparison of information required by O&M personnel, information tracked in the owner’s asset database, and information available within the model regarding a pump ....... 76 Table 9: Analysis of mechanical consultant’s design model for available component attributes using Revit schedules............................................................................................................. 78 Table 10: Inconsistent model component nomenclature and asset breakdown structure make it challenging to reuse model information, because they do not align with owner’s database . 80 Table 11: Summary of some concepts of IDM, IFC, and MVD................................................. 105 Table 12: Types of BIM requirements for industry, organization, and project scales ................ 108 Table 13: Overview of collected data ......................................................................................... 116 xiii  Table 14: Owner requirements are often documented in separate pieces of lengthy documents, which make it challenging to identify the complete set of requirements ............................ 117 Table 15: The facility management personnel that we interviewed for the two owner organizations we studied ...................................................................................................... 118 Table 16: Requirements landscape from the owners’ perspective and classification of owner requirements......................................................................................................................... 121 Table 17: Analyzed documentation relaying owner specific requirements ................................ 122 Table 18: Information required by O&M personnel to perform maintenance, building systems operation and monitoring, and manage assets ..................................................................... 125 Table 19: The computable requirements we identified from owner’s requirements documentation helped us identify what information to include in BIM in terms of spaces ......................... 131 Table 20: The computable requirements we identified from owner’s requirements documentation helped us identify what information to include in BIM in terms of equipment and systems ............................................................................................................................................. 133 Table 21: Categorization of required BIM information based on objects, property, and relations for mechanical systems ........................................................................................................ 134 Table 22: Developed two part framework demonstrates the relationship between the model, the physical product it represents, and the owner organization requirements ........................... 137 Table 23: Overview of collected data ......................................................................................... 154 Table 24: Twenty-seven personnel from various departments in two owners were interviewed to understand organizational processes, information requirements, and uses of information . 155 Table 25: Computable query examples, query categorization, and identified model queries to evaluate compliance with requirements ............................................................................... 159 xiv  Table 26: Example for a computable requirement for design review which is derived from owner's design requirements document. It is analyzed to identify the required model information, and the model query that will be used during compliance review .................. 167 Table 27: Categorization of identified modeling issues that lead to model structure issues ...... 168 Table 28: Examples of identified model structure issues related to modeling practice .............. 170 Table 29: Examples for missing geometric, and non-geometric project information identified with model content............................................................................................................... 172 Table 30: Identified computable queries from the owner requirements were turned into model queries which were later run on models using SMC to evaluate design compliance .......... 176 Table 31: Categorization of identified computable requirements which were used for model based design compliance review.......................................................................................... 177 Table 32: Highly representable (often checked) requirements that can be turned into computable queries .................................................................................................................................. 193 xv  Table of Figures Figure 1: Scale hierarchy treated .................................................................................................... 6 Figure 2: A framework for characterizing the alignment between organizational constructs ...... 10 Figure 3: The formalized iterative approach for the identification and characterization of owner requirements........................................................................................................................... 14 Figure 4: The formalized 3-stage approach to support model-based compliance verification (represented using IDEF0) ..................................................................................................... 17 Figure 5: Research contributions .................................................................................................. 18 Figure 6: This research used a three-layer research methodology focusing on the organization, the requirements, and the model analyses ............................................................................. 25 Figure 7: Proposed methodology for model based compliance review enabled by the use of rule sets which are turned into computable requirements ............................................................. 29 Figure 8: Overview of different methods used during data collection and analysis ..................... 42 Figure 9: Overview of UBC’s technology infrastructure illustrating the complexity and fragmentation of available tools to manage FM information, and the departmental silos .... 53 Figure 10: Process related with readying received records documents for users ......................... 57 Figure 11: Handed over pdf drawings are structured according to UBC naming conventions and drawings’ contents to make them accessible on the record retrieval system ......................... 58 Figure 12: Handover documents that are hundreds of pages long can be viewed only one page at a time by using the records retrieval system .......................................................................... 59 Figure 13: A number of applications have to be used together to make informed decisions for asset management within the Asset Stewardship Department............................................... 61 xvi  Figure 14: Process of gathering data from the field and populating asset database for existing buildings................................................................................................................................. 62 Figure 15: A number of applications have to be used together to make informed decisions when operating and monitoring building systems in the Building Monitoring Systems (BMS) Center ..................................................................................................................................... 64 Figure 16: There are installations of equipment in the CIRS mechanical room that are contrary to the owner requirements which lead to inefficiencies when performing maintenance during the operations phase. Looking up at the ceiling, the images show pumps which were installed at ceiling. Pumps are buried under a maze of pipes which block the access space for pump maintenance. ................................................................................................................ 68 Figure 17: Identified issues with the handover artifacts lead to problems related to usability of handover information during operations................................................................................ 74 Figure 18: The available AHU information within the model (as identified from model analysis using EcoDomus lifecycle information management application) falls short on representing the user-defined attributes tracked for the AHUs within the owners asset database ............. 77 Figure 19: Inconsistent information was identified between record drawings and the design model (from left to right; 2D plan drawing information, consultant’s mechanical design model representation, and as-build) ....................................................................................... 78 Figure 20: Identified modeling issues often lead to information reusability problems and miscomputation of model information .................................................................................. 81 Figure 21: Framework we developed to analyze organizational alignment, and compliance to requirements from the perspective of BIM implementation for FM ..................................... 83 xvii  Figure 22: The Henderson and Venkatraman (1993) strategic alignment model. Original image from Chan and Reich (2007) ................................................................................................. 85 Figure 23: O&M personnel access handover information through technology infrastructure that fails to comply with user requirements (such as accessibility), and process requirements (such as an asset database for maintenance management ...................................................... 88 Figure 24: Information within the investigated model is not sufficient to capture information tracked within the owner’s database, which is only a portion of the information required by the personnel .......................................................................................................................... 90 Figure 25: Methodology to understand the owner requirements, identify required information, and how they relate to BIM ................................................................................................. 115 Figure 26: Computable requirements were identified from the analysis of owner requirements129 Figure 27: Cross-functional process flow diagram showing information flow through number of FM functions ........................................................................................................................ 157 Figure 28: A list of consultants’ pdf drawings received by the owner at the time of building handover and later to be named and structured according to owner requirements to make them accessible to FM personnel ......................................................................................... 162 Figure 29: As build condition of the mechanical room has non-compliant characteristics to owner’s requirements for service/ maintenance space requirements which affect the performance of O&M activities during operations phase .................................................... 163 Figure 30: Model enabled design compliance review is based on identified computable owner requirements, turning such requirements into computable model queries, and finally running these queries on project models to identify non-compliant design characteristics .............. 164 xviii  Figure 31: Envisioned methodology for verification of model content and structure compliance, and design compliance review ............................................................................................. 165 Figure 32: Model queries developed from the owner’s design requirements for mechanical equipment accessibility help timely identification of design characteristics that effect maintenance performance before the start of the operations phase ..................................... 174 Figure 33: Running model queries that were based on the OSR helped identifying non-compliant design characteristics such as distance from the lab to the closest emergency shower ....... 175 Figure 34: Illustration of research contributions represented within separate chapters of the thesis ............................................................................................................................................. 184 Figure 35: Proposed methodology for model based compliance review enabled by the use of rule sets which are turned into computable requirements ........................................................... 187 Figure 36: Evaluation of eighty-seven queries' representativeness by five experts. Numbers on the outside of the radar chart indicates each evaluated query .............................................. 192 Figure 37: Pie chart visualizing the distribution of expert evaluations of the queries’ representativeness ................................................................................................................ 192   xix  Glossary  Alignment is the degree “of fit and integration among business strategy, IT strategy, business infrastructure, and IT infrastructure” (Henderson and Venkatraman, 1993).  Artifacts throughout this study are considered as a project’s handover artifacts including the project’s records set (drawings, manuals and specifications), and any digital project information such as CAD files and building information models. BIM as a term has been used within three different contexts as (1) Building Information Model from a product the “product” view (NBIMS, 2007), (2) Building Information Modeling from the “process” view (CIC, 2009), and (3) Building Information Management from the “lifecycle” view (Ex Con Draft V8.0, 2012). From the product view Building Information Model (BIM) is the digital representation of physical and functional characteristics of a facility (National Institute of Building Standards).  BIM is an enabler technology and also implies a structured process.  Compliance is defined as the level of compliance of the handover artifacts to owner requirements.  Computable requirements refers to information requirements about a facility that can be represented in and queried from a BIM using different methods and tools. The word computation refers to a broader meaning than just numerical computation, encompassing also semantic and boolean computation properties. For example computable requirements related to efficient use of mechanical pumps in a project during the operations phase may be related to the physical location or equipment information (performance, manufacturer etc.), xx  installation surface (e.g. ceiling, floor), installation height, positioning in relation to other building components or other equipment, or a combination of such information. Design characteristics are the design decisions related with a project such as decisions made about the layout of mechanical equipment in terms of equipment accessibility and maintainability. Facilities Management (FM) is “a hybrid management discipline that combines people, property and process management expertise to provide vital services in support of the organization in a rapidly changing world  (Then, 1999)”. According to Becker (1990) “FM is responsible for coordinating all efforts related to planning, designing, and managing buildings and their systems, equipment and furniture to enhance the organization’s ability to compete successfully”. Information handover can be summarized as “handing information over to organizations responsible for subsequent life cycle stages of the facility (Fallon and Palmer, 2006)”. This research focuses on the information handover to the owner after construction, to be used during the operation phase. Model alignment refers to the model’s degree of fit with the organizational processes and technology.  Operations and Maintenance (O&M) is “the decisions and actions regarding the control and upkeep of property and equipment. These are inclusive, but not limited to: 1) actions focused on scheduling, procedures, and work/systems control and optimization; and 2) performance of routine, preventive, predictive, scheduled and unscheduled actions aimed at preventing equipment failure or decline with the goal of increasing efficiency, reliability, and safety.” Sullivan et al (2010) xxi  Owner requirements are the set of requirements that are specific for an organization. In this research we categorize owner requirements as: codes and standards (national/ provincial/ consultant specific), the owner’s technical requirements, the owner’s project requirements, the often undocumented personnel requirements, and BIM requirements. Owner: the owner is the entity that a finished building project is handed over to after construction, and becomes responsible for the operation of the building.  Total Cost of Ownership (TCO) of facilities is the total of all expenditures that an owner will make over all of the planning, design, construction, operations and maintenance, renewal and revitalization, and disposal phases of a project (NRC, 2008). Users in this study are users of the handover information such as O&M personnel and the building trades.  xxii  List of Abbreviations 2D   Two Dimensional 3D   Three Dimensional AEC   Architecture, Engineering, Construction AEC/FM  Architecture, Engineering, Construction & Facilities Management AHU   Air Handling Unit BCF   BIM Collaboration Format   BIM    Building Information Modeling BIM   Building Information Model BMS   Building Monitoring System bsDD   buildingSMART Data Dictionary CIRS    Centre for Interactive Research on Sustainability CMMS  Computerized Maintenance Management System COBie   Construction Operations Building Information Exchange FM   Facilities Management IDEF0   Integration Definition Function Modeling Technique IDM   Information Delivery Manual IFC   Industry Foundation Class LOD   Level of Development O&M   Operations and Management OPR    Owner’s Project Requirements OSR   Owner’s Statement of Requirements SAM   Strategic Alignment Model xxiii  SMC   Solibri Model Checker TCO   Total Cost of Ownership WO   Work Order xxiv  Acknowledgements A long and interesting journey could not come to an end without the help, guidance, and support of many individuals. I am very much grateful to my supervisor, Dr. Sheryl Staub-French, for she has been there for me at each step of this long journey, for her continued technical and moral support. Thank you very much for your help, inspiration, dedication, and guidance. It’s been a great pleasure working with you.  I am very much thankful to all members of the research supervisory committee for their invaluable guidance throughout the research program. My special and cordial thanks go to Dr. Alan D Russell for his invaluable guidance and positive critique on various aspects of this research. I am also thankful to Dr. Rachel Pottinger for her constructive feedback and thought-stimulating questions in the committee meetings.  I thank Dr. Erik Poirier for his role in the two journal publications for reviewing and editing each manuscript multiple times. I am grateful to all professors and colleagues at the project and construction management group for their valuable discussions. I would like to express my warmest and deepest thanks to my parents and brother; Mrs. Zeliha Cavka, Mr. Ismail Faruk Cavka, and Mr. Bogachan Cavka, who have supported me morally along this journey as they have always done throughout my entire life. I am grateful for their support and unconditional love. I would also like to express my thanks and profound gratitude to my wife Mrs. Belgin Terim Cavka for her support and bearing with me throughout the long hours of work.  xxv  Dedication   To my parents and family For they taught me the meaning of unconditional love  1  Chapter 1: Introduction  The handover of asset information upon completion of a project is a critical step for owners. It is at this stage that the owner gets all the relevant information about the facility to support facilities management tasks throughout the facility lifecycle. According to the European Committee for Standardization, and ratified by the British Standards "facilities management (FM) is the integration of processes within an organization to maintain and develop the agreed services which support and improve the effectiveness of its primary activities"1. The International Facility Management Association (IFMA) defines FM as a profession that encompasses multiple disciplines to ensure functionality of the built environment by integrating people, place, process and technology. FM is divided into the core competencies and the core competency functions, which are also known as the FM functions. The core competencies, such as operations and management (O&M), technology, and project management, have higher level of management focus. The core competency functions, such as asset management and maintenance management, focus on tasks that support the core competencies. It is essential for O&M personnel to have access to quality project information to perform the core competency functions. Quality project information is important to efficiently and effectively operate and maintain equipment and systems in buildings, to extend the service life of equipment, to optimize maintenance activities, to achieve energy efficiency and to minimize labor time and downtime. However, experience has shown that handover is often given little attention and the obtained information is often erroneous, incomplete or unstructured. In addition to the issues related with project information, handed over buildings often have characteristics that are contrary to the                                                  1 http://www.bifm.org.uk/bifm/about/facilities (Accessed on April 20, 2017) 2  owner requirements. The building characteristics that are contrary to the owner requirements range from equipment accessibility issues, to non-compliance to owner space requirements. If not identified before handover, such issues with the design and handover artifacts lead to waste and inefficiencies during the performance of O&M activities, and building user dissatisfaction.  In the mid-1980’s, the Building Research Board of the US National Research Council suggested that integrated databases are potentially the most cost-effective way of managing facilities (Becerik-Gerber et al., 2011). Three decades later, Building Information Modeling (BIM) has emerged as a solution. Building Information Modeling (BIM) integrates the geometric and non-geometric information, and it is the digital representation of geometric and non-geometric facility information (BuildingSMART, 2007). It allows owners and project teams to leverage structured geometric and non-geometric project information to perform specific tasks and actions, and supports its reuse throughout an asset’s lifecycle. BIM offers great potential to generate, consolidate and maintain these integrated databases, which contain the relevant information to support operations and maintenance of a facility or portfolio of facilities. BIM has the potential for facility owners to address facility management through a project’s lifecycle and has been presented as a potential solution to current facilities management problems related to information exchange during handover, as well as facilities information management during operations.   Despite increased research efforts aimed at developing tools and technical capabilities to support BIM uses for owners, of which BIM for FM is perhaps the most discussed, widespread adoption is still relatively low around the globe (Kiviniemi & Codinhoto, 2014; Liu & Issa, 2014). Indeed, it has been reported that the utilization of BIM for FM, amongst other uses of BIM for owners, is falling behind design and construction applications of BIM (Akcamete et al., 3  2010). The issues underlying the slow rate of BIM adoption on the part of owners is multipronged. Becerik-Gerber et al. (2011) identified technology and process related, and organizational challenges in implementing BIM in the operation and maintenance processes. (Kiviniemi & Codinhoto, 2014) indicate that the difference in project based business and lifecycle management is one of the main challenges in implementing BIM in FM processes. The literature on barriers to implementing BIM for FM (Liu & Issa, 2014; Becerik-Gerber et al., 2012; Akcamete, Akinci, & Garrett, 2010; Forns-Samso, 2011; Sabol, 2008) indicate the complexity of the implementation process. In our own studies of facility owners, we observed the complexity of the implementation process as one of the most important barriers (Cavka et al., 2015).  The use of BIM by architects, engineers and contractors is increasing, and the resulting models that are created during the design and construction phases are now being provided to owners as part of the handover sequence of as-built facility information. BIM is becoming a delivery requirement for an increasing number of owner -operator institutional organizations because of its potential to address many of the challenges related to project delivery and handover, and to support O&M of the facility throughout its lifecycle. One of the areas where building information models promise improvements is the project information review for confirmation with the owners’ requirements. The project’s review is intended to ensure that the design complies with the owner requirements, such as reviewing a project’s handover artifacts to ensure that information required by owner is available within the artifacts. Owner organizations review the design of their buildings and provide feedback to the project team with further requirements, suggestions and questions regarding the project design and project information. The current review process of design documentation during design, construction and at the time 4  of handover is manual and prone to error. The review criteria are typically not formalized and are subjective based on the reviewers’ perspective. Reviews in the form of walkthroughs during construction often fail to capture all building characteristics that are non-compliant to owner requirements, since they evaluate the state of a building construction at a point in time. Any changes that are made after the construction review often remain unnoticed.  The uses of BIM for handover and FM are gaining attention from owners. However, there is still considerable work to be done to translate the BIM uses for FM from theoretical propositions into tangible outcomes. As large owner organizations transition towards BIM-enabled project delivery and start requiring digital models as project deliverables to support their organizational practices, significant adjustments are required on both the part of industry actors and the owner organizations that commission work (Crotty, 2011). With the methodology proposed in this thesis that defines the alignment needs, owners can formalize their BIM requirements in alignment with their business strategy, processes, and technology considering their organizational requirements. Therefore, owner organizations can relate the distilled requirements to the project models which will be required as part of the project delivery process. Then, evaluation of the fit of BIM and the use of models within their organizational contexts will be faster and easier. When the models comply with the owners’ requirements, the owners would be able to leverage these models to improve performance of FM functions during operations. While this may appear straightforward, this new process requires a key element: a valid source of truth, i.e. a well built and complete (to the degree necessary) BIM. 1.1 Thesis Scope and Outline  The dissertation investigates the challenges of leveraging BIM for FM from the perspective of owner organizations. The overall goals of this research are to understand the 5  organizational context for BIM implementation for FM, to understand the information requirements for FM BIMs, and to understand the levels of model compliance for a BIM for FM. The thesis is positioned within the world of facilities management, on asset and maintenance management functions, to the extent of information required, information representation, and interoperability of handover information for model-based delivery. The main focus is on the spaces, mechanical systems and equipment. Architectural systems such as building envelope, structural systems, electrical systems and components are excluded from the research. The chosen scope covers FM related information from both architectural and mechanical BIMs and therefore it enables investigation of the complexities of leveraging information from more than one consultant’s BIMs. The scope is also focused on operations and management mechanical equipment which has significant impact on total cost of ownership (TCO) of a project from an owner’s perspective. The chapters of this thesis are organized according to the scale of focus, starting with the industrial and organizational scale, narrowing the scale to the investigation of owner requirements from the project model scale, and finally focusing on BIM for a specific FM function (compliance review) at the model use scale (Figure 1). Each chapter of the research continuously narrows down the focus area starting from the larger organizational scale of alignment between organizational constructs, to the model scale of representation of owner requirements as part of project models, and finally to the model use scale focusing on the levels of reasoning to analyze model compliance with owner requirements.  This thesis is manuscript-based and consists of three manuscripts for Chapters 2, 3, and 4. Chapter 2 was published in Buildings in 2015. Chapter 3 was submitted to Automation in 6  Construction in September 2016, and has been accepted for publication. Chapter 4 is being finalized and will be submitted to Build Environment Project and Asset Management.   Figure 1: Scale hierarchy treated  1.2 Research Questions To fulfill the research goals, the research specifically seeks to respond to the following research questions: Research Question 1 What are the characteristics of organizational alignment for BIM adoption and implementation within owner organizations?  Despite the numerous benefits and the increasing availability of design and construction BIMs, the use of BIM during building operations remains significantly limited with very few owner organizations adopting BIM. Very little research has specifically looked at the transition to BIM and the scale of the effort required for large and diverse owner organizations. The reality is that implementing BIM in large owner organizations is a complex challenge. Each owner organization is a complex structure of departments, processes, cultures, networks of systems and 7  databases that are used to support functions, which are performed by people from different backgrounds and with different information needs. Adding to this complexity, each organization is also part of a network of other external organizations.  There is little hard evidence of the benefits of BIM in operations and maintenance activities (Becerik-Gerber et al., 2012), there is a lack of real life case studies on BIM in FM (Bosch et al., 2015), and the changes in work practices involved in shifting from traditional FM practices to BIM-based practices are not well-known (Kiviniemi & Codinhoto, 2014). As organizations become more complex, there is a greater need for information flow between the different parts of the system (Mcauley, Duberley, & Johnson, 2007). Previous studies have documented the potential benefits of BIM adoption for owners, such as improvements in work order processing. A number of recent research efforts addressed challenges, bottlenecks and implications in the implementation of BIM for FM in the operations stage (Bosch et al., 2015; Kiviniemi & Codinhoto, 2014), or investigated more specific issues such as BIM integration with maintenance information systems (Korpela, Miettinen, Salmikivi, & Ihalainen, 2015), the role of FM in developing data for handover at project completion (Lindkvist & Whyte, 2013), or value of BIM in managing spaces (Bosch, Arnold; Volker, L.; Koutamanis, 2015). Organizational process and technological changes come with challenges such as the use of technology by operators and trades people, as studied by Anne Anderson, Marsters, Dossick, & Neff (2012) and ECOCanada (2011). Anderson et. al. (2012) studied COBie and BIM implementation challenges within a university campus setting. Studies (Corry, Keane, O’Donnell, & Costa, 2011b; Crotty, 2011; East & Nisbet, 2010; East & Brodt, 2007; C. Eastman, Teicholz, Sacks, & Liston, 2008; Fallon & Palmer, 2006) also describe the issues related with handover information and current building information available for operations phase are. Liu et 8  al., (1994), Clayton et al., (1998), and Becerik-Gerber et al. (2012) categorize and describe different sets of information required for facilities management. The introduced alignment framework is developed based on the operational integration from the Strategic Alignment Model (SAM) by Henderson and Venkatraman (1993).  This research is based on the results of a multi-year embedded case study analysis of a large owner-operator institutional organization, which investigated the alignment of FM practices across the organizational and project contexts in relation to the owner’s requirements. The term “embedded case study” methodology is used to explain that there were individual case studies performed under the main umbrella of the main case studies of the two large owner organisations.  The “embedded case study” methodology is also used to convey that quantitative and qualitative methods are integrated as part of the research. This case study is unique in terms of the richness of the data collection and analysis methods used, the research approach investigating alignment across two interrelated contexts at the organizational and project level, and the focus on information in terms of understanding how facility information is informed by and affected by the organizational processes, technology used and information requirements.  The research objective was to examine current organizational practices in order to understand the potential, as well as the challenges, of transitioning from a paper-based to a model-based approach in handover and operations. The current state of practice was described in terms of handover, information management and facility management practices. The investigation of the current state of practice enabled us to better understand the gap between available and required information, processes and technology, and the enormous challenges owners face when considering the transition to BIM. 9   This rich and long term case study contributed to the development of a framework to characterize the alignment between organizational constructs (Figure 2) as a means to better understand the mechanisms required to transition from traditional to BIM-enabled FM practices. The organizational constructs consisted of: (a) FM processes and organizational structures, (b) information systems, managed FM related project information and its format within the organizational technology infrastructure, (c) project artifacts consisting of project handover documentation and project models, and (d) owner requirements. The framework provides a structure to evaluate organizational alignment using the identified organizational constructs. The framework allows owner organizations to better understand the potential alignment issues that arise when transitioning from a paper-based to a model-based approach in handover and operations.10   Figure 2: A framework for characterizing the alignment between organizational constructs   ARTIFACTSREQUIREMENTSORGANISATION OrganisationalStructure- Departmental breakdown- Resource deploymentFM ProcessesHandoverO&M- Asset Management- Maintenance Management TECHNOLOGYIT Infrastructure- Information- Databases- ApplicationsProcesses- Data collection- Database populationHandover Set- Drawings- Specifications- ManualsBIM- Model Content- Model Structure ALIGNMENTALIGNMENTALIGNMENTREQUIREMENTSRequired alignment between “FM processes” and “technology”, in order to support performance of FM tasksIT INNOVATIONSMARKETChange & CompetitionRequired alignment between “artifacts” and “available technology” to exchange, store and access building informationRequired alignment between “organisational processes and requirements” and the “artifacts” to ensure that artifacts represent all required informationCOMPLIANCEto requirements.As a metric to understand level of alignment at a given time11  Research Question 2 How can model requirements be represented from an owner’s perspective to enable BIM-based handover of facility information?   The prevalent discourse around identifying requirements for owner handover models focuses on the required attributes primarily related with the components of the design. From this point of view, Excel spreadsheets of component attributes are often seen as the critical representation of owners modeling needs. However, the complexity of implementation is in part due to the overall shift in practice that is required throughout a facility’s lifecycle and across the different departments that are involved in the delivery and management of a facility. The shift in practice is mainly related to how individuals generate, consume, manage and exchange facility information across its lifecycle (Crotty, 2011). For owners, who are consumers of facility information during the design and construction phases and then shift into an information generation and management role (while retaining their consumption role) during the operations and maintenance phase, the role owners play is crucial in defining and maintaining facility information throughout its lifecycle. Indeed, owners establish the facility’s requirements upfront (i.e. what are the needs, design criteria and the performance to be met), ensure compliance to requirements during design and construction, and require deliverables that accompany the facility to assist with operations and facility management. A significant barrier to BIM adoption for owners is the challenge of identifying and formalizing the information requirements needed to support model-based project delivery and asset management. The development of project requirements with the appropriate amount of detail is an important step since owner’s project requirements are considered to be the benchmark for all project related performance assessment. Establishing these requirements so that they inform not only the physical product being 12  delivered, but also its digital representation containing related project information is a significant challenge. Indeed, owner requirements, in the form of design guidelines, codes and regulations, technical manuals, etc. are not expressed in computable formats that lend themselves to BIM-enabled project delivery (Brucker & Nachtigall, 2005). Furthermore, efforts to generalize owner requirements fall short, given the highly contextual nature of the construction and asset management industries. There is therefore a need to provide robust processes through which owners can develop requirements that facilitate and take advantage of BIM-enabled project delivery and asset management, while also allowing them to check for compliance to these requirements through quality assurance and quality control methods.   Topics related to owners’ requirements in literature include requirements capture and formalization, and leveraging BIM for design reviews for compliance. These topics have been studied using different perspectives. Previous research focused on specific application areas, such as generating design rules based on design guidelines (C. Eastman, 2009), automated code checking (Choi & Kim, 2008), accessibility checking (Greenwood et al., 2010), code compliance checking (Hjelseth, 2015; Zhang et al., 2013), evaluation of owner requirements (Korpela et al., 2015; Mayo and Issa, 2014), owner requirements’ role in standardization  of data (Kensek, 2015), and evaluation of owners’ BIM requirements, such as Pennsylvania State University (CICR Program, 2013) and the University of Southern California (Kensek, 2015). Breaking a BIM into smaller pieces in Chapter 3 was based on (Hamil, 2010), (Volk et al., 2014), (Lee et al., 2015), and (Becerik-Gerber et al.,2012). Later the BIM breakdown was used to map how BIM, a proposed design solution, and the set of identified owner requirements relate to each other.  In responding to this second research question, on how model requirements can be represented, the research project set out to better understand the process of developing and 13  formulating BIM requirements to support the lifecycle of owner assets. This aspect of the research was based on a research project that investigated two large owner organizations in Canada to better understand the process of developing and formulating BIM requirements to support the lifecycle of their assets. As part of the research, an array of requirements documentation was analyzed, interviews were performed with numerous facility management personnel, and BIMs from four projects were analyzed.   The results of this research led to the formalization of an iterative approach to the identification and characterization of owner requirements, and the development of a conceptual framework that relates digital and physical products to owner requirements and organizational constructs (Figure 3). Specifically the investigation of owner requirements helped to develop an understanding of the required information content and its alignment with BIM.  Model information requirements were then exemplified through the identification of computable requirements. Finally, a framework was developed through which the relationship between digital (model) and physical (design solution) products with the owner requirements and organizational constructs can be described. The findings presented in this chapter: (a) identify the challenges associated with developing BIM requirements from the owners’ perspective and offer a solution to overcome them, (b) illustrate the complexity of identifying and formalizing information requirements from existing formal and informal requirements and the effort required to align these existing requirements to suit BIM-enabled project delivery and asset management, and (c) help to inform owners about how to think about the handover of digital facility models, and what to require in BIMs based on their specific needs, which is critical to responding to the industry shift towards model-based project delivery. 14   Figure 3: The formalized iterative approach for the identification and characterization of owner requirements Research Question 3 What are the levels of reasoning necessary to analyze a BIM for compliance with owner requirements (formalized in Research Question 2) as part of a BIM-based facility handover process? While benefits for owners are increasingly being documented, the challenges in initiating and sustaining the transition to BIM are considerable (Eastman et al., 2011). Among others, establishing clear and coherent BIM requirements, adjusting internal practices and developing capabilities to process and manage BIM-enabled project delivery are key in ensuring that the transition be successful. Among the many uses of BIM for owners, use of models to support digital handover of project information ranks consistently as highly desirable with automated review of design and compliance to technical and functional requirements slightly less important (Giel et al., 2015). These two uses in particular are seen as very important since the latter helps an owner to ensure s/he is getting the building he wants, while the former ensures s/he will be 1.   - To classify the landscape of owner requirements - To describe how digital product (BIM) relate to organization, and owner requirements - To formalize computable requirements - To identify model information requirements - To identify the landscape of owner requirements 15  able to efficiently and effectively operate and maintain it. The important process of design review, compliance checking and project handover information intake and processing have traditionally been paper-based and manual tasks. These tasks are onerous and error prone, and do not allow effective detection of design issues and validation of project information quality for handover. BIM has the potential to help owners overcome these challenges by enabling a more seamless exchange of project information between design, construction, and operations while supporting and providing opportunities for automated design reviews. While such uses of BIM from an owner’s point of view are gaining attention, there is still considerable work to be done to translate them from theoretical propositions into tangible outcomes. Based on upfront model-based design reviews, owners can influence design and make proactive decisions before handover, which could potentially lead to significant improvements with the performance of FM functions.   The points of departure for leveraging model for compliance review was based on previous research which focused on building permit approval (Hjelseth, 2015), model based code checking (Choi & Kim, 2008), accessibility checking (Greenwood et al., 2010), and safety checking (Zhang et al., 2013). Hjelseth (2015) identified that prescriptive rules could be directly converted into computable rules to support building permit application process. In our research, we used both prescriptive and descriptive owner requirements that could be represented in and queried from a model. However, Hjelseth’s compliance review was based on compliance with a BIM guideline, whereas the research included in this thesis focuses on identifying the requirements for a BIM, and the evaluation of compliance to owner’s requirements in the absence of a BIM guideline, which could in fact help to guide owners in developing their BIM guidelines. According to Hjelseth (2015) the quality of the BIM is of high importance for reliable 16  model checking, and it is measured as the structure and content of relevant information, which is consistent with our approach and findings. Previous research on model based design and compliance checking focused on model based reasoning (Korman et al., 2003; Zhang et al., 2013), rule checking and IFC based reasoning (Y. Lee et al, 2002.; Solihin et al., 2015; Eastman, 2011; Kiviniemi, 2014), and building product model requirements (Cavka et al., 2015). The information requirements for operations and maintenance was identified by Clayton et al. (1998), Klein et al. (2012) and Hjelseth (2015). Model based review was investigated from the perspective of BIM based model checking and code-checking based on rule sets (Lee et al., 2015), model structure issues (Solihin et al., 2015), code checking (Zhang et al., 2013), and safety checking (Lee et al., 2016).   In response to research question 3, this research project set out to better understand how large owner organizations that are undertaking a transition to BIM, can ensure compliance of both a facility and its digital representation in the form of model-based deliverables in the context of BIM-enabled project delivery and asset lifecycle management. The specific objective was to uncover and formalize the steps related with receiving, processing and checking project information against a set of technical and functional requirements and translating them into a model-based workflow. Two large public owner organizations were investigated to support this aim. The research project involved the study of the owner organizations and included project data from four major projects. Models and project documents were analyzed, including review comments, drawings and specifications as well as O&M manuals. Personnel from the two owner organizations were interviewed, including directors, project managers, technical support staff as well as operations and maintenance personnel. 17   The findings from this research project resulted in a 3-stage approach to model-based compliance verification (Figure 4): (Stage 1) model structure verification, which serves to identify any modeling issues that lead to miscomputation of model parameters, (Stage 2) model content verification, which relates to ensuring the availability of the required geometric and non-geometric information in a model, and (Stage 3) design compliance review, which involves a set of computable queries that are developed from extensive analysis of owner requirements and that can be represented in and queried from a project model. This staged approach provides a structure for the development of BIM requirements and informs areas of further investigation to extract and formalize computable queries. The findings highlight the potential of model based project delivery for compliance review of both project information and the proposed design of a facility. These results speak to the significant opportunities for owners to enhance the efficiency and effectiveness of design review and facility handover processes, and to improve the quality of both the facility and the supporting facility information such that a facility can be properly maintained and operated.  Figure 4: The formalized 3-stage approach to support model-based compliance verification (represented using IDEF0)  18  1.3 Research Contributions The contributions of this dissertation are summarized in this section, as illustrated in Figure 5. Chapter 5 provides a more detailed discussion of these contributions and the validation completed.  Figure 5: Research contributions Research contribution 1 - Formalization of a framework to evaluate the alignment between the organizational constructs and the project models: Chapter 2 investigates the current state of practice and the alignment of the organizational context with the handover artifacts. Using the strategic alignment model (Henderson & Venkatraman, 1993) as a point of departure, the introduced framework focuses on evaluation of alignment between organizational infrastructure and processes, and information systems infrastructure and 19  processes. The framework leverages project artifacts (including BIM) as a medium to evaluate alignment within the organizational context. Research contribution 2 - (a) Identification and classification of owner requirements, (b) Formalization of a methodology to identify model requirements based on the types of owner requirements: Chapter 3 investigates the complex landscape of owners’ formal and informal information requirements. I identified and classified owner requirements and developed a process to identify computable requirements based on the different types of owner requirements.  Research contribution 3 - Formalization of 3 stage approach to analyse a model for compliance with owner requirements: Chapter 4 describes the three levels of reasoning required for compliance review consisting of model structure verification, model content verification, and design compliance review.  1.4 Methodology  A research project was conducted over a three-year period involving case studies of two large owner organizations to investigate how owners can formalize their requirements to support BIM-enabled project delivery and asset management. Case study research is appropriate when investigating contemporary phenomenon in its real-world context (Yin, 2014). The research methodology is similar with Building Smart COBie case studies in terms of analysis of work processes using process and information flow diagrams, and analysis of owners’ technology infrastructure to identify required information. This methodology is also similar to Becerik-Gerber (2012), Becerik-Gerber (2011), Berard & Karlshoej (2012), and Forns-Samso (2011)  in terms of the focus on large institutional owner organizations to understand FM processes, required information, and operational use of FM information. However, instead of focusing on 20  only one FM process, one set of technology, or investigating either models or documents, this research followed a multi-faceted approach, focusing on multiple FM processes, numerous FM technologies, and consisting of two case studies of owner organizations across numerous BIM projects.   The first case study involved a large Canadian university. The focus was on the building operations department, which is responsible for the operations and maintenance of all non-residential buildings on campus. O&M covers a number of FM functions but the focus of this research was on asset management, maintenance management, records management, and facility information management. The building operations department is responsible for 225 core university-owned buildings, with a total gross floor area of 810,119 m2. The organizational structure was mapped and analyzed to understand the roles and responsibilities of the different departments. FM processes were mapped to understand the required steps and information exchanges to perform FM functions. The organizational technology infrastructure was mapped and analysed to understand the managed FM information, its structure and how it relates to model content and information structure. The interviews, shadowing, and walkthrough activities with the O&M personnel helped to understand the current FM processes, required information to perform FM functions, issues with current information technology, information interaction requirements of personnel, and building characteristics that negatively impacted the performance of O&M functions. This multi-faceted analysis led to the identification of different sets of requirements that make up the owner requirements for this organisation. Three university projects and their models were analysed from the perspectives of information content and modeling to evaluate model fit for FM use. Revit schedules, Navisworks, Solibri Model Checker, and EcoDomus (a lifecycle information management tool) were used to investigate the project 21  models. Technical guidelines documents and interview transcriptions were analysed extensively to identify owner requirements that can be turned into computable requirements that can later be queried in project models. Further analysis of the identified computable requirements resulted in the classification of properties and relationships related to model objects, and finally the identification of required model information. The final step of the analysis was to develop an understanding of how each part of the organisation, requirements, and BIM relate to each other in the context of model-based project delivery.   The second case study involved the agency responsible for delivering and maintaining public infrastructure for a provincial government in Canada. The agency is responsible for infrastructure planning, building and managing government-owned infrastructure, which includes health facilities, schools and other public infrastructure in the province. The agency is responsible for over 1,600 buildings, representing an approximate total gross floor area of 2,330,000 m2. Table 1 below compares the two case study organisations from the organisational FM strategies and the scale of infrastructures they operate and maintain. The research focused on the Capital Planning Division and the Properties Management Division. Data was collected through interviews with personnel from three divisions, analysis of requirements documentations (technical guidelines, owner project requirements), and analysis of organizational technology infrastructure and managed information. A large institutional project model was analysed to identify the available information and compare it with the identified requirements. The computable requirements identified as a result of the requirements analysis were combined with the list of identified requirements from the first case study to develop a richer representation of model information requirements and to explain the relationships between organisation, requirements, and BIM. 22  Table 1: Owner organizations investigated in this research vary in preferred FM strategies, and the scale of infrastructure they operate and maintain  Canadian University Government Agency FM Strategy Performs FM functions using mainly own workforce Subcontracts the performance of FM functions Managed Building Types Institutional (non-residential) and residential infrastructure on campus Health facilities, schools and other public infrastructure in the province Scale (# of managed buildings) Responsible for 225 non-residential buildings Responsible for over 1600 buildings Scale (m2 of managed space) Total gross floor area: 810,119 m2 Total gross floor area: 2,330,000 m2 Both owner organisations investigated as part of the case studies are interested in leveraging BIM for operations phase; however, they are at the initial stages of investigating BIM processes and technologies and do not have established BIM requirements. The investigated university project models were design and construction models, and the production of project models for FM purposes was not required by the owner (Table 2). The BIM for the provincial government project was produced for design and construction purposes but was also considered a test case for the provincial government to better understand how BIM could be implemented within their FM practices.   23  Table 2: Three out of the four analyzed project BIMs analyzed were not required as BIMs for FM use by the project owners Project Reason for using BIM Models developed by Owners FM BIM requirements University Project #1 Design BIM Architectural, structural, mechanical consultants None University Project #2 Design and construction BIM Architectural, structural, mechanical consultants and mechanical contractor None University Project #3 Design and construction BIM with one part of the model developed further for use during operations phase Architect, structural, mechanical consultants and BIM consultant None Provincial Government Project Design and construction BIM with the intention to be used during operations phase Architectural, structural, mechanical, electrical consultants. Structural, mechanical, electrical contractors. Requirements for spatial validation  Research activities for the two case studies of owner organizations consisted of three layers (Figure 6).  The first layer focused on the Organization where the FM processes, organizational structures and the technology infrastructure were mapped, and project records documents were analyzed. In the second layer, a diverse set of artifacts that represent aspects of owner requirements, including codes and standards, technical requirements, project requirements, personnel requirements and existing BIM requirements were collected and analyzed. In the third layer, the model content and structure of project BIMs for the two case study organizations were analyzed. The duration of the research project can be attributed to the aspects of the research methodology, including the use of two different organizations as case studies, the number of methods used for data collection, and the thorough analysis of the collected data.   24  1.4.1 Organizational Context  The organizational context refers to the characteristics of an organization and its alignment with BIM-based data and processes. In order to understand the organizational context, I investigated numerous FM functions including building and information handover, records management, asset management, and maintenance management, as well as the technology infrastructure according to the organizational departments it supports. Mapping the FM processes helped to understand the current practice, identify the bottlenecks and inefficiencies, and evaluate possible BIM implementation areas to eliminate bottlenecks or improve performance. Mapping the technology infrastructure of applications, databases and information kept within these databases helped to understand the infrastructure available to support information flow within the organization, and identify the silos of information in departments. As a result of the investigation of the organizational context, I developed an understanding of the reasons behind the gap between what is currently available and what is required to overcome the current challenges and inefficiencies. 25   Figure 6: This research used a three-layer research methodology focusing on the organization, the requirements, and the model analyses26  1.4.2 Requirements Analysis: Owner Requirements, O&M Personnel Requirements, Handover Documents  The technical guideline documents from two case studies were investigated to understand owner requirements for system design, performance, and installation, and also the requirements for handover process and handover information content. Interviews were conducted, transcribed, and analyzed with nine people from four departments within the Building Operations department from the Canadian university, and also with seventeen people from five different departments from the provincial government agency.  These interviews informed my understanding of the current processes, available technology to support these processes, and information requirements of different personnel in the organization. A project walkthrough was performed and documented to identify operational and maintainability problems and to evaluate the maintainability of CIRS mechanical systems and equipment. A shadowing activity involving a millwright during his daily routine was used to understand how service requests are handled, how the maintenance work is performed, and what information and tools are available to complete work. Personnel requirements regarding the technology for accessing information were also identified through the interviews. Technical guidelines documents were analyzed, and interviews, walkthrough and shadowing activities were performed to understand FM processes, available and required information, and the available technology for managing information.  1.4.3 Project Context  An embedded case study was performed on a University building project to understand building information handover, O&M processes, and building information and records management at the project level.  The project handover documents were analyzed, consisting of 2D drawings, manuals and specifications. The accuracy and completeness of the handover 27  documents were investigated and compared to the as-built conditions. The consistency of information between drawings, manuals, and specifications was investigated. Accessibility and reusability of handover documents within the organizational technology infrastructure were also investigated. BIM project models from three projects were analyzed to understand the model content and structure for current design and construction BIMs. Analysed project models were created by the project consultants to match the traditional requirements for design and construction information and its representation. The models for the government agency project were created by the design consultants according to the owner’s intention to leverage models for FM. The model analysis process involved investigating the model content for availability of the geometric and non-geometric information required by the owner and the O&M personnel (i.e., investigation of availability of AHU geometry and required attributes about AHU, such as air filter information). The model structure was also investigated to understand the model characteristics that enable accurate and efficient information exchange with FM information management tools (i.e., equipment-system-space relationships within the model). During model content evaluation, Revit schedules, COBie outputs using the Revit COBie Toolkit, the Ecodomus life cycle information management tool, and Navisworks visualizations were used. The model outputs were investigated to evaluate model information availability and the reusability of the available information by the owner. More specifically, the alignment of the model context with organizational processes and technology infrastructure, and its compliance with owner and personnel requirements was evaluated. 1.5 Validation Through Expert Reviews  Each outcome of the three steps explained in the previous methodology section (organization, requirements, and model analyses) informed one another, and they were not 28  performed in isolation.  This research proposed a methodology for BIM based compliance review approach for project delivery (Figure 7). The understanding and development of model compliance methodology was informed by the performed organizational and requirements analyses.  Model based compliance review methodology presented at a specific ‘use’ level in Chapter 4, is also a verification of each step of thinking that led to the creation of this dissertation. While the initial step focuses on the organizational context and evaluating the alignment of the project artifacts within this context according to requirements (Chapter 2), the following step focuses on the requirements (Chapter 3), leading to the final step (Chapter 4) leveraging requirements for model compliance review.  The proposed model review methodology in Chapter 4 is based on running rule sets on project models to identify non-compliance to model and design compliance requirements. The rule sets are further explained in Chapter 5. The proposed process consists of three stages; model structure verification, model content verification and design compliance review. Query based rule sets, which were identified in this research are at the heart of the model compliance verification and design compliance review. The rule sets were based on model queries that were developed from the analysis of owner requirements, and identified computable requirements. However the research team had to make sure that the queries that make up the rule sets were representative of the queries used by experts in the domain. This section summarizes the validation method of the identified computable owner requirements from a representativeness perspective through expert reviews.  29   Figure 7: Proposed methodology for model based compliance review enabled by the use of rule sets which are turned into computable requirements  The validation of the research is based on the representativeness of the identified queries for BIM based model and project compliance review, and the applicability of the model based compliance review process using the queries. Since the owner requirements are large sets of information and it is an enormous challenge to identify a complete set of model queries for the set of owner requirements, the validation was based on representativeness of the identified model queries rather than the completeness of the queries. The completeness of the identified queries was not validated since the owner requirements cover a wide range of building components and systems. It was not practical to gather a complete set of queries in the period of this research since new requirements are often posted by owner organizations. The investigation of the case studies indicates that new requirements are posted by owner organization on an ongoing basis. According to one interviewee, the current version of the Technical Guidelines may become outdated by the time someone prints them out from the organization’s web site. The identification of the queries is based on the analysis of four project BIMs using multiple tools and methods, analysis of investigated organizations’ formalized requirements, requirements from analysis of the performed interviews with the FM personnel, and owner’s BIM requirements 30  from the literature. In this sense validation of the queries is also supported by the grounded research approach, since the identified queries are based on analysis of actual cases and analysis of requirements from two large owner organizations.   Model structure and content compliance review criteria were based on experience gained from model analysis of four project models. Specifically during the analysis of models using life-cycle information management application, significant model preparation was required to structure model information and add required FM related content to the models. Model structure related issues were causing mis-computation or not being able to compute model information because design and construction models were lacking the geometric and non-geometric information required to perform FM functions. The model analyses performed led to an understanding that in order to perform design compliance review, a model had to be first evaluated for model structure and model content verification.  To validate the representativeness of the identified model queries, the research team performed a review panel from five domain experts. The experts were three project managers from the Project Services Department, and the Asset Stewardship Superintendent and the Maintenance Technical Specialist from the Building Operations from the large Canadian university. Experts were intentionally selected from different departments and with different responsibilities in order to capture the varying perspectives on project delivery and FM practices within the context of a large owner organization. The experts were provided with a list of identified queries before the review. Validation survey mock-up is based on a five-point Likert scale to rate the applicability of the compliance checking method that was presented. The experts were asked to rate the list of queries from not representative to highly representative. During the review sessions, a brief introduction of the research was provided on the approach for evaluation 31  of model and design compliance through predefined model queries, and also on what the experts were asked to rate. Later the experts were asked to rate the identified model queries based on representativeness. Feedback from the experts was requested at the end of the review sessions by opening the floor for a semiformal discussion, which provided insight into the use, and possible benefits of the introduced queries and process of using them. The review panels started with a summary of the conducted research. The experts were asked to evaluate whether the queries developed from the set of identified computable requirements were representative of the information that is reviewed or checked during design reviews and at handover. The representativeness survey is based on a subset of requirements identified during the analysis of project models and the analysis of owner requirements. The experts were asked to rate the importance, and the frequency of using such queries for the compliance review process. Following their review of the queries, the experts were informally interviewed; • to obtain their insights on the queries and the method of compliance checking • to comment on any items that are seen as problematic or desirable by the experts  • to compare the current compliance review process with the model based process • to talk about the ease of using the query and model based process to identify noncompliance, the required expertise to use the process, and required time for model and query based compliance review compared to current manual methods  • to comment on the usefulness of the approach, applicability in practice, their suggestions for improvement, and whether they see anything as problematic or desirable in our approach 87 queries which were related to 37 model and design conditions (Table 3) were evaluated for representativeness by the participating five experts. Overall results from the expert review of the 32  queries reflect that 76% of the identified computable queries were representative of the “often” (54%)  and “sometimes” (22%) used queries. 54% of overall queries are highly representative (often checked), 22% are somewhat representative (sometimes checked), 13% are of low representation (rarely checked), 3% are never checked during a compliance review, and 8% of the queries were marked as not-applicable by the experts. More detailed information regarding the results of the validation is included in Chapter 5. Table 3: A total of eighty-seven queries were evaluated for representativeness by five experts 1 A Orientation of a room  within a building 2 A B C D Wall fire rating of a wall in a specific  room type Availability of equipment required in a room type Availability of a not-permitted ceiling type in a room type Access condition of a specific room type 3 A Checking availability of required floor material in a room 4 A B C D E F G H I Checking space usage (e.g. room to be used for only one purpose) Checking the availability of equipment required in a room type Door swing direction of a room type Door size of a room type Location of a room type  Size of a room type (e.g. 40 sqm) Dimension of a room type (e.g. 5m x 4m) Availability of electrical equipment (outlets) required in a room type Availability of furniture required in a room type 5 A B C Representation of access space to equipment Representation of access space to remove and replace equipment Representation means of lifting equipment heavier than certain weight (e.g. 500lbs) 6  A Design requirement of a building component triggered by certain conditions  Availability of required cages for ladders to access equipment and roofs (applicable in certain cases) 7 A B Accessibility of a room type (public vs personnel access) Availability of space required for moving the largest equipment from a room type 8  A B C Equipment installation requirement regarding space: • Service space • Disassembly space • Space for removal 9 A Checking availability of equipment components that allow for easy maintenance  10  A Equipment that is mounted to a certain surface to have special pads  Checking availability of house pads for base mounted equipment 11  A B C Specifications of a door type (e.g. access doors): • Door material • Door installation • Door location (so that concealed items are accessible) 12  A B Checking availability of restricted plumbing component within a room type. • Check floor drains in private washrooms (allowed only in public washrooms where automatic flushing devices are used) 33  C Checking whether all sanitary sumps are vented to outdoors Check if all plumbing equipment requiring maintenance as frequent as one year are readily accessible 13 A Check if equipment requiring periodic maintenance is mounted in locations where access requires using ladders 14 A   B C  D E   F  G Check for safe access requirement for servicing and replacement for HVAC equipment  System and equipment types that are required to contain specific components • Check if VAV systems have reheat coils at all VAV boxes • Check if AHUs have heating or preheat coils Check air filter sizes in HVAC systems with UBC required sizes Check air filter sizes in Fan Coil Units with UBC required sizes  Component orientation according to other building components • Check for radiant heating panels that face windows Equipment specific mounting surface requirements: • Check for window mounted air conditioners and exhaust fans (not acceptable) 15  A B C Check for spatial proximity requirements: • Component to component (e.g. roof drains not to be located close to column and beams) • Component to space (e.g. air intake louvres to loading docks, fume hood exhausts, generator exhausts) • Component to elevation (e.g. outside air intake louvres to be located as high as possible above grade) 16 A B Check if water closets in public areas are floor mounted, urinals are wall-hung, partitions are floor mounted Check if plumbing fixtures are from same manufacturer (preferred) 18 A Check weight and type of the compressors in the refrigeration system. • Weight ≤ 5 tons shall be hermetic type 19 A B Check fan coils/ DX coils positioning in condensing units and cooling towers, to ensure access to service all components  Check outdoor condensing unit location • Not adjacent to fume hood areas or 10ft from roof edge without guard rail 20 A B Check if there is equipment in ceiling above communication equipment in server/communication rooms  Check if cooling towers over 8’ have service platforms with permanent ladders 21 A Check if all interior air terminal units in air conditioned buildings have reheat coils (unless the engineer demonstrates it is not required)  22 A B  C Check AHUs for sufficient access to all components  Check AHU’s clearance adequacy for coil replacement without necessity to dismantle adjacent equipment or building component  Check if AHUs have heating or preheat coils 23  A B Completeness of geometric and non-geometric model content according to requirements  Availability of the least amount of information required for ALL components  Availability of required information for EACH system component 24  A Checking information in title blocks  Availability, completeness, and nomenclature  of information 25  A Required building systems’ availability in the model  E.g. checking whether all required plumbing systems are available in the model   A B Compliance of space information with OSR  Number of required rooms vs available rooms  Required room areas vs provided room areas 26  A B C Maintainability of mechanical rooms  Elevator access to floor  space to remove the largest equipment from the room and the building  door sizes and corridor clearances to fit the largest equipment 27  Accessibility of mechanical equipment 34  A B C  Clearance around equipment  Clearance of access space for removal  Installation height of equipment 28  A  B Identification of system components located in restricted areas  Water containing pipes (except for sprinkler pipes) running through or beside exhibition and collections areas  No floor drains in private washrooms 29  A B  C Compliance with design and installation requirements of building components  i.e. installation surface for water closets wall or floor mounted  i.e. check for concealed piping systems and equipment: not allowed in trenches, shafts, furring, and suspended ceilings   i.e. check for ceiling mounted exhaust fans installed directly above meeting and conference rooms (unwanted) 30  A B Identify material properties of building components  i.e. checking material for sprinkler pipes  i.e. check air handler filter sizes for compliance 31  A  B   C Compliance with proximity requirements  Space to space i.e X room to be located in the ground floor and close to loading bay  Component to space i.e. emergency eyewash and or showers proximity to areas where chemicals are used i.e. whether all air handling equipment is located indoors in mechanical rooms  Component to component i.e. proximity of air intake and exhaust louvers, to prevent exhaust air from the HVAC system from being re-circulated 32  A B Compliance with requirements for different room types  Checking wall assembly, FR, ceiling type, floor material, door size and opening direction of rooms  Checking location of certain room types i.e “The preferred location for Electrical Rooms is on North or East exterior building wall” 33  A Compliance with (other) owner requirements  Checking to see if same brand or manufacturer was used for each specific equipment type 34  B Coordination of consultant & subcontractor models  clashes between consultants’ designs 35  A B Investigation of system/ component  nomenclature (naming conventions)  Compliance with owner databases  Naming each instant differently 36  A B C Investigation of assignment of equipment – system – space relationships  Equipment belongs to system  System serves to space  Equipment is located in space 37  A Investigation of the floor to floor height identification  So that equipment can be assigned to the level it is serviced from  87 Total number of queries   35  1.6 Reader’s Guide  Readers are reminded that this thesis follows the manuscript-based thesis guidelines. Efforts have been made to minimize repetition of content from chapter to chapter and to present the entire content in a unified and coherent form. The remainder of this thesis is organized as follows:  Chapter 2 investigates the current state of the analyzed large owner organization’s context from the perspectives of FM processes and technologies, requirements, and handover artifacts. In section two a framework to investigate the alignment between organization, technology and handover artifacts (handover set, and project models) is presented, and the results from investigation of a large Canadian university are presented.  Chapter 3 focuses on complexity related with the identification of owner requirements. The landscape of owner requirements are identified and categorized based on the analysis of two large owner organizations. Later model information requirements identification based on computable requirements is described. To achieve this, first computable requirements are identified from a thorough investigation of owner requirements, and the requirements that could be represented in and queried from a project model were selected. This is followed by the description of how the organization, requirements, and project models relate to each other and a mapping of the pieces of an organization, requirements and a BIM is presented.  Chapter 4 focuses on compliance review from a model-based project delivery perspective. The previously identified computable requirements are leveraged to review compliance at three levels; model content level, model structure level, and design compliance level. This research focuses on proactive solutions to current issues, rather than proposing methods to fix what is already wrong during the operations phase. Rather than focusing on the 36  operations phase itself, chapters three and four focus on actions to be taken during the design and construction phases, in order to prevent possible issues during the operations phase.  In Chapter 5, the conclusions are presented, focusing mainly on the contributions of this research, and the validation studies conducted. Practical implications of this research are highlighted, some limitations of the research are described, and recommendations for future research are suggested.   37  Chapter 2: Evaluating the Alignment of Organizational and Project Contexts for BIM Adoption: A Case Study of a Large Owner Organization2   2.1 Introduction  Building information modeling (BIM) has been presented as a potential solution to current facilities management problems related to information exchange during handover and facilities information management during operations. However, implementing BIM in an owner organization is a complex challenge that necessitates reconfiguration of work practices and internal structures to fully realize the benefits. Owners are often unsure about how or whether they should go through the challenges related to implementation. Although previous studies have documented the potential benefits of BIM adoption for owners, such as improvements in work order processing, very little research has specifically looked at the transition to BIM and the scale of the effort required for large and diverse owner organizations.  The handover of a building and its asset information upon completion of a project is a critical step for owners. It is at this stage that the owner gets all of the relevant information about the facility to support operations and maintenance (O&M) throughout the facility’s life cycle. The quality, efficiency, and reliability of the information handover process are therefore critical for facility managers to achieve the performance, sustainability and economic requirements of facility operations. The operational phase of a building represents as much as 80% of the total cost of ownership (National Research Council, 1998) so these are considerable economic and                                                  2  A version of chapter 3 has been published. Cavka, Hasan, Sheryl Staub-French, and Rachel Pottinger. “Evaluating the Alignment of Organizational and Project Contexts for BIM Adoption: A Case Study of a Large Owner Organization.” Buildings 5.4 (2015): 1265–1300. Web. 38  environmental concerns for building owners. Information handover practices, however, are often inefficient and error-prone which limit the utility of facility information and hinder the performance of O&M during the operations phase. Previous studies and our own observations confirm that handover and facility management practices suffer from numerous challenges, including: • Poor information fidelity: Submitted handover artifacts contain errors, and the traditional approach requires huge additional investment of resources to correct the artifacts to a sufficiently high level of accuracy (East & Nisbet, 2010). When up-to-date information is missing, additional costs are incurred due to searching, validating and recreating information (Fallon & Palmer, 2007). • Poor interoperability: The format of handover information is inadequate, not allowing others to use information effectively (East & Brodt, 2007), and it does not lend itself to everyday use, and contains information in a format that is not conducive to computerized analysis (Corry et al., 2011a). Inefficient interoperability cost the construction industry more than $15.8 billion a year (Gallaher et al., 2004). Two-thirds of this cost is borne by owners/operators, and 85% of owners’ and operators’ interoperability costs are incurred during the O&M phase (Gallaher et al. 2004). • Poor building and maintenance performance: Sustaining an increasing number of buildings and rising energy consumption levels rests largely on the possibility of maintaining and operating increasingly sophisticated building equipment, and increasingly complex, and inter-dependent building systems. In current practice, there is little or no systematic correlation between design intent and building operation (Corry et al., 2011), and buildings are not performing as expected. Eighty-five percent of 39  complaints related to comfort and high energy consumption are caused by handover of heating, ventilation, and air conditioning (HVAC) systems and maintenance issues (Borsboom, 2015).  BIM has the potential to address these challenges by providing a data-rich, non-redundant information repository of facility information that is capable of supporting a broad range of FM functions. BIM has long been claimed to bring significant benefits to FM to “improve a buildings’ performance and manage operations more efficiently throughout their life-cycle ” (Codinhoto & Kiviniemi, 2014). Many studies have documented the potential benefits of BIM in terms of reducing redundant data collection and data re-entry (National Research Council NRC, 2012), enabling better information exchange between project phases (Wu & Issa, 2012), supporting certain O&M functions, such as work order management and space planning (Fallon & Palmer, 2007; Foster, 2012), and improving access to information during operations (Forns-Samso, 2011). Progressive owners have also recognized the potential for capturing the information needed to fine-tune building system performance, establish appropriate maintenance practices and schedules, and evaluate the feasibility of proposed expansions or renovations (Fallon & Palmer, 2007).  Despite these numerous benefits and the increasing availability of design and construction BIMs, the use of BIM during building operations remains significantly limited with very few owner organizations adopting BIM. The reality is that implementing BIM in large owner organizations is a complex challenge. Each owner organization is a complex structure of departments, processes, cultures, networks of systems and databases that are used to support functions, which are performed by people from different backgrounds and with different information needs. There is also little hard evidence of the benefits of BIM in operations and 40  maintenance activities (Becerik-Gerber et al., 2012), there is a lack of real life case studies on BIM in FM (Bosch, Arnold; Volker, L.; Koutamanis, 2015), and the changes in work practices involved in shifting from traditional FM practices to BIM-based practices are not well-known (Kiviniemi & Codinhoto, 2014). This chapter presents the results of a long-term embedded case study analysis of a large owner-operator institutional organization that investigated the alignment of facility management (FM) practices across organizational and project contexts. The research objective was to examine current organizational practices in order to understand the potential, as well as the challenges, of transitioning from a paper-based to a model-based approach in handover and operations. The goal of was to better understand what is involved in the transition from a paper-based approach to a BIM-based approach in handover and FM information management. I performed a long-term multi-year embedded case study analysis of the work practices of a large owner-operator institutional organization. I investigated the alignment of FM practices across the organizational and project contexts in relation to the owner’s requirements. I describe the current state of handover, information management and facility management practices. The rich case study contributed to the development of a framework to characterize alignment between organizational constructs, available technology, project artifacts and owner requirements as a means to better understand the mechanisms required to transition from traditional to BIM-enabled FM practices. The investigation of the current state of practice enables me to understand the gap between available and required information, processes and technology, and to better understand the enormous challenges owners face when considering the transition to BIM.  The case study in this chapter is unique in terms of the richness of the data collection and analysis methods used, the research approach investigating alignment across two interrelated 41  contexts at the organizational and project level, and the focus on information in terms of understanding how facility information is informed by and affected by the organizational processes, technology and requirements.  The next sections describe the methodology and the literature review. Subsequent sections focus on the case study and the analysis of alignment across the organizational and project contexts. 2.2 Methodology  In this research we performed a long-term case study analysis of the University of British Columbia (UBC), a large owner-operator organization that operates and maintains its infrastructure using its own workforce. UBC’s Building Operations Department is responsible for 225 core University-owned buildings, with a total floor area of 810,119 gross square meters. We specifically focused on the Building Operations Department responsible for O&M of educational buildings within UBC. According to the Whole Building Design Guide, O&M “typically includes the day-to-day activities necessary for the building and its systems and equipment to perform their intended function”. O&M covers a number of FM functions but the focus of this research was on asset management, maintenance management, records management, and facility information management.  We used different methods to gather information on UBC and developed a deep understanding of the owner organization’s current FM practices from three distinct perspectives: (1) the organizational context; (2) the owner requirements; and (3) the project context (Figure 8), as described below.42   Figure 8: Overview of different methods used during data collection and analysis43  2.2.1 Organizational Context  The organizational context refers to the characteristics of an organization and its alignment with BIM-based data and processes. In order to understand the organizational context, we investigated numerous FM functions including building and information handover, records management, asset management, and maintenance management, as well as the technology infrastructure according to the organizational departments it supports. Mapping FM processes helped to understand current practice, identify bottlenecks and inefficiencies, and evaluate possible BIM implementation areas to eliminate bottlenecks or improve performance. Mapping technology infrastructure of applications, databases and information kept within these databases helped us understand the infrastructure available to support information flow within the organization, identify the silos of information in departments. Investigation of the organizational context helped us understand the processes utilized to perform O&M tasks, technology infrastructure available to support processes, the organizational structure, and the information flows across the organizational network. As a result of investigation of the organizational context we developed an understanding of the reasons behind the gap between what is currently available and what is required to overcome the current challenges and inefficiencies. We discuss the current organizational context further in Section 2.4.1. 2.2.2 Requirements 2.2.2.1 Owner Requirements  We investigated the UBC technical guideline documents to understand owner requirements for system design, performance, and installation, and also requirements for handover process and handover information content. This led to a better understanding of the gap between what was required and what was delivered at the end of construction. 44  2.2.2.2 O&M Personnel Requirements  We conducted, transcribed, and analyzed 12 interviews with nine different people within the Building Operations department to understand current processes, available technology to support these processes, and information requirements of different personnel in the organization. We performed and documented Center for Interactive Research on Sustainability3 (CIRS) project walkthrough to identify operational and maintainability problems and to evaluate the maintainability of CIRS mechanical systems and equipment. We shadowed a millwright during his daily routine to understand how service requests are handled, how the maintenance work is performed, and what information and tools are available to complete work. We also identified personnel requirements regarding the technology for accessing information.  We analyzed technical guidelines documents, and performed interviews, walkthrough and shadowing activities to understand FM processes, available and required information, and available technology for managing information. We discuss the owner and O&M personnel requirements further in Section 2.4.2. 2.2.3 Project Context  We performed an embedded case study on UBC’s CIRS building project to understand building information handover, O&M processes, and building information and records management at the project level. We discuss the project context further in Section 2.4.3. 2.2.3.1 Handover Documents  We analyzed CIRS project handover documents which consist of 2D drawings, manuals and specifications. We investigated the accuracy and completeness of the handover documents                                                  3 Center for Interactive Research for Sustainability (CIRS) is a high performance, LEED Platinum research building located on the University of British Columbia (UBC) Vancouver campus 45  compared to the as-built conditions. We investigated the consistency of information between drawings, manuals, and specifications. We investigated handover documents’ accessibility and reusability within the organizational technology infrastructure. 2.2.3.2 Building Information Model  We analyzed BIM project models from several projects to understand the model content and structure for current design and construction BIMs. This process involved investigating the model content for availability of the geometric and non-geometric information required by the owner and the O&M personnel (i.e., investigation of availability of air handling unit (AHU) geometry and required attributes about AHU, such as air filter information). We also investigated the model structure to understand the model characteristics that enable accurate and efficient information exchange with FM information management tools (i.e., equipment-system-space relationships within the model). During model content evaluation, we used Revit schedules, COBie outputs using the Revit COBie Toolkit, the Ecodomus life cycle information management tool, and Navisworks visualizations. We investigated the model outputs to evaluate model information availability and available information’s reusability by the owner. More specifically we evaluated the alignment of the model context with organizational processes and technology infrastructure, and its compliance with owner and personnel requirements. 2.3 Literature Review  The main areas of knowledge covered in this research are the organization (Section 2.3.1), requirements (Section 2.3.2), and handover artifacts (Section 2.3.3). 2.3.1 Organization  Developing an understanding of the flow of information within the organization is essential when evaluating how BIM implementation may potentially affect the information flow 46  between departments, between operations personnel, and between the owner and the consultants. (Mcauley et al., 2007) state that as organizations become more complex, there is a greater need for information flow between the different parts of the system. According to McAuley (Mcauley et al., 2007), two sorts of information become highly important as organizations become more complex: (1) information from the external environment (external information that feeds in to the organization) and (2) information flow internal to the organization (department to department or between levels of management). As the organization goes through processes of change, the flow of information must be controlled. A sophisticated IT network provides both information and control. Schultz’s (Schultz, 2001) study of, how organizational learning in subunits affects outflows of knowledge to subunits, suggests that collecting new knowledge intensifies vertical flows of knowledge, codifying knowledge facilitates horizontal and vertical flows, and combining old knowledge mainly affects horizontal flows.  Owner organizations need to adapt to a changing market in which information management and integration are becoming increasingly important, and BIM implementation is currently being suggested as an enabler to reach this goal. In the absence of clear strategy and the kind of cultural climate required to compete in both the current market and also in a market that is changing according to developing technologies, organizations may fail to harvest benefits (Tushman, Tushman, O’Reilly, & O’Reilly, 1996). This implies that organizations should develop clear strategies and consider adjustments to their cultures to be able to harvest benefits from BIM adoption. This requires an understanding of how to manage changes in strategy and culture according to what is required by BIM implementation. Developing interest in BIM within the institutional market can be linked to institutions that have already started leveraging BIM for handover and O&M. Peppard and Breu (2003) state that: 47  “Organizations do not lead isolated lives but, instead, are linked inextricably with others. The success of one organization may, thus, be as much a function of what other organizations do as what the organization itself does.”  Then (1999) points out that initial preoccupation with tasks and functions in FM has given way to an emphasis on processes and resources and their management. In order to keep strategic advantage or to be able to compete in the changing market, universities may feel the need to reshape their organizational and technological infrastructure and processes.  A number of recent research efforts addressed challenges, bottlenecks and implications in the implementation of BIM for FM in the operations stage (Bosch et al., 2015; Kiviniemi & Codinhoto, 2014), or investigated more specific issues such as BIM integration with maintenance information systems (Korpela et al., 2015), the role of FM in developing data for handover at project completion (Lindkvist & Whyte, 2013), or value of BIM in managing spaces (Kassem et al., 2015). However, the aforementioned references use interviews with project participants (Lindkvist & Whyte, 2013), with participants from the demand and supply side of the construction industry (Bosch et al., 2015), with properties and facilities department of the University of Helsinki personnel (Korpela et al., 2015) as the main source for data collection. Kiviniemi and Codinhoto (2014) map FM services, map as-is and to-be process of reactive maintenance and do a comparative analysis of current and future BIM enabled states.  Organizational process and technological changes come with challenges such as the use of technology by operators and trades people, as studied by Anderson et al. (2012) and ECOCanada, (2015). Anderson et al. (2012) studied COBie and BIM implementation challenges, including complex data and software structures in organizations, organizational distributions, and problems with use of technology by operators and trades people. Their study points out that in 48  the case of maintenance and alterations crews, people rather than information technology have traditionally been central to the flow of tacit knowledge; besides which, these crews are often not trained to use technology in daily practices. The study asks the question of how to develop information retrieval systems for construction that efficiently provide information to non-technical staff whose primary job is not computer-oriented. The answer to such questions is sought in studies such as ECO’s building operator scoping study (ECOCanada, 2015) in which the mechanisms necessary to assist building operators in adapting to the requirements of a sustainably built and operated environment are identified. We found similar issues and challenges during our study and we expand on this and provide rich examples to illustrate and give meaning to such challenges.  While organizations are affected by changes in technology and new processes, acceptance of that technology differs amongst organizations. Brooks and Lilley (2006) suggest that “understanding the organization at both the strategic business and operational levels is the key to deploying appropriate technology”.  According to Brooks and Lilley, establishing an initial understanding of the characteristics and nature of the problem and then matching that with tried and tested solutions would help technology deployment. Although the nature of the handover and FM information management problems can be understood, deployment of BIM for FM is still a complex problem, because there is currently limited documentation on the use of BIM solutions in the FM literature. 2.3.2 Requirements  Defining and formalizing the information required by FM personnel is an essential step in BIM implementation. Various people working within an organization require different sets of information to perform their tasks. Although the sets of FM information provided in Table 1 is 49  not exhaustive, the table represents the variety of information required for FM functions and by O&M personnel. It is essential for O&M personnel to access required information in order to operate and maintain equipment and systems in buildings efficiently and effectively, to extend the service life of equipment, to optimize maintenance activities, to achieve energy efficiency, and to minimize labor time and downtime. 2.3.3 Handover Artifacts  There are a number of issues with the current handover artifacts that are submitted to the owner at the end of construction, and utilization of these artifacts during operations. Eastman et al. (2008) describe the loss of facility documentation value during the handover across project phases and increased effort to produce project information. East & Nisbet (2010) found that 30% (estimated) of the content of document-based O&M manuals contain some type of error. East and Brodt (2007) describe problems with the current procedure for construction handover documents, including the errors introduced when a construction coordinator is assigned the task of creating and collating information created by others, and that deliverables prepared at the end of the construction contract time ends up being less than satisfactory. Currently, there is no single standard that addresses all of the general building industry’s handover requirements (Fallon & Palmer, 2007). The format of the current handover information is inadequate to reuse by others and not conducive to computerized analysis (East & Brodt, 2007; Corry et al., 2011; Wu & Issa, 2012).  It is imperative to align work processes and software tools to produce and deliver required handover information (Fallon & Palmer, 2007). According to Au (2009), the consistency, continuity, and traceability of BIM have the potential to greatly reduce design re-invention, re-doing, and re-creation during different phases of building life cycle and 50  applications. Fallon and Palmer (2007) explain the correlation between longevity and reusability of handed-over information according to information structure. According to Fallon and Palmer (2007), standard and structured handover information is the most reusable handed over information and has the most longevity whereas proprietary and unstructured information is the least reusable with the least longevity. However, current handover information is not structured and not reusable. A study (Forns-Samso, 2011) based on online survey among facilities operations personnel showed that better access to O&M information was the highest-ranked perceived benefit of BIM, followed by integration with asset management systems, a centralized location for information, and 3D visualization. Facilities management (FM), and operation and maintenance (O&M) information requirements from the literature are summarized in Table 4.  Among different approaches to structuring data for better handover information exchange, the COBie approach has been tested on a number of projects using different software, with promising outcomes. COBie reduces the time and effort that the facility management personnel spend on entering building information manually. COBie can use the information extracted from BIM over the project life cycle through various information exchange mechanisms. Information that is not represented in BIM has to be manually entered into COBie. A COBie file can also be created without using BIM. There are other approaches for structuring building objects in data models but COBie has been tested and evaluated in the industry in recent years with promising efficiency results in transferring information to computerized maintenance management systems (CMMS). Over the last 6 years, COBie case studies were performed by BuildingSmart to investigate how to (1) reduce inefficiencies from commissioning to FM (e.g., decreasing commissioning time and reducing data entry time to databases), (2) increase data quality and quantity, (3) gather and store useful information efficiently, (4) make information 51  more accessible, (5) create a consistent work order (WO) process inside CMMS and help reduce work order cycle time, and (6) link as-built data to 3D to visualize building information. Sandia National Labs published a study in 2010 that demonstrated they could save $2.4M per year just by linking BIM to their WOs, resulting in a savings of $0.34 per square foot (Foster, 2011). These studies demonstrate the promise of BIM and COBIE in particular which can be achieved when an organization implements BIM. This chapter is complementary to these efforts in that we wanted to better understand the scale of effort involved in the transition to BIM, specifically looking at the challenges and benefits in getting to that level of implementation. Table 4: Facilities management (FM), and operation and maintenance (O&M) information requirements from the literature Information Category  Required Information  Most important facility information  categories (L. Y. Liu et al., 1994) Floor plans, design standards and criteria, design drawings, design specifications, as-built drawings, materials and components used, shop drawings, operation and maintenance manuals, equipment model and type, equipment manufacturer, equipment capacity, warranty information, condition of equipment and facility, equipment location, utility information, maintenance records, building description. Key content for facility documentation (Clayton et al., 1998) Wall locations, door locations, room identification, furniture layout, light fixtures, finishes, mechanical systems, electrical systems, equipment identification and location, cut-off locations, distribution capacity, design rationale. Non-geometric data requirements (Becerik-Gerber et al., 2012) ID and name, service zone: site, building, floor, room, zone. Group and type based on industry standards, or organization-specific categories. Manufacturer/vendor data: manufacturer, model, serial number, acquisition date, vendor, warranty expiration date, warranty usage Specifications such as type, unit, value, lower and upper limits, and description and attributes such as weight, power, energy consumption, spare parts. Operation and maintenance data: activity status, maintenance status, maintenance history, space occupancy data. 52  2.4 Data Collection Across Organizational and Project Contexts  This section presents the data collected from the embedded case study of UBC that investigated handover and FM practices across the organizational (Section 2.4.1) and project (Section 2.4.3) contexts and in relation to the owner requirements (Section 2.4.2). 2.4.1 Organizational Context  UBC is a large 405 hectare campus with over 200 buildings that employs a staff of 700 building operations personnel including trades, custodians, laborers, project managers, professional engineers, architects and management staff. The technology infrastructure is equally complex. We mapped the technology infrastructure and departments to identify the network of tools and databases used for managing information to support FM functions (Figure 9). This section will describe the processes and tools used to support different FM functions. Specifically, this section describes the current handover, records management, asset and maintenance management processes through the evaluation of organizational constructs, work practices, and available technology. For each sub-section, we first describe the FM process and available supporting technology, and then provide a critique of the process and technology. 53    Figure 9: Overview of UBC’s technology infrastructure illustrating the complexity and fragmentation of available tools to manage FM information, and the departmental silos CMMS BMS Honeywell  Siemens Delta Johnson PMIAccess DatabasePreventive MaintenanceTask, FrequencyFor Regulatory EquipmentFME Tracks trouble callsPulse Energy Excel FileTo track trouble calls VFA Facility Database LaserficheWeb front endAsset StewardshipUtilities & EnergyFinanceMinistry of EducationHosts VFA Facility DatabasePeopleSoft Service Now (IT)Simple K (Building Operations-Locksmiths)Ad Astra (Enrollment Services) Electronic Records ManagementElectronic Document Management SystemRecords Management Portal(Online Portal)Records Retrieval System(Building and Infrastructure Records)Building RecordDrawings (PDF)Manuals andSpecificationsFloor Plans & Room InformationRecordsCampus Base maps Mapping of the campus facilities and grounds using AutoCAD and GIS.Keyplans(from As-built AutoCAD)Room NumberingDoor IdentificationInfrastructure DevelopmentClassifies Spaces by Usage and User Group(SIU relies on information from FIS)Campus way finding   Smartmap Campus + Community PlanningFacilities Inf. SystemsBldgMasterExcel FileBuild In house Building # Building Name Address Gross Area Date Constructed Construction Type Usage Core Building Floor Count Bld CRV Bld DM Bld FCI Zone Building System Category Service Type Regulatory System Shop Emergency Generator  Fuel Tank  Emergency Eyewash Primary Backflow Preventer  Fume Hood Exhaust Fan Overhead Door Roofs Skylight  Exit Doors Exterior Exiting SystemsOperational EffectivenessService Center Space Inventory UnitMaintains and updates the Archibus facility information systemLaserfiche Archibus Online Spatial Information Systems BC Records Management Services (Long term Storage)      LEGENDApplicationpplicationDatabaseatabaseInformationInfor ationDepartment54  2.4.1.1 Building and Information Handover Process  The “handover” process involves the transfer of the building and the building information to the owner after completion of construction. Building occupancy follows the substantial performance, after the completion of construction, commissioning and required testing. The technical guidelines state that the as-built documentation and specifications should be submitted within 60 days of substantial performance. While substantial performance is a statutory term In Canada, one can also come across the term substantial completion in the industry. While it is not synonymous with substantial performance under the Builders’ Lien act, American Institute of Architects (AIA) defines substantial completion as the stage when the building is “sufficiently complete in accordance with the Contract Documents so that the Owner can occupy or use the Work or a portion thereof for its intended use”. The architect, as the owner’s representative, often gathers the required document set from the main consultants and the general contractor before the handover. According to UBC technical guidelines, a building should be turned over to UBC Plant Operations 2–4 weeks after occupancy. The Building Operations Department takes over the O&M of educational buildings on campus. The Student Housing Department is responsible for the O&M of the student residential buildings.  Although the handover process and requirements are documented in the technical guidelines, they do not guarantee that the tasks within the process completely meet the requirements. One records system administrator working for the Records Department emphasized the untimely delivery of the handover information, saying they receive the handover set simply “when it shows up” (Records System Administrator, personal communication). A complete set of required handover documents is often not delivered to UBC at the start of occupancy. For example, occupancy for the CIRS building was granted in August 2011, building 55  inhabitation began in September 2011, and the testing balancing report dates March 2012. O&M personnel we interviewed stated that the current commissioning practice fails to produce building systems performance information in the detail required. Rather than identifying performance benchmarks for equipment and systems in different performance settings, the commissioning process is often based on checking whether installed equipment or systems work. Not having a clearly defined time of handover creates ambiguity regarding who is responsible for addressing these issues during the early operations phase. Describing complications related to not having a true handover date, the UBC Program Manager for operational effectiveness reported: “We never know if we are responsible for the building, if something is under warranty, should we be attending those calls or it should be somebody else?” (Program Manager for Operation Effectiveness)  In terms of the problematic commissioning and handover process, one BMS specialist reported that there: “…doesn’t appear to be any real true handover date. You might have one thing handed over at one point and something else at a different time… As I mentioned our water system [sic] still aren’t commissioned yet here. So that’s been a year since it opened or pretty close to a year now.” (BMS Specialist)  Although the timing of handover is defined contractually and the submission of the records set is one of the prerequisites for payment from the owner, this does not guarantee that handover documents will be submitted completely on time, with the required quality, or in a reusable format. Even if the required documents are handed over to the owner on time, they often lack useful information because of the processes used to produce them. Although the UBC technical guidelines outline the requirements for project documentation, the evaluation criteria 56  for handover sets are not yet formally defined. As a result, any problems with the handover set are realized during the operation phase. The manager of technical services explained the reasons behind the limited review process utilized for design concept drawings and specifications as: “we don’t have the resources to review the designs in depth to check the design details. That’s the responsibility of the contractor and the consultant.” (Manager of Technical Services) 2.4.1.2 Records Management Process and Technology  Once UBC receives the handover set, the Records Department adds structure and metadata to the submitted documents to make the building information searchable. Structured handover information about buildings on the campus is accessed through the records retrieval system in UBC. A project’s handover set mainly consists of consultants’ drawings, manuals and specifications in paper and digital (pdf) formats. The process related with readying received records documents is represented in Figure 10. Once the project drawings are handed over, the Records Department personnel manually add structure and metadata to the drawings according to UBC naming conventions and drawings’ content. Meta data for a submitted drawing includes information that can be found on the drawing legend such as the specific building number, consultant ID, drawing number, and drawing title. This enables the drawings to become searchable on the record retrieval system and accessible by the users (Figure 11). According to the Records Systems Administrator: “…we create the structured data. We get unstructured data, and we create a structured data environment around it… Having that structure beforehand would be fabulous.” (Record Systems Administrator) 57   Appreciation (Initial review of handover set) Upload to database (SQL server)Add metadataPublish to web front-endChecking received files for following:Does the project documents belong to UBC?For which building is the received set?Does UBC have such a building?Is the building  naming applying to the building? Is it for underground services or for a building? (Both have different entry process)Drawings (CAD, pdf, paper)Maintenance (O&M) Manuals (pdf, paper)Specifications(pdf, paper)Building #, discipline ID, Sequential drawing #E.g. 306-06-123456Meta data entry according to each tab in the handed over manual. Consultant s breakdown followed.Grouped according to MasterFormat divisionsTitleBuilding #DateDivisionSheet #Drawing type (revision)CreatorProject numberPrimary ConsultantUBC Records DepartmentAdded Meta Data Figure 10: Process related with readying received records documents for users  When the building construction is completed in phases, UBC receives handover documents at the end of each phase. In such cases, determining the actual handover date becomes a problem. When separate sets of information about a project are handed over to the owner, managing handover information, such as naming and structuring documents from different phases of the same project, becomes problematic. For example when a building is handed over in phases, a consultant that produces drawings for one phase may end up duplicating room names used in the previous phase’s documentation. 58   Figure 11: Handed over pdf drawings are structured according to UBC naming conventions and drawings’ contents to make them accessible on the record retrieval system  The handover artifacts that are accessible from the records retrieval system can be hundreds of pages long, and sometimes consist of poor quality or even illegible scanned pages. For example, the O&M manual for the CIRS project’s mechanical systems was handed over to the owner in two pdf files—the first file consisted of 635 pages and the second file consisted of 727 pages. When O&M personnel are looking for information using the records retrieval system, the manuals can be viewed one page at a time which makes it extremely difficult to access information efficiently (Figure 12). Information represented in scanned documents can only be viewed on the screen; cannot be reused (copy and paste information from documents), and users cannot perform word searches within these documents. The O&M personnel we interviewed require quick and easy access to reusable information. The head of mechanical 59  maintenance/projects reported during our interview that sometimes it is frustrating to look for required information using the records retrieval application, and he expressed the shortcomings of the current technology: “We used to have all the books in our library, all the maintenance manuals, and you could go to that, flip through it really fast to that section, and if it wasn’t there, sometimes you flip through the rest of the book and you would find it in the oddest places. With [current retrieval system] I find it really frustrating, because you only see one page at a time, and you can’t flip quite fast. It takes a while time to use and plus I find the way they got it set up hard to see.” (Head of Mechanical Maintenance/Projects)  Figure 12: Handover documents that are hundreds of pages long can be viewed only one page at a time by using the records retrieval system 60   Regarding accessibility of information, the records system administrator we interviewed admitted that rather than the capability of the records retrieval system, it was his familiarity with the drawings that enabled him to access the information required: “I have spent a lot of years, almost seven years now looking through the drawings; I am pretty good at it. But that is more about familiarity with the drawings than it is with the software…” (Records System Administrator) 2.4.1.3 Asset Management Process and Technology  UBC performs a periodic maintenance program on regulatory equipment and systems. When our data collection started, information required for asset management was stored in and accessed from a number of applications such as PMI (preventive maintenance for regulatory equipment, VFA Facility (database hosted by Ministry of Education), an excel file containing required information on campus buildings, and a records management application (Figure 13). UBC implemented a database of system and equipment information for campus buildings in 2014, which is currently the integrated information source for most FM functions, such as trouble call management, and maintenance management. To populate the database, O&M personnel collected asset information from existing buildings. It took UBC a period of one year to collect information about 20,000 items (components, systems) within about 175 existing buildings. Three clerks worked about three months to enter information manually into the database (Figure 14). Entering collected information into the right database fields requires a level of familiarity, knowledge and expertise about systems, equipment and buildings. Information entered into the database by clerks needs to be validated continuously for consistency and accuracy, because data collection from the field is based on personal interpretation regarding nomenclature and attributes required. 61   Figure 13: A number of applications have to be used together to make informed decisions for asset management within the Asset Stewardship Department 62   Figure 14: Process of gathering data from the field and populating asset database for existing buildings  The requirements for gathering asset database information, in a reusable format from the project participants, are currently unavailable for new projects. The process to populate the asset database for new buildings that come online involves manual data entry. Maintenance and renewal senior analyst explained unavailability of processes required to support population of asset database with new building information: “…how do I get that information from the consultant into PeopleSoft? I don’t have a good solution yet, I don’t know if I can get the consultants to fill out my forms, in my format so it works…” (Maintenance and Renewal Senior Analyst) 2.4.1.4 Maintenance Management Process and Technology   In addition to the periodic maintenance on regulated equipment and building components, we identified reactive maintenance as the main type of maintenance activity at UBC. Issues regarding building components and performance are reported to the Service Center, which dispatches service requests to the appropriate trades. The requests can be accessed from trades’ cell phones and they contain relevant information, such as the start date, priority code, and subject line briefly describing the problem. Depending on the complexity of the problem, the trade person either fixes the equipment according to the problem priority or requests additional help according to the complexity of the issue. The trade person refers to the records retrieval system to find the required information on the equipment or system. This information includes, Identify information requirementsGather data from the fieldManual data entry to Excel by the clerksData cleansingDEV1(Verification database)VER1(Verification database)VALIDATIONData integration with PeopleSoftFilter Data and convert Excel to CSV(IT to help with batch upload)Going live on PeopleSoftInformation useTraining trades on the system63  but is not limited to, the manufacturers’ information, warranty information, intended purpose and performance, routing, manual and specification information. The personnel need to locate the required information within manuals and specifications that are hundreds of pages long, and the drawings only represent systems in 2D. There is often no guarantee that a complete set of required information will be readily available within the retrieval system, and with the required accuracy or level of detail. Once the work is completed, the service request is assigned a completed status. The building monitoring systems (BMS) division monitors building systems by using applications that read data from the data points installed throughout a building. We learned that buildings on the campus are equipped with BMS systems from four different brands (Figure 15). O&M personnel either log into each system to identify issues with buildings or use a system that maps data points from all systems into one interface. However the integrated system often does not represent all of the available data points in a building, and the system visualizations are not always a true representation of the as-is condition. 64   Figure 15: A number of applications have to be used together to make informed decisions when operating and monitoring building systems in the Building Monitoring Systems (BMS) Center  Before the recent implementation of the integrated asset database, work orders (WOs) have been assigned to buildings rather than systems or equipment. For instance, if there was a problem with a pump in a building, this issue was documented under the maintenance history of that building. The maintenance work performed on the equipment was stored under the specific building history. There were also no shared sources of maintenance information, such as excel files where maintenance information was kept according to a breakdown of system or equipment. This practice has made it almost impossible to track maintenance issues and related costs per equipment or system. A database of equipment and systems within the campus buildings was made available in 2014. This database has allowed the assignment of WOs to equipment and systems within buildings, making it possible to manage costs and previous work on equipment and system level. To date, maintenance history information, such as what kind of maintenance 65  was done on equipment, who was the last maintenance call assigned to, or things to be careful about when maintaining/operating equipment have been mainly kept in the minds of personnel. The method of transferring such information among personnel has been via personal communication. We learned that when such information is not readily available and accessible by all personnel, owner’s resources are wasted in cases as such where different O&M personnel end up spending time to travel and inspect the same problem: “There is no one central point where you can see what maintenance, what history has been done on that piece of equipment, so you don’t know how many times somebody has visited that [equipment], is there a recurring problem that somebody has fixed, you got to remember there is operations and maintenance, and sometimes both of us go to a call.” (Head of Mechanical Maintenance/ Projects)  UBC has been using a zone approach for maintenance management, where the available maintenance workforce has been divided into different zones within the campus. From the interviews we performed, we learned that one of the reasons for using this approach is to ensure that the maintenance personnel are familiar with the buildings’ equipment and systems. This approach is heavily dependent on personnel’s memory that currently cannot be stored, shared or transferred automatically. As the head of mechanical maintenance projects reports, “…what we are relying on and we have relied on for the last twelve years I have been here is peoples’ experience. Well you know if you go to “X”, X will know all the history on that machine. He knows background of that machine, he might know “Y” has done some work on it on and it has that piece of equipment…” (Head of Mechanical Maintenance/ Projects) 66  2.4.2 Requirements  The first part of this section presents the comparison of the handed over building and building information with the Technical Guidelines which represent the owner’s requirements. The second part of this section documents the information and information visualization requirements of the O&M personnel based on the interview data. 2.4.2.1 Owner Requirements  The UBC Technical Guidelines “outline the principles of design and construction and include: performance objectives, technical requirements, recommended practices, project documentation requirements, sample front-end documentation, plus steps to follow to expedite completion of UBC projects” (http://www.technicalguidelines.ubc.ca). These guidelines (Table 5) serve as the code of quality and performance, and we identified issues regarding compliance to these requirements. Contrary to the owner’s technical requirements, during our analysis we identified mechanical rooms with poor access for maintenance, plumbing equipment located at ceiling height, and as-built records drawings that fail to completely represent what was actually built. Buildings on the UBC campus, even the ones most recently constructed, have maintainability problems that conflict with the UBC technical guidelines. UBC Technical Guidelines state that “no mechanical room will be accepted with poor and difficult access for maintenance”. However, the CIRS mechanical room is one of the most cramped and problematic mechanical rooms on the campus. Pumps in the mechanical room are installed on the ceiling and buried under a maze of pipes (Figure 16). Access to pumps which are installed at the ceiling height (Figure 16) is problematic. Some of these pumps require maintenance as often as every two years. In order to maintain the pumps in the CIRS mechanical room, maintenance crews will need to remove components that 67  block the access space, use additional equipment (like ladders and lifts) to remove the pumps, and therefore spend additional time on maintenance. UBC Technical Guidelines clearly state “do not locate plumbing equipment at ceiling height, requiring scaffolds, ladders, removal of other equipment”, and “all plumbing equipment requiring frequent maintenance to be readily accessible”. One of the reasons for UBC for not being able to identify such non-compliance is the lack of resources and means for timely reviewing building designs and construction for compliance with owner requirements. Table 5: Examples from the technical guidelines regarding mechanical room and plumbing designs, and requirements for records drawings submission Mechanical Rooms Section of the Technical Guidelines a. Consider maintenance access as part of the design. No mechanical room will be accepted with poor and difficult access for maintenance. b. Drawings shall show all mechanical and plumbing equipment in elevation or alternately shall specify mounting heights for the equipment. c. Design sufficient access to all components of the air handling unit. Ensure adequate clearance for coil replacement without necessity to dismantle adjacent equipment or building components. d. Locate mechanical rooms in areas accessible from outdoors. e. Confirm that sufficient space is provided to remove largest piece of equipment from the Mechanical Room. Plumbing Section of the Technical Guidelines f. All plumbing equipment requiring frequent maintenance (once a year) to be readily accessible. Do not locate at ceiling height, in walls, tunnels, buried, requiring scaffolds, ladders, removal of other equipment, in user space, or in crawl spaces g. All sanitary sumps within buildings must have gas tight covers and be vented to outdoors Records Section of the Technical Guidelines h. “Issued for Construction” drawings are not accepted as as-built drawings. i. (As built drawings) represent the final installed configuration of what was actually built j. As-built drawings incorporate all changes made during the construction process including any and all clarifications, addenda and Change Orders. k. (As built drawings) to be submitted within 60 days of Substantial Performance l. Operating and maintenance manuals: • All drawings must be legible • Complete sets of manuals should be in the hands of the Owner’s Representative no later than 60 days after the date of substantial performance.   68      Figure 16: There are installations of equipment in the CIRS mechanical room that are contrary to the owner requirements which lead to inefficiencies when performing maintenance during the operations phase. Looking up at the ceiling, the images show pumps which were installed at ceiling. Pumps are buried under a maze of pipes which block the access space for pump maintenance.  The main maintainability issues we identified during the building walkthrough and shadowing activities were related to installation and maintenance access space problems, as well as lack of information on equipment design intent and performance. Describing equipment access problems, a BMS specialist reported: “I think that that’s the largest problem we have got and it’s not just this building it is a lot of buildings but this building they really made the mechanical room tight. And it’s like a new car, where you can’t access one thing without removing three other things. It is going to be very difficult for people to work on it and maintain these things in the future.” (BMS Specialist) 2.4.2.2 O&M Personnel Requirements  It is often not clear for the owner and the project team what information is needed at handover in terms of representing the requirements of all the different users within the organization. An organization’s information requirements vary depending on the FM functions to be supported, the O&M personnel information requirements, and the processes and tools that are 69  used to perform FM functions. The users that we interviewed emphasized information and information visualization requirements that weren’t formalized anywhere (Table 6). Table 6: Breakdown of interviewed personnel according to departments and FM functions Department FM Function Interviewed Personnel Infrastructure Development Records Management Records System Administrator Building Operations Asset Management Maintenance & Renewal Senior Analyst Maintenance Management Manager of Technical Services Maintenance Maintenance Technical Specialist Head Maintenance Engineer Millwright Building Operation Monitoring & Control Head Maintenance Engineer (BMS Center) BMS Specialist Service Call Management Program Manager  FM personnel require information to be at different levels of detail, in reusable format, and prefer different information visualizations depending on the task they perform. We identified types of information required by different O&M personnel through the analysis of the interviews we performed (Table 7). During our interview, the head of mechanical maintenance/projects explained the types of equipment information he requires and the implications of not having that information: “Sometimes you go to a piece of equipment especially older piece of equipment, there is no history on it, there is nothing in the maintenance manual what this thing did, and the data tag on a piece of equipment is rusted, it is missing, and then you have a sump pump and it goes through the ceiling and you don’t actually know where it goes, and how far it goes, you are guessing how much gallons per minute, and you have to know how many feet ahead it can pump, that can be challenging.” (Head of Mechanical Maintenance/Projects) 70  Table 7: Information required by O&M personnel to perform maintenance, building systems monitoring, and manage assets  FM Function Required Information, Component & System Attributes Maintenance Personnel Maintenance • Preventive • Scheduled/Periodic • Reactive Design criteria, commissioning information (e.g. component performance), replacement part information, vendor information, serial number, location, warranty information, cost (to replace, maintain, etc.), system visualization, system performance information, locations of panels and valves that control equipment (e.g. electrical panel location, shut off valve location), sequence of operation (start-up/shut down information), maintenance history BMS Operation Monitoring/Tracking Location, commissioning information, design criteria, equipment performance information, system performance information, accurate system visualization that includes all required system components Asset Management Asset Management • Track operational costs • Track life cycle costs • Maintenance info • Maintenance schedules • Procurement PM maintenance schedule, PM inspection report, key plans, backflow prevention assembly test report, systems list, equipment lists, part of what system, required database attributes (e.g. supplier and manufacturer information, manufacturer, performance data), cost information related to replacing and maintaining equipment/system, maintenance history, installation manuals  During our interview a millwright explained the different types of information he uses and how the current technology and artifacts do not fit with his requirements: “When I refer to the record drawings, it is when I need to know how a system functions. I may know what the problem is already if it is a mechanical problem but, when we get into the technical aspects of balancing issues, supply or return issues we need to know how the system functions. So we refer to the records drawings not only to find out what the system was balanced at, but we also need to know what areas it serves, where certain components are. The BMS system doesn’t show everything. On their graphics they’ll show an air handler, a room, and a valve. But where is that valve?” (Millwright) 71   A building monitoring system specialist would like to have access to accurate system representations, with space information, supported by design and as-is performance information. We identified that the current technology for building monitoring system (BMS) representations are often not detailed enough to represent all required system components and their locations, and they may not represent the as-is condition. We learned that it would have been easier for a building operator to identify the source of a problem in a system or make informed decisions, if 3D detailed and accurate system visualizations were available. A building operator we interviewed mentioned that air handling system visualizations indicating all required systems components such as the AHU, ducts, dampers, diffusers, positions of VAVs, spaces served by the components would help during problem source identification regarding a hot/cold space. A zone millwright we interviewed explained that he needs to know what areas an equipment serves, and where certain components are in the building. According to this millwright the BMS system does not show everything, and it may be challenging to understand things like what area an equipment serves from the 2D drawings.  We identified organizational processes that are not adequate to create the required information. For example, our interviews indicate that the extent and quality of information created during commissioning often does not meet the requirements of operations personnel. When detailed commissioning information about how the systems should work together, or how components should perform under different conditions are not transferred to the operators, they are left without a performance benchmark to operate the buildings accordingly. The BMS specialist we interviewed explained the importance of access to an accurate sequence of operation information to understand how equipment items within a building should interact with each other: 72  “Having a clear accurate sequence of operation available to maintenance personnel is becoming increasingly important. As buildings become complex it is harder to determine how a piece of equipment is intended to interact with other equipment in the building without the sequence of operation.” (BMS Specialist) 2.4.3 Project Context  Artifacts are the main information sources of building information for the owner during the operations phase. The owners refer to this information set to make informed decisions while performing FM tasks. In this section, we document our investigation of the CIRS project handover documents and the design model. 2.4.3.1 Artifacts—Handover Documents   Handover documents contain information that is required by the owner to operate and maintain buildings. As mentioned earlier these documents are accessed by the personnel through the records retrieval system, after they are structured and rendered searchable by the records department. In this section, we analyze the handover artifacts from different perspectives to understand the accuracy, reusability and accessibility of this information.  According to the Records Administrator, the handover documents are often reflective of the condition of the project documentation at the time of handover, and there is no guarantee that accessed information in the owner’s records management system is accurate or up-to-date (Figure 17-a). The characteristics of the handover documents (including quality and/or accuracy) may vary depending on the project team: “If you come in looking for information about any building, I can show you what we have, that’s the strength....What I can’t tell you is that it is right. We entirely depend on what was sent to us….The biggest weakness is that what we get is what we get. We don’t have plan 73  checkers. We don’t have a department reviewing the drawings saying yes this isn’t right, it is wrong.” (Record Systems Administrator)  During the analysis of the handover set we identified that the sequence of operation information required by the personnel for operating and maintaining the building was not available at the time of handover (Figure 17-b). Handover documents are often in paper format, and digital copies of these documents are also received by the owner at the end of projects. Although much of the information is created digitally at one point, often the information set contains scanned images of information which don’t allow for reuse of content (Figure 17-c). We identified scanned pages of the manufacturers’ generic information within O&M manuals, rather than project specific information. The format of the documents also leads to information accessibility problems when using the records retrieval system. Because simple word searches cannot be performed on documents containing scanned images, it becomes challenging to access important building information such as location of water shutoff locations (Figure 17-d). 74   a- There are information nconsistencies within handover set (e.g. between drawings information, manual information, and as-build)             b- Information required for building O&M is not available at the time of handover  c- Information within the handover set is not reusable, because electronically created information is handed over to the owner as scanned images  d- Important information within hundreds of pages long documents cannot be accessed easily since scanned images do not allow for word searches Figure 17: Identified issues with the handover artifacts lead to problems related to usability of handover information during operations  2.4.3.2 Artifacts—Building Information Models  We analyzed different BIM models to understand the information that is currently represented in design and construction models, and the degree to which these models meet the needs of FM functions. We focus on the CIRS design model and use illustrative examples to convey the issues and shortcomings of this model for FM purposes. Our analysis focused on the 75  model content that is related with geometric and non-geometric information availability within the model, and model structure that is required for accurate computation of model information and to enable exchange of model information with owner’s FM systems.  We analyzed the available model content using a variety of tools, including Revit schedules, Ecodomus, COBie outputs, and Navisworks visualizations. The model content evaluations that we performed indicated that it is a significant challenge to identify available information in the models. We compared the schedules created from the model, O&M personnel information requirements derived from the interviews, and the information tracked within the UBC asset database (Table 8). We identified that the model, which was created by the design consultants, was lacking content that the owner tracked and required to perform FM functions. When we compared the tracked user defined asset attributes with the model information available, we identified that the model was lacking this information as well as the information required in the asset database, as listed in the middle column in Table 8 (Figure 18). Available information in the schedules, which we derived from the mechanical model, failed to match the asset database and personnel requirements. Useful information on system classifications, system types, and system names was also not available for all components in these schedules (Table 9). Not having this information related to systems made it challenging to understand the available building systems in the model and the components that belong to each system.  76  Table 8: Comparison of information required by O&M personnel, information tracked in the owner’s asset database, and information available within the model regarding a pump  Information Required by  O&M Personnel* Tracked Information in Asset Database Information Available Within  Design Model Equipment Type: Pump – System: HVAC Vendor information  Unit UBC Level Basement Serial number Asset ID 000000005504 Family Inline Pump—Vertical Location Acq Code P Type 120 GPM Capacities—10.85 Feet Heads Maintenance history Building Tag Number 63300 System Classification Undefined, Power Warranty information  Descr CIRS Equipment # AH1 Maintenance plans Region 633F Equipment Type P Maintenance schedule Descr – Mark 110 Cost information Asset Type HVAC Count 1 Replacement part information Asset Subtype CW PUMP – – Equipment Type: Pump – System: HVAC Performance criteria (design criteria, commissioning information) Description Circulating Pump P-2 – – Location of electrical panel Location of shut off valve  Status I – – System that equipment belong to Acq Date 01/01/2011 – – Area served by the equipment In Service Dt 01/01/2011 – – Number and locations of a type of component Description Circulating Pump P-2 – – Routing of the system which an equipment belong to Short Desc PCW002 – – Taggable Y – – Tag Number 63300PCW002 – – Version ClosedLoop – – Criticality N – – Manufacturer - – – Model - – – Serial ID – – – Equipment Location B1242 – – VIN – – – User defined attributes: – – Length 0.000 – – Length Units – – – Capacity 400.000 – – Capacity Units GPM – – Power 5.000 – – Rating Units HP – – Custom Attributes HEAD 16 FT – –  77   Figure 18: The available AHU information within the model (as identified from model analysis using EcoDomus lifecycle information management application) falls short on representing the user-defined attributes tracked for the AHUs within the owners asset database  Comparison of the available model geometry to the as-built conditions indicated the components that were not modeled, and components that were modeled but did not represent the as-is condition. For example, Figure 19 illustrates inconsistencies between what the as-built drawing shows, what the model represents, and what actually exists in the building. The actual number of expansion tanks and the size and location of the MCC unit are inconsistent with the modeled information. 78   Figure 19: Inconsistent information was identified between record drawings and the design model (from left to right; 2D plan drawing information, consultant’s mechanical design model representation, and as-build)  Table 9: Analysis of mechanical consultant’s design model for available component attributes using Revit schedules Schedules Derived from Mechanical Model  Information Available Within the Schedules  Mechanical Equipment Schedule Attributes that have assigned values for all components in the schedule Level, Count, Family, Type, Type Comments, Equipment Tag (MAN), IS-HL,  Length, Mark. Attributes that have assigned values for a number of components in the schedule System Classification, System Name, Neck Height, Neck Width, Air Flow, Color, Equipment #, Equipment Type, Comments, Comments_1 Multi-category Schedule Level, Family, Type, Category, Mark, Length, Equipment Tag, IS-HL, Type comments, Neck Size, Count, Comments1-2-3-4. Duct Schedule Family, System Classification, System Name, System Type, Flow, Free Size, Area, Bottom Elevation, Count, Diameter, Equivalent Diameter, Additional Flow, Friction, Height, Hydraulic Diameter, Length, Loss Coefficient, Mark, Overall Size, Pressure Drop, Reynolds number, Section Size, Size Lock, Top Elevation, Type, Velocity, Velocity Pressure. HVAC Zone Schedule One line of information available: Cooling Air Temperature (12 °C), Cooling Set point (23 °C), Dehumidification Set Point (0.7), Heating Air Temperature (32 °C), Heating Set Point (21 °C). Schedules that do not contain information Space Schedule, Parts Schedule, Sprinkler Schedule, Area schedule (gross building), Assembly Schedule, Duct Insulation Schedule, Duct Lining Schedule, Duct Placeholder Schedule, Flex duct schedule  The design and construction models are not immediately usable because they lack the model structure such as consistent and instance specific nomenclature. Table 10 shows the comparison of information required by O&M personnel, information tracked in the asset 79  database, and information available within the model regarding pump equipment. Type and instance names (bold in the figure) in the model are not consistent. Generic box is used to model a pump instead of using a pump family. Data derived from the models requires reorganization and restructuring because information output from unstructured models has limited value and use for an owner.  During the model analyses, we compared the available model content with the information tracked in the owner’s asset database and user requirements from the interviews. We identified modeling errors that negatively impacted the quality and reusability of the information derived from the model. The modeling errors affected space boundaries that prevented getting meaningful information from the models. We identified issues that lead to miscomputation of model information and information reusability problems such as:  Issues related with the modeled information include: • Unidentified system-equipment-space relationships; when such relationships are not defined it becomes challenging to understand available systems within a model, identify equipment which belong to a system, and where this equipment is located within the building (Figure 20-a). • Errors in spaces, such as duplicate/overlapping spaces and unintentional openings left within the walls, lead to miscomputation of space information for equipment locations (Figure 20-b). • Errors in elevations, such as inconsistent floor elevations between linked models, lead to miscomputation of space information. • Errors in floor to floor height definitions lead to computation of space that equipment is located in rather than the space it is serviced from. 80  • Errors in representing all components continuously within a system; unconnected or missing system components affect identification of systems within the model Figure 20-c). • Issues with equipment and system nomenclature;  Components named as individual systems (Figure 20-d).  Non-standard system names.  Equipment that are not named uniquely or consistently. Table 10: Inconsistent model component nomenclature and asset breakdown structure make it challenging to reuse model information, because they do not align with owner’s database Model Information Family Name Inline Pump—Vertical Inline Pump—Vertical Box-generic Box-generic Type Name 120 GPM Capacities—10.85 Feet Heads 120 GPM Capacities—10.85 Feet Heads HP4 HP05 Instance Name HL-3 HL2 1 2 Instance Description P P HPWA HPWA Tracked Information in Owners Database Asset Type HVAC Asset Subtype CW PUMP Description Circulating Pump P-2 Short Description PCW002 Tag Number 63300PCW002C  In this section, we investigated the current FM processes, technology, requirements and artifacts within the UBC context. In the next section, we will introduce the framework we developed to characterize the alignment organizational constructs, available technology, project artifacts and owner requirements along with illustrative examples using the UBC case study. 81    a - Equipment and system relationships are not defined in the model b - Overlapping space defining objects, space duplications, and unintentional openings left within the walls lead to miscomputation of equipment location information   c - Unconnected system components lead to issues when defining systems, e.g., the duct in the picture is not connected to the AHU d - A single component is defined as a system within the model Figure 20: Identified modeling issues often lead to information reusability problems and miscomputation of model information 2.5 Framework for Investigating Organizational Alignment  Our investigation of the owner operator organization indicates the challenges involved with managing infrastructure. An organization is a network of departments, technologies, 82  processes, and people. Transitioning from a paper-based to a model-based approach in handover and operations is a complex challenge and will necessitate changes in work practices and information flows within an organization. We investigated alignment as a way to better understand the complexity and the changes required to transition to a model-based work flow. This section introduces the framework we developed to characterize alignment between organizational constructs, available technology, project artifacts and owner requirements (Figure 21). The framework emerged from our analysis of the detailed case study data collected and a thorough review of the literature on alignment. This framework helped us to understand how well the different pieces within the organization work together to achieve organizational goals through the lens of potential BIM-based information exchange and FM practices (Clayton et al., 1998). 83   Figure 21: Framework we developed to analyze organizational alignment, and compliance to requirements from the perspective of BIM implementation for FM  We use the Strategic Alignment Model (SAM) by Henderson & Venkatraman (1993) as a point of departure for our framework (Figure 22). Henderson and Venkatraman define alignment as “the degree of fit and integration among business strategy, IT strategy, business infrastructure, and IT infrastructure” (as cited in Chan & Reich, 2007). Alignment in this study refers to the degree to which all parts of the organization-specific context, as a system, work together efficiently to achieve the organizational goals. Misalignment therefore refers to any issues within the organization-specific context that limit or hinder the ability of organizational processes, technology and artifacts to work together and support each other. We used SAM as a starting point for our framework because it is the most relevant, comprehensive, and most cited alignment model in the literature. The SAM identifies two types of integration between business ARTIFACTSREQUIREMENTSORGANISATION OrganisationalStructure- Departmental breakdown- Resource deploymentFM ProcessesHandoverO&M- Asset Management- Maintenance Management TECHNOLOGYIT Infrastructure- Information- Databases- ApplicationsProcesses- Data collection- Database populationHandover Set- Drawings- Specifications- ManualsBIM- Model Content- Model Structure ALIGNMENTALIGNMENTALIGNMENTREQUIREMENTSRequired alignment between “FM processes” and “technology”, in order to support performance of FM tasksIT INNOVATIONSMARKETChange & CompetitionRequired alignment between “artifacts” and “available technology” to exchange, store and access building informationRequired alignment between “organisational processes and requirements” and the “artifacts” to ensure that artifacts represent all required informationCOMPLIANCEto requirements.As a metric to understand level of alignment at a given time84  and it domains. The first, strategic integration, “is the link between business strategy and IT strategy. It deals with capability of IT functionality to both shape and support business strategy” (Henderson & Venkatraman, 1993).The second, operational integration, “deals with the link between organizational infrastructure and processes and IS infrastructure and processes” (Henderson & Venkatraman, 1993). It “highlights the criticality of ensuring internal coherence between the organizational requirements and expectations and the delivery capability with the IS function” (Henderson & Venkatraman, 1993). We exclude the business and IT strategies in our framework because in many organizations not all personnel are aware of organizational strategy that has been put in place (Peppard & Breu, 2003). Peppard and Breu (2003) describe the element of chance that seems to influence deployment of information systems (IS) in companies by referring to Ciborra’s study of organizations and observing that in certain cases “achievement of competitive advantage from the deployment of IS was due more to serendipity than formal planning” (Peppard & Breu, 2003). Although we do not have data suggesting that our observations about UBC were directly related with external factors such as market changes/competition, and IT innovations, we still included these important factors in the framework. However, the changes we observed within the organization, such as implementing an integrated asset database, leveraging PeopleSoft to support a number of FM functions, and organization’s interest in BIM for delivery of new projects, may have been influenced by changing FM practices of other owner organizations and advancements in IT. One other reason for the observed changes within the organization may be the organization’s internal effort to align processes, organizational structure, and technology infrastructure to improve work practices through technology adoption. This study extends SAM’s operational integration 85  characterization by considering artifacts as a medium to investigate alignment between organization and technology.  Figure 22: The Henderson and Venkatraman (1993) strategic alignment model. Original image from Chan and Reich (2007)  The main dimensions of the framework are Artifacts, Technology, and Organization because they were the most distinct categories that emerged during our data collection and analysis. Building information is exchanged through artifacts, it is stored in and accessed through the available technology, and it is used by the O&M personnel to perform FM functions via defined processes. We recognized that in order to perform handover and FM functions efficiently, organizational processes, structure, technology infrastructure and artifacts have to support each other, and there has to be a high level of compliance to the organization’s requirements.  We use the term ‘compliance’ within our framework to describe the ability to act according to a set of requirements, such as owner, personnel and technology infrastructure requirements. Compliance to requirements is introduced as a metric to improve alignment within 86  the organization-specific context, where more compliance to requirements leads to better alignment.  Figure 23 provides an illustrative example of the alignment issues we observed between current artifacts, technology, and processes within the organization. We use an example from Section 2.4.1 that focused on maintenance management processes and related technologies, and in particular, the process related to work requests and how they are assigned to buildings rather than systems and equipment. This process made it challenging to access equipment maintenance history or make informed decisions on procurement and planning. The main reason for this practice was the unavailability of the necessary technology infrastructure to support a database of systems and equipment available in campus buildings (Figure 23, refer to text numbered as 1). In the absence of such technology, work requests have been assigned to buildings rather than equipment, and the work performed on equipment was not captured digitally but rather resided with the personnel who performed maintenance activity. This process made it significantly challenging to track equipment maintenance history for performing tasks, like tracking the maintenance costs based on equipment, or supporting the flow of maintenance history information within the work-force. Since the maintenance history was not documented and shared, the organization preferred a zone-based approach to workforce management so that personnel familiar with the building systems and equipment are responsible for their maintenance. Although a database for systems and equipment in campus buildings was recently created, the process for getting the required information for new projects in a reusable format is not available, entering information into the database is still a manual process, and handover artifacts do not contain the required system and equipment information in a reusable and structured format (Figure 23, refer to text numbered as 2). 87   The misalignment between the process related to managing work requests, the technology related to keeping required equipment and system information, and the artifacts that should contain data to populate databases remains a challenge. Available technology for accessing artifacts fails to comply with user interface requirements, such as the ability to quickly skim through handover documents that are hundreds of pages long (Figure 23, refer to text numbered as 3). Artifacts on the other hand, fail to comply with the technology requirements (e.g., the data structure) and personnel requirements (such as the need for an accurate and complete set of information required by O&M personnel). The information that is required by the personnel to perform FM tasks mainly resides within the handover documents. The records retrieval system is intended to store handover documents, but it lacks the user interface required by O&M personnel. Specifically, O&M personnel require structured, quality information that also meets their information visualization requirements. O&M personnel often refer to manuals and specification documents within the records retrieval system. Such documents are hundreds of pages long, however the available system allows users to only view one page at a time. Since the documents often contain scanned images, the system does not allow for word searches or simple interactions like copy and paste information. Information within the records retrieval system is also accessed by other departments to support the functions that they perform. The information in the system is often re-categorized and regrouped within departments according to their information requirements. This process leads to inefficiencies due to duplication of effort to enter, structure, and update information within departments. Since the information is not integrated, O&M personnel have to use multiple tools to access the sets of required information and they have to manage information in all these applications and databases separately.88   Figure 23: O&M personnel access handover information through technology infrastructure that fails to comply with user requirements (such as accessibility), and process requirements (such as an asset database for maintenance managementTechnology should not only focus on storing handover information, but on information accessibility and required user interfaceARTIFACTSORGANISATIONTECHNOLOGYALIGNALIGNALIGNModel requirementsProcess, personnel requirementsTechnology requirementsInformation handoverMaintenance managementAsset managementNot structured according to organisational technology and user requirementsCOMPLIANCEInformation managementRecords retrievalAsset databaseTechnology (i.e asset database) and organisational processes (maintenance management) should support each other to achieve organisational goals There should be processes available to require handover information in a reusable format, and in enough detail to match personnel and  technology requirements- Original source of building information- Handover information resides and accessed from here - Departments use the information  to perform FM functions 12389   Figure 24 provides an illustrative example of alignment issues we observed between current information requirements, organizational technology, and artifacts when considering the potential uses of model-based artifacts. We use examples from section 2.4.3.2 that focused on information required by O&M personnel, information tracked and managed within the organizational asset management database, and available mechanical equipment information in the design model. When we compared the information required by O&M personnel, the information available within the owner’s asset database and the information available within the analyzed model, we identified that neither the information tracked within the asset database nor the information available in the design model is complete enough to satisfy personnel information requirements. The available asset database contains a limited set of information regarding the mechanical equipment and systems within the university buildings. The design model information on the other hand, fails to cover the limited set of information that is tracked within the asset database. When we analyzed the available information within the model, we identified misalignment between the model information structure, asset database information structure, and how O&M personnel search for information within a database. Figure 24 also exemplifies structural issues within the model regarding nomenclature, such as not using the required families to model mechanical components, using inconsistent methods for indicating individual components (such as naming one instance as HL-3 and naming other instance as HL2, or using HP4 and HP05 to identify two instances of the same type of equipment). When we look at the type of information breakdown structure used within the asset database, we see that the type and subtype breakdown utilized is not consistent with the model90   Figure 24: Information within the investigated model is not sufficient to capture information tracked within the owner’s database, which is only a portion of the information required by the personnelARTIFACTSORGANISATIONTECHNOLOGYALIGNALIGNInformation required by personnelRequired by personnel DatabaseModelInconsistentNot a mechanical familyInconsistentInformation tracked in the asset databaseInformation available in modelALIGN91   The examples above indicate misalignment between processes, technology and artifacts, and lack of compliance to requirements within an organization. In order to leverage BIM, organizations need to align artifacts, supporting technology, work practices, and processes to harvest the potential benefits. Introducing BIM as a new technology into the current state of an organization without carrying out the required alignment process would not be adequate to solve the current FM issues. The information required in an FM BIM is often not formalized by owners, and most owners are not aware of the different types of information required by different personnel. Formalizing the requirements would require identification of information related to FM functions, identification of how users access and use such information, documenting how such information should be made available in a model, and reconfiguring processes and organizational technology to accommodate model information. Aside from the internal changes required within an organization, BIM use in handover and FM also necessitates changes to the way the project teams work in terms of preparing and delivering the necessary handover artifacts to suit FM purposes. 2.6 Summary and Conclusions  The aim of this research was to better understand what is involved in the transition from a paper-based approach to a BIM-based approach in handover and FM information management. This research was motivated by our own observations and references in the literature about the low adoption rate of BIM for facility owners despite the many promised benefits and the increasing availability of design and construction BIMs. We performed a long-term embedded case study analysis that investigated the work practices of a large owner organization that spanned several years. We investigated numerous FM functions across organizational and project contexts to better understand their work practices and processes, information flows, and 92  technologies used. We further investigated owner information requirements and project artifacts to better understand the current state and quality of building information artifacts typically transferred to building owners at project completion. This rich case study informed the development of a framework to characterize alignment between organizational constructs, available technology, project artifacts and owner requirements as a means to better understand the mechanisms required to transition from traditional to BIM-enabled FM practices.  Investigated Canadian institution is representative of the large institutional owners in Canada in terms of FM practices and available information management technologies, which are also representative of the literature available from North America in terms of current research on large institutional owners. The case study of a large owner organization illustrated the many shortcomings with current FM practices and the opportunity that BIM enables, particularly for owner operators. The case study also illustrated the complexity involved in transitioning to model-based work flows and practices. This transition is significant and complex and helps to explain why so few owners are adopting BIM. The framework that emerged from the case study illustrates the importance of alignment between the organization, technology, artifacts from many resources and requirements for owners considering the transition to BIM. The reality is that implementing BIM in large owner organizations will require significant changes in the way organizations are structured, the way information is represented and exchanged, and the way work practices are configured and executed. These changes are both internal to the organization, as well as external to the organization in terms of the way project teams produce and exchange project information. Future work will focus on evaluating other owner organizations and verifying the applicability of the framework across different organizational contexts.  Further 93  research will also be pursued to better understand owner requirements and the computational mechanisms needed to evaluate a given BIM’s compliance against these requirements.   94  Chapter 3: Developing Owner Information Requirements for BIM-enabled Project Delivery and Asset Lifecycle Management4  This chapter presents the results of a research project that investigated two large owner organizations in Canada to better understand the process of developing and formulating BIM requirements to support the lifecycle of their assets.  Specifically, the objectives were to formalize an iterative approach to the identification and characterization of owner requirements and to develop a conceptual framework that would relate digital and physical products to owner requirements and organizational constructs, to underpin the formalization process. As part of this research an array of requirements documentation were analyzed, interviews were performed with numerous facility management personnel, and BIMs from four projects were analyzed. A methodology is introduced to support a rigorous and detailed analysis of BIM requirements. The investigation of the owner requirements helped to develop an understanding of the required information content, and its alignment with BIM.  Finally the relationships between organizational constructs, owner requirements, and BIM were mapped. As the construction industry shifts toward model-based project delivery, this research will inform owners about how to think about handover of digital facility models, and what to require in models based on their specific needs. 3.1 Introduction  In the mid-1980’s, the National Academy of Science's National Research Council's Building Research Board suggested that integrated databases were potentially amongst the most                                                  4 A version of chapter 3 has been submitted to Automation in Construction in September 2016. Two rounds of reviews have been completed with positive feedback from the reviewers. Cavka, H., Staub-French, S., & Poirier, E. A. (2016). Developing Owner Information Requirements for BIM-enabled Project Delivery and Asset Lifecycle Management. 95  cost-effective way of managing facilities (Scarponcini, 1996). Three decades later, Building Information Modeling (BIM) has emerged as a solution for facility owners to address the challenges of poor information fidelity, interoperability, and usability in project delivery to support the lifecycle of their assets’ information. BIM is offering great potential to generate, consolidate and maintain these integrated databases, which contain a facility’s (or a portfolio of facilities’) relevant information to support operations and maintenance. Yet, despite increased research efforts aimed at developing tools and technical capabilities to support BIM uses for owners, of which BIM for Facilities Management (FM) is perhaps the most discussed, widespread adoption is still relatively low around the globe (Becerik-Gerber et al., 2012.; Giel & Issa, 2014).  Indeed, it has been reported that the utilization of BIM for FM, amongst other uses of BIM for owners, is falling behind design and construction applications of BIM (Akcamete et al., 2010). The reality is that implementing BIM in large owner organizations is a complex challenge. Using BIM for a single, sizable project may become a significant challenge, let alone a portfolio of projects. In particular, a significant barrier to BIM adoption for owners is the challenge of identifying and formalizing the information requirements needed to support model-based project delivery and asset management.  The issues underlying the slow rate of BIM adoption on the part of owners is multipronged. Becerik-Gerber et al. (2011) identified technology and process related, and organizational challenges in implementing BIM in the operation and maintenance processes. Kiviniemi and Codinhoto (2014) indicate that the difference in project based business and lifecycle management is one of the main challenges in implementing BIM in the FM processes. The literature on barriers in implementing BIM for FM (Liu & Issa, 2014; Becerik-Gerber et al., 2012; Akcamete et al., 2010; Forns-Samso, 2011; Sabol, 2008) indicate the complexity of the 96  implementation process. In our own studies of facility owners, we observed the complexity of the implementation process as one of the most important barriers (Cavka et al., 2015). The prevalent discourse around identifying requirements for owner handover models focuses on the required attributes primarily related with the components of the design. From this point of view, digital spreadsheets of component attributes are often seen as the critical representation of an owner’s modeling needs. However, the complexity of implementation is in part due to the overall shift in practice which is required throughout a facility’s lifecycle and across the different departments that are involved in the delivery and management of that facility. The shift in practice is mainly related to how individuals generate, consume, manage and exchange facility information across its lifecycle (Crotty, 2011). For owners, who are consumers of facility information during the design and construction phases and then shift into an information generation and management role (while retaining their consumption role) during the operations and maintenance phase, the role they play is crucial in initiating and carrying facility information throughout its lifecycle. Indeed, owners establish the facility’s requirements upfront (i.e. what are the needs, design criteria and the performance to be met), ensure compliance to the requirements during design and construction, and require deliverables that accompany the facility to assist with operations and facility management.   The advent of BIM, i.e. the transition from 2D graphical representation to digital representation of a facility which contains geometric and non-geometric project information in a structured format, is seen to offer many benefits to owners over an asset’s lifecycle (Eastman et al., 2011). However, reaping these purported benefits requires owners to be very specific in asking project stakeholders to deliver both a physical and digital product. Indeed, the development of project requirements with the appropriate amount of detail is an important step 97  since owner’s project requirements are considered to be the benchmark for all project related performance assessment. According to a survey of owners, more clearly defined BIM deliverables between project partners is the most important factor contributing to increased benefits of BIM (Jones, 2012). Over the past decade, there has been increasing reports of large owners, such as universities, that provide their building project teams with detailed guidelines and deliverable requirements (Kensek, 2015). However, establishing these requirements so that they inform not only the physical product being delivered, but also its digital representation containing related project information is a significant challenge. Indeed, owner requirements, in the form of design guidelines, codes and regulations, technical manuals, etc. are not expressed in computable formats that lend themselves to BIM-enabled project delivery (Brucker & Nachtigall, 2005). Furthermore, efforts to generalize owner requirements fall short, given the highly contextual nature of the construction and asset management industries. There is therefore a need to provide robust processes through which owners can develop requirements that facilitate and take advantage of BIM-enabled project delivery and asset management, while also allowing them to check for compliance to these requirements through quality assurance and quality control methods. BIM-enabled project delivery in this context relates to leveraging BIM for exchanging project information to support handover and FM functions.  While the second chapter of this dissertation investigates the handover, FM functions, and consultants’ design models to benchmark the current state of practice, the third chapter focuses on understanding the set of owner requirements to identify owner’s BIM requirements.   The aim of this chapter is to present the findings from a research project that investigated the development of owner requirements to support BIM-enabled project delivery and asset management using two case studies from Canada. Throughout this chapter BIM is used to refer 98  to both a data model (Building Information Model), and a process (Building Information Modeling). The interrelationship between the process and the model is further explained throughout the following sections. The main objective of the research project was to better understand the process of developing and formulating BIM requirements to support the lifecycle of owner’s assets. The authors set out to formalize an iterative approach to the identification and characterization of owner requirements as well as to develop a conceptual framework that would relate digital and physical products to an owner’s requirements and organizational constructs, which serves to underpin the formalization process. Throughout this chapter, the concepts of facilities management (FM) as an integrated process, and asset management as an FM function are often used. According to CEN, the European Committee for Standardization, and ratified by BSI British Standards "facilities management is the integration of processes within an organization to maintain and develop the agreed services which support and improve the effectiveness of its primary activities" (EN15221-1:2006). International Facility Management Association (IFMA) defines FM as a profession that encompasses multiple disciplines to ensure functionality of the built environment by integrating people, place, process and technology. FM is divided into the core competencies and the FM functions of these core competencies. While core competencies have a higher level of focus such as operations and management, technology, and project management, the FM functions focus on tasks related to the core competencies such as asset management and maintenance management.  An overall methodology to guide owners in the development of their requirements for BIM-enabled project delivery and asset management is first proposed. As part of the methodology, a classification of owner requirements is developed based on data collected and analyzed from ethnographic studies of two large owner organizations. Identification of required 99  model information is exemplified through analysis of identified computable requirements from the owner requirements. Computable requirements in this research refer to the owner requirements that can be represented in and queried from a BIM. Model information requirements are then exemplified through the identification of computable requirements. Finally, a framework is developed through which, the relationship between digital (model) and physical (design solution) products with the types of owner requirements and organizational constructs are described.   The findings from this investigation suggest that current owner requirements are represented implicitly and explicitly in a large number of diverse documents as well as in the minds of facility management professionals, typically with little formalized structure. In this sense, requirements are often not formalized in a way that matches the content and structure necessary for BIM-enabled project delivery. Existing requirements available from national and international guidelines often fall short in offering a complete set of BIM requirements. This research describes how current owner requirements relate to BIM in light of a potential model-based project delivery process. The findings presented in this chapter: (a) further our understanding of the challenges associated to developing BIM requirements from the owners’ perspective and offer a solution to overcome them, (b) highlight the complexity of identifying and formalizing information requirements from a long and diverse set of existing formal and informal requirements and then realigning these existing requirements to suit BIM-enabled project delivery and asset management, and (c) highlight a lack of understanding by owners as to how to go about actually developing BIM requirements. In this regard, the owner organizations that were studied lacked the understanding of what information to require and how to require it from the project teams. Indeed, during the investigation, three core challenges were identified 100  that related to establishing clear and detailed BIM requirements: (1) owners are not aware of the complete set of information they require to support asset lifecycle information, (2) they do not have enough experience in BIM to determine how much of this information can be exchanged and managed through BIM, (3) they are often unsure about how to require information in a BIM. The lack of means or expertise to evaluate the BIMs for quality and design compliance, and the lack of understanding of how these models can be leveraged for FM during the operations phase even if these owners require BIMs as part of the handover set after the completion of construction was also identified as a core challenge. The methodology and subsequent classifications and frameworks developed from this methodology presented in this chapter aim to overcome these challenges and help owners transition towards BIM-enabled project delivery and asset management through the development of clear and detailed requirements.  3.2 Background on BIM for Owners  Despite increasing momentum in BIM adoption by building owner organizations, “the utilization of BIMs during O&M is falling behind design and construction applications” (Giel et al., 2015, p. 350). Challenges, such as lack of BIM expertise and knowledge (Coates et al., 2010), diverse formats of data during handover and operations, and understanding what data is included in BIM and its effective use for daily work processes (Ghosh et al., 2015) still need to be addressed . This section includes background on owner requirements for project lifecycle phases, and the existing BIM requirements for facility owners. 3.2.1 Owner requirements for project lifecycle phases 3.2.1.1 Design and Construction  According to Whole Building Design Guide (WBDG), the General Services Administration (GSA) project requirements are based on the owner’s expectations of how the 101  building will be used and operated. All design, construction, acceptance and operational decisions are made based on these requirements. Owner’s Project Requirements (OPR) provide direction for the execution of a project and forms the basis for evaluating all activities and products during decision making throughout project lifecycle, addressing function, form, budget and time. Besides project and owner’s project requirements, design and construction also need to comply with building codes and consultant specific design standards, such as ASHRAE. In Canada, design and construction of buildings are regulated by national and provincial governments (National Building Code) and their respective building codes (e.g. BC Building Code, fire and plumbing codes). These codes supplement requirements for design and installation of systems and components, adapted to a province’s unique context. Government requirements and consultant specific design standards are often defined in detail, and are used repeatedly in each project. Therefore, they provide a better defined design evaluation methodology.  Topics related to owners’ requirements, including requirements capture, requirements formalization, and leveraging BIM for design reviews for compliance, have been studied from different angles in the literature. For example, Eastman (2009) describes a case study for GSA, which focused on “automating the design guidelines in a way that preliminary designs could be assessed and checked against specific criteria.” Based on predefined and formalized criteria automated assessments were performed based on data from the Industry Foundation Class (IFC) file for (a) spatial validation of the layout, and (b) circulation analysis of the layout. Research in compliance checking and auditing mainly focuses on BIM enabled code checking. Construction Real Estate Network (CORENET) was one of the first initiatives in automated code-checking (Choi & Kim, 2008). During the HITOS pilot project in Norway, the accessibility rules were 102  parameterized, mapped to their associated building objects and executed using Solibri Model Checker’s Constraint Set Manager (Greenwood et al., 2010). The General Services Administration (GSA) BIM-guidelines proposed that all planners seeking funding for their spatial planning projects would need to produce building information models for validation in an open standard (Greenwood et al., 2010). SmartCodes project focused on transforming thousands of paper-based codes into machine-interpretable rules that could be executed using either Solibri Model Checker, or AEC3 XABIO. Zhang et al. (2013) introduced a BIM-enabled, rule-based automated safety checking platform. Hjelseth (2015) describes BIM based model checking (BMC) as processing the content of information in BIM files, and states the high importance of the quality of the BIM file for reliable model checking which is measured as the structure and content of relevant information. Having no standardized procedure for converting design rules and regulations into digital rules, and large variation of how the designer is modelling and structuring (entering) information in the BIM software are listed as examples of barriers related to application of BMC by Hjelseth (2015). The author goes on to identify that prescriptive rules could be directly converted into computable rules. As an application of BMC, Statsbygg have developed a digital rule set in Solibri Model checker for compliance checking with their BIM guidance (Hjelseth, 2015).  3.2.1.2 Handover  Project information from design and construction is transferred to the owner during handover for use during the operations phase. It is essential to understand the required handover information to be able to effectively review handover artifacts for compliance to requirements. Research over the past years has identified many important issues with information handover from design and construction to operations. According to Ghosh et al. (2015) information 103  accuracy and relevance are the most critical variables from the perspective of information management; “for an accurate building information model and its successful use for FM, it is imperative that the owner proactively specifies the information requirements at the front end of the life cycle, so that the data is structured as per the FM’s needs”. Current handover of building information is often untimely, project documentation is not structured, nor complete, nor reusable, and contains inconsistencies. Owner operations personnel often do not know what equipment and systems are handed over to them before the buildings are occupied and are under their responsibility. Handover information must be manually entered into FM systems by the owner after the handover most of the time. Most owners do not have clear requirements for handover that are sufficient to ensure the usefulness of delivered information. Clayton et al. (1998) recognize missing or irrelevant information included in the closeout documentation, and identify several primary issues regarding the closeout documents including inappropriate format, and a mismatch in terms of structure and content. Information requirements differ per personnel within the same organization, since FM personnel require different sets of information to perform their tasks. Handover information often falls short on answering information and interaction needs of all O&M personnel. Previous research on FM information represents the variety of information required for FM functions and by O&M personnel. For instance, Liu et al. (1994) describe the most important facility information categories, such as floor plans and design specifications, whereas Clayton et al. (1998) list the key content for facility documentation, such as wall and door location, room and equipment identification and location, etc. On their part, Becerik-Gerber et al. (2012) describe the non-geometric data requirements, such as ID, name and service zone, group and type, etc. According to Becerik-Gerber et al. (2012) a BIM needs to be 104  seen as “an individual building asset and it introduces a novel data structure for non-geometric data requirements”.  BIM’s potential to create, exchange, and manage information has been widely claimed by many researchers over the last ten years (e.g. Eastman et al., 2011). According to Mayo and Issa (2012), the advantage of BIM resides in the attribute and the relational database format” and the owner should identify the format that best suits the internal needs of the organization and include those format needs as requirements. Patacas, Dawood, and Kassem (2015) consider the limited use of open standards that define the information requirements for specific FM tasks as a key barrier for improving the information handover to the FM phase. Open standards have the potential to protect the integrity of the owners’ data over the years, and they promise a fair market for the software and information providers. However issues related to BIM enabled information exchange through open standards currently remain to be resolved. The effort towards developing standards to support widespread use of BIM encompasses five main topics: (i) Information Delivery Manuals (IDM), (ii) IFC, (iii) Model View Definitions (MVD), (iv) BIM Collaboration Format (BCF) and (v) buildingSMART Data Dictionary (bsDD) (formally International Frameworks Dictionary- IFD) to be considered during information exchange from design and construction, through to operations. Although BCF and bsDD may not relate to the creation of BIM objects that represent real objects in models, they are important parts of open BIM. The National Institute of Building Sciences (NIBS) defines Construction Operations Building information exchange specification (COBie) as an information exchange specification (IDM+MVD) for the life-cycle capture and delivery of information needed by facility managers. According to Love et al. (2014) COBie and the FM Handover MVD “provide a structure for the information the owner needs, but they do not support the owner with what to populate them with 105  in order to receive value later in the lifecycle” (Mayo and Issa, 2012). Building properties as represented in a BIM are listed as geometry and spatial relationships, quantities, and building elements’ properties (Hamil, 2010). The model from an IFC perspective has three fundamental entity types known as objects, properties and relations. Parametric objects in BIM may have geometric or non-geometric attributes with functional, semantic or topologic information (Volk et al., 2014). Table 11 below summarizes some concepts of IDM, IFC, and MVD. These concepts are used in Section 2.4.4 for mapping parts of a BIM to the parts of owner organization and its requirements.  Table 11: Summary of some concepts of IDM, IFC, and MVD Source Key Concepts IDM Entities, attributes, property sets and properties IFC Classes, attributes, relationships, property sets, quantity definitions, etc. MVD Entity, attribute, relationship, properties MVD Handover: Model structure [spatial containment (site, building, building storey, space), groups (zone)], architecture (building elements), MEP (MEP elements, MEP systems) COBie Information sets (attributes): Facility, floor, space, zones, component, system, type Coordinates, attributes, connections, contacts, documents, issues Job, resource, spare  3.2.1.3 Facilities Management and Operations  It is essential for O&M personnel to access required information to operate and maintain equipment and systems in buildings efficiently and effectively for the following reasons among others: to extend the service life of equipment, to optimize maintenance activities, to achieve energy efficiency, and to minimize labor time and equipment downtime. Defining and formalizing the required FM information is an essential step in BIM implementation. Becerik-Gerber et al. (2012) define interactions between BIM and FM by illustrating application areas 106  and data requirements for BIM-enabled FM practices. Although information is essential for performance of FM functions, having too much of unrequired information makes it challenging to manage. Mayo and Issa (2012) reference Hjelsth (2015), and state that “an overload of information causes a lack of purpose, and therefore what could be information, is simply unused data.” This necessitates identifying the information that is useful, identifying the use of this information during operations, and gathering it from the project participants in a useful way. Mayo and Issa (2012) suggest that what facilities management personnel need is more non geometric information. According to Mayo and Issa (2012), consideration of the desired intent for the utilization of information is necessary to determine optimal information requirement, and when clear deliverable requirements exist, it is possible to collect information early in the project and with specific purpose. For example, Motawa and Almarshad (2013)  proposed a methodology that combines the use of BIM and case-based reasoning to capture and manage knowledge related to a BIM to inform maintenance teams about the history of the building and its components. 3.2.2 Owners BIM Requirements  To understand an owner’s requirements landscape, it is also essential to understand the current state of owner BIM requirements around the world. This section summarizes owner BIM requirements from the literature. A study of owner requirements and BIM use among building owners completed by Korpela et al. (2015) indicates the  great variability in the level of detail found in owner requirements specifications. Owners are often unsure of what BIM deliverables and processes to require.  According to Mayo and Issa, owner guides and standards are purposely kept generic, but BIM is “now forcing owners to provide more precise information regarding required deliverables” (Mayo and Issa, 2012, p. 673). As referenced in Mayo and Issa (2012), 107  “include the abundance of data as one of the challenges for facilities management in reaching the full potential of BIM (Lewis & Whittaker, 2012)”. To ensure effective information exchange, owners’ FM BIM guidelines dictate details of what should be included in a BIM, and BIM guidelines and deliverable requirements insure a standardization of data that can more easily be incorporated into FM software (Kensek, 2015). According to Mayo and Issa (2012), owners’ misconception of the importance of the data format is one of the reasons for errors in FM programs and operations, which suggests that the owners are too focused on the information and not enough on the medium. Clayton et al. (1998) describe the owner’s degree of structure requested by consultants as an “open question” and a “moving target.” Currently there are different ways to inform BIM use in project and organizational scales. Table 12 below summarizes only a few of these from the perspectives of National Institute of Building Sciences (NIBS), NBIMS-US, Singapore BIM Guide, and PennState-CIC. In terms of Publicly Available Specification (PAS) for standards around requirements; PAS 1192-2:2013 focuses on graphical and non-graphical data and documents that are accumulated from design and construction activities.  The British Standard (BS) 1192-4:2014 “defines a methodology for the transfer between parties of structured information relating to facilities”.       108  Table 12: Types of BIM requirements for industry, organization, and project scales  Documents / prescribes Use / focus BIM Guideline (NIBS) process and procedure for a design team to produce a standard set of BIM documents BIM Standard (NBIMS-US) effective, repeatable elements and mechanisms for the creation, exchange, and management of BIM data Owner’s BIM Guide (Singapore BIM Guide) possible deliverables, processes and personnel / professionals involved to clarify the roles and responsibilities of project members, which are captured in a BIM Execution Plan BIM Planning Guide for Facility Owners (PennState-CIC) a procedure to develop a strategy for integrating BIM throughout the organization the decisions required to define an organization's standard BIM processes and practices, design information integration strategies, appropriate BIM contracting strategies  Investigation of the leading organizations in BIM adoption gives further details on how organizations leverage BIM guidelines and execution plans. BIM requirements of leader organizations’ in the North American industry such as PennState, GSA, USACE, and USC will be summarized in the following paragraphs. Each organization uses BIM for different FM tasks and functions, therefore require different model content, structure and Level of Development (LOD). This results in developing owner BIM requirements that are a fit for their organization. One standard therefore is often not applicable to all organizations. However by following guidelines and processes each organization can tailor BIM implementation to its internal processes and technology infrastructure according to the organizations strategic plan.  Pennsylvania State University’s (PennState) BIM Planning Guide for Facility Owners (C.I.C.R. Program, 2013) is intended to inform an organization about how to implement BIM and lead them through steps required to integrate BIM into the organization. Instead of pushing a list of different types of information to be included in the owner specific BIM plan, 109  determination of the required information is left for each owner and each project. Penn State’s BIM Project Execution Planning Guide (2010) defines the appropriate uses for BIM on a project, along with a detailed design and documentation of the process for executing BIM throughout a project’s lifecycle. Within the Penn State Office of Physical Plant Case Study document, required assets for this project are listed with parameter and attributes required for each asset. As identified in the PennState Asset Attribute List (V3.0) document, at a minimum each asset is required to include listed parameters, a barcode, and the following: O&M manual, installation guide, submittal information, warranty documentation, commissioning report, and any additional documentation.  GSA National BIM Program establishes a policy to require BIM adoption for all major projects, provides guidance for continued use of BIM data in asset and facility management. GSA has three tiers of requirements for BIM based project delivery depending on the specific use of the model. Tier one is a spatial program BIM and represents accurate as-built geometry for equipment. Tier two BIM includes equipment information. In tier two, BIM equipment objects in the as-built BIM shall contain geometric data and a minimum set of attributes. Tier three is an as-designed BIM with energy analysis predictions. GSA also requires exchange of facility information using COBie.  The United States Army Corps of Engineers (USACE) BIM contract requirements cover BIM contract language, BIM Project Execution Plan (PxP) template, minimum modeling matrix, and BIM submittal checklist. PxP assists organizations in planning their BIM process, and provides a standard format that streamlines the development of the execution plan. It improves the quality of the plans and accelerates the review and acceptance process. Minimum modeling matrix (M3) provides information on modeling requirements and scope-LOD-grade. According 110  to USACE BIM contract language “model element” refers to the 3D geometry, facility/site data refers to the non-graphical info attached to model objects, and model consists of combination of geometry and data. USACE provides quality control parameters, design and construction review information, general submission requirements, modeling and data requirements and additional requirements such as classification format to be used.   University of Southern California (USC) BIM Guidelines (2012) document defines the design and construction scope of work and deliverables for using BIM. Guidelines provide information on BIM process, and deliverables such as data requirements, model LOD, required COBie worksheets and information, and modeling requirements. Investigation of the University of Southern California (USC) Facilities Management Service’s (FMS) website by Kensek (2015) “showed a detailed plan including standards, file names, parameter lists, and other requirements of BIM data, which were specifically designated for facilities management use, as deliverables on new construction projects” (Kensek, 2015). USC BIM Guidelines document includes BIM data acquisition guideline for FM services, which contains data on USC Master Attributes, asset management attributes, minimum set of objects to be modeled for space management objectives, and required COBie worksheets.  Cheng and Lu (2015) review the efforts that the public sector has put forth for BIM adoption worldwide (the United States, Europe, Asia, and Australia) in order to highlight the successful implementation of BIM. The efforts of the public sector, such as preparation of BIM guidelines and standards, in different countries are described and compared in Cheng and Lu (2015). However instead of a nationwide scale, the focus of this study is on owners at the organizational scale, and specifically on the owners BIM requirements as they relate to FM. 111  3.3 Research Methodology  A research project was conducted over a three-year period involving case studies of two large owner organizations to investigate how owners can formalize their requirements to support BIM-enabled project delivery and asset management. According to (Yin, 2014), case study research is appropriate when investigating contemporary phenomenon in its real-world context. The research methodology is similar with buildingSMART Alliance’s COBie case studies in terms of analysis of work processes using process and information flow diagrams, and analysis of owners’ technology infrastructure to identify required information. This methodology is also similar to Becerik-Gerber et al. (2012), Becerik-Gerber et al. (2011), Forns-Samso (201), and Eastman et al. (2011) in terms of analysis of large institutional owner organizations to understand FM processes, required information, and operational use of FM information through performed interviews with personnel, and handover process and document analysis. However instead of focusing only on one FM process, one set of technology, or investigating either models or documents, this research adopted a multifaceted approach, focusing on multiple FM processes, a set of FM technologies, and model analysis from the two case studies. This research also involves the investigation of changes within organizations over the research period. It employed multiple data collection methods. Research activities for the two case studies of owner organizations consists of three layers.  The first layer focused on the Organization where the FM processes, organizational structures and the technology infrastructure were mapped, and project records documents were analyzed.  In the second layer, a diverse set of artifacts that represent aspects of owner requirements, including codes and standards, technical requirements, project requirements, personnel requirements and existing BIM requirements were collected and analyzed.  In the third layer the model content and structure of project BIMs for the two case 112  study organizations were analyzed. The duration of the research project can be attributed to the aspects of the research methodology such as using two different organizations as case studies, the number of methods used for data collection, and thorough analysis of the collected data. The research also included observation of the decisions made and changes which happened over time as a result of the organizations’ intention to leverage BIM for FM. The main difference between the two organizations was; while the university performed FM functions using its own resources, the government agency preferred to contract out FM functions.   The first case study involved a large Canadian university. The focus was on the building operations department, which is responsible for the operations and maintenance of all non-residential buildings on campus. The department is responsible for 225 core university-owned buildings, with a total gross floor area of 810,119 m2. Organizational structure was mapped and analyzed to understand the roles and responsibilities of departments. FM processes were mapped to understand required steps and exchanged information to perform FM functions. Organizational technology infrastructure was mapped and analyzed to understand the managed FM information, its structure and how it relates to model content and information structure. Interviews performed, shadowing, walkthrough activities with the O&M personnel helped with understanding the current FM processes, required information to perform FM functions, issues with current information technology, personnel information interaction requirements, and building characteristics that negatively impacted the performance of O&M functions. This multifaceted analysis led to the identification of different sets of requirements that make up owner requirements for this organization. Three university projects from the same campus and their models were analyzed from the perspectives of information content and modeling to evaluate the models fit for FM use. Revit schedules, Navisworks, Solibri Model Checker, and 113  EcoDomus (lifecycle information management tool) were used to investigate the project models. Technical guidelines documents and interview transcriptions were analyzed extensively to identify owner requirements that can be turned into computable requirements which can later be queried in project models. Further analysis of the identified computable requirements resulted in the classification of properties and relationships related to model objects, and finally identification of required model information. The final step of the analyses was to develop an understanding of how each part of the organization, requirements, and BIM relate to each other in the context of model-based project delivery.   The second case study involved an agency responsible for delivering and maintaining public infrastructure for a provincial government in Canada. The agency is located in a different province than the first case study, and it is responsible for infrastructure planning, building and managing government-owned infrastructure which includes health facilities, schools and other public infrastructure in the province. The agency is responsible for over 1,600 buildings, representing an approximate total gross floor area of 2,330,000 m2. The focus was put on the Capital Planning Division and the Properties Management Division. Data was collected through interviews with personnel from three divisions, analysis of requirements documentation (technical guidelines, owners project requirements), and analysis of organizational technology infrastructure and managed information. A large institutional project model was analyzed to identify the available information and geometry and compare it with the identified requirements. The computable requirements identified from the requirements analysis were combined with the list of identified requirements from the first case study to develop a richer representation of model information requirements and to explain the relationships between organization, requirements, and BIM. 114   An overall methodology was established to support the owner requirement formalization process (Figure 25). The methodology was developed initially to support the research process. Throughout the project though, it became clear that it could serve to support the owner requirement formalization process as both processes have similar objectives. To support the proposed formalization process, a conceptual framework was developed that would relate digital and physical products to owner requirements and organizational constructs. This framework was developed through an iterative coding process (Miles et al., 2013) where themes emerged, were refined and tested. The coding was undertaken by the first author and validated subsequently by two research associates. Validation of the framework took the form of protocol coding, where the research associates coded additional data sets using the framework and expanded or commented on it, until the team felt they had reached a form of theoretical saturation. The remainder of the paper describes the steps and activities undertaken in the formalization process and the framework is described.  3.4 The formalization Process: An Iterative Approach The four steps in the formalization process are the following (Figure 25): 1. Identify the range of owner requirements through investigated of data sources such as organizational guidelines, technology infrastructure, personnel requirements, and owners’ BIM requirements  2. Investigate and classify the scale and scope of owner requirements in the context of project delivery and asset management  3. Identify requirements that are computable and can be supported through BIM-based project delivery and asset management. Exemplify required model information through analysis of computable requirements  115  4. Develop a conceptual framework for relating the project’s digital and physical products with the owner requirements, and organizational context    Figure 25: Methodology to understand the owner requirements, identify required information, and how they relate to BIM 3.4.1 Step 1: Identify Sources and Collect Data  In the first step, the different sources of requirements were identified and relevant data was collected. This entailed a mixed-method data collection strategy, which included both quantitative and qualitative data. Data sources included mapping current handover and FM processes, technology infrastructure, organizational structure, documented organizational requirements, handover documents, design and construction documents and models. The principal sources of data are summarized in Table 13.  (1) Identify sources & collect data(2) Identify types of owner requirements(3) Identify required information(4) Relate project's digital and physical products with requirementsTo classify the landscape of owner requirements To describe how digital product (BIM) relate to organizational context, and owner requirements To formalize computable requirements To identify model information requirements - To identify the landscape of owner requirements 116  Table 13: Overview of collected data  Source of requirements Description Large Canadian University Organization’s Technical Guidelines Technical guidelines act as the code of quality and performance for the design, construction and renovation of University-owned institutional buildings Owner’s FM applications used for managing FM information FM applications were investigated to understand managed, therefore required, FM information  PeopleSoft (asset management, maintenance management), Archibus, Facilities Capital Planning and Management (VFA Facility), Laserfiche, Records Retrieval System Interviews with FM personnel Interviews were used to understand  - The available practice for performing FM processes - Personnel information requirements and preferred design characteristics5   Project models Three project models (two research buildings, and a mixed use building- student residence and college) were analyzed to understand and compare, available and required model content and structure Canadian Provincial Government Body Basic Master Specifications (BMS) Sixteen MasterFormat divisions explain owner’s requirements such as design and performance requirements Organization’s Technical Guidelines  Technical guidelines are the design requirements for government owned facilities Owner’s Statement of Requirements (OSR) for a sample project  OSR documents were analyzed to understand the project specific requirements  Owner’s FM applications used for managing FM information FM applications were investigated to understand managed, therefore required, FM information  Building and Land Information Management System (BLIMS), Facilities Capital Planning and Management (VFA Facility), Facility Maintenance System (FMS), Work Order Request Tracking System (WORTS), RAP (planning program) Interviews with the FM personnel Interviews were used to understand - The available practice for performing FM practices - Personnel information and preferred design characteristics Project model A large institutional project model was analyzed to understand and compare, available and required model content and structure  Taking a deeper look into the guidelines and documents available to project delivery teams that relayed specific owner requirements uncovered that many organizational requirements were gathered in disperse groups of documents that consist of hundreds of individual documents,                                                  5 Design features/characteristics that have an effect on the performance of O&M activities. 117  which may be hundreds of pages long when put together (Table 14). Sourcing and collecting the data also exemplified the extensive number of divisions, individual documents and total number of pages that need to be skimmed in order to understand the content within the requirements documentation. Additionally, certain sets of requirements oftentimes reference other requirements such as codes or design standards, which require an understanding of the content of referenced documents. Once aggregated, the entire “requirements landscape” of both owner organizations was considerable. Table 14: Owner requirements are often documented in separate pieces of lengthy documents, which make it challenging to identify the complete set of requirements Organization Requirement documentation  Large Canadian University • Guidelines by specification divisions (17 Master Format Divisions - 141 individual documents - 866 pages) Provincial government body • Technical specifications (23 Master Format Divisions, 415 individual documents) • Owned infrastructure (facilities owned or leased, and managed): o Basic Master Specifications (16 Divisions, 365 individual documents)  In terms of qualitative data, a total of twenty-seven interviews with personnel in both organizations were conducted (Table 15). The interviewed individuals were of different FM departments within each organizations. The interviews allowed the research team to capture the sets of information uses and requirements, understand technology used by different departments, and to understand what works and what does not work in the current practice. The interviews were designed to uncover each individual’s “information landscape” as well as their views on 118  current project delivery and asset management process. The interviews also touched on how they envisioned BIM to impact this current state.  Table 15: The facility management personnel that we interviewed for the two owner organizations we studied  Division Department Interviewed personnel Large Canadian University Infrastructure Development    Building Operations Records  Records System Administrator Asset Stewardship   Manager of Technical Services Maintenance & Renewal Senior Analyst Maintenance Technical Specialist  Head Maintenance Engineer Millwright Operational Effectiveness Program Manager Utilities and Energy Head Maintenance Engineer (BMS Center) BMS Specialist Provincial government body Capital Projects Division Project Services Branch   Project Delivery Branch    Technical Services Branch Assistant Deputy Minister Executive Director Head, Procurement Standards Executive Director Project Director  Senior Project Manager Director, Project Portfolio Mgmt. Director, Facility Evaluation Facility Design Coordinator Supervisor-CAD/GIS and Records CAD/GIS Technologist Building Security Systems Engineer Properties Division Regional Operations Branch Assistant Deputy Minister Director Facilities Manager Operations Supervisor Culture/ Heritage - Director, Capital Development Logistics Coordinator  The outcome of this first step in the Requirements Development process was a structured set of both qualitative and quantitative data that would serve as basis for analysis, formalization and consolidation into a clear set of requirements to inform BIM-enabled project delivery and asset management.  119  3.4.2 Step 2: Identify Types of Owner Requirements   Once the data was sourced and collected, the next step was to analyze it and set-up the requirements formalization phase. The analysis phase allowed the research team to develop an understanding of the content, design conditions and information sought through the requirements, the needs of the different stakeholders that were interviewed and perhaps, most importantly, any gap between requirements, needs and a future BIM-enabled state. In other words, it allowed the research team to gain an understanding of both the ‘information landscapes’ for each individual and the ‘requirements landscape’ for each organization, and understand where the gaps were that needed to be addressed moving forward. These requirement ‘landscapes’ were found to vary considerably between both organizations, depending on the department and user groups, and based on information tracked in FM databases to support FM functions, which is one of the main challenges in proposing generalized requirements for an entire industry segment. The two organizations had different FM strategies in terms of processes and technologies they use to perform FM functions. These functions are different in that they require different sets of information at different levels of detail, and they use different processes and technology infrastructures. The first iteration of the analysis was used to define the organizational ‘requirements landscape’, termed Owner Requirements. Five main categories emerged to define the Owner Requirements: (i) codes and standards, (ii) organizational requirements, (iii) project requirements, (iv) personnel or individual requirements, and, in a future state, (v) BIM requirements (Table 16). It is important to note that although both organizations were investigating the potential to leverage BIM for handover and operations, they did not have formalized BIM requirements fully developed. Yet, BIM requirements were 120  included as part of the owner requirements since they are an organization’s main points of reference once model-based delivery is implemented.  3.4.2.1 Codes and Standards Codes and standards include federal, provincial municipal codes, such as building, plumbing, fire, seismic codes, design standards, such as ASHRAE for mechanical design, and sustainability guidelines, such as LEED and BREAM. Codes and standards are the overarching requirements that all organizations and every project have to comply with (although not in the case of sustainability guidelines, except where mandated). With the advent of BIM, many national standards, such as the NBIMS-US (NIBS, 2007) and the UK’s PAS 1192 series (UK: PAS, 2016), have been developed to inform modeling and information delivery. In Canada, no national BIM standards currently exist.             121  Table 16: Requirements landscape from the owners’ perspective and classification of owner requirements Scale Categorization Definition, examples, and required information  Codes & Design Standards Federal/provincial/municipal building codes and regulations, standards of design for AECO professionals  Building, plumbing, fire, seismic codes, ASHRAE standard for mechanical design, LEED and/or BREAM sustainability guidelines   Organizational Requirements Owners’ general requirements about built infrastructure and space, system design, equipment and component selection, design and installation  Technical Guidelines, Master Specifications  Project Requirements Project specific requirements that are in more detail than the owner organization’s requirements  Project specific Owner’s Statement of Requirements (OSR)  Personnel Requirements Informal and undocumented O&M personnel requirements for design, information, and information interaction, and access  Design conditions, information and technology requirements  BIM Requirements Guidelines for using BIM in an organization (aka BIM implementation plan)  General organizational rules for BIM processes for owner’s projects BIM  Project BIM Execution Plan for a project team  Project specific BIM process and information requirements  3.4.2.2 Organisational BIM requirements  Organizational requirements are the overarching requirements and guidelines which apply to all of an organization’s projects or assets. They regulate what products are used, how information is developed and delivered, and so forth, across an organization’s portfolio. Overall it was understood that organizational requirements were developed to ensure project compliance to codes and design standards, that the building and its systems would operate and be maintained as intended, and project artifacts would be (re)used during operations to help perform O&M functions. Organizational requirements were also seen to cover different aspects of a building project, such as design-construction-operation processes, component-system-space BIM122  characteristics, submittals and handover documentation characteristics such as content, format, structure and representation of handover information. Organizational requirements include technical guidelines and specifications for the built infrastructure. Table 17 contains the set of organizational requirements documents analyzed as part of this research. For instance, both the Canadian university and the provincial government body developed a series of technical guidelines which act as the basis for design for all its projects. It represents in a sense a formalization of acquired knowledge and experience to ensure best practices in the delivery of physical assets for the specific organization. It also provides a standardized structure for information delivery based on accepted classification systems (e.g. Masterformat). The objective of developing organizational requirements is tied to consistency of product specification and project delivery.  Table 17: Analyzed documentation relaying owner specific requirements Organization Available documentation  Large Canadian University • Guidelines by specification divisions • Design and approvals • Construction and turnover • Structural design & snow load • Sustainability Provincial Government Body • Technical specifications • Owned infrastructure (facilities owned or leased, and managed): o Master specifications for Building Management and Maintenance Services o Property Management Services Master Specification o Basic Master Specifications o Small Projects Master Specifications o Guidelines and Standards for Owned Infrastructure • Supported infrastructure (schools, health facilities, and post-secondary facilities) • Technical bulletins  123  3.4.2.3 Project Requirements  Project requirements relate specific goals, needs, and design and installation requirements in the form of design briefs or owner’s statements of requirements for a specific project. Project review by owners will be done against project requirements through detailed design review at certain stages of a project. According to the Whole Building Design Guide (WBDG) the owner’s project requirements define the expectations, goals, benchmarks and success criteria for the project. In this sense, the project requirements may be used as a benchmark of compliance checking for a proposed design solution. For the provincial government body that was investigated, an owner’s statement of requirements (OSR) for a specific project was analyzed to uncover the types of requirements that had been formalized and communicated to the design team. Examples of these are:  Space program and list: functional requirements for spaces, area requirements, room data sheets  Overall access adjacency and circulation requirements: access, circulation and adjacency diagrams   Architectural descriptions and requirements: Code and city approval requirements for architectural design and components. Covered topics include codes, relations and standards, public consultation, sustainability, building shell, materials and finishes, communication, security, fire protection systems, access and circulation, acoustic systems, accessibility, etc.  Mechanical, structural, civil, electrical systems descriptions and requirements: system/equipment design and installation requirements such as serviceability, location requirements for main equipment 124   In the context of this specific OSR, several issues were raised by different interviewees. For instance, it was mentioned during one of the interviews that “[…] there's a lot of ambiguity that goes into them” (Project Manager for the Owner). Project requirements may explicitly reference or include organizational requirements, such as technical guidelines. This causes some ambiguity as project teams now must meet both the OSR and the technical guidelines and primacy is not always evident.  3.4.2.4 Personnel Requirements  An owner’s personnel require different sets of information to perform their functions. Individual requirements cover information requirements and technology requirements, among others. For instance, O&M personnel require information to be provided at different levels of detail, in reusable format, and prefer different information visualizations depending on the task they perform. Focusing purely on O&M, the analysis of the interviews that were conducted in the context of this research project uncovered the personnel requirements to perform O&M tasks are presented in Table 18. Although the personnel in Table 18 may be responsible for the maintenance of a set of equipment that make up a system (maintenance personnel), responsible for operating an entire system (BMS personnel), or responsible for managing the information about the same equipment and system from an operational perspective (asset management personnel) they still require different sets of information, at different levels of detail, and with different visualization of the same information to function. The interviewed personnel also required up to date and integrated information that is easy to access. However, at the time of project handover after construction, project information is not required in a reusable format in terms of asset categorization, required asset attributes, and with the structure that enables reuse and mapping this information with the owner’s databases. There are sections within owner 125  requirements that include the requirements for handover documentation format in terms of paper vs digital (pdf), or size of the paper record documentation. But this level of detail in documents fails to meet the personnel requirements outlined above. Personnel’s technology requirements cover interface, information visualization, and integration of FM applications. The maintenance personnel that we interviewed mentioned the need for visualization of building systems in order to understand the relationships between spaces, equipment, and systems. However, the technology infrastructures within the organizations that were studied did not allow for the visualization of 3D model geometry, and any model queries related with relationships between spaces, equipment, and systems. Table 18: Information required by O&M personnel to perform maintenance, building systems operation and monitoring, and manage assets  O&M Function Required Information Maintenance Personnel Maintenance  Preventive Scheduled- Periodic Reactive   Design criteria,   commissioning information (e.g. component performance),   replacement part information,   vendor information,   serial number,   location,   warranty information,   cost (to replace, maintain etc.),   system visualization,   system performance information,   locations of panels and valves that control equipment (e.g. electrical panel location, shut off valve location),   sequence of operation (start-up/ shut down information),   maintenance history BMS Operation Monitoring/ Tracking   Location,   commissioning information,   design criteria,   equipment performance information,  system performance information,   accurate system visualization that includes all required system components Asset  Management Asset Management Track operational costs Track life cycle costs Maintenance info Maintenance schedules Procurement  PM maintenance schedule,   PM inspection report,   key plans,   backflow prevention assembly test report,   systems list,   equipment lists,   part of what system,    required database attributes (e.g. supplier and manufacturer information, manufacturer, performance data),   cost information related to replacing and maintaining equipment/system,   maintenance history,   installation manuals  126  3.4.2.5 BIM Requirements  BIM requirements are found in various forms and can take on different meanings within an owner organization. The proliferation of BIM policies, standards, guidelines and protocols around the globe are a double edged sword for owners looking to transition towards BIM-enabled project delivery and asset management. On one hand, they are a great resource for owners, which do not have to “start from scratch” to build their own internal requirements. On the other hand, there is inconsistency in the terminology and in the way these documents are used and developed. At the root, a clear differentiation between policies, standards, guidelines and protocols is still lacking, although there is some work underway in this domain (e.g. bimguides.org, bimdictionary.com). The following is a first outline of this differentiation based on our interpretation of the work in other domains:   In the case of BIM, an organizational BIM policy could be as simple as mandating BIM deliverables on all projects. The policy will not dictate the content of the model nor how it should be delivered, simply that it must be delivered.   BIM Standards: A BIM standard dictates the information required, to what extent it is required, how it is to be structured and how it is to be delivered, among other things (e.g. PAS 1192-2, PAS 1192-3). The principle intent of a BIM standard is to ensure consistency in BIM implementation and BIM-enabled project delivery. There exist two levels of standards: industry standards (such as those published by ISO) and organizational standards.   BIM Protocol: A BIM protocol would establish the rules on modeling processes and information exchanges for various uses. In the UK, the Construction Industry Council developed a BIM protocol (Construction Industry Council, 2013), stating that: “The BIM 127  Protocol is a supplementary legal agreement that is incorporated into professional services appointments and construction contracts by means of a simple amendment. The Protocol creates additional obligations and rights for the employer and the contracted party.” Similarly, to BIM standards, protocols can exist at the industry or organizational level, however they also exist at the institutional level, being shared amongst groups of individuals from the same discipline, for instance. The principal difference between standards and protocols relate to the fact that standards dictate measurable outcomes, whereas protocols dictate a set of rules on how those outcomes should be achieved.   BIM Guideline: A guideline is more normative in tone and is not necessarily enforceable. A BIM guideline outlines the general steps, roles, responsibilities, infrastructure, etc. that are susceptible to change overtime within an organization. BIM guidelines should remain flexible and evolve over time as an organization gains maturity.   BIM Execution Plan: At the project level, BIM execution plans dictate specifics relating to a single project. According to the Computer Integrated Construction Research Group: “A BIM Project Execution Plan […] outlines the overall vision along with implementation details for the team to follow throughout the project” (C.I.C.R Program PSU, 2010, p.2). The BIM execution plan refers back to the owner organization’s BIM standards, protocols and guidelines and contextualises them within a project. It is used to gain consensus amongst the team and align expectations and intentions around BIM uses and deliverables to ensure the project team is all on the same page.   An investigation of BIM requirements from GSA, USACE, PennState, and USC indicate that while these guidelines outline general requirements for BIM, they do not provide a detailed and complete set of information requirements. This may be an outcome of the nature of 128  construction projects in general, since each project is unique in terms of its space, systems, and equipment design. In this sense, owners may require more detailed sets of information for certain building projects that have unique properties such as complex systems design, or complex space relationships or space properties. However, there are recurring asset information attributes that are common to all projects and that are required over the assets lifecycle that can be standardized. These information requirements relate to classification of systems and equipment for instance, which should be consistent across an organization. COBie is a standard which can be useful to owners to require information in a particular format, however while COBie and FM MVD “provide a structure for the information the owner needs, but they do not support the owner with what to populate them with in order to receive value later in the lifecycle” (Love et al., 2013 in Mayo and Issa, 2014).   In the investigation presented here, establishing these BIM requirements was the focus and understanding where each requirement resides and what form it should take was a challenge. Figuring out tracked / managed information within asset and space databases was one of the primary strategies to set these requirements. However, there is an understanding that for projects with complex systems, there may be additional information requirements that exceed the managed information in the organizational asset database that may be required. Thus, to define BIM requirements, set up mechanisms become as important as the requirements themselves.  3.4.3 Step 3: Identify Required Information   Once the analysis of the requirements was completed, the next step was undertaken to identify required information. This step involved extracting information requirements that can be represented, exchanged, and checked for compliance in BIM relating to both physical and non-physical design characteristics of the project. We use the term ‘computable requirements’ to 129  define such requirements (Figure 26). Information requirements were derived from extensive analysis of documented organizational requirements, project requirements, and personnel requirements. The information requirement identification process involved identification of computable requirements from the different type of requirements, and later identifying related model information that need to incorporated in the model.   Figure 26: Computable requirements were identified from the analysis of owner requirements  A classification based on asset type (objects i.e. types of room, mechanical equipment and system) and representation structure (relations and properties) was used. The terminology used throughout was based on object-oriented modeling structures and IFC.  Table 19 provides an example of the method used to identify required information from the analysis of owner requirements on the case study of the Large Canadian University. As an example, in  130  Table 19 the requirements for electrical and communications rooms are highlighted and the computable requirements related to these room types are identified. The required information for these room types and how it relates to model information is then presented based on the classification and terminology mentioned above. Complete analysis of the various sources of information results in the categorization of information required in BIM for these room types, in order to evaluate design compliance with owner requirements. In the example below required information based on these two room types can be summarized as room type (e.g. electrical room), orientation within the building, wall type and wall fire rating attribute, fire and life safety equipment in the room, ceiling type, space usage information, and access requirements. 131  Table 19: The computable requirements we identified from owner’s requirements documentation helped us identify what information to include in BIM in terms of spaces   SPACE RELATED REQUIREMENTS  Requirement  Required Information Documented Organizational Requirement 1.6 Electrical Rooms .1 The preferred location for Electrical Rooms is on North or East exterior building wall (for cooling). Orientation of a room type within a building   Space/ Room type/ Location 1.7 Communications Rooms .2 No fire separation or resistance rating is required on the walls or ceilings provided the walls are constructed of 16mm Type X GWB on both sides of stud walls.  .6 False ceilings are not permitted in communication rooms. .8 All Communications Rooms shall be designed and located in the building so that direct access is from a common or non-secure area.  Wall fire rating of a room type   Equipment required in a room type  Ceiling type that is not permitted in a room type  Access condition specific to a room type Space/ Room type/ Wall type/ Assembly property (Wall FR)  Space/ Room type/ Equipment  Space/ Room type/ Ceiling type  Space/ Room type/ Access 1.11.1 General Requirements (Custodial Rooms) .5 Door to custodial room to swing out. .2 Main Floor Custodial Room near Loading Bay. 400 square feet per major building is required. Room is to be located very close to a loading bay. .1 Dimensions: 20 feet by 20 feet .2 Door width: 48 inches; in-swinging Door size and swing direction of a room type   Location of a room type   Required minimum area and dimensions of a room type Space/ Room type/ door type/ door property (width and swing direction)  Space/ room type/ floor of the room type Space/ Room type/ Size (width - length) Section 15001 - Mechanical – General Requirements .7 Submit to Building Operations a set of Issued for Construction drawings showing access paths to all equipment, paths for removal and replacement of proposed equipment Representation of access space for mechanical design drawings Paths to equipment  Paths for removal  Paths for replacement 2.2 Mechanical Room Detail  .1 Locate Mechanical Rooms in areas accessible from outdoors. Confirm that sufficient space is provided to remove largest piece of equipment from the Mechanical Room. Accessibility based on a room type  Space required for moving the largest equipment from a room type  Space/ Room type/ Accessibility from outdoors  Space/ largest equipment in space/ space to remove equipment from room (and building) Interviews There should be elevator access to floors where the mechanical rooms are located.  Elevator access for a room type (mechanical room)  Access to space Space/ room type/floor of the room / availability of elevator to the floor/ clear access between elevator and room Project OSR The project OSR includes information on space list, required areas, and required access/circulation/ adjacency requirements Required spaces, areas, circulation and adjacency between spaces Room name, room type, room area, access between spaces, space/room adjacency   132  While Table 19 includes examples for the computable requirements which were identified from owner requirements documentation and identified required information to include in BIM in terms of spaces, Table 20 includes identified required information in terms of equipment and systems. 133  Table 20: The computable requirements we identified from owner’s requirements documentation helped us identify what information to include in BIM in terms of equipment and systems  EQUIPMENT & SYSTEMS RELATED REQUIREMENTS REQUIREMENTS REQUIRED INFORMATION  Documented Organizational Requirement Section 15410 - Plumbing Piping .3 All equipment requiring periodic maintenance shall be mounted in locations where access using ladders, “confined space entry” is not required. Equipment maintenance information (maintenance type and interval), installation height, space characteristics of where the equipment is located  Equipment/equipment type/plumbing/ maintenance requirement/ installation height, space characteristics 2.6 Equipment Installation  .2 Provide space for servicing, disassembly and removal of equipment and components. Equipment installation requirements: Service space, disassembly space, space for removal/replacement Space/equipment/ installation requirement/service, disassembly, removal space HVAC General Requirements  2.2 General Requirements .7 All air handling units shall have heating or preheat coils. Required system and equipment components according to specific type  Equipment/ HVAC/ equipment (AHU)/ shall have component (heating or preheat coils) .12 Air filters provided for use in HVAC systems adhere to the following nominal trade size Specific air filter sizes to be used in HVAC systems  System ( HVAC)/ Component (Air filter)/ Air filter size .15 Radiant heating panels shall not face windows. Component orientation according to other building components Equipment orientation/placement according to building component .18 Window mounted air conditioners and exhaust fans are not acceptable, except for temporary buildings. Equipment specific mounting surface requirements  Equipment type (air conditioner/exhaust fan) / mounting surface (window) restriction 2.4 Outside Air Intake Louvers  .1 Avoid locating air intakes louvers at loading docks, fume hood exhausts, generator exhausts. Outside air intake louvers are not to be located on roof tops where fume hood exhausts are located.  .2 Locate outside air intake louvers as high as possible above grade. Spatial proximity requirements:  Component to component  Component to space  Component to elevation  HVAC/ Component type(air intake louvres)/ location (outside)/ proximity to component, space, elevation 2.0 MATERIAL AND DESIGN REQUIREMENTS  .1 Do not locate drains near beams and columns which tend to become high spots on flat roofs with minimum slopes Spatial information: Spatial proximity limitation of a building component type to structural component type(s)  System (plumbing)/type (fixture-drains)/ location (proximity to beams and columns) .3 Server/Communication Rooms .1 Avoid placing equipment in ceiling above communication equipment. Required clearance to ceiling, over an  equipment type   Equipment type (communication equipment)/ in a space (server / communication room) / no equipment above the equipment 134  From the complete analysis of requirements for both cases, the identification of objects, relations, and properties allows the identification of details about categorization of required BIM information from an owner’s perspective. Table 21 below provides categorization of information requirements according to key concepts of IDM, IFC and MVD for mechanical systems.  Table 21: Categorization of required BIM information based on objects, property, and relations for mechanical systems  Objects Property, Relations Information  Space Composition Adjacency to other spaces Accessibility Handicap accessibility, accessibility by user type Served by  Equipment, system Proximity Orientation in building, proximity to other spaces Attributes Materials (wall, ceiling, floor), fixtures, area, dimensions/size, wall type and fire rating, door (size, swing direction, lock type) System Relations Space that system (a) serves to, (b) is located in Relations Equipment that the system is composed of  Maintainability Access to system components Complexity  # of systems working together Performance Set points, required power Components Mechanical Equipment Relations Part of which system Proximity   Location in relation to other building components (to other equipment, to building perimeter)  Location  Space Standardisation Type, model, manufacturer Attributes manufacturer, weight, installation height Accessibility Space to service, disassembly, and remove Performance Set points, required power A,E,S Attributes Size, material, performance (durability) Proximity  component to component/ to space/ to elevation Performance Envelope performance  3.4.4 Step 4: Relate Digital and Physical Project Products with Owner Requirements and Organizational Processes and Technology   A two-part BIM requirements framework (Table 22) was developed to demonstrate the relationship between (1) the model and (2) the physical product it represents, and the requirements within an owner organization. The first part relates to the digital model, its content 135  and structure. The model represents the physical product to be delivered and thus should technically be an accurate representation of reality. Model content involves the geometric and non-geometric (information) entities contained in the model. Model structure involves the relationships between the entities included in the model which are structured using semantic and topological information. Incomplete model content prevents repurposing the model for operational use, and issues with the model structure lead to miscomputation of model information. The model contents, the properties and attributes, the structure of the information and how it is represented is dictated by the BIM standards, protocols and guidelines of an owner organization. The characteristics of required information in the model relate to the fact that any model developed by any project team can be verified, audited and validated to ensure the quality of the information being exchanged and transferred.   The requirements guiding the design solution and its development are, as discussed, contained within industry codes and standards, an owner’s organizational requirements, project requirements and personnel requirements (Table 22). Through the design process the solutions aimed at fulfilling these requirements are developed and represented in the model. From an analysis of the digital representations of the physical and non-physical elements of the solution possess one or many of the properties and relationships that are identified in Table 22. Projects participants convey a proposed design solution using representations of design objects (such as spaces, systems, and components). The object properties and relations can be categorized, and required information attributes are identified. As part of the design solution the properties and relationships each possess attributes that may or may not be part of specific information requirements. It is these attributes that are computable and verifiable during the BIM-enabled validation and verification process. In a BIM -enabled project delivery process, the model would 136  first be audited to ensure compliance to model structure and content requirements. The model structure enables the effective computation of model information and it also enables the exchange of the model information with the owners’ FM information management technologies. Owners define the required BIM structure and content in BIM related requirements listed in Table 22. The model could then be verified to ensure design compliance to the various requirements that would be translated to computable rule sets in a model checking software. During the design compliance, required object properties, relationships and attributes that are defined in owner requirements can be evaluated for compliance using the computable model information. 137  Table 22: Developed two part framework demonstrates the relationship between the model, the physical product it represents, and the owner organization requirements   Information Entity Required information characteristics  Requirements BIM Content Geometric  Objects & Properties Compliance, accuracy, consistency, completeness, accessibility,  other(s) BIM Standard, BIM protocol, BIM guideline, BIM Project Execution Guide Non-geometric Structure Semantics, Syntax Relations Topologic  Objects Properties & Relations Attributes  DESIGN SOLUTION  Space   System  Component    Size dimensions (width / height / length) / area / volume / weight / capacity Codes and standards  Organizational requirements  Project requirements  Personnel requirements   Quantity number  Type mark / model / material Composition components / assembly Function static / dynamic / use   Condition installation / access / clearance Performance safety / durability  Location position (global / relative) / orientation System Interdependence  connection Relationship proximity Temporal frequency / timing Maintainability accessibility/ standardization/ complexity   The final step in the process is to consolidate the requirements and relate them to the organization’s industrial, institutional, organizational and project contexts. This is done to ensure that the requirements developed are consistent with the owner organizations asset lifecycle practices to ensure that data and information are valid and reusable across an asset’s lifecycle. This entails understanding how the data and information will be structured and packed during handover and linked into the organization’s databases. It also entails understanding how the different sets of requirements relate to each other and how each set influences both the design 138  and the model. The relationships between the set of requirements that form the owner requirements, the parts of BIM, and their relation to the owner requirements and organizational context, must all be consolidated for optimal efficiency. When the relationship between organizational technology, BIM execution plans and a project model are considered, the organization’s technology landscape defines the information structure used in the FM applications. In terms of BIM enabled information handover, required structure to define component relationships is defined in the BIM execution plan, so that information from the model can be exchanged with the organization’s FM applications. Within BIM, information structure is defined using association and semantics. Within an owner organization, required information to perform FM functions is stored in and accessed from the organizational FM technology infrastructure. The information structure of the model, which should follow the BIM execution plans, enables compliance with the organizational FM technology structure for information exchange between model and owner’s FM information management technologies. The representation in the model should be in alignment with the content of the owner requirements in terms of required building components and their properties.  There is a tendency on the part of technology providers to over promise on certain capabilities of software solutions to support seamless information exchanges between models and FM databases, integration of handover and FM information, and leveraging BIM for supporting certain FM functions. However, the considerable amount of work to define and set-up the requirements, as shown throughout this chapter, is not often discussed. As has been shown, owners first need to identify the required information, its uses, and required level of detail. They also need to understand the unintegrated, standalone nature, and varying breakdown structures used in current FM databases to be able to require and exchange BIM information. Consolidating 139  requirements and ensuring they are consistent with current O&M practices, or perhaps more realistically, modifying current O&M practices to suit, is critical.   In the cases presented here, there was a need to understand the lifecycle of information requirements and ensure that they are formulated in a way that supports all phases of project delivery. We observed that organizational contexts such as the organization’s business strategies, FM processes, and technology infrastructure would affect the information requirements. For instance, in this research, the focus was put on geometrically represented model components (equipment), systems, and spaces and information included (in most cases not included) to such geometry according to organizational requirements. The model information related to components, systems, and spaces were transferred into the organizational technology infrastructure, into FM function specific databases, such as asset and space databases. These databases had additional information that was required to perform FM functions but which was not necessarily included in the models that were analyzed. What was also found was that the component, system, and space breakdowns of buildings used in FM technology and databases that are used to perform FM functions did not match the component, system, and space information that was being provided in BIM. Therefore, the operations personnel that used the information within the technology infrastructure to perform FM functions had to expend a lot of effort to bring everything up to a usable level. This was compounded by the fact that both organizations had individual modules within the technology infrastructure for individual FM function such as asset management module that uses the asset database. Moreover, maintenance databases not only used asset information from asset databases, but also additional information from maintenance management databases, for instance, additional information related to maintenance frequency, maintenance procedure, labor cost etc. As a final step, consolidating the 140  different requirements, sources and storage infrastructure was seen as a significant, yet highly challenging, step, which is still underway within both organizations.  3.5 Discussion  Current BIM-enabled practices are largely focused on design and construction of facilities. While owners reap the benefits of the uses of BIM during these phases, namely in increased project predictability, the full value of BIM is not yet being captured across asset lifecycles. There is increasing evidence that the most value of BIM for owners is derived by focusing on asset management. The current issues surrounding full implementation of BIM for owners across an asset’s lifecycle however is that owners often find it very challenging to develop and clearly formalize their BIM requirements in enough detail and to check for compliance to these requirements. Over the course of the investigation presented in this chapter, three reasons were identified that could explain this: (1) owners are not aware of the complete set of FM information they require and manage for FM, (2) they do not have experience with BIM to determine how much of this information can be exchanged and managed by leveraging BIM, (3) they are often unsure about how to require information in a BIM. It was also found that the owners investigated do not have the means or expertise to evaluate the BIMs for quality and design compliance, and they lack the understanding of how these models can be leveraged for FM during operations phase even if these owners require BIMs as part of the handover set after the completion of construction. In light of the analysis performed during this research a method to help formalize owner BIM requirements is presented, and it is supported by a framework relating BIM to the physical product it represents and the owner organization requirements.    Other work has considered the requirements formalization and development both in the context of BIM and non-BIM projects. As mentioned in the background chapter, previous 141  research mainly focused on information requirements for certain tasks through case studies, and investigated application of BIM for certain FM uses (Becerik-Gerber et al., 2012). Personal and expert interviews and an online survey were used by Becerik-Gerber et al. (2012) application areas and data requirements for BIM-enabled FM.  However, this research characterizes the requirements from an owner’s perspective and describes the link between owners’ set of requirements and BIMs. The richness of data collection methods, and the detailed analysis of two case studies of large owner organizations from multiple perspectives add additional depth to the research. In addition to the foregoing, Kensek (2015) investigated how the University of Southern California BIM guidelines inform facilities management databases. A single case study research method was used with literature review, USC BIM guidelines documents review, non-structured interviews with three experts, and a summary overview of the case project implementation. However, as mentioned before most owners struggle with how to approach to developing BIM guidelines, in terms of identifying what data to require from the design teams in such guidelines. This dissertation on the other hand approaches the model information requirements identification issue through analysis of owner organization and its requirements.   Regarding limitations of the research project, it is important to note that both of the organizations studied follow different FM strategies in terms of the means and methods they use for performing FM functions. The main difference between the two organizations is while the large Canadian University operates and maintains its infrastructure using its own workforce, the public owner mainly contracts out the O&M of its buildings. The two organisations are also different in terms of geographic concentration. However the two organisations studied are representative of the large owner organisations which contributes to the generality of the findings. Both organizations have similar organizational issues regarding FM such as limited 142  O&M personnel involvement during design, an undocumented and incomplete set of requirements, unavailable BIM requirements, manually performed design reviews, and reviewer experience based design review processes. Furthermore, the objectives while reviewing the requirements was to understand the overall content, and identify requirements that can be represented in, and queried from project models. The focus was specifically put on managed assets such as spaces, and mechanical equipment and systems; which relate to FM functions such as space management, asset and maintenance management related to mechanical equipment and systems. Architectural, electrical, and structural systems and components were excluded to narrow down the research scope in order to meet the research timeline.  3.6 Conclusion  The research presented in this paper set out to investigate how large owners can develop and formulate information requirements to support BIM-enabled project delivery and asset management. There is growing work being performed in this area, both in academia and in industry, as this area is seen as being of most value. The fact is that the prevalent discourse around BIM for FM is often focused on the use of technologies to support FM functions. There is less discourse around the considerable effort involved in developing computable information requirements necessary to support these technology-driven functions, let alone the change in practice required to ensure it can be done successfully. To support the transition to BIM for large owners, the work presented here provides a method to develop and formalize owner information requirements. The practical implications of this work is moving beyond the uses of BIM by owners themselves to develop a practical understanding of the underlying effort required to support these various uses. It also extends the notion of BIM for owners across an asset’s lifecycle. The BIM requirements framework developed here unpacks the digital model from its 143  physical representation and provides a step-wise approach to leveraging BIM for compliance checking and other upstream uses of BIM for owners. It also bridges design requirements and FM requirements with regards to information being generated and consumed by the various stakeholders in each project. This research can be leveraged as a robust guide to connect all the different sets of owner requirements. Using the findings of this research, the authors are working on a concurrent article on model checking for owners. By having clearly specified information requirements, it is believed that project stakeholders can save significant amounts of time in performing various tasks across an asset’s lifecycle. Indeed, part of the analysis performed in the context of this investigation uncovered that a significant amount of time was required to identify, access, and understand the different sets of organizational requirements set out in the various documents. In terms of implications for knowledge, the research presented here furthers the discussion on asset management and the use of database driven practices in this function. It also attempts to relate the various components of BIM for owners and establish how they interact and influence each other. Additional take-aways from this paper include:  The requirement ‘landscapes’ vary considerably between investigated organizations, depending on the department and user groups, and based on information tracked in FM databases to support FM functions, which is one of the main challenges in proposing generalized requirements for an entire industry segment.  The proliferation of BIM policies, standards, guidelines and protocols around the globe are a double-edged sword for owners looking to transition towards BIM-enabled project delivery. While they are a great resource for owners, there is inconsistency in the terminology and in the way these documents are used and developed. 144   Owners need to identify the required information, its uses, and required level of detail. They also need to understand the unintegrated, standalone nature, and varying breakdown structures used in current FM databases to be able to require and exchange BIM information. Consolidating requirements and ensuring they are consistent with current O&M practices, or perhaps more realistically, modifying current O&M practices to suit, is critical.   There are recurring asset information attributes that are common to all projects and that are required over the asset’s lifecycle that can be standardized. It is important for an owner to have the knowledge of tools and methods to evaluate BIM for compliance with their requirements at the time of handover. Understanding and development of owner BIM requirements is essential to make sure that models are developed in a way to enable a useful and efficient review process. BIM-enabled project delivery and asset management promises to be valuable to help exchange information from design and construction to building operations phase, as well as enabling design reviews for compliance to owners’ requirements. Future work will consider investigating the concept of model based design compliance evaluation to the owner’s requirements. This approach would be based on using rule sets that are developed from analysis of the owner requirements. Future work could also consider a more in depth analysis of BIM and model information use for FM functions during operations use. This work would help to lay out the differences in BIM-enabled operations versus BIM-enabled design and construction in terms of information content and modeling practice. The overall intent however is to start viewing BIM for owners as more than a finite and discrete element (e.g. BIM for FM), and instead more as a core business enabling and transforming entity.   145  Chapter 4: Compliance Review for Model-based Project Delivery   The research project presented in this chapter set out to understand how owners could adopt and implement BIM to support design and information handover review. Two large public owner organizations were investigated over the past five years to support this aim. The findings are articulated around a three-stage process to develop BIM requirements, deploy and check for compliance. The findings on compliance review suggest three elements: model structure verification, model content verification and design compliance review. The presented research finding connects modeling practice to support facilities maintenance, owner information requirements, and owner design requirements and leverages this information for model based compliance review.  4.1 Introduction The important processes of design review, compliance checking and project handover information intake and processing have traditionally been paper based and manual tasks. These tasks are onerous and error prone. Moreover, they don’t allow effective detection of design issues and validation of project information quality for handover both of which both lead to waste of resources when performed during operations. Building Information Modeling has the potential to help owners overcome these challenges by enabling seamless exchange of project information between design, construction, and operations while supporting and proving opportunities for automated design reviews.   As large owner organizations transition towards building information modeling (BIM)-enabled project delivery and start requiring digital models as project deliverables to support their organizational practices, significant adjustments are required on both the part of industry actors 146  and the owner organizations that commission work (Crotty, 2011). BIM is the digital representation of geometric and non-geometric facility information (NBIMS, 2007). Assuming that the required information is known and is available within the model, BIM allows owners and project teams to leverage structured geometric and non-geometric project information to perform specific tasks and actions, and supports its reuse throughout an asset’s lifecycle. While benefits for owners are increasingly being documented, the challenges in initiating and sustaining the transition to BIM are considerable (Eastman et al., 2011). Leveraging BIM for FM has yet to fully take root in the industry due to its relative novelty, and more to the point, the technology and cadre of trained personnel not really there. Among others, establishing clear and coherent BIM requirements, adjusting internal practices and developing capabilities to process and manage BIM-enabled project delivery are key in ensuring that the transition be successful. Furthermore, understanding which organizational practices need readjustment considering this transition to BIM is key in defining a trajectory for change (Kensek, 2015). Among the many uses of BIM for owners, use of models to support automated handover of project information ranks consistently as highly desirable with automated review of design and compliance to technical and functional requirements slightly less important (Giel et al., 2015). These two uses in particular are seen as very important since, the latter helps an owner ensure he is getting the building he wants, while the former ensures he will be able to efficiently and effectively operate and maintain it.   While these uses of BIM from an owner’s point of view are gaining attention, there is still considerable work to be done to translate them from theoretical propositions into tangible outcomes. For one, owners will need to be able to evaluate the fit of BIM and the use of models within their organizational contexts. If we take BIM-enabled design review and project 147  information handover for instance, the evaluation process will entail checking for compliance of the delivered models with owner information requirements, to ensure that the required facility information is available in the models and that the model information is reusable within the owner’s FM technology infrastructure. Based on upfront model-based design reviews, owners can influence design and make proactive decisions before handover which would potentially lead to improvements with the performance of FM functions. When the models comply with owners’ requirements, owners would be able to leverage these models to improve performance of FM functions during operations. While this may appear straightforward, this new process requires a key element: a valid source of truth, i.e. a well built and complete (to the necessary degree) BIM. Such a BIM should provide and enable tracking of information required and reported by front-line O&M personnel.  The research presented in this chapter aims to understand how large owner organizations, who are undertaking a transition to BIM, can ensure compliance of both a facility and its digital representation in the form of a model-based deliverables in the context of BIM-enabled project delivery and asset lifecycle management. The objective was to uncover and formalize the steps related with in taking, processing and checking project information against a set of technical and functional requirements and translating them into a model-based workflow. The research project involved the study of two large owner organizations and included project data from four major projects. Models and project documents, including review comments, drawings and specifications as well as O&M manuals were analyzed. Personnel from the organization, including directors, project managers, technical support staff as well as operations and maintenance personnel were interviewed. A three-stage approach to model-based compliance verification was developed from the findings. The three stages involve (1) model structure 148  verification, which serves to identify any modeling issues that lead to miscomputation of, or impossibility to compute information from the model, (2) model content verification, which relates to ensuring the availability and accuracy of the required geometric and non-geometric information in a model, and (3) design compliance review, which involves a set of computable queries that are developed from extensive analysis of owner requirements and that can be represented in, and queried from a project model. This approach provides a structure for the development of BIM requirements and informs areas of further investigation to extract and formalize computable queries. The findings highlight the potential of model based project delivery for compliance review of both project information and the proposed design of a facility. This suggests avenues to greatly increase the efficiency and effectiveness of project review by owners in a bid to improve the quality of a facility itself (i.e. better responds to the owner’s needs and requirements) and the supporting information infrastructure to ensure it is properly run and maintained. 4.2 Background  Major knowledge areas identified as being related with this research are (1) the ways owners perform reviews on design and project information, and (2) the use of BIM to perform reviews on design and project information. These knowledge areas can further be broken down into model based reasoning (Korman et al., 2003; Zhang et al., 2013), rule checking and IFC based reasoning  (Kiviniemi, 2005; Lee et al., 2016); Solihin et al., 2015) and building product model requirements (Cavka et al., 2015).   Design for FM focuses on making the right design choices for the efficiency of FM functions’ performance during operation. Compliance review focuses on ensuring that the design characteristics meet owner requirements. Owner organizations require and manage a wide range 149  of project information about their built assets. The variety of information is partly related to the O&M personnel within the same organization who require different sets of information to perform FM functions ( Cavka et al., 2017). The analysis of owner requirements was presented by Liu et al. (1994) in which detailed information on categorization and content of owner requirements, and how these requirements relate to BIM enabled project delivery was examined. It is an essential and at the same time a complex task to identify such information requirements. The information needed for operations and maintenance was listed by Clayton et al. (1998), Hjelseth (2015), and Klein et al. (2012). Although literature focuses on listing required information during operations, this research analyzes owner requirements to identify required model information, and design conditions. Modeling for FM focuses on developing the required information content, and model structure. In terms of represented information in project models, Korman et al. (2003) use geometric characteristics (dimension, location) and topological characteristics of the components (components’ spatial relationship in model) represented in a model besides heuristic reasoning to determine and resolve coordination conflicts. Although this research also uses geometric and topological characteristics of components for compliance review, we also refer to a wide range of information required for FM and therefore needs to be represented within the model components as part of modeling. Model Based Reasoning as described in Korman et al. (2003) does not include required component attribute information since it was developed for design coordination purposes.  Topics related to requirements capture, requirements formalization, and leveraging BIM for design reviews for compliance with requirements have been studied from different angles in the literature. Hjelseth (2015) describes BIM based model checking (BMC) as processing “the content of information in BIM-files according to rules specified as pre-defined procedures”.  150  Having no standardized procedure for converting design rules and regulations into digital rules, and large variations in how the designers model and structure (entering) information in the BIM software are examples of barriers related to application of BMC. Hjelseth (2015) identified that the prescriptive rules could be directly converted into computable rules. This dissertation, however, uses both prescriptive and descriptive owner requirements that could be represented in and queried from a model. As an application of the BMC, Statsbygg have developed a digital rule set in Solibri Model checker for compliance checking with their BIM guidance (Hjelseth, 2015). According to Hjelseth (2015) the quality of the BIM file is of high importance for reliable model checking, and it is measured as the structure and content of relevant information, which is also in parallel with the approach and findings of this research. Previously, other researchers have investigated the model structure issues from different perspectives. Lee et al. (2015) investigated the warning messages to better understand the automatic detection of design related errors. This research however relates such model structure issues with how they affect the accurate computation of the required information from the models. Solihin et al. (2015) investigated the quality of product models using IFC testing methodologies when IFC is used for model review, and defines data quality dimensions. The IFC test items identified in Solihin et al. (2015) can also be directly related to what is categorized as model structure issues in this research. Eastman (2009) describes work which focused on automating the design guidelines a way that designs could be assessed and checked against specific criteria. Research in compliance checking and auditing mainly focuses on BIM enabled code checking. Construction Real Estate Network (CORENET) was one of the first initiatives in automated code-checking (Greenwood et al., 2010).  During the HITOS pilot project, the accessibility rules were parameterized, mapped to their associated building objects and executed using Solibri Model Checker’s Constraint Set 151  Manager (R. Liu & Issa, 2014). SmartCodes project focused on transforming thousands of paper-based codes into machine-interpretable rules which could be executed using either Solibri Model Checker (SMC), or AEC3 XABIO (Liu and Issa, 2014). Zhang et al. (2013) introduced a BIM-enabled, rule-based automated safety checking platform. A more recent study (Foster, 2011) was about leveraging BIM for maintenance accessibility problem detection using predefined rule sets in SMC during the design phase. The results showed evidence that SMC can help partially solve maintenance accessibility problem detection if there are corresponding SMC rule sets available. However the work was limited to interference of other building objects with required service space for equipment.  This dissertation on the other hand, leveraged identification and the use of equipment type specific maintainability characteristics, required information for maintenance as well as maintenance space interference for maintainability review. Lui and Issa (2014) mentioned the idea of sending design teams “design requirements for maintenance friendly designs” which would have been created from an accumulated knowledge base of situations that were encountered by maintenance personnel. However the knowledge base was the result of specific conditions observed in buildings solely by O&M personnel, and was not based on owner requirements documentation, contrary to the method followed in this dissertation.   Besides the required information and model structure perspectives, this dissertation also focused on the design compliance review from maintainability perspective.  Foster (2011) noted that the largest building cost component over a building’s life-cycle is maintenance (50% of lifecycle cost), however design for maintenance is ignored in the design phase, and the next generation of advancement for facility management should be in design for maintenance. According to Moua Her & Russell (2002) “many owners are re-evaluating business strategies to incorporate maintainability into earlier phases of the project delivery process” (p. 95). This 152  approach is in parallel with the design compliance review process introduced in this dissertation which is aimed at identifying design compliance with maintainability. Ding (2009) described maintainability as “a design characteristic that affects accuracy, ease, and time requirements of maintenance actions”. In terms of evaluating maintainability, Wani & Gandhi (1999) identified features which characterize ease in maintenance of a system and named them as the “maintainability attributes”. However system design features are not clearly defined in the study. Design compliance review as presented in this dissertation also focuses on using design features and maintainability attributes. However, they were identified from the owner requirements, turned into computable requirements, and run on a project model to identify non-compliant design features and attributes. Accessibility is one of the owner requirements and it is also related with maintainability of a building project. Dhillon (2006) defines accessibility as “the relative ease with which an item can be reached for repair, replacement, or service”. Poor accessibility is a frequent cause of ineffective maintenance and gaining access to equipment is probably the second time-consuming maintenance task after fault isolation (Dhillon, 2006). Some of the factors that affect accessibility as defined by Dhillon (2006) were also used as part of this research when defining queries for owner’s accessibility requirements for mechanical systems and equipment. 4.3 Research Methodology  The principal aim of the research project was to understand how large owner organizations, who are undertaking a transition to BIM, can ensure compliance of both a facility and its digital representation in the form of model-based deliverables in the context of BIM-enabled project delivery and asset management. The objective was to uncover and formalize the steps related with in taking, processing and checking project information against a set of 153  technical and functional requirements and translating them into a model-based workflow. To do this, the design review, project information processing and FM practices on two selected case studies were documented and mapped. Design and technical guidelines from these two cases were investigated and those requirements that were deemed computable were formalized. Finally, a series of digital models that were developed in the context of specific projects as part of these two case studies were then analyzed in the context of these computable requirements6.   A research project involving the case study of two large owner organizations was conducted over a three-year period. The first case study involved a large Canadian university. The focus of this case study was put on the building operations department, which is responsible for the operations and maintenance of all non-residential buildings on campus. The department is responsible for 225 core university-owned buildings, with a total gross floor area of 810,119 m2. The second case study involved the agency responsible for delivering and maintaining public infrastructure for a provincial government in Canada. The agency is responsible for infrastructure planning, building and managing of government-owned infrastructure which includes health facilities, schools and other public infrastructure in the province. The agency is responsible for over 1,600 buildings, representing an approximate total gross floor area of 2,330,000 m2. The focus of this case study was on the Capital Planning Division and the Properties Management Division. The principal sources of data collected from the two owner organizations are summarized in Table 23.                                                  6 Requirements that can be represented in and queried from a BIM 154  Table 23: Overview of collected data  Source of data collection Description Large Canadian University Org. Technical Guidelines The code of quality and performance for the design, construction and renovation of University-owned institutional buildings FM databases  To understand managed information in FM applications: PeopleSoft (asset management, maintenance management), Archibus, Facilities Capital Planning and Management (VFA Facility), Laserfiche, Records Retrieval System Interviews with the FM personnel To understand information and design condition7  requirements  Project data  Project documents and models for two research buildings and a mixed use building- student residence and college  Provincial Government Body Basic Master Specifications (BMS) Sixteen divisions based on the MasterFormat Org. Technical Guidelines  Technical design requirements for government owned facilities Owners Statement of Requirements for a sample project (OSR) Project specific requirements O&M databases  To understand managed information in FM applications: Building and Land Information Management System (BLIMS), Facilities Capital Planning and Management (VFA Facility), Facility Maintenance System (FMS), Work Order Request Tracking System (WORTS), RAP (planning program) Interviews with the FM personnel To understand information and design condition requirements Project data Project documents and models for a large institutional project  Data collection and analysis included both quantitative and qualitative methods. A total of 27 interviews were conducted with personnel from both organizations (Table 24). The interviews were designed to uncover each organization’s information landscape as well as the views of personnel on current project delivery and asset management processes.                                                     7 Design features/characteristics that have an effect on the performance of O&M activities. 155  Table 24: Twenty-seven personnel from various departments in two owners were interviewed to understand organizational processes, information requirements, and uses of information Case study Division Department Large Canadian University Infrastructure Development  Building Operations Records  Asset Stewardship  Operational Effectiveness Utilities and Energy Provincial Government Body Capital Projects Division Project Services Branch Project Delivery Branch Technical Services Branch Properties Division Regional Operations Branch Culture/ Heritage -  A walkthrough with a maintenance technical specialist from the university’s O&M department was performed to understand maintainability issues, and building characteristics that affected the performance of maintenance activities. A maintenance worker was shadowed for two hours to develop an understanding of the current practice, required information, and available tools to perform maintenance. Organizational structures, FM functions, and supporting technology infrastructure were analyzed to understand both organizational contexts and FM practices. Organizational structures were mapped through interviews and observations to understand information flows within the organization between different departments. FM function process mapping were used to understand required information for each process, types of exchanged information, and information exchange between different processes (Figure 27). The mapped FM processes were related with design review, handover, records management, asset management, maintenance management functions. An analysis of record documents involving project drawings, manuals, and specifications from the records management system was performed to evaluate the quality of the handover set using metrics such as availability, accuracy, completeness, and reusability of the information. While the organizational requirements were investigated through document analysis, undocumented personnel 156  requirements were identified through interviews, shadowing and building walkthroughs performed with FM personnel. Organizational technical requirements were analyzed by analyzing the technical guideline documents of both organizations. Project specific requirements were analyzed through the owners’ project briefs and statement of requirements documentation to understand project specific requirements.   Walkthrough and shadowing activities helped identify information available in maintenance tickets, additional information required to complete maintenance tasks, common issues related with building mechanical systems, and design decisions that affect the performance of maintenance activities. Analysis of technology infrastructure of FM applications and databases was used for understanding managed FM information, information requirements for each FM function, and information structure. This information was used to help partly identify what model information was required, to what level it should be developed (Level of Development - LOD), how it should be structured and in what format it should be exchanged.157   Figure 27: Cross-functional process flow diagram showing information flow through number of FM functions 158   Three project BIMs which were developed by different project teams were analyzed using Revit, Navisworks, EcoDomus, SMC, and COBie format outputs of model content to uncover (a) modeling practices for elements such as definition of levels and spaces, defined relationships between model components, and nomenclature used (b) available geometric information, (c) available non-geometric information. Two out of three project BIMs were from the university case study and the third model was a large institutional project model from the provincial government case study. It is important to note that since the owners had not developed BIM requirements for any of the four projects, nor did they have any internal BIM requirements, literature from sources such as National Institute of Building Sciences (NIBS), U.S. Army Corps of Engineers (USACE), Singapore BIM Guide, General Services Administration (GSA) National BIM Program, PennState BIM Planning Guide for Owners, were analyzed by  the researchers to develop best practices and inform how requirements could be framed.  Intensive analysis of the two owner organization requirements and analysis of four project models enabled identification of requirements that were later turned into computable requirements. In order to evaluate compliance, computable requirements were turned into model queries and were run on two project models using SMC which enabled identification of non-compliant model and design characteristics (Table 25). Running queries in models helped in validating the applicability of model based compliance verification, and design compliance review methodology.    159  Table 25: Computable query examples, query categorization, and identified model queries to evaluate compliance with requirements Computable Owner Requirement Requirement Category –Proximity- Model Query Main Floor Custodial Room near Loading Bay to be located very close to a loading bay Space to Space  Find the spaces with the names custodial room and loading bay on the main floor Check whether the identified spaces are X distance apart “Emergency eyewash and or showers shall be provided in areas adjacent to areas where chemicals are used or stored appropriate for the hazard.” (ANSI / ISEA Z358.1-2014: The distance should be no more 55 ft.) Component to Space  Identify eyewashes, showers, and labs in the model Check distances between components and spaces, whether the distance from an eyewash or a shower is greater than 55 ft. Locate outside air intake louvers as far away as practical from all sources of contamination; avoid locating intakes at loading docks, fume hood exhausts, generator exhausts.  Component to Component  Identify air intake, loading docks and fume hood exhausts in the model Check if any air intakes are located at loading docks Check if any air intakes are located within X distance from fume hood exhausts   To validate the findings, the research team performed a review panel with domain experts. These experts, three project managers from the Project Services Department, and a PM and a Maintenance Technical Specialist from the Building Operations for the large Canadian university, were asked to evaluate whether the method of compliance checking including the queries developed from the set of identified computable requirements were representative of the information that is reviewed or checked during design reviews and at handover. The use of SMC to run the queries and how this process helped in identifying non-compliance to model and owner design requirements were explained briefly to the reviewers. Experts were intentionally selected from different departments and with different responsibilities in order to capture the varying perspectives on project delivery and FM practices within the context of a large owner organization. Validation was based on a five-point Likert scale to rate the applicability of the 160  compliance checking method that was presented. During the sessions, a brief introduction of the research and what they were asked to rate was first given. Information was then provided on the approach for evaluation of model and design compliance through defined model queries. Feedback from the experts was requested at the end by opening the floor for a semiformal discussion, which provided insight into the use, and possible benefits of the introduced queries and process of using them.  4.3.1 Current Practice  One of the objectives of the investigation presented in this chapter was to uncover current review and handover practices which informed FM within large owner organizations. It was found that both owner organizations’ involvement in any given project varied per the delivery mode and the level of sophistication of the owner’s employees in terms of design and construction knowledge. Both owners were actively involved over the projects’ lifecycle in terms of design review across different disciplines. Indeed, staffs from both owners were tasked with reviewing design decisions to ensure that they comply with owner requirements. These requirements cover a wide range of both formal (codes, design standards, organizational and project requirements), and informal (personnel requirements) requirements (Liu et al., 1994). The reviewers would comment back to the project team with further requirements, suggestions and questions. In some instances, it was found that the project team would not incorporate these comments into the design and a back and forth would ensue. Interestingly, it was also found that reviewers would comment on the medium, the project documents such as plans and specifications, and highlight any inconsistencies and errors in the representation and the quality of information, i.e. its accuracy, completeness and correctness. The highlights of this portion of the research found that the design review process is a manual and time consuming one, and that 161  it is mainly based on the reviewers’ experience and knowledge rather than formalized review criteria/rules for projects. The vast quantity of information that must be processed by the reviewers in a short amount of time, leads to selective review which ultimately can result in a building that does not comply to the owner’s requirements and needs.   Upon project completion, relevant project information is handed over to the owner to populate asset management databases and inform FM practices. It was found that the evaluation of the project’s handover information poses a significant challenge for the owner, especially when it is completed near the end of construction rather than as a gradual process throughout the project. It was also found that the project information review process focused on the completeness of the document set (e.g. the presence of a set of required documents), rather than the information content. For instance, on one of the projects studied, one of the owners was provided with a stack of hardcopy drawings and documentation as well as a digital repository containing electronic versions of the documents. This consisted of hundreds of individual pdf’s, which included project drawings, manuals, and specifications. When the owners received the handover set there was no guarantee that the handover information was complete, or accurate which resulted in missing or erroneous data (Figure 28). Ultimately, it was found that upon project completion the owners lacked the time, resources, and technical knowledge to thoroughly evaluate the content of the handover set. 162   Figure 28: A list of consultants’ pdf drawings received by the owner at the time of building handover and later to be named and structured according to owner requirements to make them accessible to FM personnel  With regards to BIM-enabled project delivery, none of the owners investigated had defined information requirements for model-based project and information handover. They did not know what to require in models or how to require this information from the project teams. While it was expressed that they would like to validate completeness of the information in the handover models, they did not have the tools, expertise, or the resources to evaluate the models developed by the project teams. A significant issue that came up was that due to the unique nature of each project in terms of requirements, both owners were lacking detailed and formalized information requirement sets, and they did not possess the capacity for thoroughly evaluating design compliance according to the requirements that were in place. Moreover, due to the lack of specific BIM requirements, the project teams weren’t modeling with automated review and compliance checking in mind, which effect correct computation of required information from models. An example of this is illustrated in Figure 29. Since not all the mechanical components are modeled, the design model seemingly does not have maintenance space issues. However as all the required mechanical components gets installed during 163  construction, the mechanical room after construction is considered as one of most cramped mechanical rooms on the campus. Although adequate maintenance space is required by the owner, mechanical room at the end of the construction has equipment accessibility issues that negatively affect the O&M tasks during operation.     Figure 29: As build condition of the mechanical room has non-compliant characteristics to owner’s requirements for service/ maintenance space requirements which affect the performance of O&M activities during operations phase 4.3.2 Model Structure and Content Analysis  Several different modeling and model analysis tools, such as Autodesk Revit and Navisworks, Solibri Model Checker, and EcoDomus, were tested to support model structure and model content compliance verification. During my model analyses I realized that significant model restructuring and manipulation was required in terms of preparing models for analysis from an owner’s perspective. Such model manipulations were needed to be able to compute required information from the model. Yet often part of the managed information by the owner was not available in the models and it had to be manually entered, if required. Once the model compliance was verified then design compliance review was performed using SMC. Design compliance review was also based on identified design characteristic requirements from the 164  analysis of owner requirements. These requirements were used to identify the model queries that need to be run in order to identify non-compliant design characteristics that are contrary to the requirements. The project models were reviewed for compliance with owner requirements using the Solibri rules that were based on the identified computable requirements (Figure 30).   Figure 30: Model enabled design compliance review is based on identified computable owner requirements, turning such requirements into computable model queries, and finally running these queries on project models to identify non-compliant design characteristics  For this research SMC is used for performing the model based design compliance review. The advantage of using SMC is that it can use an IFC version of a model to run rule-based queries and identify non-compliance. The model-based compliance evaluation has the potential to improve the current compliance review process by providing the means for automation of compliance review, leading to a reduction of errors compared to a manual process, and providing owners with a method to evaluate the usability and quality of the models they receive. In the following subsections, three levels of compliance review are explained. 165  4.4 Model–based Compliance Review   So, how does a large owner organization define its BIM requirements to support design and project information compliance review? Three compliance stages emerged from the analysis and are identified as being key for model-based project delivery (Figure 31). The first stage involves the verification of a model’s information and data structure to identify any modeling errors that lead to mis-computation and/or non-computation of model information. The model should follow the owner’s specific modeling requirements. The second stage is the model content compliance verification that involves validation of model information content against the owner’s BIM requirements. This step ensures that the model content meets the owner’s information requirements in terms of geometric and non-geometric content. The third level is the design compliance review where the design’s fit with owner requirements is evaluated. This involves the computable requirements and rulesets that were mentioned above. A2Model Information VerificationA3Design Compliance ReviewContentModel V2ApplicationRule Sets RequirementsIdentifiedNon-compliant Design Characteristics & FeaturesReviewer(s)Model V3Owner BIM RequirementsApplicationReviewer(s)Owner’s Technical & Project RequirementsProject InformationA1Modeling Structure VerificationModel V1Structure ApplicationReviewer(s)Owner BIM RequirementsFigure 31: Envisioned methodology for verification of model content and structure compliance, and design compliance review  The compliance review methodology presented in this research accepts the model structure and content verification as a pre-requisite, and a part of the design compliance review from the model based delivery perspective. This approach is based on the model analyses 166  performed during this research, which led to an understanding of issues related to current project models and current modeling practices of the project teams. The compliance review process for model content, structure, and design is based on tailored rule sets that originate from owner requirements, and owner current or potential model uses for FM.  Computable requirements are used to execute model based structure and content verification and design compliance review. These requirements relate to FM requirements that are formalized in a model and therefore can be computed. Computable requirements can be leveraged for all model structure and content verification and design compliance review. They cover the model structure and information requirements which enable information exchange between model and owner’s FM application, and also the design conditions which enable efficient performance of FM functions. Identification of a model query which originates from the analysis of owner requirements is explained in Table 26. Such queries are later used to perform model based design compliance review. The methodology for identification of computable requirements, and turning these requirements into model queries is further explained in Liu and Issa (2014). The analysis of owner requirements to identify model queries also supports the development of required FM model information. In the context of this research project, these requirements were found embedded in formal owner requirements documents, and were identified through interviews with FM personnel, analysis of owner organizations FM information databases, and analysis of best modeling practices that corresponds to the FM model uses.  167  Table 26: Example for a computable requirement for design review which is derived from owner's design requirements document. It is analyzed to identify the required model information, and the model query that will be used during compliance review Computable requirement from the owner’s design requirements documentation Analysis of the computable requirement Outside Air Intake Louvers  .1 Locate outside air intake louvers as far away as practical from all sources of contamination; avoid locating intakes at loading docks, fume hood exhausts, generator exhausts. Outside air intake louvers are not to be located on roof tops where fume hood exhausts are located.  .2 Locate outside air intake louvers as high as possible above grade. Spatial proximity requirements • Component to component • Component to space • Component to elevation  Required model information System: HVAC Component type: Air intake louvres Location: Outside the building envelope Proximity to: Component (fume hood exhaust), Space (loading dock), Building elevation (above grade) Model query  Identify air intake louvres that belong to the HVAC system, are located outside on roof tops and are within the 5m radius of fume hood exhausts   4.4.1 Model Structure Compliance Verification  The intent behind model structure compliance verification is to ensure that the way in which the model is built is suitable for the owner’s purposes. Indeed, it is a given that a project BIM intended for FM use is modeled differently from a design or a construction BIM. Modeled project information is structured according to the internal rules of the modeling application (e.g. Revit) or the defined rules for the IFC open format. Ensuring appropriate model structure entails modeling practices that are required (1) for computing required FM information correctly from a BIM, (2) for enabling information exchange between the model and the owner’s FM applications. The analysis of project models created for design, construction and (partly) FM uses led to understanding that the BIMs created for handover and FM use have a model structure that is different from design and construction models. The analysis of the models for validation of structure compliance on the different projects led to identification of common and recurring 168  issues in current modeling practice for design and construction phases that were not guided by clear BIM requirements. Fundamentally, the models analyzed, because they were not structured properly, lead to a miscomputation or unavailability of FM model data. The categorization of identified modeling issues in this research that lead to model structure issues are listed in Table 27. The findings through model analysis highlight the need for the model to be checked for structural issues during structure compliance verification before the information content and design compliance review is performed. As a basic rule, SMC does prompt the user to accomplish certain tasks that relate to model structure compliance prior to performing any analysis.  Table 27: Categorization of identified modeling issues that lead to model structure issues Representation Space  Duplications Boundary errors Openings left in walls Not having space tags in rooms Mapping architectural spaces to mechanical model Redundant spaces Component & systems  Duplications Missing components: Not representing required components (completeness) Unconnected system components Level of Development (LOD) Classification & Nomenclature  Naming conventions  not uniquely naming components  instance based vs type based Classification of systems  compliance with owner databases Nomenclature for spaces (vs OSR space list) Relationships Undefined relationships (a) component-space, (b) component-system, (c) system-space Coordination Model coordination to identify clashes Floor elevation coordination so that the equipment can be assigned to spaces they are serviced from  169   The examples of identified model structure issues are listed with examples from our analysis in Table 28. Undefined relationships between equipment, system, and spaces led to not being able to identify the location of equipment, the system that equipment belongs to, and which space a system serves. Such information is required by the O&M personnel to perform their tasks.  Room related modeling issues lead to miscomputation of space information, and in return miscomputation of such information as equipment locations. These issues were also listed as model related error messages by the modeling software as the models were opened for analysis. The identified error messages included; rooms without boundaries, multiple rooms in the same enclosed region, rooms not in properly enclosed regions, geometry cannot be created for a room, duplicate rooms, elements with duplicate number values, no space created for mechanical equipment, room tags outside of the rooms they belong to, and more than one space component in one space. Issues related to poor model coordination such as uncoordinated model elevations lead to derivation of inconsistent information from project models. Modeling errors, such as not connecting system components (i.e. air intake duct to an AHU) lead to not being able to identify all components of a system, and not being able to trace the system components between two points. Issues related to system and equipment nomenclature, such as not uniquely naming each component in a family, lead to problems with identification of number of available equipment of one type.    170  Table 28: Examples of identified model structure issues related to modeling practice Modeling errors such as unconnected system components due to poor modeling.  Such modeling errors affect computation of information; such as identification of systems and components that belong to a system.          Modeling mistakes, like openings left in the walls, lead to miscomputation of room boundaries and effect definition of spaces.  This leads to problems related to equipment being assigned to incorrect space information.                   Equipment should be assigned to the floor they are serviced from. The way that floor elevations are defined affects the space-equipment relationships. In the model the equipment serviced from a floor is computed as located in the floor below. Current floor height is defined from top of the elevated floor to the top of the elevated floor above (shown with blue) Floor height should be defined from top of the wood floor to the top of the structural floor above (shown with green)  Not mapping architectural spaces to the mechanical model results in missing relationship between spaces and equipment. In such cases mechanical equipment space information cannot be identified.  Nomenclature: every object (Type) and object instance (Component) should have a unique name to be able to populate FM databases accurately   4.4.2 Model Content Compliance Verification  The intent of the model content compliance verification stage is to evaluate the quality of information contained within the model. This ensures that the information contained in the model is fit for use to support handover and FM functions. Among other things, a model intended for Modeling error Should be connected 171  FM use requires specific geometric, and non-geometric information to populate the owner’s FM databases and to help the performance of FM functions. The issues related to model content that were highlighted in this research are the missing geometric and non-geometric information compared to information required (1) by the owner, (2) for performing FM functions such as maintenance management, (3) for exchanging information with owner’s FM databases, and (4) for model-based compliance review. The ability to extract accurate FM related information from BIM in support of FM functions is a key issue. The different dimensions of information quality include missing model geometry, system, and space representations, and representation of how these relate to each other as well as missing non-geometric information relating to specific attributes found in a model. Table 29 includes examples of identified model content issues during our analysis of project models.  172  Table 29: Examples for missing geometric, and non-geometric project information identified with model content Missing Geometric Information Representation: component and system representation When the as built (left) and model representation (right) are compared, identified missing geometry: most of plumbing is not represented, electrical control panel is not represented, number of expansion tanks are misrepresented. It is also important to note that the design model was not updated for change orders, request for information etc.                         As built mechanical room                                                     Model information Missing Non-geometric Information Attributes: component, system, and space attributes Required information for pump designation Division 15    15130 Pumps       3.4 Pump schedule  Pump label, Location, Service, Manufacturer, Model, Size, Capacity L/s, Minimum pump Efficiency, Motor kW, Motor efficiency  Pump attributes in model  Model Information Available: Manufacturer, Model, Size Not available: Label, Location, Service, Capacity, Minimum Pump Efficiency, Motor, Motor Efficiency Mechanical parameters: the attribute efficiency is defined but no value was entered  Electrical parameters: the motor attribute is defined but no value was entered  4.4.3 Design Compliance Review  Once the structure and the content of a model have been validated, it is then possible to check project model for compliance to design requirements, including technical, functional, aesthetic and operational. The intent at this stage is to identify non-compliant design characteristics and design features that are contrary to the owner requirements. During the 173  analyses of project models design characteristics that were contrary to the Technical Guidelines, owner statement of requirements (OSR) document, and O&M personnel requirements (in the areas such as maintainability, accessibility, compliance with space and area requirements etc.) were identified. The example of the mechanical room in the University campus, which was mentioned as being one of the most cramped and problematic mechanical rooms on campus, is a good case in point. The technical guidelines for the university clearly stated that “no mechanical room will be accepted with poor and difficult access for maintenance”, “all plumbing equipment requiring frequent maintenance to be readily accessible”, and “do not locate plumbing equipment at ceiling height, requiring scaffolds, ladders, removal of other equipment”. However the pumps in this room were installed on the ceiling, and they were buried under a maze of pipes which make it difficult for the maintenance personnel to access the pumps for maintenance (Figure 32). For maintenance or repair, crews would need to remove other components, and need to use extra tools (like ladders and lifts) to remove the pumps that were installed at the ceiling height. Model queries were developed from this particular example for evaluating pump locations in a design for compliance with owner requirements. In this case, the researchers had to define requirements such as “poor and difficult access for maintenance”, “being readily accessible” in a computable way that would work with project models. On the other hand developing model queries for such requirements as identifying “pumps located at ceiling height” were relatively simple using SMC rule sets. 174                   Figure 32: Model queries developed from the owner’s design requirements for mechanical equipment accessibility help timely identification of design characteristics that effect maintenance performance before the start of the operations phase  As another example (Figure 33), for the provincial government body and the project that was studied, the owners statement of requirements (OSR) stated that the “emergency eyewash and or showers shall be provided in areas adjacent to areas where chemicals are used or stored appropriate for the hazard”. As a requirement the distance between a lab and an emergency eyewash & shower was determined to be no more 10 seconds’ walk or 55 feet (16.76 m) according to ANSI/ISEA Z358.1-2014. By using the owner’s requirement and the related standard, a model query was created. When the query was run on the model using SMC, the output of the model query showed that all the labs, except for one, had eyewashes at the required distance. One lab was identified as being too far from the emergency shower. Pump access space is blocked by other system components Pumps installed at the ceiling are buried under pipes 175   Figure 33: Running model queries that were based on the OSR helped identifying non-compliant design characteristics such as distance from the lab to the closest emergency shower  Table 30 exemplifies the identified computable requirements from the owner requirements and used model queries for design compliance review.           176   Table 30: Identified computable queries from the owner requirements were turned into model queries which were later run on models using SMC to evaluate design compliance Owner Requirement Model Query (SMC) Query Output Radiant heating panels shall not face windows Used SMC Rule 222 The minimum 2D distance between radiant panel and window is approximately 7 ft    Drains should not be near beams and columns Used SMC Rule 222 4’ is used as the minimum required distance between drains and structural beams and columns   Electrical rooms are preferred to be located on North or East exterior wall  Filter Rooms with Name of ‘Electrical’ or ‘Elec’ and observe the location using SMC University building model Electrical Room Number: 1 Location on North or East exterior wall: 0 Provincial Government Building Electrical Room Number: 13 Located on North or East Exterior Wall: 9  Table 31 is a list of design characteristics that influence the performance of FM functions which were identified during the investigation of owner requirements. The design characteristics are the results of design decisions and they are represented in project artifacts. BIM’s potential, as a project artifact in model-based project delivery, to be used for reviewing and evaluating a design for such characteristics, was demonstrated in the research by running identified queries on the project models.    177  Table 31: Categorization of identified computable requirements which were used for model based design compliance review  Complexity Aggregation Variety components within a system  Composition Scatter level of systems’ components throughout the building  Design complexity Variety and # of complicated systems Crowded mechanical rooms  System complexity Interdependencies between systems # of systems working together Accessibility Access for maintenance  Access to equipment or its parts  Visual access Clear line of sight to equipment for visual inspection purposes  Disassembly from location  Ease of removal, replacement  Removal from the room/building Installation requirements  Access to mechanical rooms (influence travel time/ distance) For different equipment types (e.g. height & installation surface for pumps) Layout of mechanical rooms # of mechanical rooms Closeness of mechanical rooms to each other Elevator access to rooms Standardization Equipment variety Within the building and  amongst the campus buildings (building & campus scales)  Parts availability  Maintenance Information Sources for required information: Asset databases, User requirements, Manuals and specs.  Required attributes Maintenance schedules/times Maintenance frequency Instructions for maintenance tasks Identification/ Tagging Performance information Required maintainability attributes for equipment types (e.g. maintenance frequency and weight for pumps)  Spatial requirements  Proximity     Adjacency  Relationship Component to component Component to space Space to space Component to building perimeter Component to building elevation  Space to space Access (space to space) Conflicting component-space relationships   4.5 Validation of Identified and Used Model Queries  The validation of the research is based on the representativeness of the used queries. The identification of the queries is based on the investigated organizations’ formalized requirements, 178  requirements from analysis of the performed interviews with the FM personnel, and owner’s BIM requirements from the literature. In this sense validation of the queries is already supported by the grounded research approach, which is based on actual cases and requirements from two large owner organizations. In order to validate the representativeness of the queries five FM experts (three project managers –PMs- from Built Environment, HVAC Design/ Build &Energy, and Transition departments, a senior PM from Operations Department, and a mechanical maintenance specialist) from the investigated institutional organization were asked to rate the list of queries from not representative to highly representative. A five level evaluation scale was used for the degree of representativeness of each query; query is always, often, rarely, never used for compliance review, or non-applicable for the queries that are not part of the expert’s knowledge area. 87 queries related to 38 design conditions, information requirements, and model requirements were evaluated for representativeness. The results were 72% of the identified computable queries in this research were representative of the “always” (42%) and “often” (30%) used queries that the experts would use when they evaluate handover information compliance to the owner requirements. 20% of the identified computable queries were representative of the “rarely” used queries, and 8% of the identified computable queries were not as part of the queries that the experts would use during compliance reviews. The completeness of the identified queries was not validated since the owner requirements cover a wide range of building components and systems. It was not practical to gather a complete set of queries in the period of this research since new requirements are posted by owner organizations too often and according to one interviewee, the current version of the Technical Guidelines may become outdated by the time someone prints them from the organization’s web site. 179  4.6 Conclusion  While the use of BIM is becoming more common during design and construction phases of a project, many owners still lack the knowledge and motivation to leverage BIMs throughout their facility’s lifecycle. The challenge facing owners undertaking the BIM adoption and implementation process are multiple. Organizational considerations, including staffing and training are front and center. This research looked at the technical challenges associates with this transition. Mainly, it is understood that the way in which owners ask for BIM on their projects will have repercussions across the lifecycle of their asset. This research developed a three stage process for model-based compliance review of project information. It was found that to support the different uses of BIM by an owner, there was a need to: (1) ensure project models are structured properly and consistently, and (2) the information contained in the model is accurate, complete and reliable (ie. quality information). The third step involves design compliance review which can take on many different meanings for an owner; design to support effective FM practices. The main challenges with this are to develop a clear set of information requirements, and developing the expertise and tools to evaluate compliance of consultants’ models with these requirements. This research exemplified and categorised current model content and structure issues identified from the analysis of four project models. In terms of model structure compliance review, the contribution of the research is that the determined model issues, which were also identified in previous research, are shown to have direct effect on the computation of required information, and in its reuse for FM. A process for compliance review was presented, and queries that can be represented or performed in a model for design compliance evaluation were categorized. An analysis of owner requirements was used for identification of such computable requirements. A subgroup of organizational requirements that can be turned into 180  computable queries were categorized for model based design compliance review. During the review process the queries developed from the identified computable requirements were run on models using SMC, to compare the digital representation of the project model with the owner requirements. This allowed automatic discovery of discrepancies in the proposed designs of the various projects studied, a process that could save an owner significant amounts of time and help them ensure that they obtain a design that suits their needs. It is expected that this research would help owners understand how to identify model requirements, reviewing the compliance of the handed over models according to information requirements, FM specific modeling requirements, and finally design requirements. Currently identified queries however are not adequate for a complete project review process. The number of queries and the coverage of building systems and components should be improved as a recommendation for future research in this area. Usability studies involving the owner’s personnel applying the identified queries on project models are also recommended to understand required expertise for using the BIM tools, and interpretation of model query results by the owner’s FM personnel.  181  Chapter 5: Conclusion   Transitioning to BIM in owner organizations entails changes in organizational processes, identification of owner requirements, overcoming the challenges related to transition, and training of all parties involved (i.e. designers, FM personnel). The main focus of this dissertation is on better understanding the complexities related to transitioning to BIM in large owner organizations for the purpose of BIM based project delivery and to support FM functions. First, the current alignment between the organizational constructs and handover information was investigated using a developed framework. Later, the set of requirements that make up the owner requirements were identified and categorized. Following the identification of owner requirements landscape, a process to identify model requirements was introduced. A methodology to identify computable requirements from the analysis of owner requirements was introduced. Finally, levels of reasoning for analyzing a project model for compliance with owner requirements were introduced. The identified levels of reasoning leverage the rule sets which were defined based on the model analyses and owner requirements’ analyses.  To validate the findings, three project models were analyzed retrospectively and a review panel with domain experts was conducted. Model analyses involved evaluation of model content and structure, and model based design review for compliance with owner requirements. Different tools such as Revit, Navisworks, Solibri Model Checker (SMC), Ecodomus, and COBie information exchange format were used during model analyses. Model queries, which were identified from the investigation of owner requirements, were also leveraged during the model analyses using SMC. Five industry experts were asked to evaluate whether the method of compliance checking including the queries developed from the set of identified computable 182  requirements were representative of the information checked during design reviews and handover. Validation was based on a five-point Likert scale to rate the applicability of the compliance checking method that was presented. The use of model based compliance review using identified queries and how this process helped in identifying non-compliance to model and owner design requirements were explained briefly to the reviewers. Feedback from the experts was requested at the end by opening the floor for a semiformal discussion, which provided insight into the use, and possible benefits of the introduced queries and process of using them. We believe that within the context of model-based project delivery, the development of owner delivery requirements, followed by development of computable rule sets based on these requirements has the potential to decrease issues related with current project delivery and performance of FM functions.  The remainder of this chapter is organized as follows: Section 5.1 describes the main contributions of this research; Section 5.2 explains the validation tests performed; Section 5.3 briefly outlines practical implications of the research; and Section 5.4 describes some limitations of the current research, and directions for future research. 5.1 Research Contributions  The three consecutive manuscripts as part of this dissertation contain different scales of analysis, starting with the industry scale, moving to organizational scale which focuses on requirements, and finally to the scale of a specific FM function (model-based compliance review) where the information from requirements analysis is leveraged. Contributions of the research are represented in Figure 34.  The key contributions are: 183  1. Introduction of a framework to characterize alignment between organizational constructs and project artifacts to better understand the mechanisms required to transition from traditional to BIM-enabled FM practices.  The organizational constructs are the organization (FM processes and organizational structure) and the technology (IT infrastructure and processes). The framework leverages compliance to organizational requirements as the basis for the level of alignment between the organizational constructs and the project artifacts (handover set and project BIM). 2. Two contributions related to owner requirements; 2.1. Identification and categorization of the landscape of owner requirements for which is an essential part of owners’ model requirements identification. Owner requirements landscape is the set of requirements that make up the owner requirements. The categorization includes codes and design standards, organizational requirements, project requirements, personnel requirements, and BIM requirements. 2.2. Introduction of a process to identify model requirements based on the analysis of owner requirements. The process involves investigation of owner requirements and identifying requirements which can be represented in and queried from a BIM. Such owner requirements are named as computable requirements. Further investigation of computable requirements enables identification of model requirements in terms of what information needs to be included in an owner’s BIM. 184  3. Levels of reasoning to analyze a model for compliance with the owner requirements. Levels of reasoning consist of model structure assurance, model content assurance, and design compliance review. A methodology is introduced for model based compliance review which leverages the identified model queries related with model structure and content, and design compliance. Each of these contributions are explained in detail below (Figure 34).  Figure 34: Illustration of research contributions represented within separate chapters of the thesis Contribution 1: Chapter 2 benchmarks current practice and issues related with the handover process, project and handover artifacts, and FM practices based on a long term study of a large owner organization. The case study is unique in terms of the richness of the data (Figure 2) (Figure 3) (Figure 4) 185  collection and analysis methods used, the research approach investigating alignment across two interrelated contexts at the organizational and project levels, and the focus on information in terms of understanding how facility information is informed and affected by the organizational characteristics, processes, technology and requirements. In this investigation, I identified the gap between available versus required information and organizational processes and technology, including perceived weaknesses of the current state of practice and areas for improvement within the organization. I developed an alignment framework to represent the relationships between organizational processes and structure, organizational technology infrastructure and managed information, and handover artifacts.  Contribution 2: Chapter 3 investigates the complexity related with the identification of owners’ BIM-based delivery requirements. I identified the set of owner requirements and introduced a process to support the identification of model information requirements. As part of this chapter, a methodology for identifying computable requirements from investigation of owner requirements is also introduced. The findings presented in Chapter 3 further our understanding of the challenges associated with developing BIM requirements from the owners’ perspective and offer a solution to overcome them. In this regard, the findings highlight the complexity of identifying and formalizing information requirements from the review of a long and diverse set of existing formal and informal requirements, and then realigning these existing requirements to suit BIM-enabled project delivery as well as asset lifecycle management. The model information requirements identification methodology and subsequent frameworks developed from the methodology presented in chapter three aim to overcome these challenges and help owners transition towards BIM-186  enabled project delivery and asset lifecycle management through the development of clear and detailed requirements.    Contribution 3: Chapter 4 leverages the identified computable requirements described in Chapter 3 to evaluate compliance to owner requirements across three levels of reasoning. I formalized levels of compliance with the owner’s FM requirements are presented as; model structure verification, model information verification, and design compliance. A methodology to identify computable requirements from owner requirements analysis is also introduced in Chapter 4. Identified computable requirements are leveraged for evaluating model verification and supporting design compliance reviews.  The compliance review methodology presented has the potential to be applied across a variety of project scenarios (i.e. across a range of project types). 5.2 Validation  Expert reviews were used to validate the identified model queries based on their representativeness of the queries that experts use for project reviews. To validate the applicability of the three-stage approach for model evaluation the queries were run on two project models by using Solibri Model Checker. Explained in the following two sections are validation methods used as part of this research. 5.2.1 Expert Reviews of Model Queries   This research proposes a methodology for BIM based compliance review approach for project delivery (Figure 35). The proposed approach is based on running rule sets on project models to identify non-compliance to model and design compliance requirements. The proposed process consists of three levels of compliance; model structure verification, model content verification and design compliance review. Query based rule sets, which were identified in this 187  research are at the heart of the model compliance verification and design compliance review. The rule sets were based on model queries that were developed from the analysis of owner requirements, analyzed project BIMs, and identified computable requirements. However the research team had to make sure that the queries that make up the rule sets were representative of the queries used by experts in the domain. This section summarizes the validation method of the model queries from a representativeness perspective through expert reviews.   Figure 35: Proposed methodology for model based compliance review enabled by the use of rule sets which are turned into computable requirements  The validation is based on the representativeness of the identified queries (Table 3) for BIM based model and project compliance review, and the applicability of the model based compliance review process using the queries (Section 5.2.2). The completeness of the identified queries was not validated since the owner requirements cover a wide range of building components and systems, and it was not practical to gather a complete set of queries covering all owner requirements and the dissertation focused on a subset of building systems. The identification of the model queries is based on the analysis of four project BIMs, analysis of the formalized requirements of the organizations investigated, requirements from analysis of the performed interviews with the FM personnel, and the owner’s BIM requirements from the 188  literature. In this sense, validation of the queries is also supported by the grounded research approach, since the identified queries are based on analysis of actual case studies of two large owner organizations, and four project models. The applicability of the introduced methodology for model based compliance review was demonstrated on two project models. The identified queries, which were based on the owner requirements analysis, were run on models using Solibri Model Checker. Model structure and content issues, and design characteristics that are non-compliant with owner requirements were identified by using the three-stage model review methodology introduced. SMC uses IFC and the application allows the user to define rule sets that can be run on a model. The advantage of SMC was the availability of defined rules, and ability to define new rule sets by using the existing rules. The output of running the queries was automated identification of non-compliant design characteristics, and identification of model content and structure issues.  A review panel consisting of five domain experts was used to validate the representativeness of the identified model queries.  Researchers in project-based industries often need to validate their research by triangulating different methods, such as field observations, researching theory in related literature, reviewing predictions, and investigating insights from domain experts, expert opinion, and case studies (Fischer, 2006). In this research, we use a combination of approaches to validate the research findings. The approaches used are collectively known as content and face validity approaches, as defined in the literature. Face validity (sometimes referred to as representational validity) determines whether a study represents its intended measure, and if it represents reality (Leedy and Ormrod 2005; Lucko and Rojas 2010). Content validity is another non-statistical approach that focuses on determining whether the content of a research study makes sense in its context (domain) and is representative 189  of reality. The experts were three project managers from the Project Services Department, and the Asset Stewardship Superintendent and the Maintenance Technical Specialist from the Building Operations from the large Canadian university. Experts were intentionally selected from different departments and with different responsibilities in order to capture the varying perspectives on project delivery and FM practices within the context of a large owner organization. The experts were provided with a list of identified queries (refer to Table 3, located in Chapter 1) before the review. The validation survey is based on a five-point Likert scale to rate the applicability of the compliance checking method that was presented. The experts were asked to rate the list of queries from not representative to highly representative. During the sessions, a brief introduction of the research was provided on the approach for evaluation of model and design compliance through defined model queries, and also on what the experts were asked to rate. Later the experts were asked to rate the identified model queries based on representativeness. Feedback from the experts was requested at the end by opening the floor for a semiformal discussion, which provided insight into the use, and possible benefits of the introduced queries and process of using them.  The review panels started with brief information on the research progress. The experts were asked to evaluate whether the queries developed from the set of identified computable requirements were representative of the information that is reviewed or checked during design reviews and at handover. The representativeness survey is based on a subset of requirements identified during the analysis project models and the analysis of owner requirements. The selected subset of identified requirements were about information that can be represented in and queried from a BIM. They were asked to rate the importance of the requirement, and the 190  frequency of using such queries for their compliance review process. Following their review of the queries, the experts were informally interviewed;  to get their insights on the queries and the method of compliance checking  to comment on any items that are seen as problematic or desirable by the experts   to compare current compliance review process with the model based process  to talk about the ease of using the query and model based process to identify noncompliance, the required expertise to use the process, and required time for model and query based compliance review compared to current manual methods   to comment on the usefulness of the approach, applicability in practice, their suggestions for improvement, and whether they see anything as problematic or desirable in our approach  The analysis of the expert reviews indicates that even though the queries are considered as mainly the “often checked” and “sometimes checked” queries during compliance reviews, the experts noted that their project reviews are based on the FM function they are responsible for. For example the Maintenance Technical Specialist did not evaluate the representativeness of the queries related with the architectural design since it was not his area of expertise. However all five experts from the Canadian University marked the system and equipment related queries as mostly “often checked” and of “high importance” queries. The validation study showed evidence of the different perspectives that the FM personnel have when evaluating design compliance with owner requirements depending on the specific FM function they perform.     191  5.2.2 Evaluation of Survey Results  There were 87 queries (see Appendix I for queries), which were related to 37 model and design conditions, were evaluated for representativeness by the participating five experts. The result of the evaluation of the eighty-seven queries' representativeness is represented in Figure 36. The queries were based on identified information requirements, required design conditions and model requirements. 53 of the queries could be evaluated by all five experts, while 34 of the queries were evaluated by four experts excluding the Maintenance Technical Specialist. The Maintenance Technical Specialist did not evaluate the queries related to architectural systems and design review since architecture was not his area of expertise. A five level evaluation scale was used for the degree of representativeness of each query; query is highly representative (often checked), somewhat representative (sometimes checked), low representation (rarely checked), not representative (never checked) for compliance review, or non-applicable for the queries that are not part of the expert’s knowledge area. Overall results reflect that 76% of the identified computable queries in this research were representative of the “often” (54%)  and “sometimes” (22%) used queries. 13% of the identified computable queries were representative of the “rarely” used queries, and 3%  of the identified computable queries were not as part of the queries that the experts would use during compliance reviews. 54% of overall queries are of highly representative (often checked), 22% are of somewhat representative (sometimes checked), 13% are of low representation (rarely checked), 3% are of never checked during a compliance review, and 8% of the queries were marked as not-applicable by the experts (Figure 37). Analysis of survey data of queries evaluated by all five experts indicates that the highly representative (often checked) design conditions according to the five experts are 5A, 5B, 5C, 6A, 7B, 8A, 9A, 14A, 23A, 23B, and 32B (Figure 36, Table 32). 192   Figure 36: Evaluation of eighty-seven queries' representativeness by five experts. Numbers on the outside of the radar chart indicates each evaluated query   Figure 37: Pie chart visualizing the distribution of expert evaluations of the queries’ representativeness 193  Table 32: Highly representable (often checked) requirements that can be turned into computable queries # Owner Requirements 5A  5B  5C  Representation of access space to equipment   Representation of access space to remove and replace equipment   Representation means of lifting equipment heavier than certain weight (e.g. 500lbs) 6A Design requirement of a building component triggered by certain conditions  Availability of required cages for ladders to access equipment and roofs (applicable in certain cases) 7B  Availability of space required for moving the largest equipment from a room type 8A  Equipment installation requirement related to service space 9A  Checking availability of equipment components that allow for easy maintenance (e.g., checking the availability of guards for unprotected drives) 14A  Check for safe access requirement for servicing and replacement for HVAC equipment  23A 23B Completeness of geometric and non-geometric model content according to requirements  Availability of the least amount of information required for ALL components  Availability of required information for EACH system component  32B Compliance with requirements for different room types  Checking location of certain room types within a building e.g., “The preferred location for Electrical Rooms is on North or East exterior building wall”  5.2.3 Application of Three-stage Approach for Model Evaluation  The retrospective analysis of project models is based on using model queries identified from owners’ requirements analysis from Chapter 3. A project BIM from the Canadian university, and another project BIM from the government agency were used for the retrospective analysis using the three-stage approach presented in Chapter 4. The retrospective analysis for each project reflected the non-compliance of the project BIMs with the owner requirements, which validated the applicability of the presented three-stage approach (Figure 2). The identified 194  model queries were run on project models using Solibri Model Checker to check non-compliance according to three stage approach; model structure, model content, and design compliance.   The practical research motivation was the lack of predefined processes for model evaluation for compliance with FM requirements. The applied steps which led to validating applicability of the three-stage approach are summarized in the following:  First, to benchmark the current state of the project models three project models from the Canadian university and a project model from the government agency were retrospectively analyzed.  During the analysis of the four project models a combination of tools such as Revit, Navisworks, Solibri Model Checker, and EcoDomus, and Revit COBie add-in were used. The investigation of the models indicated that the models were lacking the structure to compute model information correctly or model structure issues were leading to not being able to compute required information; the models were lacking the content required for FM use; and there were design characteristics which were contrary to the owners’ requirements. Experience with the different tools which were used for investigation led to an understanding of the significant effort required in terms of model manipulation for getting the design and construction models ready for model analysis from FM perspective. Specifically during the analysis of models using life-cycle information management application (EcoDomus) a significant model preparation was required. Model preparation involved activities such as:  Checking model content for available information  Looking for modeling errors in architectural and mechanical models  Manipulating space information in architectural model and mapping space information to mechanical model   Manipulating space information for accurate computation 195   Adding required FM related geometric and non-geometric content such as required mechanical equipment attributes to the model components  Defining systems and system-equipment relationships within mechanical models  Structuring the nomenclature of model components and systems  Performed model analyses led to an understanding that in order to perform design compliance review, a model first had to be evaluated for model structure and content verification. Model structure and content compliance review criteria were based on experience gained from model analysis of four project models. However, the process of reviewing a model for an owner had to be formalized. The process had to be clearly laid out for the owners in order to be able to transition to a model based project delivery practice. The focus of model review was to check the design information compliance with owner requirements, yet the current research was falling short on defining the complex requirements for model based project delivery. This led to the classification of three-stage approach for analyzing model compliance with owner requirements which consist of; model structure verification, model content verification, and design review for compliance with owner requirements.  Second, the criteria for each of the three-stages were formalized by analyzing the owner requirements. A list of requirements from the analysis of four project models and owner requirements was created. The list consisted of requirements that could be represented in and queried from a BIM. Later identified requirements were turned into model queries which were later applied to two project models to review models for compliance. Solibri Model Checker was used to run the identified queries on models.  By applying the developed three-stage approach which leveraged identified model queries it was possible to validate the applicability of the developed approach to review models for compliance. 196  5.3 Practical Implications  This research has many practical implications to the facility management industry, as well as the AEC industry since the AEC industry is going to be largely affected by the changes to how they currently deliver projects. In addition, the approaches presented as part of this research could be useful to design analysis and construction as well. The alignment framework introduced in Chapter 2 enables the owner to evaluate the alignment of FM processes, technology infrastructure, project artifacts, and requirements. The iterative information requirements identification process introduced in Chapter 3 helps owners develop model requirements. The identified levels of reasoning in Chapter 4 informs owners about a methodology to ensure the quality of project models they require and receive at project closeout. The research contributes towards improving efficiency, consistency and effectiveness in BIM implementation by owner organizations. Introduced rule based model compliance evaluation according to owner requirements is aimed at eliminating the tedious manual approach of reviewing design and model compliance with owner requirements. We anticipate that this work could have an impact in the following ways: I. Communicates the complexity related with implementing BIM in owner organizations II. Guides owners to evaluate alignment of their organizational processes, technology infrastructure and requirements with the project artifacts (handover information and models) III. Supports owners in developing requirements for model based project delivery IV. Provides owners with a process to evaluate FM BIMs, and project information for compliance with owner requirements 197  V. The rule-based automated model review approach has the potential to reduce errors during project information review by reducing manual work. It also promises standardization of the review process since it requires formalization of owner requirements 5.4 Limitations of the Current Research and Future Research Directions  This dissertation focused on BIM for FM from the owners’ perspective. It is grounded on actual cases, completed over a long term (2011-2015), and it deals directly with real data from the investigated organizations. The research is qualitative, and is based on ethnographic and exploratory data. Within the world of FM, this research focuses on the project information creation during design and construction, to the extent of required information and its exchange to operations phase, to be used to perform FM functions like asset management, space management, and maintenance management. Within the domain of FM functions and related model components, the specific focus was on architectural spaces, mechanical equipment and systems related information. Information such as building envelope, electrical, or structural information was excluded.  The case studies in this dissertation are from two large owner organizations from Canada, which implies that the findings related to the Canadian context. Further investigation is required to ensure validity for cases outside of Canada. On the other hand, the literature review indicates similar issues worldwide related to FM practices and model use for handover and FM. The identified requirements and rule sets from this research can be applied to other owners in and outside of Canada as well, if such owners find them applicable to their organizational processes. The research can be turned into the development of model requirements and rule sets that can be applicable to owner organizations that have similar requirements for FM or handover. Further 198  research on developing such rule sets can contribute to model based delivery and compliance review research domains. Identified queries in this research are not adequate for a complete review process that satisfies the requirements from the perspective of each and every FM function. In terms of suggestions for future research, the number of queries and the coverage of building systems and components can be improved to investigate the applicability of the approach for a whole building project. Additionally, usability studies involving the owners’ personnel where they apply the identified queries on project models can be used to understand the required expertise for using the BIM tools, to interpret model query results by the FM personnel.   199  Bibliography Akcamete, A., Akinci, B., & Garrett, J. H. (2010). Potential utilization of building information models for planning maintenance activities. Anderson, A., Marsters, A., Dossick, C., & Neff, G. (2012). Construction to Operations Exchange: Challenges of Implementing COBie and BIM in a Large Owner Organization. Construction Research …, (Cic 2011), 688–697. https://doi.org/10.1061/9780784412329.070 Anderson, A., Marsters, A., Dossick, C. S., & Neff, G. (2012). Construction to operations exchange: Challenges of implementing COBie and BIM in a large owner organization BT  - Construction Research Congress 2012: Construction Challenges in a Flat World, May 21, 2012 - May 23, 2012 (pp. 688–697). College of Environment, College of Built Environments, University of Washington, United StatesBNBuilders Inc., Seattle, WA, United StatesDepartment of Construction Management, University of Washington, United StatesDepartment of Communication, University : American Society of Civil Engineers (ASCE). https://doi.org/10.1061/9780784412329.070 Au, S. (2009). 2009 BIM / BLM for Owners. Becerik-Gerber, B., Asce, A. M., Jazizadeh, F., Li, N., & Calis, G. (2011). Application Areas and Data Requirements for Bim-Enabled Facilities Management. Journal of Construction Engineering and Management, (May), 431–442. https://doi.org/10.1061/(ASCE)CO.1943-7862.0000433 Becerik-Gerber, B., Asce, A. M., Jazizadeh, F., Li, N., & Calis, G. (2012). Application Areas and Data Requirements for BIM-Enabled Facilities Management, (May), 431–442. https://doi.org/10.1061/(ASCE)CO.1943-7862.0000433. Becerik-Gerber, B., Jazizadeh, F., Li, N., & Calis, G. (2012a). Application areas and data requirements for BIM-enabled facilities management. Journal of Construction Engineering and Management, 138(3), 431–442. https://doi.org/10.1061/(ASCE)CO.1943-7862.0000433 Borsboom, W. (n.d.). Netherlands Today. Retrieved on August 16th 2014 from http://eetd.lbl.gov/sites/all/files/%0Aborsboom120809a.pdf%0A  Bosch, Arnold; Volker, L.; Koutamanis, A. (2015).  BIM in the operations stage: Bottlenecks and implications for owners. Built Environment Project and Asset Management, 5(3), 331-343. Brooks, A., & Lilley, G. (2006). Enabling technology for outsourced facilities management. 200  Electronic Journal of Information Technology in Construction, 11, 685–695. Brucker, B. a, & Nachtigall, S. D. (2005). Initiating the building information model from owner and operator criteria and requirements. Proceedings of the 2005 {ASCE} International Conference on Computing in Civil Engineering, 211 – 222. https://doi.org/10.1061/40794(179)20 BuildingSMART. (2007). National BIM Standard - United States TM Version 2, 182. Retrieved May 15th 2013, from www.nationalbimstandard.org/nbims-us-v2/pdf/NBIMS-US2_aB.pdf Cavka, H. B., Poirier, E., & Staub-French, S. (2017). Developing Owner Information Requirements for BIM-enabled Project Delivery and Asset Management. Automation in Construction, Submitted. Cavka, H., Staub-French, S., & Pottinger, R. (2015). Evaluating the Alignment of Organizational and Project Contexts for BIM Adoption: A Case Study of a Large Owner Organization. Buildings, 5(4), 1265–1300. https://doi.org/10.3390/buildings5041265 Chan, Y. E., & Reich, B. H. (2007). IT alignment: What have we learned? Journal of Information Technology, 22, 297–315. https://doi.org/10.1057/palgrave.jit.2000109 Cheng, J. C. P., & Lu, Q. (2015). A review of the efforts and roles of the public sector for BIM adoption worldwide. Journal of Information Technology in Construction, 20, 442–478. Choi, J., & Kim, I. (2008). An Approach to Share Architectural Drawing Information and Document Information for Automated Code Checking System. Tsinghua Science and Technology, 13(s1), 171–178. https://doi.org/10.1016/S1007-0214(08)70145-7 Clayton, M. J., Johnson, R. E., Song, Y., & Al-Qawasmi, J. (1998). A Study of Information Content Of As-built Drawings for USAA. Technical Report CRS Center/USAA, (August 2015), 1–24. Coates, P., Arayici, Y., Koskela, K., Kagioglou, M., Usher, C., & O’Reilly, K. (2010). The key performance indicators of the BIM implementation process. Codinhoto, R., & Kiviniemi, A. (2014). BIM for FM: A Case Support for Business Life Cycle. In S. Fukuda, A. Bernard, B. Gurumoorthy, & A. Bouras (Eds.), Product Lifecycle Management for a Global Market SE  - 7 (Vol. 442, pp. 63–74). Springer Berlin Heidelberg. https://doi.org/10.1007/978-3-662-45937-9_7 Construction Industry Council. (2013). Building Information CIC / BIM Protocol. Cic, 1–15. Corry, E., Keane, M. M., O’Donnell, J., & Costa, A. (2011a). Systematic development of an operational BIM utilizing simulation and performance data in building operation. Proceedings of the 12th International IBPSA Conference, 14–16. 201  Corry, E., Keane, M., O’Donnell, J., & Costa, A. (2011b). Systematic development of an operational BIM utilising simulation and performance data in building operation BT  - 12th Conference of International Building Performance Simulation Association Building Simulation 2011, BS 2011, November 14, 2011 - November (pp. 1422–1429). National University of Ireland, Galway, IrelandLawrence Berkeley National Laboratory, Berkeley, CA, United States: International Building Performance Simulation Association. Crotty, R. (2011). The impact of building information modelling: Transforming construction. Routledge. Dhillon, B. S. (2006). Maintainability, maintenance, and reliability for engineers. CRC press. Ding, Y. (2009). Product Maintainability Design Method and Support Tool Based on Feature Model. Journal of Software Engineering and Applications, 2(October), 165–172. https://doi.org/10.4236/jsea.2009.23024 East, E. W., & Nisbet, N. (2010). Analysis of life-cycle information exchange. Training, (Wilbur 2009). East, W. E., & Brodt, W. (2007). BIM for Construction Handover. Journal of Building Information Modeling, 28–35. Retrieved on July 17th 2015, from https://www.pinnaclecad.com/pin-pdf/BIM-for-Construction-Handover.pdf Eastman, C. (2009). Automated assessment of early concept designs. Architectural Design, 79, 52–57. https://doi.org/10.1002/ad.851 Eastman, C., Teicholz, P., Sacks, R., & Liston, K. (2008). BIM for Owners and Facility Managers. In BIM Handbook (pp. 93–147). John Wiley & Sons, Inc. https://doi.org/10.1002/9780470261309.ch4 Eastman, C., Teicholz, P., Sacks, R., & Liston, K. (2011). BIM Handbook: A Guide to Building Information Modeling for Owners, Managers, Designers, Engineers and Contractors. Building (Vol. 2). https://doi.org/10.1002/9780470261309 ECOCanada. (n.d.). No Title. Retrieved on May 18th 2013, from http://www.eco.ca/ecoreports/pdf/2011-Buildings-Operator-Scoping-Study.pdf Fallon, K. K., & Palmer, M. E. (2006). Capital Facilities Information Handover Guide, Part 1 Project. National Institute of Standards and Technology. Fallon K.; Palmer M. (2007). General Buildings Information Handover Guide : Principles Methodology and Case Studies. National Institute of Standards & Technology. Washington DC, USA. Forns-Samso, F. (2011). Perceived value of Building information modeling in facility operations 202  and maintenance. Retrieved from https://repository.unm.edu/handle/1928/12036 Foster, B. (n.d.). BIM : Next Gen Facility Management Design for Maintenance Strategy Introduction Owners : Cost of NOT doing BIM BIM for Operational Savings “ Design for Maintenance ” Strategy Tying it all together Resource Recommendations. Foster, B. (2011). BIM for facility management: design for maintenance strategy. Journal of Building Informaiton Modeling, Spring, 18–19. Gallaher, M. P., O’Conor, A. C., Dettbarn, J. L., & Gilday, L. T. (2004). Cost Analysis of Inadequate Interoperability in the U.S. Capital Facilities Industry. National Institute of Standards & Technology, 1–210. https://doi.org/10.6028/NIST.GCR.04-867 Ghosh, A., Chasey, A. D., & Mergenschroer, M. (2015). Building Information Modeling for Facilities Management: Current practices and future prospects. Building Information Modeling, 223. Giel, B., & Issa, R. R. a. (2014). Framework for Evaluating the BIM Competencies of Building Owners, (Cmm), 552–559. Giel, B. K., Mayo, G., Issa, R. R. A., & Giel, B. K. (2015, January). BIM Use and Requirements Among Building Owners. Building Information Modeling : Applications and Practices in the AECO Industry. American Society of Civil Engineers. https://doi.org/10.1061/9780784413982.ch10 Greenwood, D., Lockley, S., Lewis, S., Malsane, S., & Matthews, J. (2010). Automated compliance checking using building information models. Cobra 2010, 363–371. Retrieved on May 25th 2013, from http://www.rics.org/site/download_feed.aspx?fileID=7953&fileExtension=PDF%5Cnhttp://nrl.northumbria.ac.uk/1667/%5Cnhttp://nrl.northumbria.ac.uk/6955/ Hamil, S. (2010). BIM and building properties. Building Information Modelling Article from NBS. Henderson, J. C., & Venkatraman, H. (1993). Strategic alignment: Leveraging information technology for transforming organizations. IBM Systems Journal, 32, 472–484. https://doi.org/10.1147/sj.382.0472 Hjelseth, E. (2015, January 1). BIM-based Model Checking (BMC). Building Information Modeling : Applications and Practices in the AECO Industry. American Society of Civil Engineers. https://doi.org/10.1061/9780784413982.ch02 Jones, S. a. (2012). The Business Value of BIM in North America: Multi-Year Trend Analysis and User Ratings (2007-2012). Retrieved on September 2nd 2014, from 203  http://analyticsstore.construction.com/index.php/2012-business-value-of-bim-in-north-america-smartmarket-report.html Kensek, K. (2015). BIM Guidelines Inform Facilities Management Databases: A Case Study over Time. Buildings, 5(3), 899–916. https://doi.org/10.3390/buildings5030899 Kiviniemi, A. (2005). Requirements management interface to building product models. VTT Publications, (572), 1–12. Kiviniemi, A., & Codinhoto, R. (2014). Challenges in the Implementation of BIM for FM - Case Manchester Town Hall Complex. Computing in Civil and Building Engineering (2014), 665–672. https://doi.org/10.1061/9780784413616.083 Klein, L., Li, N., & Becerik-gerber, B. (2012). Automation in Construction Imaged-based verification of as-built documentation of operational buildings. Automation in Construction, 21, 161–171. https://doi.org/10.1016/j.autcon.2011.05.023 Korman, T. M., Fischer, M. a., & Tatum, C. B. (2003). Knowledge and Reasoning for MEP Coordination. Journal of Construction Engineering and Management, 129(December), 627–634. https://doi.org/10.1061/(ASCE)0733-9364(2003)129:6(627) Korpela, J., Miettinen, R., Salmikivi, T., & Ihalainen, J. (2015). The challenges and potentials of utilizing building information modelling in facility management: the case of the Center for Properties and Facilities of the University of Helsinki. Construction Management and Economics, 33(1), 3–17. https://doi.org/10.1080/01446193.2015.1016540 Lee, H. W., Oh, H., Kim, Y., & Choi, K. (2015). Quantitative analysis of warnings in building information modeling (BIM). Automation in Construction, 51, 23–31. https://doi.org/10.1016/j.autcon.2014.12.007 Lee, Y., Eastman, C. M., Solihin, W., & See, R. (2016). Automation in Construction Modularized rule-based validation of a BIM model pertaining to model views. Automation in Construction, 63, 1–11. https://doi.org/10.1016/j.autcon.2015.11.006 Lewis, A., & Whittaker, J. (2012). Identifying and Overcoming Industry Challenges to Reach the BIM FM Vision. Journal of Building Information Modeling, 18–19. Lindkvist, C., & Whyte, J. (2013). Challenges and Opportunities Involving Facilities Management in Data Handover: London 2012 Case Study. Aei 2013, 670–679. https://doi.org/10.1061/9780784412909.066 Liu, L. Y., Stumpf, A. L., Kim, S. S., & Zbinden, F. M. (1994). Capturing as-built project information for facility management. In Computing in Civil Engineering (1994) (pp. 614–621). Retrieved from http://cedb.asce.org/cgi/WWWdisplay.cgi?9402591 204  Liu, R., & Issa, R. R. a. (2014). Design for maintenance accessibility using BIM tools. Facilities, 32(3), 153–159. https://doi.org/10.1108/F-09-2011-0078 Mayo, G., Issa, R. R. A., & Asce, F. (2012). Nongeometric Building Information Needs Assessment for Facilities Management. https://doi.org/10.1061/(ASCE)ME.1943-5479.0000414. Mcauley, J., Duberley, J., & Johnson, P. (2007). Organization Theory Challenges and Perspectives. Miles, M. B., Huberman, A. M., & Saldana, J. (2013). Qualitative data analysis: A methods sourcebook. SAGE Publications, Incorporated. Motawa, I., & Almarshad, A. (2013). A knowledge-based BIM system for building maintenance. Automation in Construction, 29, 173–182. https://doi.org/10.1016/j.autcon.2012.09.008 Moua Her, B., & Russell, J. S. (2002). Maintainability Implemented by Third-Party Contractor for Public Owner. Journal of Management in Engineering, 18(April), 95–102. https://doi.org/10.1061/(ASCE)0742-597X(2002)18:2(95) National Research Council. (1998). Stewardship of Federal Facilities: A Proactive Strategy for Managing thePublic Assets. National Research Council. (2012). Predicting Outcomes from Investments in Maintenance and Repair for Federal Facilities Repair for Federal Facilities. Ole Berard, Jan Karlshoej (2012). Information delivery manuals to integrate building product information into design, ITcon Vol. 17, pg. 63-74, http://www.itcon.org/2012/4 Patacas, J., Dawood, N., & Kassem, M. (2015). BIM for Facilities Management: Evaluating BIM Standards in Asset Register Creation and Service Life Planning. Journal of Information Technology in Construction, 20(10), 313–318. Peppard, J., & Breu, K. (2003). Beyond Alignment: A Coevolutionary View of the Information Systems.  C. I. C. R. Program (2013). BIM Planning Guide for Facility Owners. Pennsylvania State University Sabol, L. (2008). Building Information Modeling & Facility Management. Facilities Management. Scarponcini, P. (1AD). Time for an integrated approach to facility management. Journal of Computing in Civil Engineering, 10(1), 3. Schultz, M. (2001). The uncertain relevance of newness: Organizational learning and knowledge 205  flows. Academy of Management, 44, 661–681. Solihin, Wawan; Eastman, C.; Lee, Y. C. (2015). Toward Robust Quantifiable Automated IFC Quality Validation. Advanced Engineering Informatics, 29(3), 739–756. Then, D. S. (1999). An integrated resource management view of facilities management, 17(12), 462–469. Tushman, M. L. & O’Reilly, C. A. (1996). Ambidextrous organizations: managing evolutionary and revolutionary change. California Management Review, 38, 8–30.  Volk, R., Stengel, J., & Schultmann, F. (2014). Building Information Modeling (BIM) for existing buildings - Literature review and future needs. Automation in Construction, 38, 109–127. https://doi.org/10.1016/j.autcon.2013.10.023 Wani, M. F., & Gandhi, O. P. (1999). Development of maintainability index for mechanical systems. Reliability Engineering and System Safety, 65, 259–270. https://doi.org/10.1016/S0951-8320(99)00004-6 Wu, W., & Issa, R. R. A. (2012). BIM-enabled building commissioning and handover BT  - 2012 ASCE International Conference on Computing in Civil Engineering, June 17, 2012 - June 20, 2012 (pp. 237–244). Department of Construction Management and Civil Engineering, Georgia Southern University, P.O. Box 8047, Statesboro, GA 30460-8047, United StatesRinker School of Building Construction, University of Florida, P.O. Box 115703, Gainesville, FL 32611-5703, Un: American Society of Civil Engineers (ASCE). https://doi.org/10.1061/9780784412343.0030 Yin, R. K. (2014). Case study research: Design and methods (5th Editio). Thousand Oaks, California: Sage. Zhang, S., Teizer, J., Lee, J. K., Eastman, C. M., & Venugopal, M. (2013). Building Information Modeling (BIM) and Safety: Automatic Safety Checking of Construction Models and Schedules. Automation in Construction, 29, 183–195. https://doi.org/10.1016/j.autcon.2012.05.006   206  Appendix A: Analysis of Expert Reviewers’ Responses   Expert A (PM, Built Environment) Expert B (PM, HVAC Design/Build & Energy)  Expert C (Senior PM) Expert D (PM, Transition) Expert E (Mech. Maintenance Specialist)          Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly(Often Checked) Somewhat(Sometimes) Low (Rarely) No (Never) N/A totals 1A Orientation of a room  within a building 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 0 ARCH 0 3 1 0 1 4 2A Wall fire rating of a wall in a specific  room type 1 0 0 0 1 0 0 0 1 0 0 0 0 0 0 1 ARCH 3 0 0 1 1 4 2B Availability of equipment required in a room type 1 0 0 0 1 0 0 0 1 0 0 0 0 1 0 0 ARCH 3 1 0 0 1 4 2C Availability of a not-permitted ceiling type in a room type 1 0 0 0 1 0 0 0 1 0 0 0 0 0 0 1 ARCH 3 0 0 1 1 4 2D Access condition of a specific room type 1 0 0 0 1 0 0 0 1 0 0 0 0 1 0 0 1 0 0 0 4 1 0 0 0 5 3A Checking availability of required floor material in a room 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 0 ARCH 0 3 1 0 1 4 4A Checking space usage (e.g. room to be used for only one purpose) 0 1 0 0 1 0 0 0 0 1 0 0 1 0 0 0 ARCH                                            (BELONGS TO ARCHITECTURAL DEPARTMENT, IT IS NOT THIS PERSON'S E1PERTISE) 2 2 0 0 1 4 4C Door swing direction of a room type 0 1 0 0 1 0 0 0 1 0 0 0 0 0 0 1 2 1 0 1 1 4 4D Door size of a room type 0 1 0 0 0 1 0 0 0 1 0 0 0 0 0 1 0 3 0 1 1 4 4E Location of a room type  0 1 0 0 1 0 0 0 1 0 0 0 0 0 0 1 2 1 0 1 1 4 207    Expert A (PM, Built Environment) Expert B (PM, HVAC Design/Build & Energy)  Expert C (Senior PM) Expert D (PM, Transition) Expert E (Mech. Maintenance Specialist)          Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly(Often Checked) Somewhat(Sometimes) Low (Rarely) No (Never) N/A totals 4F Size of a room type (e.g. 40 sqm) 0 1 0 0 1 0 0 0 1 0 0 0 0 0 0 1 2 1 0 1 1 4 4G Dimension of a room type (e.g. 5m 1 4m) 0 1 0 0 1 0 0 0 1 0 0 0 0 0 0 1 2 1 0 1 1 4 4H Availability of electrical equipment (outlets) required in a room type 0 1 0 0 1 0 0 0 1 0 0 0 0 1 0 0 2 2 0 0 1 4 4I Availability of furniture required in a room type 0 1 0 0 1 0 0 0 1 0 0 0 0 0 0 1 2 1 0 1 1 4 5A Representation of access space to equipment 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 5 0 0 0 0 5 5B Representation of access space to remove and replace equipment 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 5 0 0 0 0 5 5C Representation means of lifting equipment heavier than certain weight (e.g. 500lbs) 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 5 0 0 0 0 5 6A Design requirement of a building component triggered by certain conditions   ·         Availability of required cages for ladders to access equipment and roofs (applicable in certain cases) 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 5 0 0 0 0 5 7A Accessibility of a room type (public vs personnel access) 1 0 0 0 1 0 0 0 1 0 0 0 0 1 0 0 1 0 0 0 4 1 0 0 0 5 208    Expert A (PM, Built Environment) Expert B (PM, HVAC Design/Build & Energy)  Expert C (Senior PM) Expert D (PM, Transition) Expert E (Mech. Maintenance Specialist)          Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly(Often Checked) Somewhat(Sometimes) Low (Rarely) No (Never) N/A totals 7B Availability of space required for moving the largest equipment from a room type 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 5 0 0 0 0 5 8A Equipment installation requirement regarding space:                                        •       Service space 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 5 0 0 0 0 5 8B •       Disassembly space 0 1 0 0 0 1 0 0 0 1 0 0 1 0 0 0 1 0 0 0 2 3 0 0 0 5 8C •       Space for removal 0 1 0 0 0 1 0 0 0 1 0 0 1 0 0 0 1 0 0 0 2 3 0 0 0 5 9A Checking availability of equipment components that allow for easy maintenance  1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 5 0 0 0 0 5 10A Equipment to that is mounted to a certain surface to have special pads     ·         Checking availability of house pads for base mounted equipment 0 1 0 0 1 0 0 0 1 0 0 0 0 0 1 0 1 0 0 0 3 1 1 0 0 5 11A Specifications of a door type (e.g. access doors):                                                 •       Door material 1 0 0 0 1 0 0 0 1 0 0 0 0 0 0 1 ARCH 3 0 0 1 1 4 11B •       Door installation 1 0 0 0 1 0 0 0 1 0 0 0 0 0 0 1 3 0 0 1 1 4 11C •       Door location (so that concealed items are accessible) 1 0 0 0 0 1 0 0 1 0 0 0 1 0 0 0 3 1 0 0 1 4 209    Expert A (PM, Built Environment) Expert B (PM, HVAC Design/Build & Energy)  Expert C (Senior PM) Expert D (PM, Transition) Expert E (Mech. Maintenance Specialist)          Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly(Often Checked) Somewhat(Sometimes) Low (Rarely) No (Never) N/A totals 12A Checking availability of restricted plumbing component within a room type.  •      Check floor drains in private washrooms (allowed only in public washrooms where automatic flushing devices are used) 0 1 0 0 1 0 0 0 1 0 0 0 0 1 0 0 0 1 0 0 2 3 0 0 0 5 12B Checking whether all sanitary sumps are vented to outdoors 0 1 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 4 1 0 0 0 5 12C Check if all plumbing equipment requiring maintenance as frequent as one year are readily accessible 0 1 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 4 1 0 0 0 5 13A Check if equipment requiring periodic maintenance is mounted in locations where access requires using ladders 0 1 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 4 1 0 0 0 5 14A Check for safe access requirement for servicing and replacement for HVAC equipment 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 5 0 0 0 0 5 14B System and equipment types that are required to contain specific components                                                                                                                        •       Check if VAV systems have reheat coils at all VAV bo1es 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 1 0 0 0 1 4 0 0 0 5 210    Expert A (PM, Built Environment) Expert B (PM, HVAC Design/Build & Energy)  Expert C (Senior PM) Expert D (PM, Transition) Expert E (Mech. Maintenance Specialist)          Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly(Often Checked) Somewhat(Sometimes) Low (Rarely) No (Never) N/A totals 14C •       Check if AHUs have heating or preheat coils 0 1 0 0 1 0 0 0 1 0 0 0 0 1 0 0 1 0 0 0 3 2 0 0 0 5 14D Check air filter sizes in HVAC systems with UBC required sizes 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 1 0 0 0 1 4 0 0 0 5 14E Check air filter sizes in Fan Coil Units with UBC required sizes 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 1 0 0 0 1 4 0 0 0 5 14F Component orientation according to other building components                  •       Check for radiant heating panels that face windows 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 0 0 1 0 0 0 4 1 0 0 5 14G Equipment specific mounting surface requirements:                                          •       Check for window mounted air conditioners and e1haust fans (not acceptable) 0 1 0 0 0 0 0 1 0 0 0 1 0 0 1 0 0 1 0 0 0 2 1 2 0 5 15A Check for spatial pro1imity requirements:                                                               •       Component to component (e.g. roof drains not to be located close to column and beams) 0 1 0 0 0 1 0 0 0 1 0 0 1 0 0 0 0 0 0 0 1 3 0 0 1 4 15B •       Component to space (e.g. air intake louvers to loading docks, fume hood e1hausts, generator e1hausts) 0 1 0 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 0 0 3 2 0 0 0 5 211    Expert A (PM, Built Environment) Expert B (PM, HVAC Design/Build & Energy)  Expert C (Senior PM) Expert D (PM, Transition) Expert E (Mech. Maintenance Specialist)          Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly(Often Checked) Somewhat(Sometimes) Low (Rarely) No (Never) N/A totals 15C •       Component to elevation (e.g. outside air intake louvers to be located as high as possible above grade) 0 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 0 0 3 1 1 0 0 5 16A Check if water closets in public areas are floor mounted, urinals are wall-hung, partitions are floor mounted 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 1 0 0 0 1 4 0 0 5 16B Check if plumbing fi1tures are from same manufacturer (preferred) 0 0 1 0 0 0 1 1 0 0 1 0 0 0 1 0 0 0 0 0 0 0 4 1 0 5 18A Check weight and type of the compressors in the refrigeration system.     •       Weight ≤ 5 tons shall be hermetic type 0 0 1 0 0 0 1 0 0 0 0 0 0 1 0 0 0 1 0 0 0 2 2 0 1 4 19A Check fan coils/ D1 coils positioning in condensing units and cooling towers, to ensure access to service all components  0 1 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 4 1 0 0 0 5 19B Check outdoor condensing unit location                                                                        - Not adjacent to fume hood areas or 10ft from roof edge without guard rail 0 1 0 0 1 0 0 0 0 1 0 0 0 1 0 0 1 0 0 0 2 3 0 0 0 5 20A Check if there is equipment in ceiling above communication equipment in 0 1 0 0 1 0 0 0 1 0 0 0 0 1 0 0 0 1 0 0 2 3 0 0 0 5 212    Expert A (PM, Built Environment) Expert B (PM, HVAC Design/Build & Energy)  Expert C (Senior PM) Expert D (PM, Transition) Expert E (Mech. Maintenance Specialist)          Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly(Often Checked) Somewhat(Sometimes) Low (Rarely) No (Never) N/A totals server/communication rooms  20B Check if cooling towers over 8’ have service platforms with permanent ladders 0 1 0 0 1 0 0 0 1 0 0 0 0 1 0 0 1 0 0 0 3 2 0 0 0 5 21A Check if all interior air terminal units in air conditioned buildings have reheat coils (unless the engineer demonstrates it is not required)  0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 1 0 0 0 1 0 4 0 0 5 22A Check AHUs for sufficient access to all components  0 1 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 4 1 0 0 0 5 22B Check AHU’s clearance adequacy for coil replacement without necessity to dismantle adjacent equipment or building component  0 1 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 4 1 0 0 0 5 22C Check if AHUs have heating or preheat coils 0 1 0 0 1 0 0 0 1 0 0 0 0 1 0 0 1 0 0 0 3 2 0 0 0 5 23A Completeness of geometric and non-geometric model content according to requirements                                                                                                                          ·         Availability of the least amount of information required for ALL components 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 5 0 0 0 0 5 213    Expert A (PM, Built Environment) Expert B (PM, HVAC Design/Build & Energy)  Expert C (Senior PM) Expert D (PM, Transition) Expert E (Mech. Maintenance Specialist)          Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly(Often Checked) Somewhat(Sometimes) Low (Rarely) No (Never) N/A totals 23B ·         Availability of required information for EACH system component 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 5 0 0 0 0 5 24A Checking information in title blocks:                                                           Availability, completeness, and nomenclature  of information 0 0 1 0 0 1 0 0 Would be good to have 1 0 0 0 1 0 0 0 2 1 1 0 1 4 25A Required building systems’ availability in the model                                            E.g. checking whether all required plumbing systems are available in the model 0 1 0 0 1 0 0 0 Would be good to have 1 0 0 0 1 0 0 0 3 1 0 0 1 4 26A Compliance of space information with OSR                                                            ·         Number of required rooms vs available rooms 0 1 0 0 1 0 0 0 Would be good to have 0 0 1 0 1 0 0 0 2 1 1 0 1 4 26B ·         Required room areas vs provided room areas 0 1 0 0 1 0 0 0 0 0 1 0 1 0 0 0 2 1 1 0 1 4 27A Maintainability of mechanical rooms                                                                         ·         Elevator access to floor 0 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 4 0 1 0 0 5 27B ·         space to remove the largest equipment from the room and the building 0 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 4 0 1 0 0 5 27C ·         door sizes and corridor clearances to fit the largest equipment 0 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 4 0 1 0 0 5 214    Expert A (PM, Built Environment) Expert B (PM, HVAC Design/Build & Energy)  Expert C (Senior PM) Expert D (PM, Transition) Expert E (Mech. Maintenance Specialist)          Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly(Often Checked) Somewhat(Sometimes) Low (Rarely) No (Never) N/A totals 28A Accessibility of mechanical equipment                                                                     ·         Clearance around equipment 0 1 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 4 1 0 0 0 5 28B ·         Clearance of access space for removal 0 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 4 0 1 0 0 5 28C ·         Installation height of equipment 0 0 1 0 0 1 0 0 1 0 0 0 0 1 0 0 1 0 0 0 2 2 1 0 0 5 29A Identification of system components located in restricted areas                  ·         Water containing pipes (e1cept for sprinkler pipes) running through or beside e1hibition and collections areas 0 0 1 0 1 0 0 0 1 0 0 0 0 1 0 0 1 0 0 0 3 1 1 0 0 5 29B ·         No floor drains in private washrooms 0 0 1 0 0 0 1 0 ? ? ? ? 1 0 0 0 0 0 1 0 1 0 3 0 1 4 30A Compliance with design and installation requirements of building components                                                                                                                       ·         i.e. installation surface for water closets wall or floor mounted 0 0 0 1 0 0 1 0 0 0 1 0 0 0 1 0 0 1 0 0 0 1 3 1 0 5 30B ·         i.e. check for concealed piping systems and equipment: not allowed in trenches, 0 0 1 0 1 0 0 0 1 0 0 0 0 1 0 0 0 1 0 0 2 2 1 0 0 5 215    Expert A (PM, Built Environment) Expert B (PM, HVAC Design/Build & Energy)  Expert C (Senior PM) Expert D (PM, Transition) Expert E (Mech. Maintenance Specialist)          Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly(Often Checked) Somewhat(Sometimes) Low (Rarely) No (Never) N/A totals shafts, furring, and suspended ceilings  30C ·         i.e. check for ceiling mounted e1haust fans installed directly above meeting and conference rooms (unwanted) 0 0 1 0 0 0 1 0 0 0 0 1 0 1 0 0 0 1 0 0 0 2 2 1 0 5 31A Identify material properties of building components                                          ·         i.e. checking material for sprinkler pipes 0 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 0 1 0 3 0 2 0 0 5 31B ·         i.e. check air handler filter sizes for compliance 0 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 0 1 0 3 0 2 0 0 5 32A Compliance with pro1imity requirements                                                                ·         Space to space                                                                                                             i.e 1 room to be located in the ground floor and close to loading bay Generally good to have 1 0 0 0 1 0 0 0 1 0 0 0 0 1 0 0 3 1 0 0  4 32B ·         Component to space                                                                                               i.e. emergency eyewash and or showers pro1imity to areas where chemicals are used 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 5 0 0 0 0 5 32C i.e. whether all air handling equipment is located indoors in mechanical rooms Generally good to have 1 0 0 0 1 0 0 0 1 0 0 0 0 1 0 0 3 1 0 0 1 4 216    Expert A (PM, Built Environment) Expert B (PM, HVAC Design/Build & Energy)  Expert C (Senior PM) Expert D (PM, Transition) Expert E (Mech. Maintenance Specialist)          Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly(Often Checked) Somewhat(Sometimes) Low (Rarely) No (Never) N/A totals 32D ·         Component to component                                                                                   i.e. pro1imity of air intake and e1haust louvers, to prevent e1haust air from the HVAC system from being re-circulated Generally good to have 1 0 0 0 1 0 0 0 0 0 1 0 1 0 0 0 3 0 1 0 1 4 33A Compliance with requirements for different room types                                  ·         Checking wall assembly, FR, ceiling type, floor material, door size and opening direction of rooms 0 1 0 0 1 0 0 0 0 0 0 0 0 0 1 0 1 0 0 0 2 1 1 0 1 4 33B ·         Checking location of certain room types 0 0 1 0 1 0 0 0 1 0 0 0 0 1 0 0 0 0 0 0 2 1 1 0 1 4 33C i.e “The preferred location for Electrical Rooms is on North or East e1terior building wall” 0 0 1 0 1 0 0 0 1 0 0 0 0 0 1 0 1 0 0 0 3 0 2 0 0 5 34A Compliance with (other) owner requirements                                                       ·         Checking to see if same brand or manufacturer was used for each specific equipment type 0 0 1 0 0 1 0 0 cannnot be ensured 1 0 0 0 1 0 0 0 2 1 1 0 1 4 35A Coordination of consultant & subcontractor models                                             ·         clashes between consultants’ designs 1 0 0 0 1 0 0 0 would be great 0 0 1 0 1 0 0 0 3 0 1 0 1 4 217    Expert A (PM, Built Environment) Expert B (PM, HVAC Design/Build & Energy)  Expert C (Senior PM) Expert D (PM, Transition) Expert E (Mech. Maintenance Specialist)          Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly (Often Checked) Somewhat (Sometimes) Low (Rarely) No (Never) Highly(Often Checked) Somewhat(Sometimes) Low (Rarely) No (Never) N/A totals 36A Investigation of system/ component  nomenclature (naming conventions)          ·         Compliance with owner databases 0 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 4 0 1 0 0 5 36B ·         Naming each instant differently 0 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 4 0 1 0 0 5 37A Investigation of assignment of equipment – system – space relationships           ·         Equipment belongs to system 0 0 1 0 1 0 0 0 Would be good 1 0 0 0 1 0 0 0 3 0 1 0 1 4 37B ·         System serves to space 0 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 3 0 1 0 1 4 37C ·         Equipment is located in space 0 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 3 0 1 0 1 4 38A Investigation of the floor to floor height identification                                      ·         So that equipment can be assigned to the level it is serviced from 0 0 1 0 1 0 0 0 ? ? ? ? 0 0 1 0 1 0 0 0 2 0 2 0 1 4  11 Generally good to have 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0      218  Appendix B: Experts’ Evaluation of Representativeness of Identified Queries  Highly (Often)Somewhat (Sometimes)Low (Rarely)No (Never)N/ATOTALS2359556153311A0310122A3001132B3100142C3001152D4100063A0310174A2200184C2101194D03011104E21011114F21011124G21011134H22001144I21011155A50000165B50000175C50000186A50000197A41000207B50000218A50000228B23000238C23000249A500002510A311002611A300112711B300112811C310012912A230003012B410003112C410003213A410003314A500003414B140003514C320003614D140003714E140003814F041003914G021204015A130014115B320004215C311004316A014004416B004104518A022014619A410004719B230004820A230004920B320005021A104005122A410005222B410005322C320005423A500005523B500005624A211015725A310015826A211015926B211016027A401006127B401006227C401006328A410006428B401006528C221006629A311006729B103016830A013106930B221007030C022107131A302007231B302007332A31007432B500007532C310017632D301017733A211017833B211017933C302008034A211018135A301018236A401008336B401008437A301018537B301018637C301018738A20201

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
https://iiif.library.ubc.ca/presentation/dsp.24.1-0354549/manifest

Comment

Related Items