“The scope has changed” can describe a project learning something important or a project losing control. The existence of change tells you very little. The evidence, trade-off and decision process tell you which situation you are in.

Treating every change as failure encourages teams to deliver obsolete assumptions. Treating every request as valuable learning destroys accountability. Mature delivery creates room to adapt and boundaries that make the cost visible.

A plan is a set of current assumptions

Discovery should reduce uncertainty before significant delivery begins. It can test user needs, map processes, inspect data and systems, expose dependencies and align leaders around an outcome.

It cannot reveal everything.

Documents can describe an aspirational process rather than the work people perform. An integration can behave differently under production constraints. User research can expose a need stakeholders did not mention. A regulation or supplier decision can change during delivery. Building and testing a small part can show that an earlier design will not work.

Some unknowns could have been found sooner with better work. Others become economical or possible to investigate only during delivery. The distinction matters because it tells the team how to improve, but it does not remove the immediate decision.

The project needs to ask whether the new information changes the desired outcome, the proposed route or merely a preference about the solution.

Managed evolution has four ingredients

A healthy scope change begins with evidence. “Users could not complete the tested task” is different from “a stakeholder would like another feature.” Both deserve consideration; they carry different weight.

It has an explicit trade-off. New work consumes time, money or capacity. The team must remove or defer something, change the budget or schedule, reduce another quality, or acknowledge a higher risk. A claim that the addition is free usually means its cost is hidden.

It has an authorised decision. The person approving it understands the impact and has the mandate to make the trade. Developers and stakeholders can identify and shape changes; a corridor conversation should not alter a commercial commitment.

It leaves a record. The project can show what changed, why, what evidence was considered, which options were rejected, who approved the decision and how the baseline moved.

When all four are present, adaptation can improve the likelihood that the work solves the real problem.

Uncontrolled creep has recognisable symptoms

Scope creep is cumulative work entering without a deliberate portfolio decision. It often arrives through reasonable sentences: “while you are there”, “it should only take an hour”, “we assumed that was included” or “one partner needs a slightly different version”.

Warning signs include:

  • no current shared view of what is included;
  • repeated changes without evidence or prioritisation;
  • delivery teams absorbing requests to protect the relationship;
  • approvals happening after work starts;
  • budget and dates staying nominally fixed while quality or testing erodes;
  • the same issue reappearing because the underlying decision remains unresolved;
  • no record of what was removed;
  • client and supplier using different definitions of completion.

Creep is not limited to the client. A supplier can expand a technical solution, add appealing capability or redesign work that already met the need. Internal specialists can introduce standards or platform ambitions without showing how they serve the project outcome.

Five questions for each proposed change

1. What did we learn?

Ask for the observation, source and relevance. Was it found through user testing, a technical spike, data analysis, regulatory review, operational walkthrough or stakeholder preference? How representative and reliable is it?

Evidence need not be statistically conclusive to justify action. A single severe accessibility barrier or security exposure may be enough. The decision record should explain why.

2. What happens if we keep the current scope?

This counterfactual prevents novelty from winning automatically. The existing route may remain acceptable, need a workaround or fail the outcome. State the consequence and confidence.

3. What options did we consider?

The choice is rarely simply add or reject. The team may simplify, defer, test further, change the process, use configuration, reduce another component or create a second phase. Include the smallest option that addresses the learning.

4. What changes elsewhere?

Show impact on cost, date, people, dependencies, security, accessibility, compliance, operations and expected value. Estimates can be ranges where uncertainty is real. State which assumptions drive them.

5. Who decides, and by when?

Delay has a cost. Name the decision owner and deadline. If evidence is insufficient, approve a bounded investigation with a clear output rather than allowing indefinite analysis.

Pattern matters more than a magic number

One or two changes are not inherently healthy, and a change every iteration is not automatically evidence of failed discovery. A complex product deliberately using experiments may make frequent small choices. A well-understood migration may expect very few.

Look for the cause and shape of the pattern.

Many independent requests from previously absent stakeholders suggest a governance and engagement problem. Repeated discoveries about one legacy system suggest the technical investigation was too shallow or the system is less knowable than assumed. Regular user-led changes that replace lower-value work can be exactly how iterative product delivery is meant to operate.

