Change Management in Project Delivery
A practical guide to change management in project delivery, covering the difference between change control and organisational change, a workable change control process, helping people adopt the change, and how to measure whether it landed.
Change control failures show up as scope creep and budget overrun. Adoption failures show up as a successful project that changed nothing. This guide covers both.
Quick answer: Two different disciplines share the name. Change control manages changes to the project's scope, schedule and budget. Organisational change management helps the people affected actually adopt what the project delivers. Projects need both, and confusing them is why organisations sometimes run rigorous change control and still deliver something nobody uses.
Two Things Called Change Management
Change control governs modifications to what the project will deliver; organisational change management addresses whether people will use it.
Change control: managing scope changes
A formal process for assessing requested changes to scope, schedule, budget or quality, and deciding whether to accept them.
It exists to make trade-offs visible. Every accepted change costs something, and change control is the mechanism that surfaces the cost before the commitment rather than after.
Organisational change: helping people adopt
The work of ensuring the people affected understand the change, are prepared for it, and actually adopt new ways of working.
This is where projects most often fail invisibly. The system is delivered on time and on budget, and six months later half the intended users have reverted to the old process.
Why projects need both
A project with strong change control and no adoption planning delivers exactly what was specified to people who ignore it.
A project with strong adoption work and no change control delivers something well-received, late, and over budget. Neither discipline substitutes for the other, and they are usually owned by different people — which is precisely why the gap between them is where problems live.
The Change Control Process
Step Activity Output Typical time 1. Raise Requester submits the change with reason
What should a change request include?
2. Log Record and acknowledge Numbered entry Same day 3. Assess Analyse impact on scope, time, cost, risk, quality Impact assessment 1–5 days 4. Decide Approve, reject, defer, or approve with conditions Decision recorded At next authority point
5. Update Amend the baseline, plan and communications Updated baseline Immediately after 6. Implement Deliver the change Completed work Per plan
Running Change Control That People Use
Change control works when it is fast, when impact assessment is honest, and when decisions happen at the appropriate level rather than all escalating.
Make it fast
If raising a change request takes two weeks to reach a decision, people will route around it with informal agreements — and you will end up with undocumented scope, which is the outcome the process existed to prevent.
Target a few days for routine changes. A simple form, a named assessor, and a standing decision point is enough. Where requests come through the project tool as tasks rather than through email, the log builds itself and nothing gets lost.
Assess impact honestly
The assessment is the value of the process. It should state plainly what the change costs in time, money and risk, and what else moves as a consequence.
Assessments that understate impact to make a change palatable destroy the process's credibility. The point is to inform a decision, and a decision made on optimistic information is not informed.
Decide at the right level
Not every change needs the sponsor. Define thresholds: the project manager decides below a certain impact, the sponsor above it, the board above that.
Escalating everything makes the process slow, which makes people avoid it. Delegating appropriately is what keeps it usable.
Helping People Actually Adopt the Change
Adoption depends on involving affected people before the design is fixed, finding a credible internal advocate, and supporting the first weeks after launch rather than only the launch itself.
Involve them before the design is fixed
The most common cause of rejected change is that the people affected first encountered it as a finished decision.
Involving them during design produces a better result — they know the edge cases and why the last attempt failed — and produces ownership. A change designed with a team is defended by that team; a change delivered to them is endured.
Find the credible advocate
Every group has someone whose opinion carries disproportionate weight, often not the most senior person.
A credible advocate explaining why the change makes sense achieves more than any volume of communication from the project. Equally, if that person thinks the change is wrong, understanding why is usually more valuable than working around them.
Support the first weeks, not just the launch
The period immediately after go-live is when people encounter the situations training did not cover, and when reverting to the old way is easiest.
Plan for it explicitly: available support, a visible route to report problems, and rapid fixes for the things that surface. This period costs more effort than the launch itself and determines whether adoption holds.
Measuring Whether Change Landed
Measure adoption rather than attendance, sustained use after support ends rather than initial use, and whether the intended benefit actually appeared.
Adoption, not attendance
Training completion tells you people attended. It tells you nothing about whether they use the thing.
Measure usage: how many of the intended users are actually working in the new way, as a proportion. That figure is uncomfortable and actionable in a way attendance never is.
Sustained use after the support ends
Usage during the supported period is inflated. The real test is four to six weeks after intensive support stops.
If usage drops sharply then, adoption did not happen — people complied while being watched.
Where your tooling shows active usage per team, this curve is straightforward to observe rather than guess at.
Whether the intended benefit appeared
The project existed for a reason. Did the thing it was supposed to improve actually improve?
This is measured months later and is routinely skipped because the project team has moved on.
Assigning benefit measurement to someone who remains — usually the sponsor — is the only way it reliably happens.
Common Change Management Mistakes
The three failures are running change control as an obstacle course, treating training as the whole adoption plan, and declaring success at go-live.
Change control as an obstacle
A process designed to discourage change achieves exactly that — visibly. Informally, changes still happen through side agreements, and the project ends with scope nobody documented.
The purpose is visibility of trade-offs, not prevention. A fast process that people use produces better control than a rigorous one they avoid.
Training as the entire adoption plan
Training teaches people how to use something. It does not address whether it fits their workflow, whether they believe it improves anything, or what they do when it fails at an awkward moment.
Training is one component of adoption work, not a substitute for the rest.
Declaring success at go-live
Go-live is the start of adoption, not the end of the project. The measures that matter — sustained usage, realised benefit — are visible weeks and months later.
Projects closed at go-live never learn whether they worked, which means the organisation cannot improve how it delivers change.
Frequently asked
What is change management in projects?
Two disciplines share the name: change control, which manages modifications to scope, schedule and budget, and organisational change management, which helps affected people adopt what is delivered.
What is the difference between change control and change management?
Change control governs changes to the project itself. Organisational change management addresses whether people will actually use the result. Projects need both, and they are usually owned by different people.
What should a change request include?
What is being requested, why, who is requesting it, and — after assessment — the impact on scope, schedule, cost, risk and quality, plus a recommendation and the decision taken.
Who approves project changes?
It should vary by impact. Define thresholds so the project manager decides small changes, the sponsor decides larger ones, and the board decides the largest. Escalating everything makes the process too slow to use.
Why do people resist change?
Most often because they were not involved, because the change makes their work harder in ways nobody asked about, or because a previous change was imposed badly. Resistance usually contains information worth hearing.
How do you measure change adoption?
By actual usage as a proportion of intended users, measured four to six weeks after intensive support ends rather than during it, and eventually by whether the intended benefit appeared.
How much scope change is normal?
Some is expected on any project of length — the point of change control is that it is visible and costed, not that it is zero. Persistent large changes usually indicate the requirements work was insufficient.
Sanju Shrestha is a SaaS content writer at Taskzin who explores smarter ways to manage work, organize priorities, and improve team performance. Her content covers productivity strategies, digital workflows, collaboration, and task management, with a focus on helping modern teams work more efficiently and stay aligned.
All posts by Sanju Shrestha
Comments