Every consultant has the change-order conversation. A client asks for something adjacent to what you agreed on, you weigh whether it is small enough to absorb, and either you absorb it or you have an awkward discussion about scope.
I ran that playbook for years and it never worked well. The problem is that by the time you're having the conversation, you have already lost. The client has an expectation, you're the one introducing friction, and whatever you decide costs you either money or goodwill.
What changed things for me was noticing that scope creep isn't really a boundary problem. It's a diagnostic. The request tells you something specific about what the engagement is missing, and the useful move is to read it rather than defend against it.
What the request is actually telling you
When a client asks for something outside scope, there's a reason, and it's almost never that they are trying to get free work. In my experience, it's one of three things.
The original scope was wrong. You scoped a solution to the problem as described, and the real problem is adjacent. This is the most common case and it is your error more than theirs, because diagnosing the real problem was your job. When this happens, the correct response isn't a change order. It's to go back to the scope and say clearly that we defined this wrong, here is what I now think the problem is, here's what I would do instead. That conversation is uncomfortable and it's the one that saves the engagement.
Something changed on their side. A new priority, a new executive, a new constraint. The scope was right when written and is not now. This is a legitimate change order and it's the easy case.
Somebody internal is routing around a blockage. A person asks you for something because you are the only resource they can actually direct. This one looks like scope creep and is really an org chart problem. Doing the work will not help them and will make you the permanent workaround.
Those three require completely different responses, and the standard change-order reflex applies the same response to all of them.
What to protect
When scope does expand, and it will, the question is what you refuse to give up. My list is short.
The definition of done. If the engagement has a clear finish condition, protect it above everything, including the fee. An engagement without a defined end does not end, it decays, and both sides eventually feel bad about it. I would rather do less work with a crisp completion than more work that trails off.
The thing the engagement was actually for. Every project has one outcome that justified it. Additional requests dilute attention, and the failure mode is delivering six adequate things instead of the one thing that mattered. When I have to choose, I protect the primary outcome and let the additions go, explicitly and out loud, so it is a decision rather than a drift.
Your ability to say the unwelcome thing. This is the one people surrender first and it's the most valuable thing you have. If you have taken on so much work that the relationship depends on the client being pleased with you week to week, you have lost the independence they hired you for. A consultant who cannot deliver bad news is an expensive contractor.
What I don't protect: the exact deliverable list, the hours, the sequence. Those should flex. Being rigid about them is how you get a reputation for being difficult while still losing on the things that matter.
The mechanism that prevents most of it
The single change that reduced scope conversations for me was moving the definition of done from a list of deliverables to a list of decisions.
A deliverable-based scope invites expansion, because deliverables are visible and enumerable and there's always another one that would obviously help. A decision-based scope is naturally bounded: we're going to answer these four questions, and when they're answered with enough confidence to act, we're finished.
It also reframes what the client is buying. They aren't buying documents. They're buying the ability to make a decision they couldn't make before. When an out-of-scope request arrives, the test becomes obvious: does this help answer one of the four questions? If yes, it's in scope regardless of what the deliverable list said. If no, it is a new engagement, and that is a much easier conversation than arguing about hours.
On absorbing small things
I do absorb small requests, and I think the advice never to is wrong. Relationships run on some amount of unreciprocated generosity and refusing every twenty-minute favor makes you tiresome to work with.
The rule I use: I will absorb anything that doesn't change the shape of the engagement. A quick answer, a small extra analysis, a review of something adjacent. What I won't absorb is anything that adds a stakeholder, extends the timeline, or creates an ongoing obligation, because those aren't small even when the immediate ask is.
The tell is whether the request creates a second one. If doing this thing means someone will reasonably expect the next thing, it's not a favor, it's a scope change wearing a favor's clothes.
