Every design change comes with a price on the variation. Its real cost often sits somewhere else, in the settled requirements it undoes without anyone noticing and in the record you will need if it is ever disputed.
A third of the budget, in dispute.
HKA’s eighth CRUX Insight report draws on more than 2,200 projects in 114 countries that its experts have investigated, with a combined capital value of around US$2.4 trillion. On those projects, sums in dispute averaged 33.4% of contract budgets, and change in scope remains the most common cause of conflict.
These are projects that ended up in claims, so the figure is not a picture of every job. It does show how much can be at stake once change goes wrong.
Construction claims rarely start with one big decision. They tend to start with a sequence of small ones, each reasonable at the time, whose combined effect nobody saw until the bill arrived.
Why changes get priced against the contract, not the design.
When a change is proposed, its cost and programme impact are usually assessed. What is rarely assessed is which settled requirements the change undoes, because that would mean holding every requirement, its history and its evidence in one place. Most teams do not have that, so the consequence is discovered later, in a clash, a validation turn-back or a claim.
The timing makes it worse. Its effect on the settled design is usually judged after the design has been redrawn, which means the effort has been spent before anyone knows whether the change was worth making. Three questions, asked before anything is modelled, change that.
- What does the change touch? Every requirement it reaches, across every discipline.
- What does it undo? The settled requirements it would reverse, and who settled them.
- What has to be reissued? The deliverables that no longer stand once the change goes ahead.

In the example above, a change to the facade build-up agreed in week 12 touched 14 requirements and undid two that had already been settled. Nobody saw it until it surfaced as a claim 22 weeks later. Had the change been tested against the requirement register before anything was modelled, that consequence would have been visible on the day of the decision, for the cost of a question rather than a week of redesign.
The variations hiding in your inbox.
Not every change arrives as a formal instruction. A client asks for an upgraded reception finish in a progress meeting. An email adds pressurisation to a second stair. A design team memo adds an acoustic screen to the plant deck. Each one gets built, and none of them is ever raised as a variation or a compensation event.
That is margin given away, and it is the hardest kind to recover once the job has moved on. A request that arrives in a sentence can still change the scope, and a variation order that is never raised is simply work delivered for free. Many standard forms of contract also set notice periods for change, so a late notice can cost the entitlement altogether.

The fix is to read the correspondence these requests arrive in. Meeting notes, emails, reports and memos can be scanned for changes that were asked for but never raised against the Employer’s Requirements or the brief, each one with the document and date that carries it.
When value engineering costs more than it saves.
Value engineering has a reputation problem, and it has earned some of it. Speaking at a building engineers’ conference in 2018, Dame Judith Hackitt said it was a phrase she would be happy never to hear again, as Construction Management reported.
It is anything but value. It is cutting costs and quality.
Dame Judith Hackitt, 2018
Her final report on building regulations and fire safety did not call for value engineering to be banned. Building a Safer Future called instead for a stronger change control process, with robust record-keeping of every change made to plans that had already been signed off. The report’s concern was changes made without control or record, not savings in themselves.
The practical answer is to set every saving against the requirements it would break, before anything is modelled. Most proposals will come back clear. The ones that do not are exactly the ones worth a second look.

A saving that reappears as rework was never a saving. It was a cost moved further down the programme, usually to the point where it is most expensive to deal with.
Requirement drift and the record a dispute turns on.
Drift rarely announces itself. It is usually a change that looks harmless in the room, made without sight of what was agreed before. Picture a party wall specified at 45 dB in the brief, confirmed at 45 dB by the acoustician, then reduced to 41 dB in a value engineering round that never referred back to either decision.

The defence is to keep every value a requirement has held, with the decision and the person behind each one. A later change that moves it then shows up as the reversal of something agreed, rather than a fresh position nobody thinks to question.
Higher-risk buildings in England already work to a version of this by law. Every change to the agreed documents is a controlled change that has to be assessed and recorded, and major changes need the regulator’s approval before the related work goes ahead, as the regulator’s guidance on making changes explains. The Principal Contractor must keep a change control log, and the guidance on building control applications lists what each entry should cover.
- Who recorded the change, with a description of it
- Why the change is being made
- Whether it is a recordable, notifiable or major change
- Whose advice was sought, and a summary of what they said
- Which agreed documents it affects, and confirmation that each has been revised
- How the building regulations will still be met once the change is made
Even outside that regime, it is a sensible standard. When a variation is disputed, the argument turns on what changed, when, who asked for it, what it affected and what was decided. That record is either kept at the time or rebuilt under pressure, and our commercial and change control page shows what keeping it at the time looks like.
Key takeaway
A change log records that something changed. A requirement register can tell you what the change undid, before you sign it off.
Before you sign it off
A 30-minute session showing a proposed change tested against the requirement register before anything is modelled, on a project we have prepared. Nothing to set up, no project data needed.
Book a demo