Change requests and scope creep

0:00 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.

0:42 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.

1:12 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.

1:51 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.

2:31 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.

3:14 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.

3:53 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.

4:39 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.

5:29 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.

6:17 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.

7:02 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.

7:27 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.