The built environment routinely treats the project-operations gap as a single, uniform problem. In the first of a two-part series, Justin Kirby, founder of Start with Smart, explores whether the vagueness of the term “digital operations” is part of the issue
By plotting two ongoing industry discussions onto a digital maturity progression, he asks whether stakeholders are trying to solve very different problems with mismatched tools, and whether viewing these challenges through a maturity lens helps explain the disconnect.
Part 1: The maturity ladder & the two vectors
I have been exploring how we can plug the gap between project delivery and building operations for nearly four years, facilitating market engagement on the topic since November 2022. Everyone across our sector acknowledges that this project-operations gap exists, and begrudgingly that it remains unsolved.
I am not writing this as a consultant pitching a proprietary methodology, nor as a vendor selling software. I am approaching this simply as an independent facilitator.
My intent here is to ask an honest question. If we look at this gap through a different lens, specifically through digital transformation and digital maturity, can we have better, more grounded discussions about how it is actually addressed in practice? I will let you be the judge.
My background is in human-centred design. Taking a qualitative approach to this engagement made one thing very clear. The project-operations gap is a classic wicked problem. You cannot solve a wicked problem with traditional engineering and linear project thinking alone because it requires design thinking.
Very recently, it became clear to me that how we use the term “digital operations” may be adding to the problem rather than helping solve it. The term is so poorly defined that asking different stakeholders what it means yields completely different answers. It resembles the parable of the blind men and the elephant. The software vendor touches the dashboard and calls it digital operations; the information manager points to an ISO 19650 spreadsheet; the controls engineer points to the BMS; and the facilities manager points to the CAFM. Everyone holds onto a single, isolated part of the beast, claiming their piece is the whole thing, while no one looks at the overall picture.
To break through this fragmentation, we need a shared language. Viewing the challenge through digital transformation may offer a path forward, specifically by borrowing adoption segments from Everett Rogers’ diffusion of innovations model.
Giving stakeholders a clear ladder, spanning innovators, early adopters, early majority, late majority, and laggards, is helpful because it provides a common vocabulary. It lets different groups step back from isolated functional silos and start an honest conversation about where an organisation actually sits on its digital maturity journey.
Where this model stops being helpful, however, is the assumption that tech adoption in the built environment follows Rogers’ neat consumer bell curve. In consumer markets, products naturally spread as individuals choose to buy them. The built environment does not work like that. Tech adoption here is weighed down by complex supply chains, split capital and operational budgets, high-risk procurement rules, and strict legal liabilities.
Crucially, it is further fractured by the conflicting commercial motivations of key budget holders, namely owners, occupiers, and operators. Data from SFG20’s State of Facilities Management research starkly illustrates why this market looks nothing like a smooth bell curve. Their findings reveal that only 10% of FM professionals believe their asset registers are fully accurate, while over half lack confidence in achieving basic statutory compliance. Instead of a balanced bell curve, sector digital maturity appears to be more like a steep, bottom-heavy pyramid.
Viewing digital operations through the lens of digital maturity offers a different perspective. It suggests we might not be dealing with a single, universal gap, but rather different challenges to address depending on where an organisation sits along that spectrum.
Based on my discussions across the industry and my former industry roles, two distinct patterns consistently emerge:
- Vector 1 (The Foundation): The challenge of establishing data usability and minimum data requirements to support day-to-day human tasks at handover.
- Vector 2 (The Frontier): The challenge of defining the evolving role of the Master Systems Integrator, specifically separating the physical labour of system integration from the logic of semantic data modelling and establishing the Independent Data Layer where the rubber hits the road for performance optimisation, data alignment, and AI readiness.
Other distinct gaps may exist across that spectrum, and there may ultimately be a progression from one to the other, but these two represent the clearest patterns from my engagement so far. Rethinking this challenge through the lens of digital transformation suggests these may be distinct problems to explore at different levels of maturity.
Before examining where these pathways run into real-world operational friction in part 2, it is worth briefly outlining the frameworks and discussions I have been facilitating around each vector.
Vector 1 (The Foundation): The information management handover pathway
Perhaps the best way I can explain Vector 1 is through my work setting up the Digital Operations Working Group (DOWG) earlier this year, and its strategic collaboration with nima on their Information Management Initiative. In short, that collaboration was formed to help ISO 19650 fulfil its full asset lifecycle ambitions.
Through facilitating sessions with standard authors, consultants, software vendors, and major FM operators, and drawing upon the cross-framework alignment work of the ADS Alliance, a clear left-to-right progression emerged, showing how the information management community could attempt to join the dots from Information Management, through Asset Management, to traditional Facilities Management execution:
- ISO 19650 (Information Management): Defines the process, roles, and data container governance within the Common Data Environment (CDE).
- COBie and AOH (The Transport Mechanism): COBie remains the primary mandated data schema used within information management workflows to transfer static records into operational software, with buildingSMART’s emerging Asset Operations Handover (AOH) framework representing its ongoing evolution.
- Uniclass 2015 (The Classification System): The standardised taxonomy used to categorise physical assets consistently, aligning design records with operational management.
- Point-in-Time and Seasonal Commissioning (Verification): The physical baseline validation required at Practical Completion, across the defects liability period, and through ongoing seasonal checks to prove statutory compliance and calibrate systems.
- SFG20 (Facilities Management): The task specification library used to automatically trigger statutory planned preventative maintenance calendar schedules inside the CAFM based on those commissioned baselines.
- CIBSE Guide M (Asset Management): The static baseline tables used to assign theoretical operational lifespans to classified assets.
- NRM 3 (Financial Lifecycle): The RICS New Rules of Measurement used to structure data for 30-year capital replacement forecasts.
By linking these frameworks sequentially, Vector 1 illustrates one way the industry attempts to extend ISO 19650 across the full asset lifecycle. In this approach, Asset Management serves as a structural bridge at handover, connecting project delivery to operations by translating project records into facilities management execution within a CAFM system.
However, what this theoretical sequence does not guarantee is day-to-day data usability, nor does it provide ongoing data quality management. We will explore those operational friction points in Part 2.
Vector 2 (The Frontier): Live architecture and the pathway to dynamic performance
Vector 2 draws on my previous role as Executive Director of the Digital Buildings Council, where I facilitated discussions on bridging the project-operations gap. This included supporting the BIM to Smart Working Group, as well as curating sessions on The ROI of Smart Buildings and The Evolving Role of the Master Systems Integrator (MSI).
Where those themes meet is where the design of the Independent Data Layer (IDL) goes beyond a simple Smart Readiness Indicator and next-level scoring of ‘smart enablement’ to the new frontier of AI-ready buildings.
This represents a different level of digital maturity than Vector 1, where an IDL is rarely required and transferring static asset records into operational software is an administrative task outside an MSI’s project-side scope. Instead, discussions about unlocking this frontier explore the need for the MSI to decouple physical integration labour from semantic data logic, delivering two functions:
- Independent Data Modelling (Client Ownership): Ensuring the operational data schema remains vendor-neutral so the client owns the data model and data, preventing long-term lock-in to proprietary software platforms.
- Semantic Modelling (Context and AI Readiness): Giving live operational platforms structural context. While Vector 1 standards provide classification lookups for static assets, semantic modelling using ontologies like Brick or Project Haystack maps machine-readable relationships between sensors, equipment, spatial zones, and controls to drive live building performance and automated diagnostics.
By separating physical labour from data logic, Vector 2 provides a lens for scaling from basic enablement to continuous performance optimisation.
In information management terms, Vector 1 and Vector 2 reflect a shift across the digital maturity spectrum from a static digital twin to a dynamic performance twin. While Vector 1 provides a point-in-time record of physical components for Day 1 operations, Vector 2 focuses on building a live, operational architecture to support an asset owner’s long-term performance priorities.
How Vector 2’s dynamic architecture copes with real-world procurement constraints, fragmented OT protocols, and on-site commercial boundaries is another matter entirely, and we unpack those operational friction points in part 2.
The post The project-operations gap: Distinguishing the static foundation from the dynamic frontier (part 1) appeared first on Planning, Building & Construction Today.
