Scope creep rarely looks like a problem on the day it happens. It arrives as a small, sensible request, gets a quick yes, and only shows up weeks later as overtime or a missed date. Take a staff intranet briefed as five pages and a June launch: a staff directory is added in week three, room booking in week five, and by June the team is building seven things on a budget sized for five.

That is scope creep: work added to a project without matching changes to its time, budget or people. The Project Management Institute (PMI), the professional association headquartered in the US, calls it the uncontrolled expansion of product or project scope without adjustments to time, cost and resources.¹ In PMI’s own Pulse of the Profession surveys, project professionals have estimated that somewhere between a third and a half of their organizations’ recent projects experienced scope creep, depending on the survey year.²³ Scope creep is controlled by making every addition visible and priced before anyone agrees to it:

1. Write down the scope baseline, including what is out.
2. Log every request, however small.
3. Check the impact before anyone says yes.
4. Let the right person decide, within a set allowance.
5. Update the baseline and tell everyone.

Scope creep versus approved change: one decision apart

Scope creep is growth in a project’s work that nobody has paid for with extra time, money or people. Approved change is the same new work accepted on purpose, after someone has weighed its cost and adjusted the schedule, the budget or the rest of the scope to make room for it. The work can be identical; what differs is whether anyone decided to pay for it.

The distinction matters because change itself is normal. Projects learn as they go, and a plan that could never change would often deliver the wrong thing. The damage comes when the plan’s limits stay fixed while the work grows, because the extra effort is then taken from somewhere nobody chose, such as evenings or testing time. Those limits are set when a project is first defined, the ground covered in what project management is and how projects differ from ongoing work.

PMI’s lexicon supplies the two key terms. A scope baseline is the approved version of the formal scope documents; it is changed through formal change control, and it is what actual results are compared against. Change control is the process by which changes to documents, deliverables or baselines are identified, documented, and then approved or rejected.¹ PMI’s standards committees are chartered to use the lexicon’s terms without modification, so these are also the terms of PMI’s standards, the PMBOK Guide among them.⁴

PRINCE2, another established project method, says much the same thing in its own words: its change control procedure makes sure that every change that may affect a project’s agreed objectives is identified, assessed and then approved, rejected or deferred.⁵

In the intranet example, the staff directory could have been an approved change. The sponsor might have moved the launch by two weeks, or swapped the directory for one of the five planned pages. Either way, the plan would still describe the real project. The practical lesson: when a new request arrives, the question is never only “is this a good idea?” but also “what will we give up, or add, to pay for it?”

How common is scope creep? Practitioner surveys say very

Nobody measures scope creep across all projects, so the best available figures are practitioners’ estimates from PMI’s own Pulse of the Profession surveys. They put scope creep in a large share of projects, but the size of the estimate moves a lot between survey years.

The study

Limited evidence

How often scope creeps, in the estimate of 5,402 surveyed professionals

Asked what share of the projects their organization had completed in the previous 12 months experienced scope creep or uncontrolled changes to scope, respondents gave an average estimate of 52 percent, up from 43 percent five years earlier. In organizations PMI classed as champions, which reported most projects on time, on budget and meeting their goals, the estimate was 33 percent, against 69 percent in underperformers.²

These are impressions, not measurements. Each figure is a respondent’s guess about many projects, and the question bundles scope creep with any “uncontrolled change”. The gap between champions and underperformers is a correlation, and partly a built-in one: the groups were defined by how well their projects performed, so the better group would be expected to report less creep. PMI, which certifies project managers and sells training, is also not a neutral party.⁴

The estimate also shifts between years. In PMI’s 2021 edition, based on an online survey of 3,950 project professionals, the average estimate was about a third.³ PMI’s reports do not explain the drop, so the safest reading is a base rate rather than a trend: plan as if your project will face pressure to grow. In practice, use the kickoff meeting to agree who can approve changes and where requests get written down, so the rules are set calmly rather than in week five with the requester in the room.

Why projects creep: small yeses, blurry edges and a bias toward adding

Scope creep usually arrives as many small, reasonable requests rather than one large one, and each is accepted because saying yes is easier in the moment than working out what it costs. In a 2020 systematic reviewsystematic review: A review that fixes its question and its rules for including studies in advance, then searches out every study that fits and weighs them together. Some systematic reviews pool the results into a meta-analysis; others describe what the studies found without combining the numbers.Full entry in the glossary focused on software projects, the causes named most often were schedule pressure and weak scope management.⁶

Bakhtawar Komal and colleagues counted how often 29 studies from 2010 to 2018 named each cause, and changing requirements, project size and stakeholder involvement came next. A count of mentions is not a measure of effect, so read the list as a map of suspects rather than a ranking.⁶

PMI’s 2018 report describes creep as extra work that cannot be absorbed without missing an objective or passing up other opportunities. It adds that a lack of clarity makes creep nearly impossible to control, and that shifting priorities, changing objectives and inaccurate requirements gathering all feed it.² If nobody wrote down where the project’s edges are, every request looks like it might already be inside them.

A habit of mind may add to the pull. Across eight experiments, Gabrielle Adams and colleagues found that people asked to improve something tended to search for things to add and overlooked changes that took something away, especially when nothing prompted them to consider subtraction or when they were under heavier mental load. The authors, writing in Nature in 2021, suggest this default may be one reason people struggle to ease overburdened schedules.⁷ The experiments did not study projects, so treat this as a plausible contributor rather than a proven cause. It is one of several cognitive biases that shape everyday judgments.

