Twiniti Blog

FM-Oriented Data Governance for Streamlined Lifecycle BIM to FM

Written by George Broadbent | Oct 24, 2025 1:56:33 PM

Link to Original Article

FM-Oriented Data Governance for Streamlined Lifecycle BIM to FM Transition

Xifan Chen, Ph.D., LEED AP,1 Eve Lin, Ph.D., WELL AP, LEED AP, CPHD/C2 and
George Broadbent3

 

1Microdesk, Inc., 5 Pennsylvania Plaza 14th floor, New York, NY 10001, jchen@microdesk.com

2Microdesk, Inc., 5 Pennsylvania Plaza 14th floor, New York, NY 10001, elin@microdesk.com

3Microdesk, Inc., 5 Pennsylvania Plaza 14th floor, New York, NY 10001, gbroadbent@microdesk.com

 

ABSTRACT

While the abundance of available data provides limitless opportunities for higher performance design, more efficient construction processes, and more effective operations and maintenance (O&M) solutions, it also introduces another layer of unprecedented complexity. The means and methods of collecting, managing, distributing, and streamlining the data from various stakeholders during project stages have become the determining factor for the overall performance, effectiveness, and efficiency of project stages, especially O&M. Various classification standards have been developed to address the need for information standardization. To this end, this paper first review current standards and coding systems, identifies the gaps between the project delivery and operational stages, followed by presenting an FM-oriented data dictionary management system (DDMS) that aims to bridge the gaps and depict how the proposed data governance approach can streamline and benefit the entire project lifecycle.

INTRODUCTION

Due to inadequate interoperability, facilities in the U.S. waste approximately 15.8 billion dollars annually (NIST, 2004). Over 60% of that amount is incurred during the operation and maintenance phases (NIST, 2004). A 2001 estimate was given that the averagely-knowledge worker spends about 2.5 hours per day, or around 30% of the workday, searching for information (IDC, 2001). With the rapid growth of data demand and increasing data complexity, the time wasted in locating pertinent information has become a more severe issue in the asset management program. The trending of BIM technologies brings a data-rich environment that facilitates various activities throughout the project delivery phase. Meanwhile, the complexity and richness of information persists as a significant issue during the handover at the end of the construction phase (Chen & Broadbent, 2020).

AS-IS REVIEW

This section reviews taxonomies that are mostly adopted during the project handover stage then depicts the practical limitations behind the scenes when applying these standards, from strategic planning to CMMS implementation based on authors' project experiences and industry practices.

Existing Coding Systems Review

MasterFormat was designed by the Construction Specifications Institute (CSI) and Construction Specifications Canada (CSC) to address building construction specifications in the 1960s and later expanded in 2004. MasterFormat is primarily used to support cost estimating and quantity taking off, and therefore is not directly applicable for use during the transition within BIM project delivery nor from O&M. Later on, MasterFormat became a nice addition to UniFormat 2010 as the optional 5th level, which gives facility data managers the option to extend their data structure to a more granular level.

On top of the original version of UniFormat (the year 1973), two UniFormat standards have been developed separately: UniFormat II (2015, ASTM) and UniFormat 2010 (CSI and CSC). Both standards are top-down 4-level structured, mostly identical but with minor differences, particularly naming conventions and hierarchy arrangements. As mentioned above, CSI and CSC incorporated their own MasterFormat into UniFormat 2010 and provided an optional Level 5 in this system (named MF code) in order to make the classification include specific items. UniFormat 2010 is adopted nowadays by many facilities in the U.S. to frame their asset data dictionaries (with limitation). As an example, Figure 1 below presents a portion of the asset data dictionary spreadsheet. The subsystems are directly adopted from the UniFormat 2010 structure (D3030.10 & D3030.70), while the assets indicate the company's revisions to Level 5.

Figure 1: Sample of a top-down structured data dictionary adopting UniFormat 2010.

Evolving from the developments of MasterFormat and UniFormat, the OmniClass intends to expand the classification scope to cover the entire project lifecycle. It includes (but is not limited to) sorting and retrieving information for use in preparing project information, cost, and specification. Adhering to the framework of ISO 12006-2 and ISO 12006-3, OmniClass integrates various domain-specific systems as its tables, such as the aforementioned MasterFormat for work results table (Table 22), UniFormat for elements table (Table 21), and EPIC for products table (Table 23).

