Scope Creep: How to Spot It and Stop It
· 7 min read
Scope creep is work that enters a project without a decision about what it costs. You stop it with two written things: a signed list of what is in, out and later, and a short change-request routine that puts a price and a date on every new request before anyone starts. Below is what it looks like, where it comes from and what to do when it has already happened.
What scope creep looks like
The PMI describes scope creep as the uncontrolled expansion of project or product scope without matching changes to time, cost and resources (PMI, Scope and stakeholder management). The word that matters is uncontrolled. Scope may change, and often should. The problem is a change that nobody priced.
In practice it rarely arrives as one large request. It looks like this:
- "While you are in there, can you also…" added to a task that is already running.
- A small tweak to the same screen for the third time, each one "just five minutes".
- A requirement that is quietly read more widely: "user management" turns from a login page into roles and permissions.
- A stakeholder who was not in discovery joining in month three with a list.
- A "bug" report that is really a feature nobody wrote down.
- Work done for free to keep the relationship friendly, which sets the price of the next request at zero.
A useful test is to ask of any request: "Is this in the agreed list?" If nobody can answer, the list is the first thing to fix.
Where it comes from
Most creep traces back to one of four causes, and only one of them is a difficult client.
- The scope was never written down. If "what we are building" lives in meeting memory, every person remembers a slightly different project.
- The "out" list does not exist. Teams write what is included and forget to write what is not. The excluded items are the ones that return as requests.
- New people arrive late. A stakeholder who has not been asked in discovery will have needs. The earlier you ask, the fewer arrive as surprises. A stakeholder analysis is the cheapest defence.
- Estimates were a single number. A fixed price with no listed assumptions leaves nothing to point at when a request changes them.
The fourth cause is partly a pricing habit. How to estimate a software project covers ranges and written assumptions, which turn "this is more work" into a visible fact.
Prevention: a signed in, out and later list
Take the prioritised requirements and sort each one into a column, then write the result as one short section of the scope document. How to scope a software project walks through this step by step.
| In (this release) | Out (not this project) | Later (a known next step) |
|---|---|---|
| All Musts | Ideas that do not serve a goal | Shoulds and Coulds that did not fit |
| Shoulds that fit the budget | Work someone else owns | Items waiting on a decision or dependency |
Four habits make the list work:
- Write the "out" column in full sentences. "No native mobile app; the web app works in mobile browsers" is clearer than "mobile: out".
- Give "later" items a trigger, such as "after the pilot", so they do not read as forgotten.
- Review it line by line with the decision maker. Silence is not agreement.
- Reference the list in the contract or statement of work, so it is the same document everyone points to. A statement of work template shows where it fits. This article is not legal advice; have a lawyer review any wording that matters.
The priority labels come from the MoSCoW prioritization guide: Must, Should, Could and Won't (this time). The "Won't" items belong in the "out" column.
Keep the assumptions next to the list. In the example report of an invented project, Fieldwise, the milestones sit beside four assumptions, such as that the first release covers two of three regions. When a request breaks one of them, the assumption tells you which date and which estimate move:
Before the list is final, the discovery phase checklist asks whether the scope for the first release is agreed in writing, and whether the next step is clear:
A simple change-request routine
When a new request arrives, run the same four steps every time. The routine is deliberately small, so that people actually use it.
- Log it. Write the request down with the date, who asked, and what they want in one sentence. Do not start work yet.
- Check it against the list. Is it in, out or later? If it is already in, it is not a change; if it is out or later, it is.
- Price it as a range. Give the effort as a low and a high figure, the effect on the date, and what it depends on. If it pushes out the date, say which milestone moves.
- Decide in writing. The decision maker accepts it (with the cost and date), swaps it for something already in, defers it to "later", or declines it. Record the decision on the same log line.
A change log can be one line per entry: date, request, rough hours, status (decided or pending). Anything that would start a long discussion can wait until the point where a decision is needed, so the log stays something people read.
The swap is the most useful answer. "We can add that if X moves to the next release" is a choice, not a refusal, and it uses the priority you already agreed.
What to do when it has already happened
If the project is already carrying unpriced work, repair it in this order:
- Write down what is in the project today, including the extras. Do not argue about who is to blame; just list.
- Compare it with the original list. The difference is the creep. Count it in the same units as the estimate.
- Tell the sponsor plainly: here is what was agreed, here is what has been added, here is its effect on cost and date.
- Offer three options: absorb the cost, move the date, or remove items of equal size.
- Start the routine now. Past work is past; the aim is that the next request is priced before it is started.
If the original scope was never written, take the earliest document that describes the project, such as the discovery output or the proposal, and treat it as the baseline. It is not perfect, but a baseline you can point at beats none.
Scope creep is easier to prevent in discovery, when the list is cheap to change. If you are deciding whether you need a discovery phase at all, do you need a discovery phase lists the signs that the scope is unclear enough to justify one.