When the client asks for “just a bit more”: how an FDE reads the SOW to decide what is in scope

Picture this: in week three of a deployment, the client’s head of operations messages you. “The ticket-classification agent is working well. While you’re at it, could it reply to customers too? Shouldn’t take long.” It sounds like praise. It is actually a scope decision, and you are the one who has to make it.

Nod it through and the project quietly grows. Brush it off and you become the rigid vendor the client deliberately avoided when it chose an FDE team. Handling this well doesn’t take a silver tongue. It takes knowing how to read a SOW and having a test you can apply again and again.

Creep and discovery look alike from the outside

Tandem defines scope creep as work that grows while time, cost or resources do not change to match. Discovery is the opposite: the scope becomes clearer as you understand the client better. Both start with the same sentence, “we’d like to add this”, which is why they are so easy to confuse.

The risk runs in both directions. Call everything discovery and unnamed work slowly eats your margin. Call everything creep and, as Tandem warns, you force a client into a standard mould when they chose you precisely because you were willing to build something specific to them.

Tandem also separates two terms that are often used interchangeably. A change request is the client asking for something outside the agreed scope. A change order is the formal amendment, priced and approved. Creep is when a request skips the change order and the work gets done anyway.

Two questions to ask before you answer the client

Tandem offers four tests for telling creep from discovery. Two of them any FDE can use on the spot at the client’s site. The “goal” test asks: does this request clarify an outcome the client has already bought, or does it add a new one?

The “record” test asks: can you point to what was in scope, what was said and what was delivered?

This test only works if you have a record: the SOW, meeting notes, handover notes. Without one, every scope argument comes down to one person’s memory against another’s.

That is why the SOW is something to read closely from the kickoff, not something to open only when a dispute starts. Scope is usually defined in the SOW or the contract. A good SOW also sets out the process for handling scope changes, and may even classify the types of change, so that both sides agree in advance when a change order is needed.

One SOW, two requests

Take a hypothetical SOW to practise on. The in-scope section reads: “The agent reads email tickets, assigns each to one of five categories, and routes the ticket to the right team.” The out-of-scope section reads: “Drafting or sending replies to end customers.”

First request: the client wants to split the “payments” category into “refunds” and “invoices”, because those are two different teams. Goal test: the outcome the client bought is routing tickets to the right team, and splitting the category routes them more accurately, so this is clarification. Record test: the SOW says “the right team”. Verdict: discovery.

Second request: the “let the agent reply to customers” message. Goal test: replying to customers is a new outcome, not just more accurate classification. Record test: the SOW states plainly that this is out of scope. Verdict: a change request, and it has to become a change order before anyone starts work on it.

Even with the first request, don’t just do the work quietly. FDE Academy advises turning every significant scope change into a short written summary. It only needs to be this long:

Scope change summary — [date]
Request: split the "payments" category into "refunds" and "invoices"
Classification: discovery — clarifies the "route to the right team" goal in the SOW
Impact: labels and evaluation examples for 1 new category
Confirmed by (client side): [name]

For the second request, Tandem advises opening a change order before work begins, with a draft already written. Your reply to the client might go something like this:

“Good idea, but it’s a new outcome compared with the current SOW. I’ll send you a draft change order this afternoon setting out the scope, the impact on the timeline and what needs your approval. Once it’s approved, we’ll get started straight away.”

That reply is not a refusal. You are saying yes, just in a controlled way.

How do you make “yes” a safe answer?

FDE Academy argues that the fix is not getting better at saying no, but building a process solid enough that saying yes carries no risk. Refusing every new request can damage the client’s trust. The process has five steps.

Step one, in the first week, read the SOW for three things: the outcomes the client bought, the out-of-scope list, and the clause on the change process. Step two, update the account record after every meeting, so that when you need the record test, you have documents to check against.

Step three, when a new request comes in, run it through the goal test and then the record test. Step four, tell the client as soon as you see a scope deviation, however small, rather than waiting to batch them up.

Step five, write the summary; if the request is a new outcome, that is, a change request, draft the change order and wait for approval so that it doesn’t turn into creep. PM Study Circle’s project management guidance likewise calls for a formal assessment of every proposed change.

Common FDE mistakes

The most common mistake is “I’ll just do it, it’s quicker”. The job is small, the client is friendly, and you’re confident you can finish it in an afternoon. That is exactly Tandem’s definition of creep: a request that skips the change order and gets done anyway, and next time the client will treat it as normal.

The second is the opposite reflex: citing the SOW in response to every question, including those that are really just clarifying the goal. You protect your margin but lose the reason the client hired FDEs instead of buying packaged software.

The third is flagging late, waiting until five changes have piled up to raise them all at once. The fourth is keeping no notes, so that by the end-of-project review the record test has no data to work with.

Putting this skill on your CV and in interviews

A scope issue handled cleanly is a story worth telling in an interview. Have an example ready with three parts: what the request was, what criteria you used to classify it, and how you handled it in writing.

On a CV, a line such as “drafted change orders and scope change summaries for deployments” shows the reader you can work with both code and contracts.

When reading a job description, treat words like scoping, SOW or change management as a signal to put your scope example near the top of your application and to prepare to tell it in detail.

Next time a client messages “while you’re at it, could you just…”, you will have two questions to test it with, a SOW to check it against, and a draft change order already written.