Handling Change Requests Without Losing Control of Scope

Changes are normal. Unpriced changes are the problem

Clients change their minds because they learn things during a project. They see a first draft and realize what they actually need. A competitor launches something. A new manager joins with different priorities. None of this is bad behavior, and a team that treats every change as a fight will wear out its clients quickly.

Scope creep happens when changes are absorbed without anyone deciding to absorb them. Each one seems too small to discuss, so it slips into the work. After a dozen of them, the project is late and over budget, and nobody can point to the moment it went wrong.

The goal of a change-request process is not to block changes. It is to make each one a conscious decision, with a known cost, that both sides agreed to in writing. That turns "can you just..." into a normal part of working together.

You can't spot a change without a baseline

A change is a difference from something. If the original scope is vague, every request becomes a debate about whether it was "already included."

Project management textbooks describe a scope statement as the document that sets out the project scope, the major deliverables, the assumptions and the constraints. For a freelancer or small agency, that can be a single page in the proposal. What matters is that it answers these questions in plain words:

• What will be delivered? List the deliverables by name: "five-page marketing website", "logo in primary and secondary versions", "eight blog articles of about 1,500 words".
• What is explicitly not included? Exclusions prevent more arguments than inclusions. "Copywriting is provided by the client" or "does not include e-commerce" closes off whole categories of later requests.
• What assumptions are you making? "Client provides final copy before design starts" is an assumption. If it turns out to be false, that is a change.
• How many rounds of revision are included? Revisions within the agreed direction are not change requests, but a new direction is. Defining this up front is covered in our guide to setting revision limits.

Once a baseline exists, a change is anything that adds to it, removes from it or alters it after it was agreed.

A four-step change request

A good process fits on an index card. Use the same four steps every time, so the client learns the pattern.

1. Capture it in writing

When a client asks for something new, write it down in a sentence or two, in their words if possible, with the date and who asked. Do this even when the request came in a call. You are not being bureaucratic; you are making sure you understood it.

2. Assess the impact

Before you answer, work out what the change really means. Textbook change control looks at effects on scope, schedule, cost, resources and quality. For a small team, three questions cover most of it:

• How much extra work is it? Include the knock-on work, not only the obvious part. Adding a page to a website can mean new navigation, new copy, extra testing and another review.
• What does it do to the deadline? Some changes fit around other work. Others push everything back.
• What does it replace or put at risk? If the budget or date is fixed, the change has to displace something else.

3. Decide together

Send the client a short summary: what the change is, what it costs, how it affects the timeline, and the options. Then ask for a clear answer. The decision belongs to the client; your job is to make the trade-off visible.

4. Record the outcome

Whether the answer is yes, no or later, write it down in the same place as the original request. Keep the declined ones too. A log of changes that were considered and rejected is as useful as a log of the ones that went ahead, because it shows that the conversation happened.

Estimating a change quickly and honestly

Clients usually want an answer fast, and you don't want a small request to wait a week for a quote. A few habits help:

• Estimate in ranges for small changes. "Between two and four hours" is honest and quick. Agree to bill actual time within the range.
• Separate the work from the waiting. A change that needs new assets from the client may take little effort but add days of delay. Say so.
• Re-check the plan, not just the task. Ask what else moves. A late change to the brand colors may ripple into every page you have already built.
• Don't negotiate against yourself. Give your real estimate first. If the client wants a smaller version, define the smaller version and estimate that.

If a change is large enough that you need time to estimate it properly, say when you will have an answer and keep that promise.

Saying yes with terms

Most change requests deserve a yes. The skill is in attaching the right terms to it. Here are four ways to say yes, with wording you can adapt.

Yes, at an added cost:

"Happy to add the team page. It's outside the original scope, so it would be an additional [amount] and would move the launch date by about three working days. If that works, reply to confirm and I'll add it to the plan."

Yes, as a swap:

"We can add the team page within the current budget if we drop the second case study page. Same total, same launch date. Which would you prefer?"

Yes, but later:

"Good idea. To protect the launch date, I'd suggest we build it as a short phase two right after launch. I'll send a separate estimate this week."

Not now, with a reason:

"I'd recommend we don't change the navigation at this stage. Pages two to five are already built on it, so it would mean reworking most of the site. If it's important, I can estimate what that would involve."

Notice that none of these responses is defensive or apologetic. They state the facts, offer options and leave the decision with the client.

Keep a change log

A change log is a running list of every change request on the project. It is your memory when the invoice is questioned, and the client's memory when they wonder why the date moved. Project management guidance suggests tracking each request through its life, from submission through analysis and decision to the point where it becomes part of the plan. For a small team, these columns are enough:

#	Date	Requested by	Change	Estimate	Effect on deadline	Decision	Decided by
1	3 Mar	Head of marketing	Add team page	6 hours	+3 working days	Approved	Client lead
2	9 Mar	Client lead	Change navigation labels	1 hour	None	Approved, goodwill	Client lead
3	14 Mar	Sales lead	Add live chat widget	10 hours	+1 week	Moved to phase two	Client lead

Keep the log where the client can see it. That visibility is what turns the log from a weapon into a shared tool.

Putting the process into your tools

You don't need special software for change control, but it helps when requests, estimates and decisions sit in one place instead of across inboxes. In Ayebridge, a typical flow looks like this:

1. The client raises the change as a comment on an update or approval in their portal, or you write it up from a call.
2. You post a short update describing the change, the estimate and the effect on the timeline.
3. For a priced change, you create a quote document with the extra line items and share it in the portal. Quotes in Ayebridge are documents only, and you set their status by hand, such as "Accepted". Ayebridge doesn't process payments.
4. You ask for a decision with an approval request on a text deliverable, such as "Change 01: add team page, 6 hours, launch moves to 21 March". The client's answer is stored with their name, email and the date and time, and can't be edited afterwards.

That gives you a change log that writes itself, with the decision attached to each entry.

When a change is really a new project

Sometimes the requests add up to something different from what you agreed to build. Signs to watch for:

• The client's goal for the project has changed, not just the details.
• The changes would take longer than the remaining original work.
• You find yourself redesigning the foundation rather than adjusting what sits on top of it.

When that happens, stop patching. Suggest closing the current phase at a sensible point, getting sign-off on what is finished, and scoping the new direction as its own project with its own proposal. Clients generally appreciate the honesty, and you avoid a project that never seems to end.

The short version

• Write down the baseline: deliverables, exclusions, assumptions and included revisions.
• Treat every change the same way: capture, assess, decide, record.
• Estimate honestly and quickly, including the knock-on effects.
• Say yes with terms: added cost, a swap, a later phase or a reasoned "not now".
• Keep a change log the client can see, including declined requests.
• When the changes add up to a new direction, scope a new project.

A calm, predictable change process makes you easier to work with, not harder. Clients know that any request will get a fair answer, and you know that every hour of extra work was agreed to before it started.