Skip to content

What is scope creep, and who pays when a project's scope grows?

Scope creep is the growth of a project's scope with no matching change to time, cost and resources: added work that nobody has estimated, priced or rescheduled.

Scope creep is the uncontrolled drift, or expansion, of a project's scope, meaning the set of things the project has committed to deliver. The Project Management Institute (PMI), the association of project managers, defines it in version 5.0 (2026) of its official glossary, the Lexicon of Project Management Terms, as the uncontrolled expansion of product or project scope without adjustments to time, cost and resources. A project can grow, and often has to: growth becomes scope creep when the extra work comes in one piece at a time, through an email, a meeting, a "while you're at it," without anyone estimating its cost, moving the date or deciding who pays for it. Each addition looks small on its own. Added together, they eat the budget, delay the benefits and leave client and supplier arguing over what the price covered.

See also: Time & Material vs Turnkey (T&M vs TK) · T&M (time and material) and TK (turnkey) are the basic ways to buy an IT project: days billed at a rate with the client in charge, or an outcome at a set price.

Why scope drifts in data and AI projects

In data and AI projects, scope grows not only through new requests but through what the team discovers along the way: a table everyone thought complete is missing years, a key field is filled in three different ways, the model reaches the promised accuracy on only half the products. Each discovery opens work nobody planned, and the temptation is to absorb it quietly so the project keeps moving. Who pays for that drift depends on the contract, as the entry on time and material and turnkey explains. Under T&M every extra day falls on the client. Under turnkey the price covers the written scope, but in an Italian appalto (a contract to deliver a work or service), unless agreed otherwise, client-requested additions are billed separately.

The change request as a control

What separates managed change from scope creep is the change request, which the same PMI Lexicon defines as a formal proposal to modify a document, deliverable or baseline, meaning the approved version of scope, schedule or cost. It works when every request follows the same path: the supplier estimates its effect on cost and schedule, and the client approves or rejects it in writing. A change that has been priced and rescheduled is not scope creep, even when it is large. The starting scope belongs in the statement of work, the document that describes what will be delivered: without that reference, nobody can say what counts as an addition. In agile, the Scrum Guide allows scope to be clarified and renegotiated with the product owner, the person who sets priorities, as more is learned during the sprint, the fixed-length work cycle, provided no change endangers the Sprint Goal.

An enterprise example

A retail chain commissions a model that forecasts weekly sales for each store, at a fixed price. In the second month, marketing asks to include the effect of promotions, then someone notices that stores open for less than a year do not have enough data. Every request arrives in a meeting, and the supplier says yes. At release the model covers everything poorly, the date has slipped by three months, and the supplier submits a bill for extra work the client considered already included. With a change log, promotions would have become an estimated and approved change, and the new stores an explicit decision: leave them out or pay to collect the missing data.

Why it matters for decision makers

In the 2018 edition of PMI's annual Pulse of the Profession survey, the 4,455 project management practitioners who responded estimated that 52% of projects completed in the previous twelve months had experienced scope creep or uncontrolled changes to scope, up from 43% five years earlier. The figure is eight years old and is best read as an order of magnitude. The same report ranks avoiding scope creep among the three factors with the most impact on project success. For whoever signs the contract, the defense is cheap: a written scope with its exclusions, a single path for changes and a budget reserve that is spent only on approved requests.

Frequently asked questions

A change request is the formal proposal to modify a deliverable or the approved version of scope, schedule or cost, according to the PMI Lexicon. Scope creep is change that skips this step: the extra work comes in with no estimate, no new date and no agreement on who pays for it.

No. The PMI Lexicon definition does not say who adds the work: it only asks whether time, cost and resources were adjusted. So it also covers the supplier's team adding features on its own initiative, perhaps to impress, without estimating them or getting them approved.

By writing the scope, with its exclusions, in the statement of work, by placing a data review phase, under a spending cap, before development, and by routing every addition through a change request that is estimated and approved in writing before the work starts.
  • Time & Material vs Turnkey (T&M vs TK) · T&M (time and material) and TK (turnkey) are the basic ways to buy an IT project: days billed at a rate with the client in charge, or an outcome at a set price.
  • Statement of Work (SOW) · A statement of work (SOW) is the document that sets out what a supplier must deliver: the outcome, data, acceptance criteria, change process and exclusions.
  • Agile · Organizing development in short cycles, re-deciding priorities: it works only if the contract lets the scope change.
  • RFI vs RFP vs RFQ · RFI, RFP and RFQ are supplier requests that differ by how much the buyer knows: ideas on an open problem, proposals on requirements, prices on a closed spec.

See it in the universe

If it is a technical decision you keep postponing, that is the decision I help you make.

SEE CUSTOM TOOLS AND GOVERNANCE

Or write to me.