Change Management Explained: Controlling Scope Without Freezing Delivery

Change management in a project context is the process by which the agreed scope, schedule or budget is deliberately altered. Its purpose is not to prevent change — change is normal, and a project that cannot absorb any is a project that will deliver the wrong thing precisely on time.

Its purpose is to make sure change is a decision rather than an accumulation.

The two failure modes sit at opposite ends. A process too light means scope grows by a series of small favours, none of which was ever costed, and the project is late for reasons nobody can point to. A process too heavy means people route around it, changes happen informally, and the documents stop describing the system. The second is more common, and more damaging, because it produces the appearance of control.

What counts as a change#

Anything that alters what was agreed in the Project Charter or the baselined requirements: new functionality, altered behaviour, a different date, a different budget, a different quality standard.

What does not count: clarifying an ambiguous requirement, fixing a defect against an agreed requirement, or a decision about implementation approach that leaves the requirement unchanged.

That boundary is worth writing down explicitly, because arguing about which side something falls on consumes more time than assessing it would. When it is genuinely unclear, the useful question is whether the original agreement would have cost more if it had said this in the first place.

The process, at the size it should be#

Raise. Anyone can. What is requested, why, who wants it, how urgent.

Assess. The honest part. Effort, cost, schedule impact, effect on other work, risks introduced, and what will not happen if this does. That last element is the one usually omitted, and it is the one that makes the decision real: on a fixed-capacity project, every addition is a substitution.

Decide. By whoever has authority at that size — see below. Approve, reject, or defer with a date.

Record. What was decided, by whom, when, and on what basis. The record is what stops the same request returning in three months as though it were new.

Update. Requirements, plan, RTM, test scope, budget. A change approved but not reflected in the artefacts is the mechanism by which documents and reality diverge.

Delegated authority is what keeps it usable#

A single board approving everything creates a queue, and a queue creates workarounds. Set thresholds:

Most requests are small. If the small ones move in a day, the process retains credibility for the large ones — which are the ones that genuinely need scrutiny.

🔴 A process that takes three weeks to approve a two-hour change will be bypassed, and the bypassing will not be visible. You will have a tidy change log and an untracked project.

Assessing impact honestly#

The estimate people give under pressure is the effort to write the code. The real cost includes retesting what it touches, updating requirements and traceability, documentation, regression risk, the disruption to whatever it displaces, and the coordination.

Two questions expose most of it:

What does this displace? If capacity is fixed, adding something removes something. Naming what is removed converts an abstract approval into a real trade-off, and it changes decisions.

What has to be retested? Frequently the largest hidden cost, especially late in a project when the regression surface is at its widest.

Where the honest answer is "we do not know yet", say that and offer to assess properly. An estimate invented in a meeting becomes a commitment by the end of it.

Scope creep, and where it actually comes from#

Rarely from formal requests. It arrives as small clarifications that expand behaviour, as undocumented conversations between a stakeholder and a developer, as "while you are in there", and as requirements that were always ambiguous being resolved consistently in the more expensive direction.

Three things reduce it:

A written out-of-scope list, so declining is a reference rather than a negotiation.

One route in. Requests arriving directly to individual developers bypass assessment entirely, and the developer is in the worst position to decline.

Clarifications recorded. When an ambiguity is resolved, note which way and why. Otherwise the same ambiguity is resolved differently by someone else next month.

In agile delivery#

The mechanics differ; the principle does not. Where scope is expected to flex within a fixed capacity, reordering the backlog is normal and needs no ceremony — the product owner decides.

Formal change control still applies to the things that were actually fixed: the budget, the date, the outcome the project was funded to deliver, contractual commitments. The common error is assuming that because backlog priority is flexible, the charter is too. Those are different levels, and conflating them is how an agile project delivers something nobody authorised.

Why processes fail#

Too slow. Covered above, and the root of most others.

Assessment done by the person who wants the change. Optimism is not dishonesty, but it is predictable.

No rejections, ever. A process that approves everything is a recording mechanism. If nothing is ever declined, either the requests are unusually good or the process has no authority.

Approved changes not reflected in the artefacts. Requirements, tests and plan drift from what was agreed, and by the end nobody can say what the project committed to.

No visible cumulative position. Fifteen individually reasonable changes have added eleven weeks, and nobody has said so because each was assessed alone. Report the cumulative effect at every review — it is the number that matters and the one nobody volunteers.

A realistic starting point#

A one-page form: what, why, requested by, assessed effort and cost, schedule impact, what it displaces, risks, decision, decider, date. Delegated thresholds so small changes clear in a day. A single register showing open and decided changes with cumulative schedule and cost impact. One route for requests to arrive.

That is enough to keep a project honest without becoming the reason people stop telling you things.

FAQ#

Is fixing a defect a change?#

Not if it is a defect against an agreed requirement — that is delivering what was already promised. It becomes a change when the "fix" alters agreed behaviour, or when the requirement turns out never to have been specified. Reclassifying missed requirements as defects to avoid a change conversation is a habit worth resisting; it destroys trust in both directions.

Who should sit on a change board?#

For material changes: the sponsor, the project manager, and someone who can assess technical impact — plus the business owner of the affected area when relevant. Small boards decide; large boards discuss.

How do we handle urgent changes?#

Define an emergency path in advance: who can approve, what evidence is needed, and the requirement that it is documented within a fixed period afterwards. Emergencies happen. Undefined emergencies become the normal route.

What if the sponsor keeps approving everything?#

Then present the cumulative position rather than individual requests. Fifteen approvals, eleven weeks, and here is what will not be delivered. Sponsors approve individually reasonable things; the aggregate is usually not what they intended, and they are generally grateful to see it.

Do agile projects need change control?#

For the backlog, no — reprioritising is the normal operation. For the budget, the date, the contracted commitment and the charter's outcome, yes. Backlog flexibility does not extend to the things the project was authorised on.

Should we charge for changes on internal projects?#

Charging in real money is usually unhelpful. Charging in schedule and displacement is essential: this adds two weeks, or removes that. A change that appears free will be requested freely, and the cost is paid in dates nobody agreed to move.

How much documentation does a change need?#

Enough to reconstruct the decision later: what, why, impact, who decided, when. One page. The temptation is to expand the form until it deters requests — which works, and produces undocumented changes rather than fewer changes.

Related Articles#

Baseline in the Project Charter, keep requirements aligned through the BRD and FRD, maintain coverage in the RTM, and track consequences in the Risk Register.

What else is coming for Change Management