Scope creep rarely arrives as one big request. It comes as a second round of revisions, one more report, a page nobody priced, each small enough to say yes to. By the end, the project can easily have grown by a quarter, and the budget and the team have absorbed it without anyone deciding they should. 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 the project’s scope,” up from 43 percent five years earlier (PMI).
This guide explains what scope creep is, how it differs from a legitimate scope change, and what it looks like in practice, with five examples. It then covers something most guides skip, which is measuring scope creep in hours and money from your own time data so you can spot it while the project is still running.
What is scope creep?
Scope creep is the gradual, unapproved growth of a project’s scope after work has started. The scope creep definition in a paper by Richard and Elizabeth Larson, presented at PMI Global Congress 2009, is “adding additional features or functions of a new product, requirements, or work that is not authorized (i.e., beyond the agreed-upon scope).” The PMBOK Guide they cite describes it as “adding features and functionality (project scope) without addressing the effects on time, costs, and resources, or without customer approval” (PMI, Top Five Causes of Scope Creep).
The words that matter are “without addressing the effects.” Scope creep in project management is not the same as change. Projects change all the time, and many changes are good. Creep is change that nobody prices or approves, so its cost quietly lands on the budget and the team.
Other names for the same problem include requirements creep, feature creep (common in software), and kitchen sink syndrome.
Scope creep vs scope change vs gold plating
Three things that look alike on a task list need different responses.
| Term | What happens | What to do |
|---|---|---|
| Scope change | New work is requested, assessed, priced, and approved, and the budget or deadline is adjusted | Nothing wrong; this is how change should work |
| Scope creep | New work is added through small requests with no change to budget, deadline, or resources | Route requests through a change process and price them |
| Gold plating | The team adds extras the client never asked for | Agree on a definition of done and stop at it |
What separates the first two is approval, not the size of the request. A large change that was approved is a scope change. Ten small ones that nobody approved add up to creep.
What causes scope creep
The Larsons’ PMI paper names five causes, drawn from two case studies:
-
Ambiguous or unrefined scope definition.
If scope and requirements are not “clear and precise,” the paper calls it a “breeding ground” for scope creep.
-
No formal scope or requirements management.
Without a process for handling new requests, every request is handled informally, and most get absorbed.
-
An inconsistent process for collecting requirements.
Fuzzy boundaries bring in extra stakeholders and extra requirements.
-
Weak sponsorship and stakeholder involvement.
Stakeholders who join late, or a sponsor who does not defend the scope, invite late additions.
-
Project length.
The paper notes that longer projects “don’t directly cause scope creep,” but they give needs more time to change.
In client work, watch for two more patterns: fixed price contracts with loose deliverables, where every extra is free to the client, and teams that never say no because the request seems small. If your team regularly works late near deadlines, scope creep is one of the first things to check, as our guide on how to reduce overtime explains.
Scope creep examples
These five scope creep examples are illustrative. None of them starts with a single dramatic request, and that is what makes the pattern so easy to miss.
- Agency website. A 12 page site grows to 17 pages through “just one more landing page” requests over two months. The fixed fee stays the same, and design and content hours rise by about 40%.
- Software feature. A reporting module is scoped with three reports. Each review adds a filter, an export format, or another chart, and the module ships six weeks late.
- Internal rollout. A new HR system is planned for one department. Two more departments ask to join halfway through, and the project team, timeline, and training budget stay the same.
- Construction. An owner asks for upgraded finishes during the build. If they go through a priced change order, that is a scope change. If the contractor absorbs them to keep the client happy, it is creep.
- Agile sprint. A stakeholder adds two urgent stories in the middle of a sprint without removing anything, and the sprint goal slips.
In each case, the fix would have been the same question: what do we drop, or what do we add to the budget and the schedule, to make room for this?
Is scope creep good or bad?
Uncontrolled scope creep is bad by definition, because its cost is never decided by anyone. The change behind it is often good. A client who asks for more is engaged, and a new requirement may make the product better. One PMI interviewee, Monica Sacco of IBM, also pointed out that experiencing scope creep is “a very good way to learn lessons, gain experience and improve the controls” for the next project (PMI, Scope Patrol).
So the aim is to turn creep into scope change rather than turn the request down. The request stays the same, but its cost is now visible and approved.
How to measure scope creep in hours and money
Most teams notice project scope creep when the deadline is already at risk. Time data shows it weeks earlier, as long as hours are tracked against tasks and each task has an estimate. Four numbers are enough:
| Metric | How to calculate it | What it tells you |
|---|---|---|
| Scope creep rate | Hours on tasks added after kickoff without approval, divided by the original estimate | How much the project has grown without a decision |
| Estimate variance on original tasks | Actual hours on planned tasks minus their estimate | Overruns caused by estimating, not by scope; keep the two apart |
| Approved vs absorbed requests | Count of new requests that went through change control vs those that did not | Whether the change process is actually used |
| Cost of absorbed work | Absorbed hours times the cost rate, and times the billing rate for client work | What scope creep is costing in margin |
Worked example: a fixed price website project
The figures are illustrative. An agency sells a website for a fixed fee of $38,000, based on 400 estimated hours at a $95 blended rate. The team’s average cost is $55 an hour, so planned margin is $16,000, or 42.1%.
It pays to split the overrun. Of the 150 extra hours, 30 come from estimating and 120 from scope creep. The first calls for better estimates next time. The second calls for a change process now, and a conversation with the client about the $11,400 of unbilled work.
How to manage scope creep
Good scope creep management, or knowing how to handle scope creep, mostly comes down to making each change visible and deliberate. The steps below apply to client and internal projects.
1. Define scope in a way you can check against
A scope of work or scope statement should list deliverables, what is explicitly excluded, and acceptance criteria. Break it down into tasks with estimates, for example with a work breakdown structure. If a request cannot be matched to a task, it is new scope.
2. Agree on a change process before work starts
Write down who can request changes, who approves them, and how they are priced. PMI’s interviewees stress putting this in the contract. Sacco advises that “a contract should clearly state the client’s responsibilities and must contain the change management procedure that will be used with the client.”
3. Assess every request against time, cost, and priority
Estimate the hours, show the effect on the deadline and budget, and offer options: add it with more time or money, swap it for something of equal size, or move it to a later phase. A request that costs nothing to say yes to will keep coming.
4. Say “not now” instead of “no”
A flat refusal can strain the relationship. If you log the request for a later phase with an estimate, the client feels heard and the current scope stays intact.
5. Track hours against the plan every week
Compare actual and estimated hours per task weekly, and flag tasks that were not in the original plan. Small additions are easy to discuss in week three and hard to recover in week twelve. Reporting on this belongs in your regular project status reports.
Scope creep in agile projects
Agile methods welcome changing requirements, which leads some teams to assume scope creep cannot happen. It can. The Scrum Guide says that during a sprint “no changes are made that would endanger the Sprint Goal,” while “scope may be clarified and renegotiated with the Product Owner as more is learned” (Scrum Guide). Change goes through the backlog and the Product Owner, not straight into the current sprint.
Budgets still apply. Claudia Farias of Citibanamex told PMI that “a new requirement shouldn’t be introduced into the backlog without verifying how it impacts the budget.” In agile terms, scope creep is new work that bypasses the backlog, or a backlog that grows while the budget and release date stay fixed.
Catching scope creep in actiTIME
actiTIME tracks time against customers, projects, and tasks, which is what the measurements above need.
- Task estimates and the Estimated vs. Actual Time Report show which tasks run over and by how much.
- Time budgets on projects and tasks turn red when exceeded, and cost and billing budgets show the money side (project budgets).
- Each task keeps a change history with the date, action, and user, so you can see which tasks were added after kickoff.
- Custom fields let you mark tasks as change requests, approved or absorbed.
- The Cost of Work Report and Profit/Loss Report show what added work costs against what it earns.
FAQ
What is scope creep, with an example?
Scope creep is unapproved growth in a project’s work after it starts. Example: a 12 page website becomes 17 pages through small requests while the fee and deadline stay the same, so the extra work comes out of the margin and the team’s time.
What best describes scope creep?
In short, the scope creep meaning is adding work to a project without adjusting time, cost, or resources and without formal approval. What gives it away is the missing decision. The size of the addition matters less.
What is another word for scope creep?
Requirements creep, feature creep, and kitchen sink syndrome are the most common alternatives. Gold plating is related but different: it describes extras the team adds on its own initiative.
How do you handle scope creep with a client?
Acknowledge the request, estimate it, and offer options: more budget or time, a trade for something of equal size, or a later phase. Point to the change process in the contract, and bring the hours data, which makes the conversation about facts rather than goodwill.
How common is scope creep?
Very. In PMI’s 2018 Pulse of the Profession, 52 percent of completed projects experienced scope creep or uncontrolled scope changes. In PMI’s 2023 report, even organizations that prioritized power skills saw scope creep on 28 percent of their projects (PMI).
Make every change a decision
Scope creep is a decision problem more than a client problem. Each small request either goes through a process where its cost is seen and agreed, or it slips into the project unpriced. If you define scope you can check against, agree on how changes work, and compare hours with estimates every week, most creep becomes ordinary approved change.
To see where your projects grow, start a free trial of actiTIME. It runs for 30 days with every feature included, and afterward you can keep the permanent free version for teams of up to 3 users.