Not every change is creep, though. PMI’s 2026 report describes requirements shifting because technology, markets and regulation move faster than the original plan, and because political dynamics among stakeholders keep reopening decisions.⁸ A change that keeps the project useful is worth having. The lesson is to ask of each request what it would replace, and to treat “can we also…” as a prompt to name something that could come out.

Further reading

• 

  Subtract: The Untapped Science of Less

  by Leidy Klotz

  Klotz, a co-author of the Nature experiments cited here, on why people default to adding and how to look for what could come out.

As an Amazon Associate WiserHours earns from qualifying purchases.

A control routine: baseline, change log, impact check

Controlling scope creep does not mean refusing change. It means every change passes the same checkpoints: a written baseline to compare against, a log where each request is recorded, and an impact check before anyone agrees.

PRINCE2 7 describes the steps as capture, assess, recommend, decide and implement: register the request, assess its effect on the project’s business case and risk profile, set out options, then approve, reject or ask for more information, and finally act and update the records.⁹ The five steps below adapt that sequence for teams without a formal method.

1. Scope baseline: the agreed work written down, including what is out
2. Change log: every request recorded, however small
3. Impact check: what the request costs in time, money, quality and risk, before anyone says yes
4. Decision: approve and update the baseline, reject, or defer, by someone with the authority to decide

1. Write down the scope baseline, including what is out

A baseline is the approved description of the work, and it is what makes creep visible: without one, there is nothing to compare a request against.¹ List the deliverables and the main features of each. Then add a short “not in this release” list, our own suggestion rather than a requirement of either standard. For the intranet, one line such as “no links to other company systems” would have turned the room-booking request into a visible decision.

2. Log every request, however small

PRINCE2 treats a request for change as a proposal to change the baseline and records it in an issue register alongside other issues, such as concerns and queries.⁵ A shared spreadsheet is enough: the date, who asked, what they asked for, why, and what was decided. Log the small requests too, because small requests are how creep arrives. A log also shows patterns, such as one stakeholder whose needs were missed at the start.

3. Check the impact before anyone says yes

For each request, ask four questions: what it adds, what it costs in time and money, what it does to quality and risk, and what could be dropped or moved to pay for it. For the intranet’s room-booking request, the answers might read: one new page; perhaps a week of developer time; a connection to the facilities calendar, which brings new risk; and, as the price, one of the five planned pages or a July launch. Written down like that, the request becomes a choice the sponsor can make.

Timing matters too. In a study of 162 construction projects, William Ibbs linked late changes to bigger losses of labor productivity than early ones, all else being equal.¹⁰ Our reading was limited to the abstract, and construction differs from office work, but the lesson travels: the later a request arrives, the more carefully its impact deserves checking.

4. Let the right person decide, within a set allowance

PRINCE2’s project board may delegate decisions to a change authority, a person or group that can approve requests within a change budget set aside for them.⁵ The same idea works informally. As an illustration, a team might agree that the project manager can approve changes up to a day of effort, while anything bigger goes to the sponsor. The mechanics of writing up and processing each request belong to a separate guide on change requests.

5. Update the baseline and tell everyone

An approved change should change the plan: the accepted request becomes part of the baseline, with new dates or budget where needed. Tell the team and the person who asked. A rejected or deferred request is recorded too, so it does not come back next month as if new.

WiserHours

Your scope control routine

• Write the scope baseline, with a not-in-this-release list
• Agree who can approve small changes and who approves big ones
• Log every request with date, requester, reason and decision
• Check time, cost, quality and risk before saying yes
• Name what could come out to make room
• Update the baseline, dates and budget after each approval
• Tell the team and the requester what was decided

Find this checklist online:
https://wiserhours.com/project-management/scope-creep/#checklist-scope-creep-routine

Agile teams control scope too, by trading instead of adding

Agile methods expect requirements to change, but they still guard against creep. The 2020 Scrum Guide fixes a goal for each sprint, allows no changes that would endanger it, and lets scope be clarified and renegotiated with the product owner as the team learns.¹¹ New work usually replaces something instead of landing on top.

PMI’s 2018 report notes that agile teams make requirements trade-offs and re-scope work at the start of each iteration, and it quotes Jesse Fewell, a core team member of PMI’s Agile Practice Guide, proposing a dynamic scope option.²

You can replace any not-started deliverable with anything of equal or lesser cost. As long as we stay within our business constraints, we have options.

In a Scrum team, for example, a stakeholder who asks for a new feature mid-sprint might be asked to wait for the next planning session, where the product owner decides what it displaces. The request is neither refused nor quietly absorbed.

Myth

Agile projects cannot suffer scope creep, because agile welcomes change.

Fact

Agile moves the control point. The Scrum Guide fixes the sprint goal and renegotiates the work around it, so new work displaces other work instead of piling on.

Teams outside Scrum can borrow the trade. Keep a short list of work that is agreed but not yet started, and when a new request arrives, ask the person making it which item on that list it should replace.

Standards and surveys, but no trials: weighing the evidence

The advice to baseline, log and assess changes rests on professional standards and practitioner experience, not on trials: we found no study that randomly assigned projects to use change control or not. The table sets out what each piece of evidence can support.

The honest reading: the routine is sensible practice, widely agreed, and cheap to try, but it is not a proven cure. Scale it to the project: a two-week job may need only a shared note of requests and a word with the sponsor, a year-long program a formal register and board. Either way, judge it by whether surprises in your own change log become rarer.

The bottom line

Change is normal; scope creep is change nobody paid for. Write down what the project includes and excludes, record every request, and check what each one costs in time and money before anyone agrees. When something new comes in, ask what it replaces, and update the plan so it keeps describing the project people are really running.