PWPM Wiki
🎯 Scope, Requirements & WBS

Scope Creep

Scope creep is the uncontrolled expansion of a project’s scope — features and work slipping in without matching adjustments to time, budget or resources — and it is one of the most common reasons projects run late and over budget.

Scope creep is the gradual, unauthorised growth of project scope after the baseline is set. It happens when new requirements, features or "small additions" are absorbed into the project without going through change control — so no one updates the schedule, budget or expectations to match. Each addition may seem trivial, but together they overload the plan. It differs from legitimate scope change, which is requested, assessed and formally approved with corresponding adjustments.

Scope Creep at a glance

Category
Scope, Requirements & WBS
Type
Concept
Appears in
1 section
Related
Scope Baseline, Scope Change, Scope Statement

Why it matters

Understanding scope creep matters because it is silent and cumulative. Unlike a blown deadline, which is obvious, scope creep erodes a project from the inside: the team keeps saying yes, the baseline never changes on paper, and the gap between plan and reality widens until the project misses its dates or budget "for no clear reason". Naming and controlling it protects both the schedule and the team.

When to use it

Guard against scope creep from the moment a scope baseline exists — throughout execution. The risk is highest on projects with vague requirements, many stakeholders, weak change control, or eager-to-please teams. Recognising the early signs (frequent "can you just also…" requests) is the key to catching it.

How to use it

  1. Define scope precisely up front — a clear scope statement and WBS, with explicit exclusions.
  2. Establish a change control process so every addition is a visible request, not a quiet absorption.
  3. Assess each change for its impact on schedule, cost and quality before deciding.
  4. Say no, or "yes — and here is the revised date/budget", rather than an unconditional yes.
  5. Track scope against the baseline and raise creep as a risk the moment a pattern appears.

Example

A website project is baselined at five pages. Over two months the client asks for a blog, then a newsletter signup, then a members area — each framed as minor. None goes through change control. The launch slips a month and the team is blamed for being "slow", when in fact the scope had quietly doubled. A change process would have made each addition a costed, dated decision.

Template

The antidote is a change request form and change log plus a crisp scope statement; use those templates to make every addition explicit.

Browse templates →

Tools

Change control board processJira (change tickets)SmartsheetConfluence

FAQs

What is the difference between scope creep and scope change?
Scope change is requested, assessed and formally approved with time/budget adjustments. Scope creep is the same additions happening informally, without approval or adjustment — the uncontrolled version.
What causes scope creep?
Vague initial requirements, weak or absent change control, too many stakeholders with direct access to the team, gold-plating, and a culture of saying yes without assessing impact.
How do you say no to scope creep politely?
You rarely say a flat no. You say "yes, and here is what it means" — quantify the impact on date and budget and let the sponsor decide. That converts creep into a controlled, owned change.

Alternatives

  • Change control — the process that prevents creep
  • Agile scope management — fixed time/cost, flexible scope via the backlog
  • Gold plating — a related anti-pattern (adding unrequested "improvements")