Scope Creep: When the Project Changes but the Budget Doesn’t
The Hilarious Dance You Never Agreed to Join
Nobody begins an infrastructure project by saying:
“Let us approve one scope, price another and quietly deliver a third.”
Yet this is how many projects develop.
The job starts with a sensible brief, an approved budget and a reassuring programme. Then somebody requests a minor addition. Another stakeholder remembers a requirement that was never documented. A design interface turns out to belong to everyone and therefore, mysteriously, to no one.
Soon, the original estimate will be compared with a project that no longer resembles the one it was priced for.
Welcome to the Scope Creep Cha-Cha: one step forward, two steps sideways and a final spin towards the contingency allowance.
Scope change is not automatically bad. Infrastructure projects evolve as information improves, risks become clearer, and stakeholder needs develop. The problem begins when the scope changes, but the budget, programme and approvals pretend that it has not.
That is not flexibility.
It is financial theatre.
What Scope Creep Actually Means
A properly governed change is not scope creep.
If a client adds a station entrance, strengthens a bridge, increases electrical capacity, assesses the consequences, secures funding, and rebaselines the project, that is an authorised change.
Scope discovery is not necessarily scope creep either.
Finding undocumented utilities, unsuitable ground, or unexpected asset defects may expose an omission, a risk or incomplete early information. It still requires control, but calling every unwelcome discovery “creep” can hide the real cause.
True scope creep is quieter.
It is additional or altered work entering the project without a transparent decision on cost, time, risk and responsibility. It often arrives disguised as coordination, clarification, enhancement or:
“Something we assumed was already included.”
The Association for Project Management defines change control as the process through which requests to alter an approved baseline are captured, evaluated and then approved, rejected or deferred.
The important word is baseline.
Without one, there is nothing reliable to control, and every argument becomes a retrospective interpretation exercise.
The Familiar Dance Partners
The “We Forgot About That” Tango
A requirement was absent from the brief, the estimate or both.
Perhaps the access road also needs drainage. The bridge repair requires temporary works. The substation needs protection modifications. The rail possession strategy assumed in the estimate cannot actually be secured.
This is often called scope creep, when it may really be:
- scope omission;
- incomplete definition;
- poor interface management;
- inadequate early investigation;
- or an assumption that was never properly tested.
Renaming the problem does not fund it.
The “While We Are Here” Waltz
This is one of the most expensive phrases in infrastructure.
While the road is closed, could we replace the drainage?
While the station is being refurbished, could we improve the lighting and toilets?
While the cable route is open, could we install extra ducts?
Some of these ideas may offer excellent value. Combining work can reduce future disruption and repeated mobilisation. But a good opportunity is still a chance.
It must be tested against benefits, affordability, programme impact and delivery risk.
“While we are here” is not a recognised source of unlimited funding.
The Shiny New Feature Samba
A new technology, architectural feature or stakeholder aspiration appears after the budget has been established.
The proposal may improve the project. Unfortunately, enthusiasm often arrives before an impact assessment.
The purchase price is discussed. Redesign, testing, assurance, approvals, installation, maintenance and programme effects are not.
The feature is described as “only a small addition”.
The estimate then performs a small nervous breakdown.
The Unforeseen Circumstances Mambo
Ground conditions, buried services, environmental constraints and existing asset defects can force a project to adapt.
Some events are genuinely difficult to predict. Others were predictable but not investigated, recorded or priced.
A residual risk may require an appropriate risk allowance. A known requirement omitted from the base estimate should not be relabelled as uncertainty.
Contingency is not a corporate washing machine into which every uncomfortable decision can be placed until its ownership disappears.
Why Budget Reality Always Wins
A budget does not automatically expand because the project has developed a more interesting personality.
Every change has consequences.
The obvious impact is the direct construction cost. The less visible impacts can be larger:
- redesign and additional engineering;
- supervision and project management;
- temporary works;
- testing and assurance;
- possessions or traffic management;
- remobilisation;
- extended preliminaries;
- procurement disruption;
- and additional exposure to risk.
This is why: It
“It is only £100,000 of extra work”
is rarely the end of the conversation.
If that work delays a critical possession, extends the programme or disrupts a procurement package, the total impact may be far greater than the visible construction cost.
UK government cost-estimating guidance recommends presenting infrastructure estimates as ranges reflecting project risk and uncertainty.
But uncertainty is not permission to absorb uncontrolled scope.
A cost range describes possible outcomes for a defined project. It is not an invitation to redefine the project without changing the budget.
Once a senior stakeholder remembers the approved headline number, any subsequent increase may be treated as an estimate failure. The original scope, assumptions, exclusions and level of maturity are forgotten.
The estimate is expected to remain constant while the project changes around it.
Apparently, the number signed the contract.
The scope did not.
How to Stop the Music
The answer is not to prohibit change.
Infrastructure projects could not function without adaptation. The objective is to make change visible, assess it consistently and ensure that the person approving it understands what is being purchased.
Establish a Real Baseline
A credible baseline must describe what is included, excluded and assumed.
It should identify:
- interfaces;
- quantities;
- technical requirements;
- delivery strategy;
- programme assumptions;
- and the maturity of the estimate.
“Construct a bridge” is not a controlled scope.
What capacity? Which standards? What temporary works? What access arrangements? What utilities? What environmental mitigation? What road closures or rail possessions are assumed?
The thinner the scope definition, the more confidently the project will later claim that missing work was “always included”.
Record Assumptions Before They Become Fiction
Assumptions are necessary during early project development.
They become dangerous when they are buried inside spreadsheets, forgotten after approval, and later treated as facts.
A proper Basis of Estimate should explain:
- the information used;
- the pricing methodology;
- exclusions and qualifications;
- risk treatment;
- delivery assumptions;
- and the conditions underpinning the cost.
When an assumption changes, the project should trace the resulting impact.
An undocumented assumption is merely a future argument waiting for a meeting room.
Give Every Change One Door
Changes should enter through a defined process, not through meeting minutes, design comments, informal emails and corridor conversations.
Each change request should state:
- What is changing;
- Why is it required;
- who requested it;
- what the consequences are;
- and what decision is needed.
The assessment should consider cost, programme, risk, benefits, carbon, operations, procurement and interfaces—not merely the purchase price of the new physical item.
Change control is not bureaucracy for its own sake.
It stops projects from making decisions in fragments and discovering their combined impact several months later.
Put Cost and Authority in the Same Room
Technical approval does not equal budget approval.
A designer may confirm that an enhancement is feasible. An operator may support it. A stakeholder may insist that it is essential.
None of those statements identifies the funding source.
The decision must be explicit:
- approve and fund it;
- reject it;
- defer it;
- substitute another requirement;
- Or return it for further development.
A project should not approve additional scope first and begin searching for money afterwards.
That is not change control.
That is budgetary hide-and-seek.
Rebaseline Honestly
Once a change is approved, the scope, estimate, programme, risk register and forecast should tell the same story.
Leaving the approved budget untouched while adding work to the forecast does not preserve project performance.
It manufactures a future variance and gives management several months to practise looking surprised.
The original baseline may still be retained for performance measurement, but the current authorised position must also be reported honestly.
Otherwise, the project ends up operating with several different truths:
- the scope being designed;
- the scope being delivered;
- the scope being reported;
- and the scope that the budget can actually afford.
The Estimator’s Uncomfortable Role
Estimators are frequently asked to price a change after the project has effectively been decided to proceed.
At that point, the estimate does not support a decision.
It is documenting an inevitability.
The estimator should be involved earlier: challenging definition, separating base cost from risk, identifying consequential impacts and recording the difference between the original and revised scope.
Most importantly, the estimator should resist silently absorbing new work into an old number merely to preserve the appearance of affordability.
That may make the meeting less comfortable.
It also makes the eventual outcome less fictional.
Estimators are not there to make every decision look affordable. They are there to explain what the decision is likely to cost.
Change the Scope or Protect the Budget—But Do Not Pretend to Do Both
Projects change. Requirements mature. Risks emerge. Opportunities appear.
None of this is inherently a failure.
The failure occurs when governance refuses to acknowledge the trade-off.
A project can add scope, but it may need more money or time.
It can protect the budget, but it may need to remove, defer or redesign requirements.
It can use contingency for genuine uncertainty, but not as a substitute for funding known additions.
Scope creep thrives in the gap between what the project is now expected to deliver and what its budget is still pretending to buy.
Before accepting the next “tiny clarification”, pause the music and ask five questions:
What has changed?
Why is it required?
What is the full impact?
Who can approve it?
Where is the funding coming from?
If nobody can answer, you are not managing change.
You are simply dancing towards an overrun.
