In part 1, Justin Kirby, founder of Start with Smart, introduced an observational lens to explore whether different teams are attempting to solve fundamentally different operational problems
In this second part, he tests that perspective against frontline site friction. Comparing vector 1’s administrative baseline with vector 2’s live telemetry, he examines where site disconnects occur and asks whether plotting these issues along a maturity journey helps explain why current approaches stall.
In part 1, we introduced an observational lens, viewing the project-to-operations gap not as a single, static line, but as a moving target defined by an organisation’s position on a digital maturity journey.
If we move from theoretical deadlocks to frontline execution, a basic question arises. What happens when low-maturity administrative tools meet high-maturity, IT-intensive operational demands? Is that mismatch why we still haven’t solved the project-operations gap?
By plotting these two ongoing discussions onto a digital maturity progression, we can begin to explore where and why operational friction occurs.
Exploring vector 1: Friction in the handover baseline
In part 1, we outlined a theoretical progression showing how ISO 19650, COBie, Uniclass, CIBSE Guide M, NRM 3, and SFG20 map together to connect project delivery to operations. On paper, this mapping presents a logical journey. In practice, vector 1 represents the digitisation of traditional O&M, focusing on workforce and process management, coordinating maintenance engineers, issuing work orders, and logging statutory compliance.
Software platforms in this domain bring administrative efficiency, but implementation teams routinely encounter hard commercial and operational realities:
- Ingestion vs. usability: Data flowing seamlessly into operational software without manual translation does not automatically make it usable for day-to-day tasks. Without early operational input, or an operational proxy during design, information management risks delivering just a compliance box-ticking exercise rather than practical value.
- Procurement lens and the compliance shield: Information management in vector 1 is fundamentally procured through a capital project lens. For a Tier 1 contractor, static handover data like COBie frequently functions as a compliance shield, which is a contractual checklist item required to secure final retention payments and transfer liability before exiting the site.
- Operational distrust: Because this data is generated to satisfy project sign-off rather than Day 2 usability, incoming facilities teams routinely distrust the delivered asset registers, frequently paying for physical re-surveys on day 1.
- The absence of data quality management: Static handover data cannot maintain itself. Without embedding active data quality management and governance disciplines into daily operational workflows, asset records quickly drift from physical reality, turning the handover deliverable into an unmaintained data museum. The upshot is that without operational data quality management, maintaining the Golden Thread becomes legally and practically impossible.
- The geometric misalignment: Project delivery demands heavy 3D spatial models to coordinate construction risk, whereas operations relies on functional attribute data, spatial relationships, and clear 2D layouts. Maintaining a live 3D geometric model after handover requires specialist software and ongoing budget that rarely demonstrates operational ROI, frequently leading to its abandonment.
- The static ceiling: While decision-support tools inside a CAFM can optimise data ingestion and calendar scheduling, administrative optimisation hits a structural ceiling. Because static records lack live operational feedback, optimising workforce management alone cannot dynamically adapt to environmental conditions or reduce energy consumption.
To push this static baseline to its limit before hitting that ceiling, operational software platforms can reshape traditional commissioning. Practical completion is merely a point-in-time snapshot, and seasonal commissioning frequently falls through the cracks. Within the static domain, an operational platform provides immediate value during enhanced commissioning by verifying technical data jumps cleanly into the system, testing asset record usability before sign-off, and connecting bi-annual seasonal checks directly to calendar-based SFG20 schedules inside the CAFM.
Moving beyond digital administration to performance-driven operations requires layering live telemetry on top of that validated foundation.
Exploring vector 2: Friction at the dynamic frontier
Where vector 1 focuses on administrative digitisation, vector 2 moves into a higher domain of digital maturity, addressing strategic priorities like deep energy reduction, carbon compliance, occupant flow, and indoor environmental quality. Without live telemetry and dynamic data, organisations may find it extraordinarily challenging to deliver on board-level net-zero targets, meet ESG commitments, and protect long-term asset value.
Unpacking vector 2 requires questioning a pervasive industry myth: the assumption that a building must achieve a fully joined-up static digital twin in vector 1 before it can deliver smart performance. In reality, vector 2 operates on entirely different principles:
- The independent smart domain: For energy reduction and climate control, smart platforms operate directly on live building physics, though their data requirements vary significantly. Pure energy-reduction engines can simply “bolt onto” raw time-series telemetry streams, driving massive performance gains through pattern recognition without needing formal data models or semantic tagging. Conversely, active climate orchestration demands contextual logic, using semantic ontologies like Brick or Project Haystack to map machine-readable relationships between equipment and zones. Crucially, however, neither approach requires vector 1. Both run their optimisation loops entirely independent of static COBie sheets, Uniclass lookups, or traditional CAFM records.
- The maturity chasm: Significant effort has been invested in crosswalks between static frameworks like ISO 19650, Uniclass, and SFG20, but the equivalent mapping into vector 2 is simply not happening. Delivery and traditional FM teams, focused on workforce management and statutory compliance, frequently operate at a lower digital maturity level than the semantic data orchestration required by a Master Systems Integrator (MSI).
- Intersection points: The two vectors primarily intersect when moving into data-led or condition-based maintenance, where a live telemetry fault must trigger an engineer’s work order in a CAFM. They also meet under performance frameworks like NABERS UK, where maintaining a verified rating relies on keeping physical plant correctly maintained alongside continuous telemetry tracking.
Protocol chaos, ontologies, and telemetry waste
Operating at this level without standardised integration frameworks forces project teams to navigate competing IT, OT, and IoT protocols, fragmented device naming conventions, and competing semantic ontologies such as Brick, Project Haystack, and ASHRAE 223P.
Furthermore, the market remains split between legacy integration middleware, open-source frameworks like UDMI, custom MQTT brokers, and emerging building operating systems. Confusing the physical labour of systems integration with the logic of semantic data orchestration risks devolving into a costly, custom “Frankenstack.”
Stepping across this maturity chasm without an operational strategy introduces severe site risks. Specifying smart hardware without the operational skills to run it creates a massive capability gap requiring IT literacy, network security awareness, and advanced analytics capabilities that traditional operations teams rarely possess. Designing vector 2 in an operational vacuum leads to paying CapEx and OpEx for redundant hardware, custom software integrations, and vast oceans of unused cloud telemetry, which ironically increases energy consumption to power hardware deployed to reduce it.
This shift also disrupts established industry benchmarks. Frameworks like SFG20 struggle to keep pace with rapid developments in real-time analytics. Furthermore, if real-time optimisation extends physical asset lifespans by 20% to 25%, static replacement tables in CIBSE Guide M and 30-year capital expenditure forecasts in NRM 3 shift from reliable economic benchmarks to theoretical assumptions disconnected from site reality.
Addressing site friction: Right-to-Left CONOPS and the IDL
Overcoming these obstacles points toward an alternative approach in how outcomes are specified and governed:
- Right-to-Left CONOPS and human-centred design: In human-centred design, you never start with engineering parameters or software packages because you start with human reality and the desired operational outcome on day 2, working backwards. In enterprise IT, aligning strategy with execution typically involves cascading heavy, top-down architecture frameworks such as TOGAF through complex operating models, an approach that often leads to paralysis across fragmented construction supply chains. Applying a human-centred design approach suggests a different pathway through a Right-to-Left Concept of Operations (CONOPS). By defining specific Day 2 performance outcomes, user experiences, and maintenance workflows first, project teams can work backwards to specify only the telemetry, networks, and integrations genuinely required to run the building.
- Decoupling the MSI Scope and the Independent Data Layer (IDL): As highlighted in part 1, formally separating physical systems integration labour from semantic data logic provides the structural bridge needed here. It gives the client an independent mechanism to govern data ownership and semantic context, preventing the technical and commercial chaos that occurs when integration work is bundled into a traditional sub-contractor package. By extension, what is being outlined here is not another physical contracting tier for the digital package, but a strategic design and governance role that helps shape how what is procured will actually work and perform dynamically on day 2.
Conclusion: Testing the lens
When I opened part 1, I deliberately chose not to offer a consultant’s fix, a vendor’s software pitch, or a rigid theoretical methodology. Instead, I posed a simple, honest question. If we examine the project-to-operations gap through the lens of digital transformation and digital maturity, can we start having better, more grounded discussions about how it is actually addressed on site? I promised to let you be the judge.
The goal here isn’t to manufacture a neat, grand definition for “digital operations.” Rather, it explores whether viewing the gap through a maturity journey helps explain why different teams face such radically different challenges.
Across these two articles, I’ve taken two ongoing discussions I’ve been facilitating and plotted them onto a digital maturity progression. Looking at these two spaces suggests that what teams are trying to achieve at different stages may be fundamentally different.
As we step into the new frontier of digital operations in vector 2, I suggest the Independent Data Layer (IDL) emerges as an essential foundation for AI-ready buildings. Decoupling physical integration from semantic data logic provides the structural gateway to shift from static calendar schedules to dynamic, condition-based, data-led maintenance; elevate point-in-time sign-offs into continuous, monitor-based commissioning; and enforce performance-related contracts that hold supply chains commercially accountable to real-world operational results.
This raises a simple question for our sector. Is solving the project-operations gap dependent on recognising where an organisation sits along its digital maturity journey, and therefore the precise problem they are trying to fix at that point?
I ask because if the answer is yes, then closing the gap relies on matching the right capabilities, mindsets, and governance to an organisation’s specific position on that maturity spectrum. Expecting blanket software deployments, a single process standard, or better alignment across existing frameworks to solve the problem alone misses the mark.
If looking at it this way helps illuminate why current approaches stall, it gives us a far more grounded baseline to explore specific frontline conversations next, whether around commissioning, data quality governance, or data-led maintenance. Based on the industry feedback from this series, I am planning follow-up articles to dive deeper into these specific sub-topics. If this lens isn’t helpful, then the search for a useful diagnostic tool continues.
To discuss these vectors in more detail, Justin Kirby is moderating a panel on the Digital Handshake at London Build Expo in November. As always, I leave the final verdict to you.
The post The project-operations gap: Frontline realities across the maturity journey (part 2) appeared first on Planning, Building & Construction Today.
