Operating Intelligence
Scope Creep Starts With the Promises Your Team Cannot See
Your team tells a client the extra work sits outside the agreement, and the client says someone already agreed to it. That is scope creep, and a firmer boundary would not have stopped it, because your team could not see the promise.
Scope creep is the gradual growth of the work you deliver beyond what was agreed, without a matching change to the price, the timing or the people doing it. A tighter contract helps with new requests. It does nothing when the request rests on something a colleague said on a call or in an email, and nobody wrote down.
If your team keeps arguing about what a client was promised, this piece shows how to sort a request, record it, approve it and keep the answer where the next person will look.
How do hidden promises create scope creep?
Hidden promises create scope creep when a one-off exception, agreed by one person and recorded nowhere, becomes what the client expects every time. A hidden promise is a commitment someone in your business made to a client that the person now doing the work cannot see.
Picture an account manager who adds a second location to a client's monthly report as a favour during a busy quarter. Months later, a newer team member prepares the report from the original agreement and leaves the second location out. The client asks why the service has gone backwards. To the client, something they were given has been taken away. Your team believes nothing changed at all.
The pattern is common. PMI's 2018 Pulse of the Profession found that 52 percent of projects completed in the previous 12 months experienced scope creep or uncontrolled changes to scope. Five years earlier, the figure was 43 percent. In a 2009 paper for PMI, Richard and Elizabeth Larson point to one reason: some change requests "are or appear to be small", so teams act on them without a formal change process.
In a small service business, the gap is wider. The agreement lives in one place and the exceptions live in inboxes, call notes and someone's memory. Before you treat a request as scope creep, ask who might already have said yes to it.
Is the request included work, clarification or a change?
Every request that looks like out of scope work is one of three things: work already included, a clarification of something the agreement left vague, or a genuine change. Each one needs a different answer, so sort the request before you reply.
- Included work: the agreement covers it, even if your team has not done it before. Do it, and note where the agreement says so.
- Clarification: the agreement is silent or ambiguous. Agree what it means with the client, then write that meaning down so it is not debated again.
- Change: the request adds to or alters what was agreed. It needs a decision on price, timing and capacity before the work starts.
Check two sources before you decide, in this order. First, the agreement itself: the proposal, engagement letter or quote the client accepted. Second, the commitments made since then: accepted changes, emails and call notes where anyone on your team discussed this client's work, and invoices that show whether something similar was charged before.
If you find an earlier exception, the request is not new to the client, even if it is new to you. That changes the conversation, because the client is asking you to keep doing something they already receive.
Tip
Please note: an exception that has been repeated without charge is hard to present as a one-off. Decide whether it stays, and tell the client either way, rather than quietly stopping it.
What should a change-request record contain?
A change-request record holds five things: the request, the original scope, any earlier exceptions, the impact and the decision owner. A change request is a written note of something a client wants that sits outside what was agreed, kept so the decision about it can be found later.
- Request: what the client asked for, in their words, with the date and the name of whoever took it.
- Original scope: the clause, line item or deliverable in the agreement it relates to, linked rather than copied.
- Earlier exceptions: every time this or something like it was provided before, who agreed to it and whether it was charged.
- Impact: what it adds in hours, cost, timing or risk, and which other work it would push back.
- Decision owner: the one person who decides whether it is included, charged, declined or deferred.
Once the decision is made, add two more lines: the outcome and the date the client accepted it. The earlier exceptions field is the one that deals with hidden promises. Filling it in forces someone to look for what was said before, while the people who said it can still be asked.
Keep the record short enough to fill in while the client is still on the phone. A note in your job or client tool is enough, as long as it sits with that client's other records.
Who can approve the change?
Two approvals settle a change: your business decides whether to offer it and on what terms, and the client decides whether to accept those terms. They are separate decisions, often made by different people, and a change is not settled until both are made.
Internal approval belongs to the person with authority over price and capacity, who is not always the person who took the request. Larson and Larson make the same point about project teams: added work should be decided only by the people authorised to decide it. The PMBOK Guide definition they quote describes scope creep as work added without addressing time, cost and resources, "or without customer approval".
Until the client accepts, the change is a proposal and the work stays as it was. Name the internal approver for each client or type of work in advance. Then anyone on your team can reply "I will check that and come back to you by Friday" instead of saying yes to keep the peace.
How do you communicate the decision without damaging trust?
Tell the client three things in one message: what is agreed, what changes and what happens next. A clear answer given before the work changes is easier to accept than one the client discovers on an invoice.
- What is agreed: restate the part of the original scope the request touches, so you both start from the same wording.
- What changes: the decision, and the option the client is choosing between, such as adding the work at a price, swapping it for something else or scheduling it later.
- What happens next: who does what, by when, and what the client needs to confirm.
If the hidden promise came from your side, say so plainly. Writing "we did include this for the last few months, and we should have told you it sat outside the agreement" keeps more trust than acting as though it never happened. Clients can live with a change of terms. Being told they imagined the earlier arrangement is much harder.
Tip
In practice, this means: the client should never learn about a scope decision from an invoice.
How do you stop the same disagreement returning?
The same disagreement returns when the accepted change sits in one person's inbox instead of the client record. Three steps close it.
- Keep the accepted change with the client record, next to the agreement it changes, so anyone who opens the file sees both.
- Update the affected work: the job template, the recurring task, the report checklist and next year's quote.
- Tell everyone who serves that client, including whoever covers when the usual person is away.
This is the same discipline that makes client follow-up consistent: what was said to a client has to be findable by whoever speaks to them next. It matters most when people change. When the person who made a promise leaves, the promise stays and the context goes with them, which is how knowledge walks out with leavers.
It is also one of the first things to fail the two-weeks test: what breaks if you take two weeks off? If only you know what each client was promised, your team either says no and upsets the client, or says yes and gives away work.
A written record is the right place to start, and it does not have to stay manual. At Catalyst Systems we build systems that hold what the best people in a business carry. Clearly, our product, captures what happens in client conversations and connects it to what the business already knows, so your team can see what was promised before they answer.
Start with the client who argues most about what is included. Write up the last three exceptions they were given, decide which ones stay, and tell them. Scope gets easier to hold once the promises are visible.
Frequently asked
- What is the main cause of scope creep?
- There is rarely a single cause. Common ones are vague agreements, requests that seem too small to put through a change process, and team members adding work to keep a client happy. In small service businesses, a frequent cause is that the person doing the work cannot see an exception someone else agreed to earlier.
- Is scope creep always bad?
- No. Some changes add real value and are worth doing. Scope creep becomes a problem when the work grows without anyone deciding it should, so the price, timing and capacity never adjust to match.
- How do you say no to extra work without upsetting a client?
- Answer with what you can do as well as what you cannot. Acknowledge the request, say whether the agreement covers it, and offer options such as adding it at a price, swapping it for other work or scheduling it later. A clear answer before the work changes is easier for a client to accept than a surprise on an invoice.
- What is the difference between a change request and a variation?
- They describe the same idea. In Australian building and trade contracts, a formal change to the contracted work is usually called a variation, while service and project work more often uses change request. Use whichever term your agreements already use, and record the same details either way.