There's a moment most account managers and project managers know well.
The client is on a call, the project is going fine, the relationship feels good… and then they mention something new. A version for another market. An extra cut for a different platform. A small adaptation, they say. Shouldn't take long.
And you feel it: that split-second calculation. “Do I flag this as out of scope and risk making things awkward? Or do I just say yes, keep the energy positive, and figure it out on the back end?”
Most of the time, you say yes. And that's not because you're a pushover. It's because you care about the relationship, you want to be seen as collaborative, and raising a cost conversation in the middle of a perfectly good client call can feel wildly disproportionate to the ask. So the work gets absorbed, a task gets added to the board, and the team adjusts. Nobody makes a fuss.
Then it happens again the following week. And the week after that.
By the end of the project, the team has delivered significantly more than was agreed, the margin has quietly disappeared, and someone is trying to figure out how to write a retrospective that explains why the project ran long without making it sound like the client's fault.
This is scope creep. And it's worth understanding why it keeps happening before trying to fix it.
Scope change and scope creep are not the same thing
First, a distinction worth making, because the two get lumped together surprisingly often.
Scope change is normal. Clients learn things as a project develops. They see the early creative and realise they want to go in a different direction; a new market opportunity comes up; a stakeholder joins late and has a strong opinion. That's all part of how creative projects work. A good agency should be able to handle change. In fact, some of the best work comes from being able to respond to it.
Scope creep, on the other hand, is what happens when that change isn't actually handled. There's no formal approval, no adjustment to the budget or timeline, and often not much visibility for anyone involved. The work just grows quietly, one request at a time, until the project is already off the rails and everyone is wondering when exactly that happened.
The difference isn't the change itself. It's what happens after the change is requested. Scope change, managed properly, is just part of the work. Scope creep is what it looks like when nobody stops to deal with the change properly.
The goal, then, isn't to prevent clients from asking for things. It's to have a defined way of handling those asks: the request gets documented, the cost and timeline implications are worked out, and both sides agree on what's happening before anyone starts doing the work.
Why scope creep happens: there's no process for handling change
Most agencies don't have a particularly clear way of handling scope changes.
When a client makes a new request halfway through a project, what happens next depends on who's on the call, what the relationship is like, how much time there is, and how the request was framed. There isn't usually a standard step that the request has to go through before it quietly becomes another task.
The result tends to look like one of two things, both of them frustrating in their own way.
- The request gets actioned without being properly documented.
The client suggests a creative direction mid-project - not a confirmed deliverable, just an idea worth exploring. The team spends two days on it, but then the direction gets dropped and a new one takes its place.
Nobody documents that the exploration happened or logs the time against the project, which makes it difficult to raise later because there's nothing concrete to point to. No deliverable, no record, just a couple of days of work that quietly disappeared into something that never became anything.
- Or the request gets noted but the commercial conversation gets skipped.
Someone sends a follow-up email confirming the new deliverable, which is a good start, but nobody talks about what it costs or what it does to the timeline. So there is a record of what was asked, but not what saying yes actually meant.
When the invoice arrives with a line item the client wasn't expecting, or the delivery date moves and nobody knows why, the written record doesn't help much. The agency documented the what without documenting the so what.
In both cases, the outcome is basically the same: work gets added to the project without the cost and timeline being renegotiated at the time of the request. And renegotiating later, once the work is already done or well underway, is about the hardest version of that conversation to have.
How to build a change control process
An operational win every agency needs is a change control process. It doesn't have to be complicated or formal to the point where everyone starts quietly resenting it. At its core, it's just a defined way of handling new requests so they get looked at before they become work. Three steps tend to do most of the heavy lifting.
- Submission: a formal way for new requests to be raised.
Rather than having requests arrive casually on calls or buried in Slack, there should be a clear place for scope changes to be submitted. So when something new comes up, the response becomes, “Let's put that through as a change request,” rather than, “Sure, we'll get on it.”
That small distinction matters. Calling something a change request, rather than treating it like just another task, signals to both sides that this is new work.
It also means the request gets documented somewhere consistent - the brief, a shared change log, a dedicated column on the project board, whatever works for the agency. The tool matters less than the habit: when something new comes up, it goes there before it becomes work.
- Review: actually assess what the change means before agreeing to it.
This is the step most agencies skip. They go from request to yes or no without really stopping to work out what they're agreeing to. Instead, always ask:
How long will it take?
What does it affect in the existing plan?
What does it cost?
Who needs to be involved?
It doesn't have to become a week-long feasibility study. Even a short pause to look at the implications means the decision is being made with some actual information behind it, rather than an optimistic estimate made live on a client call.
- Decision: accept, defer, or decline - and write it down.
Once the request has been assessed, somebody needs to make a clear decision and document it. If it's accepted, the new deliverable gets added to the scope and the cost and timeline implications are agreed before work begins. If it's deferred, it's noted for a future phase. If it's declined, the reason is recorded.
The important thing is that both sides know what was decided. Otherwise you can end up three weeks later with two people operating on completely different versions of what was agreed, which is not a particularly fun place to be.
Communication habits that prevent scope creep
A few communication strategies make the change control process easier in practice.
Anchor the conversation in the brief, not in the ask.
When a client makes a new request, the most useful response isn't necessarily yes or no. It's something like, “Let me check how that sits against what we have in the brief.”
That gives everyone a moment to pause and look at the request in the context of what was actually agreed. You're not shutting the idea down, and you're not agreeing to it either. You're simply putting it next to the existing scope and figuring out what it means.
Separate the creative response from the commercial one.
When a new request comes in, it's tempting to say, “Yes, great idea - here’s how much that will cost you,” all in the same breath. The problem is that the cost can then sound like a reluctant limitation on something the client has just got excited about.
Instead, respond to the creative merit first. Acknowledge why the idea makes sense, then deal with the scope implications separately and clearly: “That's a strong direction for the campaign. In terms of what it means for the timeline and budget, here's what we're looking at.”
The client gets to feel heard before they hear the complication, which tends to make the whole conversation feel a little less adversarial.
Have the numbers ready before the call, not during it.
One reason scope conversations feel awkward is that they often require an estimate on the spot.
“I think that would take… maybe a couple of days? And probably around… I'm not sure exactly.”
That uncertainty is hard to avoid when you're trying to calculate something in real time, but it doesn't exactly make you sound confident about the number you're about to put in front of the client. It also gives the client room to start negotiating before you've really had a chance to think it through.
If you know a client tends to make requests on calls, come prepared with rough estimates for the most likely additions. Being able to say, “An additional market adaptation typically takes two to three days and runs at X,” changes the dynamic of the conversation quite a bit.
Frame it as protecting the project, not the agency.
The scope conversation lands differently when it's positioned around what's good for the work rather than what's good for your margin.
“I want to make sure that if we add this, we can do it properly, which means building the time in rather than squeezing it into an already full schedule” is a very different conversation from “we need more money for that.”
You're not pretending the commercial implication doesn't exist. You're explaining why it exists. And most clients who care about the quality of the work will understand that.
Put agreed scope changes in writing, always.
Verbal agreements about scope feel perfectly fine in the moment. Three weeks later, when nobody remembers exactly what was said, they become a problem.
A quick follow-up email after a call - “Just to confirm, we've agreed to add the German market adaptation, with an updated delivery date of X and an additional cost of Y” - creates a change record that protects both sides. It's not bureaucracy for the sake of bureaucracy. It's just a way of making sure everyone is working from the same version of events.
What good habits can't fix on their own
Effective communication genuinely helps. But it has a ceiling, and that ceiling is the amount of discipline any individual can maintain across multiple simultaneous projects, under deadline pressure, while also trying to keep a live client relationship running smoothly.
The account manager who should be having the change-control conversation is probably also managing four other client relationships, answering emails, trying to preserve goodwill, and making real-time judgment calls about which requests are worth raising and which ones aren't worth making a fuss about.
Some of those calls will go wrong. Some requests will slip through. Some costs will get absorbed that shouldn't.
Good communication can reduce the frequency of scope creep, but it doesn't remove the conditions that make it easy for scope creep to happen in the first place. This is where structure matters more than individual skill. Not because the people are failing, but because a process that depends on someone making the right judgment every single time is always going to be less consistent than one that makes the right thing the default.
Habits require maintenance. Systems run on their own.
The brief as your change control process
Every project starts with a brief. And the brief, in theory, is exactly where a change control process should live. It defines what the project is: the deliverables, the timeline, the scope. It's the document both parties agreed to. When something new comes up, it's what everyone can return to. When scope changes, it's where that change can be formalised.
In theory.
In practice, most briefs are written once and never looked at again. They set the initial direction, everyone nods, and then the real work begins… and the brief quietly recedes somewhere, overtaken by task boards, Slack threads, files, meetings and the general momentum of the project.
Part of the reason this happens is structural, but it's also about how the brief is perceived. In most agencies, the brief is a project initiation document. It gets the project started. Once it has done that job, it recedes - not because anyone decided to ignore it, but because the work now lives somewhere else entirely.
The tasks are on a board. The files are in a library. The conversations are in Slack. The brief is two tabs away in a folder that nobody has much reason to open. So when a new request comes in halfway through the project, measuring it against the brief doesn't naturally occur to anyone.
The brief isn't where the work is. It's where the work came from.
But what if the brief itself were the change control process?
Not a separate form the client has to fill out. Not a change log that runs alongside the project and gets updated when someone remembers to update it. The brief - the same document that started the project - becomes the place where every scope change lands, gets assessed and gets agreed.
Here's what that looks like in practice.
Every task on the job board traces back to a deliverable in the brief. If it's not in the brief, it doesn't exist as work. So when a client makes a new request, the natural response is, “Let's add that to the brief.”
The brief reopens. The new deliverable gets specified. The cost and timeline implications are discussed before anyone starts work. Both parties agree. The brief gets updated. Only then does the work begin.
What just happened is the full change-control process - submission, review, decision - without another system, another form or another layer of overhead. It happened as part of updating the document the whole project already runs from. The structure made it the obvious next step, so nobody had to remember to enforce it.
Adaptations are a good example of where this matters most. Towards the end of a project, a client might ask for a version of an existing asset adapted for a different market, format or platform. Adapts feel small - they're not being made from scratch, after all - and that's exactly why they tend to get absorbed without much of a conversation.
But an adapt still takes time, and time has a cost.
When the brief has a specific place for adaptations, where each one is added as a new deliverable linked to the original, it becomes much easier to say yes while still having the cost and timeline conversation. The client gets their adaptation. The agency gets a record of what was agreed. Nobody has to choose between being responsive and protecting the margin.
Done this way, the brief stops being a document that simply initiated the project and becomes a living record of what the project actually is, updated whenever scope legitimately changes and reflecting the decisions made along the way. By delivery, it's an accurate account of what was made, when it was made and at what agreed cost. That's useful for client relationships, margin analysis, and the inevitable moment when someone asks, “Weren't we supposed to also get a version for print?”
This is exactly how QuickProof, a creative workflow management software, is built.
The brief is the source of all work: every task, deliverable and revision traces back to it. When a client requests something new, the brief reopens first. The cost and timeline conversation happens before anything begins, rather than after the work is already underway. The person managing the client relationship doesn't have to be the one who remembers to bring it up. The system does it for them.
A brief is only as good as its authority
All of this only works if the brief is actually where decisions happen, rather than simply where the project started.
If new work can be added through a Slack message, a task card or a quick nod on a call, it will be. That's just how work moves when people are busy. The brief needs to be the place new work comes through first.
That means two things in practice.
First, every task on the project needs to trace back to something in the brief. If it isn't in the brief, it isn't in scope.
Second, when a client asks for something new, the response is always the same: let's put it in the brief first. Not after. Not eventually. Before anyone starts working on it.
When that's how things work, the brief earns its authority naturally. It stops being the document that kicked the project off and becomes the document that runs it. And when something changes - as things inevitably do - there's one clear, shared place to deal with it.
The team doesn't need to get better at saying no.
The system makes the conversation happen.