Compared to its predecessor, primarily hierarchical systems, OmniClass is a faceted classification system, which is a great fit and improvement from the asset management utilization perspective. OmniClass has been utilized more frequently (sometimes work together with UniClass) in the European market.

Despite the prior standardization efforts, a method to smooth the handoff transition was still absent, and that led to the development of the Construction Operations Building Information Exchange (COBie) in late 2006. COBie is a widely used performance-based information exchange specification developed to mitigate the tedious, time-consuming handover process during facility asset information delivery.

To digitize documentation from all channels. COBie allows the utilization of standardized formats (i.e., IFC, ifcXML, Excel spreadsheets) for stakeholders to collect, populate, and exchange data. It enables data handoff among different software and maintains its interoperability and integrity. The conventional spreadsheet format is the most convenient and straightforward. COBie establishes a set of predefined spreadsheet templates that build an imaginary sharable common "database" between all stakeholders. However, COBie is still confusing most of the time, even though it aims to be the ideal solution to solve all the data problems during the BIM lifecycle implementation.

Implementation Challenges

Spreadsheet Size & Data Error

In a large-scale project like airports, hospitals, or high-Ed facilities, using COBie exchange sheets lead to intensively long spreadsheets. With an acceptable error rate of 1.3% tested by buildingSMART (BIM+, 2017), it will lead to hundreds of thousands of rows of problematic data and a stressful process considering the difficulty of checking and correcting an oversized, color-coded spreadsheet.

On the other hand, the lifecycle of BIM embraces an extensive portfolio of applications, processes, systems involving various stakeholders. Data from all sources need to be mapped to the COBie sheets – sometimes, it is more like a highly maintained business process rather than a pure technical data exchange. Meanwhile, a portion of the COBie data spreadsheet is required to be populated/updated manually. This creates more trouble over the long run because an automated population must be maintained alongside manual edits. Most firms do not consider this as a risk in the data management and lead to the most critical challenge during the later BIM to FM transition.

Infrastructural Unfriendly

The incapability of handling infrastructural projects is a significant limitation and sometimes an immediate turn-off for most transit agencies who own many infrastructural capital projects (e.g., bridges, tunnels, piers, highways). Therefore, most of these agencies started to develop their own asset classifications rather than use the abovementioned coding system once an Enterprise-level Asset Management (EAM) program is on their roadmap. Most of the time, these agencies also own building-type projects (e.g., bus terminals, airports, substations). To maintain the EAM data consistency, the self-developed asset dictionary also needs to be implemented on these building-type projects, which thoroughly screening standard coding systems out of the game.

One step further, when asset management was not part of the Integrated Project Delivery (IPD), extra effort on data processing is inevitable between project delivery and operational stage. For example, an agency owns various types of projects (building and infrastructure). UniFormat 2010 has been adopted in their building-type project delivery phase. However, due to the fact, their EAM program requires a self-developed data dictionary that covers both building type and infrastructural projects, the data structure asymmetry creates a gap from the project delivery phase to the operational phase. An extra mapping layer is then required to bridge the gap in terms of data validation, migration, and transition. These drawbacks open the subsequent stage discussion of gap analysis between project delivery and operational stage.

Delivery to Operational Stage Gap Analysis

Incomplete Integrated Project Delivery

For an Integrated Project Delivery (IPD), all the project stakeholders should be invited to the table, planning and developing the project deployment plan. In reality, facility managers are often the ones left out, which leads to the case that, before the occupancy of the facility when the as-build model is needed for FM transition, the delivered models contain great details of graphical representations, but missing the data required by FM team, (i.e., warranty information, serial numbers). The reason is that the project delivery stage stakeholders don't fully comprehend what the facility manager needs. Meanwhile, there are no specific FM data requirements to regulate compliance checking for their data submission. Without a generalized data dictionary that meets their AM/FM needs, each stakeholder still works in a silo. The scattered information becomes a significant risk in BIM to FM transition by the end of the project delivery stage.

Traditional Asset Management Data Dictionary Limitation

Besides the aforementioned gap, there are several inherent issues and drawbacks within the traditional asset management realm (Lin, Chen, & Broadbent, 2020). The first issue regards the AM/FM data dictionaries hosted and maintained on Computerized Maintenance Management Systems (CMMS) (e.g., IBM Maximo, SAP, Archibus). Once the dictionary has been defined, it will be fixed in the CMMS after implementation. New classifications and attributes can still be added but very hard to maintain data consistency and accuracy.

