PERSPECTIVE

When does an asset defect become a commercial issue?

Two systems, one asset

Most operational infrastructure organisations run two systems over the same asset.

One is technical. It records condition, raises work, schedules interventions, closes jobs and reports performance. It is designed to resolve things.

The other is commercial. It administers the contract, tracks obligations, handles notices, allocates cost and manages the relationships with the parties who designed, built, supplied or maintain the asset. It is designed to protect a position.

Both are usually competent. They are rarely triggered by the same event. And an asset condition enters the first of them automatically, because that is what the first one is for — while entering the second requires somebody to decide that it should.

That decision is the subject of this Perspective. It is not the question of who is liable, what is recoverable, or whether anything is owed. It is the earlier and more practical question of when a matter should stop being handled exclusively as a technical one.

ASSET CONDITION
ENGINEERINGMAINTENANCEOPERATIONS
RECOGNITION
COMMERCIALCONTRACTFINANCE

Recognition does not transfer responsibility for managing the operational consequence.

An asset condition reaches Engineering, Maintenance and Operations above a Recognition threshold, with Commercial, Contract and Finance below; recognition does not transfer responsibility for managing the operational consequence.

Why competent technical management can suppress the signal

Start from a position that is often left out of this discussion: not every defect is a commercial matter, and an organisation that escalated every one would be worse off, not better. Engineering and maintenance functions exist to diagnose and resolve conditions. Most conditions are resolved. Routing them all through a commercial process would slow the work, load the contract administration with noise, and damage relationships that the organisation needs for the next twenty years of operation.

The difficulty is that the same competence which resolves conditions also conceals them. When something behaves abnormally, an effective organisation increases inspection, adds interventions, introduces a control, replaces parts, absorbs the cost and protects availability. Every one of those responses is correct. Taken together they produce a condition that is under control — and a condition that is under control generates no event that forces anyone to ask whether its origin, its contractual treatment, its warranty position or its cost allocation belongs somewhere else.

Nothing has gone wrong. That is precisely the problem. The commercial signal is not suppressed by failure. It is suppressed by success.

When the question changes

There is no external authority that states the moment at which an asset condition becomes a commercial matter, and this Perspective does not offer one. What can be done is to identify the signals that recur, and to say plainly that they are indicators for an organisation to define for itself rather than a validated test.

Six are worth watching:

  • recurrence, where the maintenance regime is appropriate and unchanged;
  • evidence that the origin of the condition sits outside ordinary operations and maintenance;
  • intervention demand materially different from the behaviour the asset was assumed to have;
  • the introduction of an unplanned operational control;
  • premature or anomalous behaviour in one part of an asset or component population;
  • expenditure whose causal basis cannot be reconciled with the maintenance obligation.

None of these establishes anything. Each is a reason to look, and the useful organisational question is not is this a claim but does anyone outside engineering know this is happening.

Origin, consequence and where each is managed

The underlying proposition is simple to state and difficult to operate:

Where a problem is managed is not necessarily where the problem originated.

An operator manages the consequence because the consequence is in front of passengers, users or the service. The origin may sit in design, manufacture, installation, asset condition, operating or maintenance activity, external physical conditions, a supplier several steps down a chain, or a decision taken long before the current organisation held the asset.

Two abstracted patterns illustrate the distance between the two. In the first, a manufactured infrastructure component behaves abnormally after entering service, generating additional inspection and intervention. In the second, an operational asset is affected by a physical condition whose apparent origin lies outside ordinary maintenance activity. In both patterns, the function managing the operational consequence does not, by that fact alone, establish where the condition originated. Competent management of the consequence and investigation of its origin are different tasks.

It bears stating directly, because the inference is easy and wrong: origin does not equal entitlement. Establishing that a condition arose elsewhere does not establish that anything is recoverable from anyone. It establishes that a question exists which the technical system is not designed to answer.

Why recognition can be time-sensitive

Technical resolution can take as long as it takes. Recognition often cannot.

Recognition can be time-sensitive because contracts may attach notices, records or other procedural requirements to particular events or circumstances. The relevant trigger, period and consequence depend on the contract and applicable law. Sophisticated infrastructure contracts do make categorical distinctions of this kind. Under the NEC forms, for instance, the early-warning mechanism is explicitly forward-looking — the publisher’s own guidance describes early warnings as concerned with risks which could, in future, cause problems, and states that a defect can only be notified once you are aware of it, that is once it has happened. Different category, different process.

That example is offered as an illustration that a contract form may separate types of recognition and attach a different process to each. It is specific to the NEC forms and is not offered as a universal rule, nor as a description of infrastructure contracts generally. Which mechanisms apply, what they require and when they operate depends on the contract and on the applicable law — a limit that FIDIC itself observes in its published guidance, which states that it can comment only in general terms on the interpretation of its clauses and that a specialist should be consulted for the application of a clause to a particular situation.

The practical consequence for an operator is not legal. It is organisational. If the only route by which a matter reaches the commercial system is a decision that nobody is accountable for taking, then the timing of that decision is accidental — and late recognition can narrow what the organisation is able to do under whatever contractual processes actually apply.

The organisational handshake

Recognition is not a document. It is a handshake between functions that usually meet only at budget time.

Asset Management holds the record — identity, installation, intervention history and the party responsible for each. Whether that record can answer a commercial question is a substantial subject in its own right; here it is enough to say that recognition is limited by what can be shown.

Engineering holds the diagnosis, and is the only function able to say whether behaviour is anomalous for the population.

Maintenance holds the demand history, and knows what is being done repeatedly and why.

Operations holds the service consequence and the controls being carried to protect it.

Commercial holds the obligations, the notice regime and the counterparties.

Finance holds the cost, usually classified by where the work was done rather than by why it arose.

No single function can recognise a commercial matter, because no single function holds enough of it. That is the structural reason recognition fails, and it is not solved by asking people to communicate better. It is solved by naming who is accountable for asking the question, and on what trigger.

What changes when the matter becomes commercial — and what does not

What changes is who is running it, what is being recorded, what is being notified, and where the cost sits while the question is open.

What does not change is the operational responsibility. The organisation responsible for operating or maintaining the infrastructure still has to manage the asset and its operational consequences appropriately while questions of origin, responsibility or cost allocation are being examined. Continuing to act is not a concession, and recognising a matter as commercial is not a reason to stop.

The organisations that handle this well are not the ones that escalate quickly. They are the ones that can say, at any point, which conditions they are managing, which of those have a question attached, and who is holding the question.

Westheath is engaged where a technical matter and a commercial one have become the same matter, and the organisation needs an independent read of which is which.

Westheath Infrastructure Advisory

← All Perspectives