How Engineers Can Handle Out-of-Scope Client Requests
It often starts with a reasonable question.
“While you are looking at the model, can you quickly check this as well?”
“Could you add one more load case?”
“Can you update the drawing before tomorrow’s meeting?”
The request may sound small. It may even be technically interesting. And because you want to help the client and keep the project moving, the easiest response seems to be: “Yes, I’ll take a look.”
Two hours later, the quick check has become a new calculation, three revised drawings and a discussion about the planning.
Nobody deliberately agreed to extra work. But the work has already started.
This is how scope creep often enters engineering projects. Not through one dramatic change, but through a series of small, sensible requests that are accepted before their impact is understood.
Handling an out-of-scope client request does not mean becoming rigid or unhelpful. It means making the change visible before time, budget and responsibility become unclear.
The goal is not to stop change.
The goal is to control it.
Why engineers often start before the scope is clear
Engineers are trained to solve problems.
When a client asks a technical question, the natural response is to investigate it. You may need to understand the request before you can explain whether it is included. You may also think:
It will probably only take 15 minutes.
The client needs an answer to continue.
We should be flexible.
Raising a change for something this small will create unnecessary friction.
I do not know whether I am allowed to discuss cost.
It is quicker to do the work than to start a commercial discussion.
That reasoning is understandable. It is also where scope control starts to disappear.
In conversations with engineers, one pattern keeps returning: projects do not always start on time, client information arrives late and technical teams still try to make the original deadline. The project usually gets delivered somehow. But the extra effort remains largely invisible.
This creates frustration for the engineer and unreliable information for the business. Management sees a completed deliverable. It does not always see the additional hours, changed assumptions and decisions that made it possible. Helpful behaviour becomes hidden project risk.
Not every additional question is a scope change
You should not label every client question as out of scope. That would make collaboration slow and defensive. Before responding, determine what kind of request you are dealing with.
1. A clarification
The client asks you to explain work that is already part of the agreed deliverable. For example: “Can you explain why this load case is governing?”
Answering the question may simply be part of delivering useful engineering work.
2. A correction
The work does not meet the agreed requirement because of an error on your side. For example: “The drawing does not include the connection specified in the approved input.”
That is not a client change request. It is work needed to meet the original agreement.
3. A scope change
The client asks for a different or additional outcome, based on new information, priorities or requirements. For example: “We have changed the installation method. Can you reassess the structure for the new lifting arrangement?”
The technical work may look related to the original assignment. But the input, analysis or deliverable has changed. That means the effect on hours, planning and risk must be assessed.
The difficult cases sit between these categories. The client may call something a clarification while you see a new requirement. Do not start by arguing about the label. Start by making the difference visible.
Five steps for handling out-of-scope client requests.
Use this sequence:
Clarify → Compare → Explain → Offer → Confirm
It gives you a practical way to manage scope changes without turning every conversation into a negotiation.
1. Clarify what the client actually needs
Do not assess the request based on the first sentence alone. Ask what triggered it, what outcome the client needs and when the answer will be used. Useful questions include:
“What has changed since we agreed the original scope?”
“Which decision does this additional check need to support?”
“What do you need from us: an initial technical view or a fully verified deliverable?”
“Which input should we use?”
“When do you need the result, and what happens if it is delivered later?”
This prevents two common mistakes.
The first is doing a full analysis when the client only needs an initial indication. The second is promising a quick answer before discovering that the request affects several disciplines and deliverables.
You are not delaying the client by asking questions. You are stopping both sides from acting on different assumptions.
2. Compare the request with the agreed scope
Once the request is clear, compare it with what was agreed. Check the proposal, scope of work, approved client input, deliverable register or earlier confirmation email. Look at:
The agreed output
Included and excluded activities
Assumptions and client-supplied information
Number of revisions or design iterations
Interfaces with other disciplines
Approval responsibilities
Planning and milestones
Avoid saying “That is not in scope” from memory. Show the difference. For example: “The agreed scope includes the analysis for the original lifting configuration. This request introduces a different lifting point and requires us to update the model and recheck the governing load cases.”
That sentence is stronger than a blunt refusal. It connects the technical change to the additional work.
3. Explain the project impact
Clients do not automatically know what sits behind a technical request. To them, moving a component on a drawing may look like a minor edit. To you, it may require a new calculation, an interface check and revised documentation.
Do not hide behind technical detail. Explain the impact in terms the client can use:
Additional engineering hours
Effect on the delivery date
Dependencies on new input
Consequences for other documents or disciplines
New technical or contractual risks
Decisions or approvals required
For example: “We can make the change. Because it affects the load path, we first need to update the calculation and verify the connection design. That will also require revisions to two drawings. I need to check the hours and the effect on Friday’s issue date before confirming.”
This is not being difficult. It is giving the client the information needed to make a proper decision.
4. Offer a workable next step
Scope management is not the art of saying no.
It is the ability to show what is possible, under which conditions. Depending on the situation, you might offer:
A quick preliminary review before committing to a full analysis
The additional work through a formal change request
A revised delivery date
A trade-off: add the new task and postpone another deliverable
A smaller technical assessment focused on the immediate decision
Escalation to the project manager or commercial lead for approval
For example: “We can provide an initial assessment tomorrow to support your meeting. A verified calculation and revised drawing will require a scope change. I will ask our project manager to confirm the hours and delivery date today.”
You stay helpful without committing the team to undefined work.
5. Confirm the agreement in writing
A good conversation is not enough. If the request affects scope, timing, cost, input or responsibility, confirm it in writing. Keep the message short and specific.
Include:
What the client requested
What has changed from the original scope
What your team will deliver
What is not included
Required client input or approval
Effect on hours, price or planning
Who owns the next action
This matters even when the commercial decision is made by somebody else. Your notes give the project manager the facts needed to handle the change.e.
Practical scripts for client conversations
You do not need a polished sales pitch. You need a clear sentence at the right moment.
When you need to understand the request first:
“I can look into this. Before I start, can we clarify what changed and which decision you need the answer for?”
When the request appears to be outside scope
“This is related to our current work, but it adds a new requirement that was not included in the agreed analysis. Let me assess the impact before we commit.”
When the client says it is only a small change
“The drawing change itself is small. The engineering check behind it is larger because it affects the load path and two connected deliverables.”
When the request threatens the deadline
“We can prioritise this request, but not without affecting the current delivery plan. Shall we decide which result is most important for Friday?”
When you are not authorised to discuss price
“I can define the technical work required. Our project manager will confirm the commercial impact and approval with you before we start.”
When you want to remain flexible
“There are two ways we can support you: a quick initial assessment for tomorrow’s decision, or a full verified update. Let me explain the difference.”
These phrases do not damage the client relationship. They make your reasoning visible and give the client a choice.
Always write an email with the discussed detail to verify
This email does not need corporate language. It needs an accurate record of the decision.
When the engineer should not make the decision alone
Engineers are often closest to the request but do not always control the contract, budget or resource planning.
That creates an awkward gap. The client expects an immediate answer, while the engineer may not know what can be approved.
In that situation, your responsibility is not to negotiate the entire change. It is to:
Clarify the technical request.
Identify the difference from the agreed scope.
Estimate which work and deliverables are affected.
Avoid starting undefined work.
Bring the right decision-maker into the conversation.
You can say:
“Technically, I understand what is required. Before the team starts, I need our project manager to confirm the effect on scope and planning.”
That is ownership. Not avoidance.
What engineering managers need to organise
Client communication training for engineers can improve individual conversations. But training alone cannot compensate for an unclear change process.
Engineering managers and project managers should make five things explicit:
1. What engineers may approve themselves
Can they spend one hour investigating a request? Can they agree to a different delivery date? At what point must they escalate?
2. Who decides on commercial changes
Engineers need to know who can approve hours, price and planning — and how quickly that person can respond.
3. How changes are recorded
A complex system is not always necessary. But decisions cannot live only in meetings, chat messages and somebody’s memory.
4. How the team handles late client input
When client information arrives late, the original planning cannot remain unquestioned. The team needs a consistent way to explain the consequences.
5. Whether the culture rewards invisible rescue work
If engineers are praised for “making it work” while additional effort remains unrecorded, scope creep will continue. The organisation is then depending on personal overtime instead of reliable project control.
Engineers need business skills. They also need a system that allows them to use those skills.
Better scope management creates better client relationships
Many engineers worry that discussing scope will make them look inflexible or commercial.
Usually, the opposite is true.
Clients gain more confidence when you explain what a change means, what options they have and what decision is required. They may not always like the consequence. But they can understand it.
Trust does not come from saying yes to everything.
It comes from making reliable commitments.
So the next time a client asks, “Can you quickly add this?”, do not answer with an automatic yes or no.
Clarify the need. Compare it with the agreement. Explain the impact. Offer a workable option. Confirm the decision.
That is how engineers can handle out-of-scope client requests without creating unnecessary conflict — or quietly giving away engineering work.
Protect the Scope
Protect the Scope is practical client communication training for engineers who work with changing requirements, late input and additional client requests.
Engineers learn how to clarify expectations, recognise scope changes, explain project impact and guide the conversation towards a clear decision — without turning into salespeople or contract managers.
For engineering companies, this means more visible scope changes, better-informed client decisions and fewer surprises in hours and planning.
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.
