{"id":166061,"date":"2026-09-28T09:37:28","date_gmt":"2026-09-28T08:37:28","guid":{"rendered":"https:\/\/www.pbctoday.co.uk\/news\/?p=166061"},"modified":"2026-09-28T09:37:28","modified_gmt":"2026-09-28T08:37:28","slug":"project-operations-gap-dynamic-verbs-living-logic-conops-bridge-part-4","status":"publish","type":"post","link":"https:\/\/www.pbctoday.co.uk\/news\/digital-construction-news\/project-operations-gap-dynamic-verbs-living-logic-conops-bridge-part-4\/166061\/","title":{"rendered":"The project-operations gap: Dynamic verbs, living logic, and the ConOps bridge (part 4)"},"content":{"rendered":"

After exploring the geometric clash between linear Waterfall delivery and circular operations in part 3<\/a>, Justin Kirby concludes his four-part inquiry into the project-operations divide<\/h2>\n

Testing the limits of ISO 19650-3 against machine-speed AI optimisation, he explores why a dictionary of static nouns cannot govern dynamic operational verbs and asks whether human-centred design tools like a Concept of Operations (ConOps) can provide the missing collaborative bridge.<\/p>\n

Section 7: The operational proof<\/h3>\n

In part 3, we explored the geometric clash between linear Waterfall delivery and circular Agile operations. But where does this theoretical mismatch create visible friction in practice?<\/p>\n

A telling place to look is how traditional information management approaches operations once the keys are handed over.<\/p>\n

In the ISO 19650 framework, the operational phase is governed by part 3. The central mechanism underpinning part 3 is the “Trigger Event.” The standard appears to assume that operations can largely be managed through a series of discrete, periodic occurrences that prompt an information cycle. A boiler breaks down, a planned statutory inspection falls due, a tenant alters an internal layout, or a component reaches the end of its anticipated lifespan.<\/p>\n

When one of these events occurs, the framework initiates a miniature version of the project delivery loop. An information requirement is identified, an appointed party is tasked, a data container is created or revised, it is checked through the Common Data Environment, and the Asset Information Model is formally updated.<\/p>\n

That logic seems entirely reasonable if your operational focus is traditional facilities management and human-scale maintenance ticketing. It is well suited to supporting a technician receiving a CAFM work order, turning up with a ladder and tools to replace a filter, and updating an asset log so the business knows the task is complete.<\/p>\n

In practice, however, this mechanism breaks down on two fronts: economics and architecture.<\/p>\n

The first breakdown occurs within traditional facilities management itself (vector 1). The framework assumes maintaining the asset model is frictionless, ignoring the commercial reality of operational expenditure. Facilities management contracts run on razor-thin margins. Who is budgeted or billable to run a miniature project delivery loop, update a COBie schema, and push files through CDE approval gateways every time a pump is replaced on a wet Tuesday afternoon?<\/p>\n

Because operational budgets simply do not fund that specialised administrative overhead, the loop is quietly abandoned. The digital model stops reflecting the physical asset within months of Practical Completion, accelerating the slide into an expensive, static “data museum.”<\/p>\n

The second, deeper breakdown occurs in vector 2, when that same mechanism is asked to govern dynamic, continuous performance.<\/p>\n

Consider what happens when an AI optimisation engine is deployed across a commercial portfolio to tune rooftop units. The system is not waiting for a component to fail or an annual calendar date to roll around. It ingests continuous telemetry streams, monitors airflow, evaluates ambient outdoor conditions, tracks indoor carbon dioxide levels, and calculates dynamic energy tariffs in real time.<\/p>\n

Based on those live data loops, the engine might make small adjustments to damper positions, supply fan speeds, and setpoints thousands of times a day.<\/p>\n

It is difficult to see where the traditional concept of a “trigger event” fits into that reality.<\/p>\n

No human logs a CAFM ticket, and no technician walks to the plant room. More to the point, it would be impractical to run continuous telemetry adjustments through a manual container approval gateway in a Common Data Environment to check static naming conventions before an actuator is permitted to move.<\/p>\n

By treating operations primarily as a sequence of milestone transactions, the framework reflects its project-delivery heritage. It looks very much like a linear project tool trying to govern an operational environment with a fundamentally different rhythm. For those working at the performance frontier, trying to manage an automated, machine-to-machine loop with a process built for human document compliance does not feel like a natural fit. It suggests a genuine gap in operational logic.<\/p>\n

Section 8: Language, context, and the shift to verbs<\/h3>\n

To see why this gap proves so stubborn, you have to look beneath the process and examine the nature of the information itself. An underlying assumption quietly runs through the alignment movement: if we can agree on the labels, the data will naturally flow.<\/p>\n

The belief is that standardising an asset tag, a Uniclass code, or a spatial reference gives that data inherent, portable meaning. But coming from a design background, that assumption feels questionable. A word or an alphanumeric classification tag has very little intrinsic meaning on its own, detached from the operational context of how people and systems actually use it.<\/p>\n

In many ways, the divide between these two vectors comes down to the difference between nouns and verbs.<\/p>\n

Vector 1 is almost exclusively focused on nouns. Its purpose is to catalogue physical things. It asks what an object is, where it sits, who supplied it, and what periodic maintenance schedule it should follow. That is a perfectly sensible ambition if your goal is to build an accurate inventory for statutory compliance and human maintenance ticketing. Even when it includes tasks like inspecting a valve or replacing a filter, the physical asset remains the centre of gravity. At its heart, it still looks like a library of static components with a calendar of chores pinned to them.<\/p>\n

Vector 2, by contrast, seems driven entirely by verbs and operational outcomes. The building does not exist simply to be catalogued; it exists to achieve dynamic goals. It is about how an occupied environment behaves, responds, and adapts in real time to optimise energy, maintain comfort, or reduce peak load. For those working at this frontier, an asset is not just a static box on a drawing. What matters is the live telemetry points that asset exposes, how it communicates, and how it interacts within continuous control loops. Sensor A monitors zone B, which modulates airflow C, which reacts to occupancy pattern D.<\/p>\n

To me, those relationships are verbs. Aren’t they representing active dependencies, continuous control loops, and live telemetry exchanges?<\/p>\n

I ask this because this is where the idea of solving the project-operations gap purely through static data crosswalks seems to hit a hard ceiling. When project-side teams develop information requirements in an isolation tank, they are effectively compiling a dictionary of nouns. The assumption here seems to be that if they define the vocabulary carefully enough, that vocabulary will automatically govern live operations.<\/p>\n

In practice, can you orchestrate an ecosystem of verbs using a dictionary of static nouns?<\/p>\n

The syntax of real-world performance is relational and continuous, not tabular and frozen. Trying to govern the fluid interactions of a dynamic building with static tables created during design leaves the operational layer with plenty of labels, but very little understanding of how the living system actually behaves.<\/p>\n

Section 9: The alternative (human-centred dialogue via ConOps and StRS)<\/h3>\n

If static data crosswalks and project-delivery cascades struggle to bridge this divide, what is the practical alternative?<\/p>\n

Whenever this question comes up, some quarters have an understandable instinct to look to enterprise IT for answers. The temptation is to reach for overarching systems architecture frameworks like TOGAF to bring order to the chaos. Yet, in practice, the mere mention of enterprise architecture often makes operational teams roll their eyes. Those frameworks tend to feel overly heavy, abstract, and aggressively top-down. They risk replacing an unworkable construction process with an equally rigid IT bureaucracy, suffocating practical collaboration under layers of complex diagramming.<\/p>\n

What the operational layer seems to need is not more heavyweight IT governance, but a grounded, human-centred way to articulate day 2 intent before engineering specifications get locked into concrete and contracts.<\/p>\n

This becomes especially acute in retrofit, refurbishment, and smart technology upgrades. Given that between 80-90% of our building stock already exists, the real frontier is not pristine new builds, but improving live, occupied environments. In those settings, deploying a heavyweight project-delivery process feels particularly heavy-handed. There is already a quiet acknowledgement across parts of the information management community that part 3 is not as well developed or intuitive for operational reality as it could be. Why would an estate team wrap an agile technology upgrade inside a rigid project-delivery mechanism when the building is already functioning around them?<\/p>\n

This is where the concepts of a Concept of Operations, or ConOps, and its companion, the Stakeholder Requirements Specification, or StRS, start to look like an intriguing alternative.<\/p>\n

Originating in systems engineering, these approaches were developed specifically to solve the challenge of getting diverse groups to agree on what a complex system needs to do before anyone starts building it. Rather than getting bogged down in technical jargon or prescriptive hardware lists, they operate in plain language to define two essential things:<\/p>\n