When does a Client Request become a Scope Change?
“Could you quickly take a look at this as well?”
It sounds like a small request.
Maybe the client wants one extra calculation. A different configuration checked. Another option added to the report. Or a minor adjustment to a design that is almost finished.
Technically, the request may be straightforward. So you say yes, open the model and get to work.
Only later does it become clear that the change affects more than the task itself. It requires additional input. It changes an interface. Someone needs to repeat a review. The delivery date moves. Or your team spends twenty unplanned hours on work nobody formally approved.
This is how scope creep usually starts.
Not with one major change, but with a reasonable-sounding request that nobody stops to clarify. A small technical change can have a large project impact.
Engineers are trained to solve problems. When a client asks a technical question, the natural response is to find the answer.
That is useful—until solving the immediate problem creates a bigger one elsewhere in the project.
A request becomes relevant to scope management when it changes one or more of the following:
The agreed deliverable
The work or engineering hours required
The planning or sequence of activities
The technical or contractual risk
An interface with another discipline, supplier or system
The responsibilities of your team or the client
The assumptions on which the original work was based
The size of the request is not the deciding factor.
Its consequences are.
A ten-minute change to a drawing can create several hours of checking, coordination and documentation. A quick alternative can introduce a new technical responsibility. And an informal promise in a meeting can become a firm client expectation by Friday.
If the impact remains unspoken, the client may reasonably assume that the request is included. Your project manager may assume nothing changed. And your engineering team is left trying to protect quality, planning and budget at the same time.
That is not only a contract problem. It is a client communication problem.
Why engineers often start before clarifying the request?
Most engineers do not ignore scope on purpose. They start because, in the moment, helping feels like the sensible thing to do. There are several common reasons:
1. The technical task looks small
You assess the work itself, but not the coordination around it. The calculation may take one hour. Getting the right inputs, checking the interfaces, updating the report and completing the review may take a day.
2. You do not want to sound difficult
Stopping to discuss hours, planning or commercial consequences can feel unnecessarily formal. Especially when the client presents the request as urgent or minor. But clarification is not resistance. It is part of giving reliable advice.
3. You assume someone else will handle the commercial side
You expect the project manager or account manager to decide whether the work is included. Meanwhile, the technical work has already started—and the project has lost its strongest negotiating position.
4. You want to demonstrate service
Good client service matters. But there is a difference between consciously providing extra service and accidentally creating free, unplanned work.
One is a decision. The other is drift.
5. The decision space is unclear
Engineers are often told to “take ownership” without being told what they may approve, when they should pause and who must decide about additional work. That is a management problem, not a lack of initiative.
When does a client request become a scope change?
Use this practical rule:
A client request may be a scope change when accepting it changes the agreed output, effort, timing, risk, assumptions or responsibilities.
You do not need to decide immediately whether the client should pay extra. You do need to make the impact visible before the team commits.
That distinction matters.
Recognising a potential scope change is not the same as rejecting it. It simply creates the information needed to make a sound decision.
Five questions to ask before you start:
When a client asks you to add, check or change something, pause long enough to answer these questions.
1. What is the client actually asking for?
Clarify the requested outcome, not only the task.
“Take a quick look” could mean anything from an informal engineering opinion to a verified calculation that the client intends to use for a decision.
Ask:
“What decision will you make based on this?”
“Do you need an initial view, or a checked and documented engineering conclusion?”
2. Was this included in the original agreement?
Check the agreed deliverables, exclusions and assumptions. Do not rely on memory—especially when several people were involved in earlier conversations. The contract does not need to enter the conversation immediately. First understand whether the request fits the agreed work.
3. What changes if we accept it?
Look beyond your own task. Consider:
Additional engineering and review hours
New or revised client input
Dependencies with other disciplines
Changes to milestones or delivery dates
New technical, safety or contractual risks
Updates to drawings, reports or documentation
This is where technical expertise becomes commercially valuable. You can see consequences the client may not yet see.
4. Who needs to decide?
You may have authority to spend two hours investigating a request, but not to commit the project to a revised deliverable. Know the difference between:
What you can clarify independently
What the project manager must approve
What the client must formally confirm
What requires a commercial proposal or contract change
5. What needs to be recorded?
A good conversation still needs a clear follow-up. Record:
What the client requested
What your team understood
The impact on deliverables, planning, budget or risk
What was agreed
Who owns the next action
A short written confirmation can prevent a long discussion later.
How to discuss a scope change without sounding defensive
You do not need to open with: “That is outside scope.”
That may be correct, but it skips the part that helps the client understand why the request matters.Use this sequence instead:
Confirm the need.
Explain the project impact.
Present the available options.
Agree on the decision and next step.
For example:
“We can look into this. Before we start, I want to clarify the level of detail you need, because a verified answer will require additional input and review.”
“This change is technically possible. It will also affect the interface calculation and the current delivery date. Shall we assess the impact first and come back with the options?”
“The original deliverable covers option A. Adding option B requires an additional analysis and report update. I will align the impact with our project manager so we can give you a clear proposal.”
“We can include this as a small additional service, provided it does not require further design changes. If it develops beyond that, we will pause and discuss the impact with you first.”
These responses are helpful, not obstructive. They show that you understand both the technical request and its consequences.
Extra service or free extra work?
Not every additional request needs a change order. Sometimes doing a little extra is the right commercial decision. It may strengthen the relationship, resolve an issue quickly or create a valuable opportunity for further work. But make that choice consciously. Before providing extra service, decide:
Why you are doing it
How much time or risk you are willing to accept
Who approves the decision
What boundary you communicate to the client
What happens if the request grows
You can be flexible without making the scope invisible. In fact, clear boundaries often improve client trust. The client knows what to expect, what decisions are needed and what the consequences will be.
What engineering managers need to organise
Training engineers to communicate more clearly helps. But it will not solve scope creep if the project system remains vague.
Engineering and project managers need to define:
Which changes engineers may accept themselves
When work must pause for an impact assessment
Who owns the commercial conversation
How potential scope changes are recorded
How quickly engineers can get a decision
Whether the team is rewarded for raising risks early—or only for staying busy
If every scope question disappears into a slow approval process, engineers will work around it. If every raised concern is treated as negativity, they will stop raising concerns.Clear decision space matters.
The goal is not to turn engineers into contract managers or salespeople. It is to help them recognise when a technical request affects the wider project—and give them a practical way to act before the impact reaches the planning or budget.
The conversation needs to happen before the work
Scope problems rarely come as a surprise because nobody could see them.
They become a surprise because the technical consequences were not translated into a timely client decision. So the next time a client asks, “Could you quickly add this?”, do not jump straight to yes or no. Clarify the request. Assess the wider impact. Make the decision explicit. That short pause can save a great deal of project recovery later.
Help your engineers protect the scope
Protect the Scope — Client Communication Skills for Engineers is a practical half-day incompany training for project and lead engineers.
Engineers learn how to clarify client expectations, communicate technical risks and address scope changes before they affect planning or budget. The training uses real engineering situations and practical conversation tools—not generic communication theory.
Annick Sabel
Annick Sabel (36) spent ten years as a Managing Director of engineering companies in the offshore industry. She combines technical understanding with strong business experience and a practical, people-focused approach. Through CTD, she helps engineers develop business skills they can apply directly in their daily work. She is keen to get in touch and discuss your thoughts.
