SCOPE & CLIENT CHANGES / RUNBOOK BUREAU

Scope Creep Examples & Change Request Process

An extra revision, format or meeting can change a project even when the main deliverable stays the same. Compare the request with the agreed brief first. If it changes the commitment, record the impact and get a decision before it becomes delivery work.

Check these requests against the baseline

Extra revision rounds: the included round is complete and a new batch of preferences arrives. Separate new direction from corrections needed to meet the brief.
Additional deliverables: one agreed report becomes a report plus a slide deck. Record the extra output and its review work.
New formats or versions: the client needs another language, size, audience or channel. Check adaptation, checking and export time.
Extra meetings: weekly check-ins become daily calls. Include preparation and follow-up, not only call duration.
New stakeholders: a new reviewer asks to revisit an approved direction. Clarify decision authority and whether earlier approvals still stand.
Faster deadline: the work is unchanged but the delivery commitment is not. Assess capacity and dependencies before agreeing.
Additional research: the client wants interviews or a new evidence base beyond the agreed desk research. Clarify the depth and outputs.
Added reporting: a one-off handover becomes recurring performance updates. Define frequency, duration and data responsibilities.
Work outside the original brief: a design project expands into copywriting or implementation. Treat the new responsibility as a separate scope decision.

None of these requests is automatically chargeable. The brief may already include it, or you may agree a no-cost substitution. The point is to decide explicitly rather than assume that every request is included or every request deserves an extra fee.

Seven steps from request to updated project record

Record the request: note who asked, when, the desired outcome and the requested date.
Compare against agreed scope: identify the affected deliverable, allowance or exclusion and whether the request is already included.
Assess time, cost and deadline impact: include coordination, review, dependencies and other accepted changes.
Send revised terms: state the changed work, exclusions, proposed fee, timing and inputs in plain language.
Get written approval: obtain a decision from the agreed approver on the same version you will deliver.
Complete the work: schedule the approved change and deliver within its agreed boundaries.
Update the project record: mark completion, record actual effort and agreed billing, and keep the approval with the revised scope.

Update the working scope as soon as approval is received so the delivery team uses the right version. The final update closes the record with what actually happened. If the request is rejected or deferred, record that outcome too.

Worked example: a new stakeholder requests a new version

The agreed job is a customer research summary for the product team, with one consolidated review. After that review, the sales lead asks for a client-facing version with different examples and a separate approval round.

The change record identifies a new audience and output. You estimate the adaptation and review work, explain any effect on the original handover, and propose a fee. The client approves the new version and timing in writing. You update the scope, schedule the work and record actual effort when it is complete.

If the client instead chooses to keep the original internal summary only, mark the request as declined. An unanswered request should remain awaiting a decision, not silently move into your task list.

Keep a change record short enough to maintain

Request reference, date, requester and a one-sentence description.
Original scope reference and the specific difference.
Estimated effort, direct costs, proposed fee and schedule impact.
Decision-maker, approval date and a link to the written decision.
Status, updated scope version, actual effort and completion note.

Use a single shared reference rather than conflicting copies in chat, a task board and an invoice draft. Review the combined impact of accepted changes: several small additions can affect a deadline even when no single request looks substantial.

Where the process usually breaks

Recording the request but never asking who can approve it.
Treating the latest stakeholder comment as a replacement for the agreed brief.
Getting approval for the idea while leaving the fee or deadline unresolved.
Starting “just the first part” before the decision, then feeling committed to finish.
Losing the original baseline by overwriting it without a version or decision record.
Closing the request without comparing actual effort with the estimate.

Use the process on one real request

Take the latest client change and write down its baseline, impact and decision. If you need a structured working file, the Scope Control System brings scope, change requests, impact assessment and approval records into one system.

Explore the Scope Control System

Paid products are purchased on Etsy.