What handover costs the people who inherit it

An asset is handed over twice. Once on paper, when the certificate is signed and the documents are accepted. Then again months later, when somebody in operations needs to know something nobody wrote down.

Most writing about handover treats this as a documentation problem, and recommends better documentation. That is not wrong, but it skips the question owners should be asking, which is what the gap actually costs and who pays it.

That has been measured. Once, properly, more than twenty years ago.

The one time anyone counted

In 2004 the US National Institute of Standards and Technology published a study by Gallaher, O'Connor, Dettbarn and Gilday estimating the annual cost of inadequate interoperability in the American capital facilities industry. Interoperability here means the ability to move project and product data between firms and between systems, which in practice means whether information survives the journey from one party to the next.

The headline was $15.8 billion a year, in 2002 dollars. The headline is the least interesting part.

Costs rose at every stage. Planning and design accounted for $2.7 billion. Construction, $4.1 billion. Operations and maintenance, $9.1 billion, which is more than the other two combined. Of that operations figure, $9.0 billion fell on owners and operators.

So just under three fifths of the total cost of information failing to travel properly showed up in a phase where the people who caused it were no longer present.

Costs compound as one moves forward in the facility life cycle and their heavy costs in the O&M phase are a result of disconnects in the design and construction phases.

That is how Robert Chapman of NIST summarised what owners had concluded from the data. It is worth sitting with, because it inverts how handover is usually discussed. The problem is not that operators receive their documents late. It is that the cost of a decision taken during design lands on a different organisation, years later, in a different budget.

The largest single line item is checking

Within that $9 billion, one item dominates: $4.8 billion of what the study calls operations and maintenance information verification.

Not building anything. Not fixing anything. Verifying. Owners spending money to establish whether the information they hold about their own assets is correct.

If you have ever watched a team walk a site with a clipboard and a drawing set, confirming whether the drawing matches the wall, you have watched this cost being incurred. It rarely appears as a line in a budget. It is absorbed into salaries, into consultant fees, into the time it takes to answer a question that should have taken a minute.

What the number does and does not tell you

The study is old, and the honest reading requires saying so.

The data is from 2002 and covers the United States only. It excludes residential buildings and transportation infrastructure. The method was survey-based, comparing observed costs against a constructed scenario in which information is entered once and flows without loss, so the figure is an estimate of a gap rather than a measurement of a transaction.

It also predates almost everything the industry now points to as the answer. BIM was marginal in 2002. COBie did not exist. ISO 19650 was years away.

You could argue the number is therefore too high today. You could argue the opposite, that assets have become considerably more instrumented and more complex since, and that there is more information to lose. Both are reasonable. Neither is settled, because no comparable exercise appears to have been repeated since.

That is the striking part. A cost of this size, attributed this precisely to a specific phase and a specific party, and the measurement was taken once.

There is no shortage of recent numbers about the cost of poor data generally. Most trace back to consultancy surveys with no published methodology, and none of them isolate the built asset lifecycle. They are not a substitute.

Meanwhile the contract got stronger

While the measurement stalled, the drafting improved.

In FIDIC's 1999 Yellow Book, the obligation to supply as-built records, operation and maintenance manuals and training sat in Sub-Clauses 5.5 to 5.7, away from the completion machinery. The 2017 edition moved it into Sub-Clause 10.1, so the supply of those items is now an express requirement of taking over, and coupled it with a requirement for the Engineer to issue a Notice of No-objection on the as-built records and the manuals. As Victoria Tyson of Howard Kennedy puts it, there cannot be a deemed taking over under Sub-Clause 10.1 without those notices.

That is a real strengthening. It moves asset information from a schedule item to a completion condition.

There appears to be a route around it. Tyson notes that because of how Sub-Clause 10.3 was redrafted, deemed taking over following interference with tests on completion seems to occur even without the as-built records, the manuals and the training. That is one experienced practitioner's reading of the drafting rather than a settled position, and it may never be tested. But it is the kind of gap worth knowing about before you rely on the clause.

And the standard already exists

ISO 19650-3, published in 2020, covers information management during the operational phase. Its structure is the useful part. Asset Information Requirements are derived from Organizational Information Requirements, which is a formal way of saying that what you collect should follow from what your organisation actually needs to decide.

Most handover specifications are written the other way around. They list what the contractor can readily produce, then hope it proves useful. The standard asks the owner to state, in advance, what they will need to know in order to run the thing. That question is harder, which is probably why it is so often skipped.

What tends not to survive

Three categories fail to make the transfer, and none of them appear on a document register.

What was installed, as distinct from what was specified. As-built records describe what was drawn. Late substitutions, field modifications and the small resolutions of clashes are often absent, because the document was updated to close a contractual requirement rather than to describe reality.

Why it was done that way. Design intent is the least recorded and most valuable category. An operator who does not know why a system was configured a particular way cannot safely change it, and will eventually either leave a problem alone or create a new one while fixing it.

What was already known to be marginal. Every large project ends with a private list of things accepted rather than resolved. That list lives in people's heads and in email. It is also, reliably, the list operations most needs.

Four things that change the outcome

None of these require a contract variation, which matters, because by the time anyone is worried about handover the contract is signed.

• Specify information as a deliverable with a named recipient and a named acceptor. A requirement that says who receives it, and who signs that it is usable, behaves differently from one that names a document.
• Run the handover review before handover. A review three months out can still change what gets produced. One conducted afterwards can only describe what is missing.
• Test the pack with a stranger. The only honest test is whether a competent person who was not involved could operate the asset from what has been supplied. It is cheap, and almost nobody runs it.
• Ask, in writing, what was accepted rather than resolved. People generally answer a direct question.

The part worth remembering

The 2004 figure will not be exactly right for your asset, your country or this decade. Treat it as a shape rather than a value: the cost of information failing to transfer rises through the lifecycle, and the largest share falls on whoever ends up owning the thing.

Which raises a more uncomfortable question than how to improve handover. If most of the cost lands on owners during operations, and owners are the ones commissioning the work in the first place, why is the information requirement still usually written by the people who will have left before the bill arrives?