Outside the CMMS platform, asset information is usually maintained and tracked by different individuals from separate departments in various formats (e.g., BIM models, CAD files, Excel spreadsheets, and PDFs). All these other formats need to be gathered before reconciliation and consolidation for these diverse data sources and information can be established. Different sub-departments have their own ways to track their intake in various spreadsheets, result in numerous systems be input in different periods by different individuals. As the example illustrated in Table 1, three different asset definitions, including misspelled words, are defined by three various departments. Based on our data analysis on some of our confidential large-scale public transit agencies, approximately 62% of their data dictionary is suffering from data inconsistency and invalidity. Furthermore, this dispersed and unsynchronized solution impedes teamwork and collaboration, limits data analytics support, and at the same time, creates a lot of unnecessary rework throughout the larger organization (Lin, Chen, & Broadbent, 2020).

Table 1: Sample of an inconsistent data dictionary

Classification Names Centrifgal Pump Pump, Centrifugal Centrifugal Pumps
Sample Attribute Names Manufacturer Maker Manufacturor
  Serial # Serial Number  
  Mount Mounts Mount
  Dimension Size HxW

FM-oriented Data Governance

Based on the current issues defined and users' needs collected, a more fundamental and practical approach might be an FM-Oriented Data Governance hosted by a Data Dictionary Management System (DDMS), which can support different stakeholders to access a centralized FM data dictionary and fetch corresponding information as they need. A DDMS does not merely serve as a database repository – its functionalities are specifically designed to address the commonly seen gaps between project delivery to operation stage transition, as well as during operational stage. The DDMS can embrace both standard coding systems (e.g., UniFormat, OmniClass) and the facility's own developed data dictionary or their hybrid. The true value of a DDMS lying in enhancing the hosted data dictionary quality and conveying FM-oriented data governance to the delivery stage (e.g., design, construction, commissioning).

Enhance Data Quality

Data Health Assessment

The main issues mentioned before are the ambiguous and inconsistent data structure and naming conventions. All CMMS implementations should start with a well-defined and organized data dictionary rather than leave all the troublesome data to the future. Therefore, the DDMS needs to have the capability to evaluate FM data dictionary health from different angles, including but not limited to 1) Semantical Analysis (Fuzzy analysis); 2) Grammar & Spelling Check; 3) Completeness & Uniqueness Analysis; and 4) Classification Consistency Analysis.

When all the asset information is collected from multiple sources, the DDMS goes through the entire asset data dictionary to perform the semantical analysis automatically. All identified issues will be presented to the user in a proactive and interactive approach, as illustrated in Figure 1Figure 2. This process provides a tremendous advantage for the facility managers in saving them a lot of time to go through every entry to purify the data dictionary.

Figure 2: A high-level workflow of DDMS running semantical analysis

Cloud-based Knowledge Sharing

One niche function of a cloud-based DDMS is the ability to aggregate the wisdom from all users and benefit each other. The DDMS applies cloud-based Machine Learning (ML) by utilizing backend labeling to tagged asset information from different entities. Through the learning and training of the aggregated data and wisdom, the DDMS establishes a robust knowledge base for intelligent recommendations of which attributes should be considered for a specific classification.

Data Management Throughout the Project Lifecycle

The DDMS enables data handshakes to multiple platforms (e.g., Excel, Revit, SAP, and Maximo) and acts as a central hub of all the data streams. This capability allows the DDMS to bridge the gaps in data management and benefit the entire building lifecycle. From the delivery to operational stage transition perspective, the DDMS serves as a synchronized data process platform that conveys all the FM data requirements. The FM data dictionary can be packaged into different Shared Parameter packages based on corresponding project stages and disciplines. Stakeholders can incorporate the parameter groups that they are responsible for in their own workflow and collect pertinent information accordingly.

The DDMS also serves as the data validation gate during the project handoff process. It checks model (or other formats)-collected information against the FM data requirements and provides a complete score and data analysis breakdown as the reference for the next round of the model submission. From the FM perspective, the data dictionaries hosted on the DDMS can be fully exported into a CMMS-compatible format for the implementor. The standardized and validated data dictionary hosted in the DDMS also makes the implementation process more streamlined. Lastly, the DDMS facilitates the onsite data collection process by providing an easy-to-use interactive web app on a mobile device with the most updated information without letting users fishing through the legacy spreadsheets. Figure 3 illustrates how DDMS could help streamline the project lifecycle from delivery to the operational phase.

CASE STUDY

