Scope creep is the gradual expansion of a project beyond what was agreed, without a corresponding change to the timeline, budget or team. The word suggests something happening to you, which is part of why it persists — in practice it is a series of small decisions, each individually reasonable, that nobody recorded as a decision.
It almost never arrives as a request for something large. It arrives as "while you're in there, could you also…", as a stakeholder who was not consulted appearing in week six, and as a deliverable that was described vaguely enough that the client's reading is larger than yours.
Where it actually comes from
- A vague scope, where two readings are both defensible and the client's is bigger.
- Missing acceptance criteria, so "finished" keeps moving.
- Small requests made directly to the person doing the work, who says yes because refusing feels disproportionate.
- Stakeholders discovered late, each with requirements nobody collected.
- Undocumented assumptions — data quality, access, decision speed — that turn out false.
- Gold-plating from your own side: improvements nobody asked for that consume real days.
- Discovery genuinely revealing that the original plan was wrong, which is legitimate and still needs re-planning.
- A change process that exists on paper but is slower than just doing the work.
The most common source is not the client. It is the individual contributor who agrees to a twenty-minute favour twenty times, because each refusal would seem petty and nobody has told them that logging it is not the same as refusing it. Give people a way to say "yes, and I'll log it as a change" — that sentence solves most of the problem, and it needs to be explicitly sanctioned by whoever manages the relationship.
Keeping scope visible
- Write scope and out-of-scope in the statement of work, specifically enough that a new person could classify a request.
- Give every deliverable acceptance criteria, so completion is testable rather than negotiable.
- Route all requests through one channel — not to individuals — and make that channel faster than a corridor conversation.
- Log every request, including the ones you agree to for free. The log is what makes the pattern visible at week eight.
- Say the sentence: "we can do that, it is outside the agreed scope, here is the impact". Neutral, not confrontational, and it converts a favour into a decision.
- Show the cumulative impact rather than pricing each small item. Twenty half-days is a conversation; half a day is not.
- Re-baseline when discovery genuinely changes the picture, instead of pretending the original plan survives.
- Review scope changes at every status report, so the client sees the accumulation as it happens rather than at the end.
- Track your own gold-plating with the same log — it is scope creep with better intentions.
Saying yes is often right
Refusing everything is not scope management; it is a way of being unpleasant to work with, and clients remember it. Small accommodations build the relationship, and the goodwill is real. What matters is that they are recorded as accommodations rather than absorbed silently, so that when the timeline slips the conversation is about a documented list rather than a feeling. A supplier who can show fourteen logged extras delivered at no charge is in a strong position; one who says "we did lots of extra work" is not.
Ettex Board makes the accumulation visible: columns and cards with drag-and-drop, a label for anything outside the original scope so a filter shows the whole list at once, assignees so requests are not absorbed silently by whoever was asked, due dates, checklists inside cards, and WIP limits that make the cost of extra work visible in flow rather than in a spreadsheet. Every move and edit is logged per card. The agreed scope lives in Ettex Docs with version history, incoming requests arrive through Ettex Forms rather than by message, and the cumulative impact on time and money is easiest to show from Ettex Sheets at the status meeting.
Said plainly: Ettex has no project-management engine. There is no baseline versus actual tracking, no earned value, no critical path, no automatic variance reporting and no scope-change workflow. A label on a card and a logged request are conventions you maintain. That is enough for a small team; formal change control across a programme wants dedicated PM software.
Signals scope has crept
- The team is busy but milestones do not move.
- Nobody can say confidently whether a given request is in scope.
- Work appearing on the board that nobody can trace to a deliverable.
- Requests arriving directly to individuals rather than through the agreed route.
- The phrase "it's only a small thing" recurring in stand-ups.
- A stakeholder appearing after week four with requirements.
- Margin falling while the client is satisfied — the classic silent case.
- The change process bypassed because it is slower than doing the work.
Frequently asked
What is scope creep?
The gradual expansion of a project beyond what was agreed, without matching changes to timeline, budget or resources — usually through many small unrecorded additions.
What causes it?
Vague scope, missing acceptance criteria, requests made directly to individuals, late-appearing stakeholders, false assumptions, and a change process slower than simply doing the work.
How do you stop it without damaging the relationship?
Log everything and price the accumulation, not each item. Small accommodations are often worth granting — what matters is that they are recorded as accommodations rather than absorbed silently.
Is scope creep always bad?
No. Discovery sometimes shows the original plan was wrong, and adapting is correct. The failure is doing so without re-planning the timeline and budget.
What is the difference between scope creep and a change request?
A change request is a decision made visibly, with an impact assessment. Scope creep is the same expansion happening without anyone deciding.
Who is usually responsible?
Most often the supplier's own team, agreeing to small favours individually. Giving people permission to say "yes, and I'll log it" removes most of the problem.
Scope creep is unrecorded decisions. Write the exclusions, give deliverables acceptance criteria, route requests through one channel, and log every yes — then price the accumulation rather than arguing about half-days.