What is Change Management?
Change Management
Change management is a controlled process for approving and implementing changes to a project's scope, timeline, or budget, so changes don't quietly derail delivery.
Change management, in a project context, is the structured process for evaluating, approving, and implementing changes to the agreed scope, timeline, or budget. It's the mechanism that prevents every new client request from silently becoming unplanned work.
Note: change management also has a broader meaning in organizational context (managing how teams adapt to major organizational shifts). This article focuses on the project management definition.
Every project encounters change. Clients discover new requirements. Technologies turn out to work differently than expected. Business priorities shift. Change is inevitable. The problem isn't change itself but uncontrolled change that erodes budget and timelines without anyone explicitly deciding to accept that cost.
The Change Control Process
A formal change control process has five steps:
- Request: anyone can request a change; document what's being requested and why
- Impact assessment: project manager evaluates how the change affects scope, cost, and timeline
- Decision: designated approver reviews the impact assessment and approves, rejects, or defers
- Implementation: if approved, update the project plan, scope document, and budget accordingly
- Communication: inform all affected parties of the approved change and its implications
What a Change Request Should Document
| Field | What to capture |
|---|---|
| Requester | Who is asking for the change |
| Date | When the request was submitted |
| Description | What change is being requested |
| Reason | Why this change is needed or desired |
| Impact on scope | What additional work is required |
| Impact on cost | Additional budget needed (if any) |
| Impact on timeline | Days or weeks added to the schedule |
| Decision | Approved / Rejected / Deferred, with date and approver |
Change Management for Agencies
For agencies, change management is primarily about scope: protecting the agreed deliverables from "just one more thing" requests that accumulate into significant unplanned work.
The change control threshold determines what goes through the formal process. A common approach: changes that require 2 or more hours of work trigger a change request. Smaller tweaks are absorbed. This prevents process overhead for minor adjustments while ensuring significant scope changes are explicitly priced and approved.
The change request itself can be simple, such as a short email or a line in the project board noting: "Client requested X. Impact: 6 hours / $900. Client has approved via email dated [date]." That documentation protects the agency if billing is disputed later.
Change Request Template for Agencies
A change request form doesn't need to be complicated. The goal is to make the impact of the change concrete before approval. When a client sees that adding one feature costs $2,400 and 5 days, they make a different decision than when the change was described abstractly.
| Field | What to include | Example |
|---|---|---|
| Change reference | Sequential number for tracking | CR-007 |
| Project name | Full project name | Harborview Legal: Website Redesign |
| Date submitted | Date of this change request | July 14, 2026 |
| Requested by | Who's asking for the change | Sarah Chen, Managing Partner |
| Change description | What specifically is being requested | Add a search and filter function to the case studies page |
| Scope impact | What work is added or changed | New UI component, back-end filter logic, QA for new functionality |
| Hours estimate | Additional hours required | 16 hours (Designer: 4h, Developer: 10h, PM: 2h) |
| Cost impact | Additional cost at agreed rates | $2,400 (16 hours × $150 blended rate) |
| Timeline impact | Effect on project schedule | +5 business days; launch moves from Sep 15 to Sep 22 |
| Approval required from | Who must sign off | Sarah Chen (client), PM (agency) |
| Status | Current state | Pending client approval |
Pricing Change Requests: How to Calculate
The most common mistake when pricing a change request: estimating only the direct labor hours and forgetting indirect costs. A change that looks like 8 hours of development often involves 12+ hours when you account for everything it touches.
Start with a complete task breakdown. Every change request involves at least two types of work: the work itself and the overhead of managing the change. PM time to write the change request, coordinate with the team, and update the project plan is real work. Include it.
Consider downstream effects. Does the change require retesting work that was already complete? Does it touch components the client signed off on that will now require re-approval?
Get input from everyone who will touch the change. A developer who estimates '8 hours' without involving the designer and PM has produced an underestimate.
Present the change request cost with a breakdown the client can follow: 'Design: 4h × $120 = $480. Development: 10h × $160 = $1,600. PM: 2h × $130 = $260. Total: $2,340.' Itemized pricing is more credible and harder to dispute.
- Include PM overhead in every change estimate: it's real work, not free
- Check for downstream effects: retesting, client re-approval, third-party coordination
- Get estimates from everyone who touches the change. Don't let one person estimate all disciplines
- Add 15-20% contingency for changes with unclear requirements or unfamiliar tech
- Present itemized pricing: discipline + hours + rate = line total
Change Management Culture: Getting Clients On Board
The cultural challenge of change management is getting clients to accept that scope changes have a cost when they're accustomed to agencies absorbing them.
The foundation is setting the expectation before the project starts. At kickoff, explain the change process as a feature: 'When you have a new idea during the project, and you will, that's normal, we have a clean process for evaluating it and deciding together whether to include it and on what terms. That process protects you from surprise costs and protects us from unbounded scope.'
When a client pushes back on a change request ('but it's such a small thing'), be specific and consistent. 'I understand it seems straightforward. Here's the breakdown of what it actually involves and why the cost is $1,200.' Don't apologize for charging for work; explain what the work is.
Make the process fast. Target 48-72 hour turnaround from change request submission to client receiving a priced change order. Slow process trains clients to avoid it.
Track change requests over time. If a client submits 8 change requests on a single project, the original scoping process failed.
- Introduce the change process at kickoff as a benefit, not a bureaucratic requirement
- Frame it: change management protects both sides from unbounded, unpredictable costs
- When clients resist: itemize the work involved; don't apologize, explain
- Target 48-72 hour turnaround on change order pricing: slow process trains clients to avoid it
- Track change volume per project: high frequency signals scoping or discovery gaps
In Melororium
Manage project changes in Melororium
Common mistakes with change management
What teams get wrong most often, and what to do instead.
- 1
No formal change request process
Letting scope changes happen through casual Slack messages. Without a process, changes accumulate invisibly instead of getting evaluated.
- 2
Approving changes without pricing them
Saying yes to a change before estimating its cost and time impact. Every unpriced change is a future budget overrun waiting to surface.
- 3
One person approving changes alone
Letting any team member accept a client's change request on the spot, instead of routing it through whoever owns budget and timeline.
- 4
Not logging rejected or deferred changes
Only tracking approved changes. A record of what was declined protects the team when the same request resurfaces later.
Frequently asked questions
What's the difference between a change request and a bug fix?
A bug fix corrects something that was supposed to work but doesn't. A change request adds or modifies something beyond what was originally specified. If the homepage navigation was specified as 5 items and is delivered with 5 items but one link is broken, that's a bug. If the client now wants 7 items, that's a change request.
Can you say no to a change request?
Yes, but framing matters. 'We can't do this' closes the conversation. 'We can do this as a change order for $600 and 3 additional days, or we can swap it for X from the current scope at no extra cost' gives the client options and protects the project.
What if the client refuses to go through change control?
This is a relationship conversation, not just a process conversation. Explain why change control protects them: it ensures the original commitments are met and new requests are delivered properly, not rushed into existing scope. A client who consistently bypasses change control is a risk to project profitability.