Review whether changes improve the outcome, whether decision time is increasing and whether the unplanned proportion of work threatens commitments. That is more informative than counting requests alone.

Iterative delivery still needs boundaries

Agile delivery is sometimes used to imply that scope can remain undefined. Iteration should create shorter feedback loops, not remove commercial clarity.

Different arrangements handle scope differently. A fixed-price project may protect a tightly defined result and use formal changes for material movement. A capacity-funded product team may hold budget and time relatively stable while varying the backlog. A discovery or prototype may be explicitly designed to decide the scope of a later phase.

The contract, governance and delivery method should agree. If the commercial model rewards adding change, or punishes the supplier for reporting uncertainty, behaviour will follow.

Define at the start:

  • the outcomes and important constraints;
  • the current scope baseline;
  • what the team can trade within its authority;
  • thresholds for cost, timing, risk or value escalation;
  • who approves at each level;
  • the information required for a decision;
  • how contingency may be used;
  • how changes affect acceptance and contract terms.

A change-control process can be lightweight. A one-page decision is enough for many changes if it contains the necessary reasoning.

Client and supplier both have responsibilities

The delivery partner should maintain the scope, surface learning early and assess impact before committing work. It should make uncertainty visible and resist adding work merely to avoid a difficult conversation.

The client should provide an empowered owner, timely access to the right people and decisions within the agreed window. It should resolve conflicting stakeholder requests and accept that changing a commitment requires a trade.

Both parties should distinguish advice from authority. A supplier can recommend a change strongly; the client may decline after understanding the consequence. The decision and accepted risk should be recorded without turning disagreement into blame.

The person paying is entitled to a current scope, a written impact view before a material change, transparent commercial treatment and the ability to say no. The supplier is entitled to have the effect of that decision recognised rather than being held to an outcome the rejected change made impossible.

The cost of rigid scope

A fixed scope can provide useful control. It becomes dangerous when delivery evidence is prohibited from affecting the solution.

A team can deliver every specified feature and still fail the intended outcome. This happens when acceptance tests confirm that the system matches a document while nobody tests whether a client or employee can achieve the task. The project reports green up to the point that adoption is weak or the old workaround continues.

Protect outcome testing inside the plan. Demonstrate working increments to real users where appropriate. Inspect operational readiness, data and controls. If the evidence challenges the specification, bring a decision forward.

Changing nothing is still a scope decision, with a consequence that should be explicit.

The cost of constant change

The reverse failure is a project that never allows knowledge to settle. Teams repeatedly rebuild, testing is compressed, dependencies cannot plan and users assess unfinished ideas. Leaders may call this responsiveness while delivery loses a stable definition of done.

Use product direction and prioritisation criteria to reject plausible requests. Set periods in which teams can complete agreed work. Limit work in progress. Separate urgent risk changes from ideas suitable for the next review.

The ability to adapt includes the ability to continue.

What to ask a delivery partner before appointment

Ask the supplier to show the mechanics of change control, including a redacted example of a change that improved a project and one it advised against. Examine the evidence, options, impact and approval rather than accepting a success story.

Ask how its commercial model treats discovery, contingency, backlog trade-offs and estimation uncertainty. Identify who can commit the supplier and which changes need contract variation.

Then examine your own side. Name the person who can decide, the subject experts they need and the escalation route for consequential choices. A supplier process cannot compensate for a client steering group that meets too late.

A simple classification

When a change appears, classify it as one of four types:

  • Correction: required to meet an existing agreed requirement or quality level.
  • Learning: new evidence changes the best route to the existing outcome.
  • External change: regulation, supplier, market or organisational conditions have moved.
  • Enhancement: additional value outside the existing commitment.

The type does not decide who pays or whether to proceed; contracts and facts do. It gives the conversation a clearer start and makes patterns visible across the project.

Good projects begin with a credible scope and retain the ability to learn. The standard is neither perfect prediction nor permanent flexibility. It is the quality of the decisions made when reality differs from the plan.

That's the difference between getting what you asked for and getting what you actually need.

If you're about to kick off a project and want to make sure your foundations are solid before you sign anything, our Fragility of Digital Foundations scorecard is worth fifteen minutes of your time. It'll surface the questions you should be asking - and a few you probably haven't thought to ask yet.