The authors have been working with one of the largest public transit agencies in the United States to implement a customized DDMS to assist its EAM program. This confidential agency has been responsible for planning, designing, building, operating, and maintaining diverse infrastructure assets in a vast trade and transportation network critical to the local and regional economy. In recent years, the agency has evolved its approach to managing its assets from a maintenance and operations focus to a holistic lifecycle overview of the holdings in line with asset management practices.

 This shift has been driven by creating the EAM Program and in collaboration with key stakeholders.

A foundational step in the EAM roadmap was the development of an asset data dictionary that comprehensive enough to cover all types of facilities this agency owns. Several challenges were encountered during the data dictionary development. One of the most critical was the asset data standardization and governance across the entire agency. Data migrations from all sub-departments create data inconsistency, inaccuracy, and invalidity. Due to the scale of the agency and the complexity of the program, since 2018, the agency started to build up a DDMS that supports the data dictionary repository, development, coordination, and publishing. The DDMS introduces semantical algorithms into the asset registry database that examines all existing and new asset requirements, as well as offers interactive data dictionary health reporting to the owner to help with decision-making conveniently.

Meanwhile, this DDMS initiated a cultural shift from siloed asset management practices to a more integrated and collaborative approach for end-users to provide varied services and comply with regulatory requirements. One of the critical factors in this shift was replacing spreadsheets with an asset registry database and associated web-app deployment. This central database of DDMS information avoids complexities and confusion in using the spreadsheet to perform version controls and management of naming conventions and other standards. Meanwhile, the DDMS still allows the traditional workflow of spreadsheet-based batch editing and provides portals in the asset registry database to import sheets and updates accordingly. With the data requirements refined and hosted in the asset registry database, there was an opportunity to enhance the connectivity between the operational and project delivery project phases. Asset management-oriented data requirements were packaged into the language compatible with BIM processes to encourage true lifecycle implementation and integrated project delivery.

The DDMS centralized workflow benefits the agency's EAM program development and creates valuable opportunities to develop, implement and govern the data dictionary, ensuring minimal impact to business processes and reporting requirements. The successful deployment of the asset registry database for use within the organization was achieved by incorporating data standards around assets across the enterprise, leveraging existing asset data, maintenance staff experience, technology, and creating a collaborative environment for all stakeholders to participate in the roadmap process.

CONCLUSION

The DDMS shifts the focus on choosing a standard coding system into how to develop one that suits the facility's specific need and, more importantly, conveys the FM data requirements to upstream stages to achieve lifecycle BIM implementation.

Based on the authors' project experiences and feedbacks, the DDMS makes considerable improvements for the agency's EAM practice. An FM-oriented DDMS with the abovementioned functionalities can serve as a practical center hub to support all data flow activities throughout the lifecycle, from collecting, refining, to synchronizing, and managing. While the upcoming parts of the ISO 19650 series are still being finalized and its potential benefits to the asset management and BIM implementation lifecycle are still forthcoming, an FM-oriented DDMS would be the essential currently available foundation to support the data flow and activities throughout the building's lifecycle.

REFERENCES

BIM+. (2017, August 23). The Chartered Institute of Building. Retrieved from COBie inventor develops open source improvements: https://www.bimplus.co.uk/news/cobie-inventor-develops-open-source-improvements/

Chen, X., & Broadbent, G. (2020, August 1). New Era of BIM Lifecycle Implementation – Part 1: An Overview of How The ISO 19650 Series Affects Asset Management. Retrieved from Civil + Structural Engineer Media: https://csengineermag.com/new-era-of-bim-lifecycle-implementation/

IDC. (2001). The High Cost of Not Finding Information. Framingham, MA: International Data Corporation.

ISO. (2018). ISO 16739-1:2018 Industry Foundation Classes (IFC) For Data Sharing In The Construction And Facility Management Industries - Part 1: Data Schema. Geneva, Switzerland: International Organization for Standardization.

Lin, E., Chen, X., & Broadbent, G. (2020, October 1). New Era of BIM Lifecycle Implementation Part 3: Implementation of An FM-oriented Data Dictionary Management System (DDMS) for Lifecycle Project Delivery. Retrieved from Civil + Structural Engineer Media: https://csengineermag.com/new-era-of-bim-lifecycle-implementation-3/

NIST. (2004). Cost Analysis of Inadequate Interoperability in the U.S. Capital Facilities Industry. U.S. Department of Commerce Technology Administration. Gaithersburg, Maryland: National Institute of Standards and Technology.