Engineers, if it’s not in the contract, it’s unlikely to happen

When I was working on a major rail programme in the north of England, I was part of a team that built a process for delivery partners to hand over asset information as the work progressed.

This was the record of what had been installed, where it sat and what condition it was in – the information the railway's future operator and maintainer depend on.

When it arrives late or incomplete, the operator ends up having to conduct surveys to find out what was built, long after the people who built it have gone.

But as an alliance, with several consultants and contractors under one programme, each partner had its own systems and established ways of managing information.

Bringing them together, onto a common data environment, meant asking most of them to set aside an approach that already suited them.

At first, the uptake did not follow.

That quickly changed when the requirement was written into the alliance agreement.

Contracts can be one of our most effective tools

Information requirements and data specifications became a shared obligation, supported by guidance and governance. Each partner's compliance was measured and reported across the alliance.

Once every partner could see where it stood against the others, behaviour changed quickly.

Within months, the question was no longer whether the process was worth the effort. It was why we had not done it from the start.

To be clear, nobody behaved badly in that story. Professional teams deliver what they are obliged to deliver, and a project that optimises for its contract is doing its job.

The consequence is that the contract quietly sets the behaviour of a project.

It defines what gets measured, what gets paid and what counts as done, long before anyone arrives on site.

We tend to treat it as a risk allocation exercise, when it may be one of the most effective tools we have for making innovation happen.

Writing the requirement in

None of this was unique to one programme. NEC's X10 option, introduced in 2017, puts the client's information requirements into the scope and requires the supplier to plan how they will be met.

Information standards only carry force once they are written into appointments.

The same thinking, beyond information

Information is one example of a wider principle, and sustainability commitments follow the same logic.

NEC added a climate change option, X29, in 2022.

X29 allows a client to set climate specifications in the scope, requires the contractor to plan against them, and can attach financial consequences to performance.

Whether decarbonisation is treated as an aspiration or as a deliverable is, in the end, a drafting decision.

The mechanics are already visible in practice.

On the Lower Thames Crossing, National Highways gave carbon management the same weighting in its procurement as it gave to tunnelling methods. It asked bidders to set out how they would cut carbon and offered incentives for coming in below the requirement.

Examples include a payment for every tonne saved against the figure proposed at tender, and compensation for overrun where a contractor takes on a new decarbonisation method.

Collaboration can be harder to integrate at drafting stage, because it is a behaviour rather than a deliverable.

Even so, shared pain and gain and whole-programme incentives change the tender calculation, making cooperation the outcome a contractor is paid to reach.

What makes it work

The honest objection to all this is that writing a requirement into a contract turns an aspiration into a minimum, and teams deliver minimums.

Guaranteed compliance is not the same thing as ambition, and most of us have seen a contractual deliverable arrive on time, in the right format, and go straight into a folder nobody opens.

That is not what happened on the programme I described.

Once the obligation existed, nobody had to win the argument about whether to bother, and the effort moved to what the information could do.

For example, one major closure (16 days with the railway shut to remove and replace bridge decks) was rehearsed as a four-dimensional model.

The construction programme linked to the design models, so the sequence played out against real dates before anyone went near site.

The same models ran on screens in the control room throughout the closure, updated with actual progress. If needed, the team could adjust while there was still time to act.

None of that is available when each party holds its own information in its own way and hands it over at the end.

You get what you ask for, so ask well

A contract rewards the measure that was written down, and the measure is only ever a stand-in for the outcome.

Require a data set in a set format by a set date and you will get exactly that, whether or not anyone can use it.

Choosing measures well, and keeping them under review as the programme matures, matters as much as writing them in at all.

It also matters who does the writing.

Specifying what an asset owner will need in 10 or 20 years takes genuine operational understanding.

So, for me, this is a question of professional competence.

If contracts now set the terms for digital delivery, for example, then commercial and contractual literacy belongs in an engineer's continuing professional development alongside technical skill.

Our obligation to work within our competence applies to the clauses we write as much as to the structures we design.

A path to getting what we want from projects

That rail programme settled the point for me.

The things we say we want from our projects – better information, lower carbon, genuine collaboration – only become real when they are written down where they carry consequences and then managed deliberately through the life of the programme.

If it’s not in the contract, it’s unlikely to happen, however sincerely everyone wants it.

The encouraging part is that the mechanisms now exist, and the next time we are in the room when a contract is being drafted, the most innovative thing we can do may be to reach for them.