A client asks for another concept, a new page or an extra round of revisions. The request may be entirely reasonable. The problem begins when the team agrees before understanding what the request changes, and the new commitment never reaches the project plan.
A scope change process gives both sides a shared way to make that decision. It can be lightweight: one request record, an impact assessment and a written outcome. The aim is to keep the relationship clear while protecting the commitments already made.
The useful idea
Treat a change as a decision with consequences. Acknowledge the request, assess its impact, offer options and record the agreed outcome before doing the work.
Check whether it is a change or an unfinished requirement
Compare the request with the current agreed scope and acceptance conditions. Work required to meet an existing commitment should not be re-labelled as a new request simply because the team underestimated it. A clarification may reveal missing detail without creating a new deliverable.
If the boundary is ambiguous, say so. Review the original brief and conversation with the client, then agree how to treat the request. Starting with this distinction makes the process more credible than applying a change label to every difficult piece of feedback.
Capture the request in the client’s own terms
Record what they want and why it matters. Ask whether it is essential to the original outcome or a new opportunity. A request for ‘another dashboard’ may actually be a need to answer one additional question, which could have a simpler solution.
Link the request to the relevant deliverable and keep the original message as evidence. Nominate one person to coordinate the assessment so the client does not receive different answers from sales, design and delivery.
Assess impact before offering a date
Ask the people doing the work what must change. Consider effort, dependencies, review time and the work that would be displaced. Separate a rough assessment from a confirmed commitment and make assumptions visible.
Use a small table to explain the effect. The illustrative example below concerns an additional page type; it is not an estimate for your project. Your team must evaluate its own requirements and commercial terms.
| Area | Question to answer |
|---|---|
| Output | Which new or changed deliverable is needed? |
| Dependencies | Do we need more content, access or approval? |
| Timing | Which existing milestone would move? |
| Commercial agreement | Does the agreed scope or fee need revision? |
| Ownership | Who can authorise the decision? |
Offer options with visible trade-offs
Present a small set of credible routes: replace an existing deliverable, extend the engagement, or schedule the request after the current work. Explain what remains the same and what changes under each route. Do not make ‘no’ the only alternative to silently absorbing the request.
A response can be simple: ‘We can include the new page in this phase by replacing the planned resource page, or assess it as an addition with revised timing. Which outcome matters most?’ Use the actual alternatives your team can deliver, and avoid presenting an unreviewed price or date as final.
Record the decision where delivery happens
After approval, update the scope reference, project milestones and affected tasks. Tell the people whose commitments changed. A written approval in an email thread is insufficient if the production team keeps working from the old brief.
If the request is declined or deferred, preserve the reason and the next point at which it may be considered. This prevents the same request from returning as if no decision was made. Use your normal agreement process whenever a contractual change is involved.
Review the pattern after the engagement
At project close, examine which requests came from unclear scope, which reflected useful new learning and which were caused by incomplete delivery. These categories call for different improvements. Add clearer boundaries to the brief when appropriate, but leave room for deliberate change.
The Project Management Institute describes scope control in terms of defining the work and managing changes to it. The workflow here is our practical adaptation for client teams, with an emphasis on visible choices and a recorded decision rather than a large approval bureaucracy.
Client change request record
Copy this before promising the additional work.
CHANGE REQUEST Request and reason: [client words] Related deliverable: [link] Current scope reference: [link] Classification: [existing requirement / clarification / change] Impact: [effort / inputs / review / timing] Options: [replace / add / defer, with trade-offs] Assessment owner: [name] Decision maker: [name] Decision and date: [approved / declined / deferred] Updated plan and agreement: [links] People notified: [names]
Sources and further reading
Background on defining project scope and managing changes; the checklist above is original Tamaam guidance.
Bring the context into your workspace.
Explore how Tamaam connects the relationship and the work around it. Tamaam is in development; product pages show previews and illustrative workflows. Joining early access does not start a subscription.
Found something we should clarify? Send a correction or question.
