In the first two parts of this series, Justin Kirby mapped the project-operations divide across an organisational digital maturity spectrum
In this third article, he examines current baseline alignment efforts and asks whether they form an ascending progression ladder or reveal an irreconcilable paradigm fork. Looking at the on-site reality faced by Master Systems Integrators, he explores the fundamental geometric clash between linear Waterfall delivery and circular building operations.
The recap and the maturity lens
In the first two parts of this series, I pointed out that “digital operations” remains poorly defined across the built environment. Depending on which functional silo you speak to, you receive an isolated and often conflicting answer. It closely resembles the parable of the six blind men and the elephant. The software vendor touches a dashboard and calls it digital operations, the information manager points to an ISO 19650 spreadsheet, the controls engineer references the BMS, and the facilities manager looks to the CAFM. Everyone holds onto an isolated piece of the beast, mistaking their individual perspective for the whole.
To cut through that fragmentation, and to look past the traditional view of the project-operations gap as a single, uniform hole, I introduced the lens of digital maturity. Looking at the sector through that spectrum revealed that we are not dealing with one universal challenge. Instead, distinct gaps emerge depending on where an organisation sits on a steep, bottom-heavy maturity pyramid.
From that analysis, two clear, parallel patterns emerged:
- Vector 1: The static compliance foundation. This is the linear information management domain established to catalogue physical components at rest. Its primary role is to ensure day 1 statutory compliance and provide a usable baseline asset register at handover.
- Vector 2: The dynamic operations frontier. This is the smart performance domain driven by real-time telemetry, semantic modelling, and client-owned data architectures. It is designed to optimise how a building actively behaves on day 2 and beyond.
Recapping these two pathways is essential because, since publishing those pieces, my focus has shifted to what happens next. If we accept that these two vectors define our landscape, we must examine the nature of their relationship.
Section 2: The baseline alignment effort
To understand where we go from here, it helps to look at where the industry is currently investing its collective energy. Right now, a significant amount of pragmatic work is being led by bodies such as the ADS Alliance, chaired by Steven Boyd. Their focus is squarely on solving the data handover challenge, as reflected in their work on frameworks like the government’s mandatory asset management standard for facilities management, FMS 002.
The primary mechanism here is alignment. Their work focuses on building crosswalks and matrices that map disparate industry classifications, task frameworks, and guidance used across the sector today. They are attempting to tie SFG20 maintenance schedules, NRM 3 cost structures, and CIBSE Guide M life expectancy tables sequentially into RIBA Stage 7, alongside classification tables like Uniclass. The aim is to create a common language so that asset data flows neatly across the contractual boundary at Practical Completion and into operational systems like a CAFM.
At first glance, it’s easy to dismiss this kind of foundational work if you are looking at it purely from the dynamic frontier, but that misses the operational reality. When SFG20’s own research indicates that roughly 90% of facilities management professionals do not even have a workable asset register, establishing a clean, structured baseline is not just helpful; it is vital. For that overwhelming majority of the market, standardising the data handover solves an immediate, painful problem.
In practice, they seem to be delivering a specification for a static digital twin. It appears to be designed to catalogue physical assets and support the human workflows that keep them running, like replacing a filter or fixing a broken fan coil unit, squarely in vector 1, rather than governing the real-time automation and dynamic performance of vector 2.
Section 3: The core inquiry
If we recognise that this baseline alignment work sits firmly in vector 1, it raises the core inquiry of this piece. We must ask what this effort is actually constructing. Does building crosswalks between these foundational frameworks create a linear maturity ladder that naturally ascends into dynamic building performance, or are we looking at fundamentally different paradigms?
My intuition is that the answer you receive depends heavily on where you sit in the industry.
For the traditional establishment across information management, asset management, and facilities management, there is a natural tendency to see a continuous progression ladder. The assumption is that once we master static data handover and agree on a common language, information will begin to flow neatly into the higher reaches of operational maturity.
Yet, when you speak to progressive practitioners operating in the smart buildings domain, that intuition changes. They increasingly see a hard fork rather than an ascending ladder. From their perspective, the static compliance baseline and the dynamic performance frontier do not naturally connect, because they are built to solve entirely different problems.
Testing this intuition matters, because if these two worlds represent distinct paradigms rather than steps on a single staircase, it changes how we approach the entire problem.
Section 4: The conditional concession
This is where the debate often stalls, because people get caught defending their own corner of the industry. Information managers double down on the idea of a continuous journey, while smart-building specialists dismiss the compliance effort as an outdated dead end.
To move past that entrenched standoff, it helps to make a conditional concession.
Even if you accept that there is a continuous progression between the two, we still have to look at the tools used along that journey. Believing that a progression exists does not mean that tools forged purely for baseline static compliance will automatically transfer to the operational frontier as you climb that ladder.
The instruments and frameworks designed to solve an immediate, foundational challenge are tailored for a specific job. In vector 1, that job is documenting physical assets, mitigating contractual liability, and getting clean registers across the line at handover. That is a vital task, but assuming those same mechanisms can simply stretch upward to govern dynamic performance, live telemetry, and machine-to-machine optimisation is an enormous leap.
Even if you are on a single staircase, the tools you need at the top aren’t necessarily the ones that got you through the front door.
Section 5: The upstream breakdown and the MSI reality
To see why that toolset struggles to transfer, you only have to look at what happens when the project procurement cascade meets the practical reality of modern building integration.
In traditional information management theory, there is an assumed neat line of sight running from the Organisational Information Requirements (OIR) through to the Asset Information Requirements (AIR), which then informs the Project Information Requirements (PIR) and becomes the Exchange Information Requirements (EIR). On paper, this is supposed to ensure that operational requirements are pulled backwards into design and construction. In practice, that cascade is fragile even on the project side, where the EIR rarely aligns cleanly with the BIM Execution Plan (BEP).
When a Master Systems Integrator (MSI) arrives on site, they find themselves caught in the middle of that disconnect.
In many ways, the MSI is forced into doing their own version of an alignment exercise, but not on agreed industry classifications or neat national frameworks. They are left reconciling the messy, conflicting project documentation they actually inherit from separate silos. That routinely means cross-referencing disjointed EIRs and BEPs against dedicated smart building specifications, client design guidelines, MEP schedules, disparate asset registers, and unverified COBie data dumps. Invariably, it also means contending with an entirely separate asset condition survey that the incoming operations team had to commission at extra cost, simply because they did not trust the project data handed over the fence. This is a recurring theme with MSIs I speak to, suggesting this is not an occasional hiccup but standard practice.
To those firmly anchored in vector 1, it is tempting to believe that this reconciliation problem can be solved simply by perfecting the cascade and building better crosswalks upstream. The assumption is that if we just get the static baseline right, this friction will naturally disappear.
Yet progressive practitioners in the smart buildings domain remain deeply sceptical. That scepticism exists because the standard project cascade, no matter how cleanly executed, remains fundamentally blind to the two core architectural foundations an MSI is brought in to deliver: the Independent Data Layer and the semantic model.
These two requirements are effectively two sides of the same coin, and understanding the “why” behind them explains why static handover data falls short.
The first requirement is the Independent Data Layer (IDL). If the client doesn’t specify an independent architecture to hold their data model, a software vendor inevitably does that modelling work inside a proprietary platform just to make their own tools work. The moment that happens, the data schema ends up trapped inside that vendor’s environment, creating immediate platform lock-in and stripping the client of true ownership of their estate data. The IDL exists to give the client sovereign control of their operational architecture.
The second requirement is the semantic model. While static vector 1 classifications can tell you what an item is and where it was bought, they offer no live operational context. They cannot describe the active relationships between sensors, spatial zones, airflow, and control loops. Semantic modelling provides that relational map. Without it, there is no foundation for automated fault detection, dynamic optimisation, or future AI readiness.
By remaining blind to that data reality, the traditional project cascade fails to procure the very components that the smart operations layer depends on.
Section 6: The inherent geometric clash
To understand why this disconnect persists, you have to look at the underlying geometry of how we build versus how we operate. The friction the MSI experiences on site is not just an administrative oversight. It is the inevitable result of two incompatible models colliding.
Traditional capital project delivery is an industrial-era mechanism. It is fundamentally linear, operating on a classic Waterfall approach inherited from civil and structural engineering. Everything is structured around sequential stages, contractual gateways, data freezes, and legal liability boundaries. Project success is defined by hitting specific milestones, culminating in a hard stop at Practical Completion. At that point, retention monies are released, liability shifts over the fence, and the project team packs up and moves on to the next job.
Operational performance, by contrast, is inherently circular. A living, occupied building has no end state. It operates as a continuous, agile loop of monitoring telemetry, testing responses, tweaking parameters, and repeating the cycle. It mirrors the software and digital product world far more than the construction world, thriving on regular iteration, ongoing adaptation, and live feedback loops.
When you place these two approaches side by side, the geometric clash becomes obvious. The linear project mechanism is designed to produce a frozen snapshot of historical intent. The operational frontier requires an adaptive engine for continuous optimisation.
Trying to govern a circular, agile operational reality using a linear, milestone-based project tool is not just difficult. It would appear to be a fundamental architectural mismatch.
If our project delivery mechanisms are fundamentally linear, designed to capture frozen snapshots of historical intent, operational performance is inherently circular, thriving on continuous feedback and adaptive iteration.
Recognising that geometric clash forces us to confront what happens when these two incompatible philosophies meet on site once the keys are handed over.
In the fourth and concluding part of this series, we will examine the operational proof. We will test the limits of ISO 19650-3’s “Trigger Event” mechanism against machine-speed AI optimisation, explore why a dictionary of static nouns cannot orchestrate an ecosystem of dynamic verbs, and ask whether human-centred design tools like a Concept of Operations (ConOps) and Stakeholder Requirements Specifications (StRS) can finally provide the collaborative table our industry so urgently needs.
The post The project-operations gap: Progression ladder or paradigm fork? (part 3) appeared first on Planning, Building & Construction Today.
