A scope change workflow should capture the request, compare it with the current agreement and identify its delivery, timing and commercial effects. Give the decision to an authorized owner. Update the scope and project instructions only after the decision, so a request in a message does not silently become a commitment.
- Capture the requestKeep the original wording and current scope.
- Assess the effectReview work, timing, dependencies and terms.
- Get the decisionRoute it to the authorized agency and client owners.
- Update the planRecord the accepted change and tell the team.
An unapproved request stays in review. Acknowledging a message does not approve additional work.
Capture the request without accepting it
Clients and team members can raise useful ideas at any stage. Record a proposed change in a way that acknowledges the request while preserving the distinction between discussion and agreement.
Capture the original wording, requester, affected deliverable and reason for the change. Link to the current scope. If the request is vague, ask what outcome the requester wants before estimating the work. A request to “add more reporting” could mean a new metric, a new audience or an entirely new report.
Compare it with the current commitment
| Question | Information to collect | Decision it supports |
|---|---|---|
| Is it already included? | Accepted scope and exclusions | Clarification or genuine change |
| What work changes? | Deliverables, tasks and dependencies | Delivery assessment |
| Who is affected? | Team, suppliers and client contacts | Responsibility and capacity |
| What timing changes? | Milestones and blocked work | Revised schedule |
| What commercial decision is needed? | Agreed terms and owner assessment | Authorized commercial response |
| Who can approve? | Named agency and client owners | Valid change decision |
Use your actual agreement and commercial process. This guide does not determine whether a particular request is contractually included or how it should be priced.
- Included or excludedCheck accepted scope and exclusions.
- Delivery effectIdentify changed deliverables, tasks, and dependencies.
- Timing effectIdentify milestones and blocked work.
- Decision authorityName agency and client owners who can approve.
This comparison does not determine contractual inclusion or pricing.
Assess the effect before promising a date
Ask delivery to identify the work and dependencies involved. A small visible edit can require significant checking or affect other outputs. Conversely, a request that sounds large may be a minor clarification. Assess it rather than deciding from the message length.
For an illustrative reporting engagement, the client asks to add another business unit. That could require a new data source, access, a different approval contact and another reporting view. List those effects before saying the existing deadline still applies.
Keep unresolved assumptions visible. If the estimate depends on access being available, say so. Do not turn an assumption into a scheduled commitment while the client or agency still needs to make a decision.
Present a decision with options
The owner can decide to accept the change, defer it, replace existing work or decline it. Explain the consequences of the available options in plain language. If the change affects commercial terms, use the agency's approved process to document them.
- Accept changeDocument the approved commitment and consequences.
- Defer changeKeep it outside the current commitment for now.
- Replace workExchange existing work for the proposed change.
- Decline changeRecord the decision using the approved process.
A delivery team member may clarify work without authority to alter the engagement.
Name both the person proposing the option and the person authorized to accept it. A delivery team member may be able to clarify work without being authorized to alter the engagement. Make that boundary easy to follow.
Update the operating records after the decision
Identify the new scope version, changed tasks, revised milestones and relevant approvals. Mark superseded instructions clearly. Notify the people affected rather than relying on them to notice an edited document.
- Identify new versionRecord changed scope and relevant approvals.
- Update delivery workRevise tasks and milestones.
- Mark old instructionsClearly identify superseded instructions.
- Notify affected peopleTell people what continues, pauses, or is replaced.
Do not rely on people noticing an edited document.
If work is already underway, record what should continue, pause or be replaced. The project brief guide helps carry the approved change into a usable delivery instruction.
Review patterns without blaming the requester
Repeated changes can reveal an unclear brief, a poorly defined offer or a discovery gap. Review the source of requests and the point where they appear. That helps the agency improve earlier decisions.
Track requests waiting for assessment, changes acted on before approval and work repeated because instructions were not updated. A visible request register is more useful than assuming that every project stays within scope because nobody filed a formal change.
Questions and answers
Does recording a client request mean we accepted it?
The record should clearly identify a proposed change and its review status. Capture the request, assess it against the current scope, and have an authorized owner make the decision. Use wording that does not confuse acknowledgment with acceptance.
Who should approve an agency scope change?
Use the owners authorized under your engagement and agency process. Delivery can assess the work, while the commercial owner handles any change to terms. The client also needs a clearly identified person able to approve the proposed commitment.
Can automation approve a scope change?
Automation can capture requests, route review tasks and distribute an approved update. Whether a change can be accepted without review depends on a specific agreed rule. Do not let a broad task-creation rule become permission to alter deliverables or commercial commitments.