--- title: "Change requests and scope creep | Optimize All Academy" description: "Change is normal; unmanaged change is costly Clients' needs evolve. New ideas appear once they see work in progress. That is normal. The problem is scope…" url: https://optimizeall.com/learn/negotiation-and-client-management/change-requests-and-scope-creep updated: 2026-10-05 --- Negotiation & Client Management · Scoping, change requests and contracts · lesson 11 of 18 · 13 min # Change requests and scope creep ## Change is normal; unmanaged change is costly Clients' needs evolve. New ideas appear once they see work in progress. That is normal. The problem is **scope creep**: additional work absorbed without adjusting price or timeline, eroding margins and causing delays and frustration. ## Recognising scope creep - "While you're at it, could you also…" - Feedback that introduces new features rather than refining agreed ones. - New stakeholders with new requirements late in the project. - Revision rounds that exceed the agreed number. - Requests to support items outside the SOW. ## A simple change request process 1. **Acknowledge positively:** "Great idea, let me look at what it involves." 2. **Check against scope:** Is it included? If not, it is a change. 3. **Assess impact:** time, cost, dependencies, risks. 4. **Present options:** add it (with price and timeline change), swap it for something else of similar effort, or defer it to a later phase. 5. **Get written approval** before starting. 6. **Update the plan** and communicate to the team. ## Change request template ``` Change request #CR-04 Date: 12 Mar Requested by: Client marketing lead Description: Add Arabic version of 3 landing pages Reason: Campaign expanding to Saudi market Impact: +18 hours design/dev; translation by client; +4 working days to launch Cost: 1,350 (18 hours × 75) Options: (A) Add now with 4-day extension; (B) Launch English on schedule, Arabic 1 week later; (C) Swap for the 'blog page' deliverable Approval: __________ Date: ______ ``` ## The language of change Keep the tone collaborative, not defensive: - Instead of "That's not in the contract," say "That's a great addition. It's outside the current scope, so here are a few ways we could include it." - Instead of "No," say "Yes, and here is what it would take." ## Small requests add up Individually small favours can be fine, especially to build goodwill. But track them. Consider a **goodwill log**: when you do something extra for free, note it and mention it ("We've included the extra banner at no charge this time"). This makes your generosity visible and sets expectations for future requests. ## Change control for retainers For monthly retainers, define capacity (e.g., hours or deliverables per month) and a process for extra work: prioritise within capacity, carry over, or bill additional work at an agreed rate. ## Worked example *Illustrative.* A software developer in Lahore building an app for a UK startup noticed that client feedback kept adding features. She introduced a change request form and a short weekly call to review requests. The client began to prioritise: some requests were added with extra fees, others deferred to version 2. The project finished close to the original timeline, and the client appreciated the transparency, later hiring her for version 2. ## Hands-on: change request log (shared with the client) ```text # | Date | Requested by | Request | In scope? | Impact (time/fee) | Decision | Status 1 | 03/10 | Marketing mgr| Add Arabic version of 3 pages | No | +5 days / +AED 4,500| Approved | In progress 2 | 07/10 | CEO | Change hero image | Yes (rev) | none | - | Done 3 | 09/10 | Marketing mgr| "10 more AI ad variants" | No | +2 days / +AED 1,800| Declined | - Monthly total of approved changes: AED 4,500 ``` A visible log helps both sides see how the project is evolving, and makes the monthly or quarterly scope conversation easy. ## Hands-on: change-request email ```text Subject: Change request #4 - [short name] Hi [name], thanks for the idea to [request]. It's outside the current scope, so here's what it would involve: - Work: [summary] - Timeline: +[X] working days (new launch date [date]) - Fee: +[amount] - Alternative: we could swap it for [lower-priority item] at no extra cost Reply "approve #4" and we'll start; or let's discuss on Thursday's call. ``` ## Retainers: scope control without friction Define monthly capacity (for example deliverables or hours), a request queue with priorities, a rule for unused capacity (usually no rollover), and a quarterly review. When requests consistently exceed capacity, offer a larger tier rather than absorbing the work. ## Common mistakes - Saying yes to everything to please the client. - Saying no defensively and damaging the relationship. - Starting changes before approval. - Not tracking small favours. - Not updating timelines when scope changes. ## Quick self-check List the extra requests you completed for free in your last project. What was their total value? How will you handle similar requests next time? ## Pricing changes fairly Set a clear basis for pricing changes before the project starts: an hourly or daily rate for additional work, or a rate card for common extras (additional pages, extra revision rounds, new languages). This makes change requests quick to estimate and harder to dispute. For larger changes, provide a short estimate with assumptions, just as you did for the original scope. ## When the client pushes back If a client insists that a change is "obviously included", return calmly to the SOW together. If the scope is genuinely ambiguous, consider sharing the cost or absorbing a small item as goodwill, and fix the ambiguity in future SOWs. Being fair when your own documentation was unclear protects the relationship. ## Quick practice Prepare a one-page rate card for common additional requests in your work, so you can respond to change requests quickly and consistently. ## Team alignment Make sure everyone on your team knows the change process. Scope creep often enters through team members who want to be helpful and agree to extras informally. A simple rule, "log it and let the account lead respond", protects both the team and the relationship. ## Video lecture: Change requests and scope creep Lecture coming soon · 12 chapters · about 8 minutes. Read the full transcript below. 1. Change requests and scope creep 2. Why it matters 3. The side-order analogy 4. Recognising creep 5. Change process 6. Worked example 1: Sam in Cardiff (illustrative) 7. The language of change 8. Worked example 2: Nadia's retainer (illustrative) 9. Watch me: '20 more AI variants' 10. Team and fairness 11. Common mistakes 12. Recap and try this now ## Lecture transcript ### Change requests and scope creep Nobody sets out to wreck a project with scope creep. It happens one small, reasonable request at a time. Could you just add one page? Can we try a different colour? And now, the 2026 version: could you just run it through AI and give us ten more versions? Each one seems tiny. Together, they can double the work and wipe out your margin. In this lecture, you'll learn to recognise scope creep, run a simple change request process, use language that keeps relationships warm, price changes fairly, control retainers, and bring your whole team into line. ### Why it matters Why does this matter? Because change is normal. Clients learn as projects progress, markets shift, and good ideas appear mid-way. The problem isn't change. It's unmanaged change, where extra work gets absorbed silently until you resent the client and the client doesn't even know. Here's the key idea. Welcome change, but make its cost visible and let the client choose. Visibility turns a silent drain into a normal business conversation. ### The side-order analogy Here's an analogy. Think of a restaurant. You order a main course. Halfway through, you ask for a side of chips. The waiter doesn't argue, and doesn't bring them free either. They say, of course, and they go on the bill. You're not offended, because the rules are clear and the price is visible. If the waiter brought extras free every time, the restaurant would go broke, and you'd never know why the service suddenly got worse. Change requests are your side orders. Yes, happily, and here's what it adds. ### Recognising creep How do you recognise scope creep? Requests that aren't in the agreed deliverables. Revisions that are really new concepts. New stakeholders appearing late with new opinions. Platform or language additions, like, can we have the Arabic version too? Requests to change something already approved. And the AI version: more variants, more formats, more versions, because they seem cheap to produce. They still need your review, selection and editing, and each one creates more decisions for the client. So treat them like any other change: agree the quantity, the review level and the fee. ### Change process Here's a simple change process. One: acknowledge the request positively. Two: check it against the SOW. Is it in scope or out? Three: if it's out, assess the impact on time and fee, and consider a swap: could it replace a lower-priority item? Four: send a short change request with the work, the timeline impact, the fee and any alternative. Five: get written approval before starting. Six: log it in a shared change log, so both sides can see how the project is evolving. It sounds formal, but in practice it takes five minutes, and clients appreciate the clarity. ### Worked example 1: Sam in Cardiff (illustrative) A simple worked example, illustrative. Sam, a web developer in Cardiff, is building an online shop. Mid-project, the client asks for a product comparison feature. Sam replies: great idea. It's outside the current scope, so here's what it would involve: three extra days and six hundred pounds. Alternatively, we could swap it for the blog section, which you said was lower priority, at no extra cost. The client chooses the swap. Nobody felt refused. The project stayed on budget. And the client got the feature that mattered more to them. ### The language of change Now the language, because tone decides whether this feels like service or bureaucracy. Avoid no, and avoid that's not in the contract as your opening line. Instead: happy to help with that. It's outside what we agreed, so I'll send a quick change request with the cost and timing. Or: we can do that instead of this within the current budget, or in addition for this amount. Which would you prefer? Or: let's park that for phase two so we protect the launch date. Every script is positive, offers a choice, and makes the trade-off visible. The email template in the lesson follows the same pattern. ### Worked example 2: Nadia's retainer (illustrative) Now the realistic scenario, illustrative. Nadia runs a content agency in Lahore with a monthly retainer for a UK fintech company: eight articles and one report a month. Over two months, requests grow: extra LinkedIn posts, urgent rewrites, and ten AI-generated ad variants a week for testing. Her team is stretched. So she introduces a shared change log and a request queue, with the client's marketing manager prioritising each month's work within the agreed capacity. Extra requests go into a change request. At the quarterly review, the log shows that approved extras have averaged a third of the retainer. The client moves to a larger tier, and everyone's happier because the work is visible. ### Watch me: '20 more AI variants' Watch me handle an AI-flavoured request. The client emails: can you just generate twenty more ad variants with AI for next week's test? I open the change log. Is it in scope? The SOW includes five variants a month, so no. Impact: generating is quick, but reviewing, editing for brand and claims, and preparing twenty variants for upload takes about a day and a half. So I reply: happy to support the test. Twenty variants is outside the current scope. Here's what it involves: one and a half days, and this fee. Alternatively, ten variants could replace next month's allocation. Reply approve and we'll start. They approve ten as a swap. ### Team and fairness Two more points. First, team alignment. Scope creep often enters through your team, when a designer quietly says yes to a client on a call. So make sure everyone knows the scope, knows the change process, and has a friendly script: great idea, let me check with the account lead how we fit it in. Second, pricing changes fairly. Base the price on the same rates and logic as the original project, not a punitive premium. And for genuinely small items, you can choose to absorb them, but say so: this one's on us. Visible generosity builds goodwill. Invisible generosity just builds resentment. ### Common mistakes Let's list the common mistakes. Saying yes to everything to be nice. Saying no bluntly and damaging the relationship. Starting changes before approval. No change log, so nobody remembers what was agreed. Pricing changes punitively. Letting team members agree changes informally. Treating AI variants as free. And never reviewing retainer capacity, so creep becomes the new normal. ### Recap and try this now Let's recap. Change is normal; unmanaged change is costly. Recognise creep early, including requests for extra AI variants. Follow a simple process: acknowledge, check scope, assess impact, offer a swap, get written approval, and log it. Use positive language that offers choices. Price changes fairly, align your team, and control retainers with capacity, a queue and quarterly reviews. Your try this now: set up a shared change log for your current project, save the change request email template, and brief your team on the one-line script. Next, we'll look at contract basics for service businesses. ## Key takeaways - Change is normal; scope creep is unmanaged change that erodes margins and timelines. - Acknowledge, check scope, assess impact, present options, get written approval, update the plan. - Use collaborative language: 'Yes, and here is what it would take.' - Track small favours in a goodwill log and define capacity for retainers. - Extra AI-generated variants still need review, editing and client decisions: treat them as change requests with agreed quantity, review level and fee. ## Try it Create a change request template for your work and use it for the next out-of-scope request you receive. - [Previous: Scoping work and writing a statement of work](https://optimizeall.com/learn/negotiation-and-client-management/scoping-and-sow) - [Next: Contract basics for service businesses](https://optimizeall.com/learn/negotiation-and-client-management/contract-basics-for-services) - [All lessons of Negotiation & Client Management](https://optimizeall.com/learn/negotiation-and-client-management)