Client request or scope change? A practical way to decide before work begins

A client asks for revised wording on a contact page just before their website goes live. Later, they ask for that page to include a form that sends enquiries into their management system. Both requests arrive by email, and both sound manageable. But treating them alike could disrupt the delivery plan or create a commitment nobody agreed to make.

Scope change management is not about rejecting every request that was not spelled out word for word. It is about comparing the request with the current agreement, understanding its consequences and making an informed decision before the team starts work. Done well, that protects the client relationship as well as the project plan.

Compare the request with the agreed outcome

An adjustment changes how an agreed deliverable is completed without materially changing the result, ownership or delivery conditions. Revising supplied copy during an agreed review round may fit that description. Fixing something that fails the agreed acceptance criteria is different again: a correction should not be relabelled as a new feature.

A scope change alters what must be delivered or what it takes to deliver it. It may add an outcome, extend a workflow, introduce an integration, require further approvals or affect timing and resources. A form connected to another system can involve data mapping, access permissions, testing and coordination with the owner of that system. Its visible size on the page says little about the underlying work.

The comparison needs a usable reference: the approved proposal, deliverables, exclusions, assumptions, milestones and acceptance criteria. If those documents are unclear, neither an automatic extra charge nor silent acceptance is a good substitute for a conversation. Clarify what each side understood, then record the interpretation you agree to use.

Five questions that make the decision easier

When a request comes in, avoid estimating effort or promising a date before establishing its purpose:

• What outcome does the client need? The suggested solution may not be the simplest way to solve the underlying problem. Asking about the goal can reveal an option already within scope.
• Was the outcome agreed, not just the component? An agreed form does not necessarily include a connection to another system or a new approval process.
• Do the acceptance criteria change? If completion will now be judged against different conditions, the delivery decision needs another look.
• Are there new dependencies or owners? Additional data, system access, another department’s review or new tests can alter the sequence of work.
• What is the cumulative effect? A small change may be manageable on its own, while several small changes can crowd out agreed tasks. Assess the full queue, not just the latest email.

There is no universal hours threshold that turns an adjustment into a scope change. A more useful classification separates correction of agreed work, an adjustment within the agreed review process, an unresolved clarification and a change requiring a decision about deliverables, timing or cost. Each label should lead to an action that both the client and delivery team understand.

Give the right people a decision to make

Start with one place to record requests, even if they arrive in meetings, messages and emails. Capture who asked, what they want, why they want it, when they need it and any supporting material. A project owner can acknowledge receipt promptly without implying that the request has been approved.

Next, the delivery team checks the work and its dependencies. The project owner proposes a classification and explains the reasoning. On the client side, someone with authority over priorities and commercial consequences should approve a change. An informal «go ahead» from a meeting attendee may not be enough to settle those questions. Consult affected specialists before making a commitment on their behalf.

For a scope change, offer a choice rather than just a new estimate. Options might include adding the work under revised conditions, replacing an agreed task, scheduling it for a later phase or declining it. Explain what each option includes and excludes, what information or decisions the client must provide, and the likely effects on timing and resources. Even an adjustment warrants a short written confirmation if it changes priorities or uses an agreed review round.

The operating rule is simple: receiving a request is not the same as approving work. If an issue requires immediate containment, authorize that limited action separately. The lasting solution can still go through the normal decision process.

Record the outcome so it survives the next handoff

Documentation need not be elaborate. A shared request record can hold the original request, the relevant scope reference, its classification, the impact assessment, the options considered, the approver, the decision and the updated plan version. Keep declined and deferred requests visible too. They provide context when someone later asks why a discussed item is missing from a deliverable.

Consider a client who asks for one more question on an agreed enquiry form. If it fits the agreed data needs and review process, it may be a straightforward adjustment. If the answer must trigger approvals, produce documents and move into another application, it introduces a workflow that needs assessment. The distinction is not the number of fields; it is the work and responsibilities behind them.

A structured request form and shared board may be enough to assign owners and track decisions. Rules-based automation can notify the next owner and update a status after approval. AI may help summarize a long request or highlight missing information, but it should not independently interpret the agreement or approve a commercial commitment. A person remains accountable for those decisions.

To get started, choose one active project and one type of request that currently arrives through several channels. Identify the scope reference, who classifies requests, who approves changes and what written confirmation is needed before execution. Then review where requests wait, require clarification or cause repeated work. That gives you evidence for improving the process without adding unnecessary ceremony.

If this decision is difficult in a current project, Cibercoding can help review the request workflow and identify what to clarify, document or automate.