When project scope changes: adapt, defer or stop

Scope can change because a project is learning. It can also change because nobody is governing it.

The source says every one of more than 170 Distinction projects changed scope. That absolute claim requires the engagement record and a definition of change. Complex work often reveals facts absent from the original brief. Normality still does not make every addition healthy.

The sponsor's task is to distinguish valuable response from uncontrolled creep and make the trade-off visible before work proceeds.

Change can protect the outcome

Three causes deserve a fair hearing.

Discovery exposes hidden complexity. A nominal 500-page migration may contain calculators, widgets, embedded logic or inconsistent components. The source describes 47 undocumented Kentico modules adding three weeks to an accountancy project. Verify the details and client permission. The mechanism is credible: surface inventory can conceal implementation variation.

User evidence contradicts the brief. A portal specified as a document store may be less useful than status visibility. The source says a live status feed became the most-used feature on one engagement; that result needs analytics and permission. User evidence should change a plan when it reveals the team is solving the wrong task.

Business conditions move. Merger, regulation, service or client change can make the original outcome obsolete. Delivering the signed scope unchanged may be contractually tidy and commercially wasteful.

In each case, the proposed change must still compete with defer, simplify or stop. New information does not automatically justify more work.

Creep hides its aggregate effect

Managed change is named, assessed, decided and recorded. Creep arrives through requests that appear individually small:

• An additional field
• A different approval
• Another content type
• A dashboard refinement
• A new user role
• A temporary integration

The supplier may absorb them to preserve the relationship. Client stakeholders may assume they fit inside the price. Delivery then protects date by compressing testing, accessibility, migration or support.

Both parties contribute. “While you're in there” is still a change request. A sound protocol removes moral judgement and shows consequence.

The contract should also define tolerances. A team may have authority to refine minor implementation detail within an agreed outcome, contingency and guardrail. Anything outside that envelope returns to the sponsor. Without a tolerance, governance becomes either paralysing, with every tiny choice escalated, or permissive, with consequential work described as routine interpretation. Agree the boundary before pressure arrives.

A one-page decision record

The source offers a four-step process. It is strong enough to preserve with some refinement.

Identify

Describe the new fact, request or assumption as soon as it becomes material. Do not begin work merely because the change appears small, unless pre-agreed tolerance gives the team authority.

Assess

Record:

• Reason and evidence
• Effect on intended outcome
• Time, cost and internal capacity
• Quality, accessibility, security and other guardrails
• Dependencies and downstream work
• Contract or assurance implications
• Options and recommendation
• Confidence and unresolved questions

Include cumulative impact. The fourth small change may be the one that exceeds contingency or makes the launch date unrealistic.

Decide

An authorised person chooses:

• Add the change and update baseline
• Swap it for existing scope
• Defer it to a later decision
• Reject it and accept the stated limitation
• Pause for more evidence

Sometimes a legal, security or regulatory requirement removes practical discretion. Explain the authority and options that remain.

Record and communicate

Update scope, budget, plan, risks and acceptance. Tell affected teams which baseline now governs. Keep the decision trail accessible at handover.

The source's 30-minute write-up, 15-minute approval and 24-hour circulation are useful ambitions for ordinary changes, not service guarantees. Consequential decisions may need more evidence and authority.

Rights and responsibilities

A client should understand material changes before they consume budget or alter outcome. A supplier should receive timely decisions and payment for agreed additions under the commercial model.

The client can expect:

• A traceable reason
• Impact and alternatives
• A recommendation
• Cumulative programme view
• A real decision before material work

The delivery team can expect:

• One authorised route
• Stakeholders to use it
• Decisions by an agreed date
• No informal instruction that contradicts governance
• Recognition that discovery can change a responsible estimate

Absolute rights to reject change depend on contract, law and feasibility. The source overstates this. A client can decline to fund a discretionary addition; it may not be possible to deliver the original approach safely or lawfully after new evidence appears.

The companion article on managing an agency without micromanaging provides the wider governance context. Commercial treatment also depends on whether the engagement is fixed price, time and materials or outcome-based.

Warning patterns

No impact assessment. “It will not take long” is an assertion. Ask what changes and which evidence supports the estimate.

Vague explanations for movement. “More complex than expected” needs a named discovery, date, consequence and response.

No cumulative baseline. Individually approved changes never reach the main budget and plan.

Work begins before decision. The request becomes difficult to reverse and the sponsor is asked to ratify it.

Every change adds. The programme never removes lower-value work.

Learning is treated as supplier fault or client entitlement. Defensive positions prevent the joint decision the work needs.

The article on mid-project health shows how unresolved change appears among broader delivery signals.

Learn from the change pattern

Review changes by cause. Repeated undocumented content variation may show weak discovery. Frequent late stakeholder additions may show poor participation. Many regulatory changes may show an assurance owner joining too late. Repeated supplier surprises may show inadequate technical access or capability.

Use that evidence to improve the rest of the programme and future procurement. Avoid declaring every change a success simply because the final product benefited.

Report change as part of forecast, not in a separate register nobody reconciles. The sponsor should be able to see approved budget, used contingency, current completion evidence and remaining exposure in one view. Suppliers should also distinguish discovery that refines an estimate from rework caused by an avoidable error; the commercial treatment may differ even when both alter the plan.

That's it. Four steps. The whole thing fits on a single page. If you want the scope change protocol as a one-page decision template - covering the four-step process and the impact assessment format - download it here below.

If you want the scope change protocol as a one-page decision template - covering the four-step process, the impact assessment format, and the three decision options - download it here below. It's designed to be used the moment a scope change is identified, not filed away in a project governance folder nobody opens.

Scope change is neither failure nor virtue. It is new information or a new request that consumes choices. A mature project makes those choices explicit, protects the intended outcome and knows when learning should change the plan.