Scope Creep

What actually happens

Scope creep is the growth of project scope outside the approval process, with no matching adjustment to schedule, budget, or resources. It arrives not as a dramatic event but as an accumulation of small requests: "just one button," "while you're at it," "that thing from last week's meeting." Over a few weeks, the contracted scope and the scope the team actually builds quietly diverge. There is a self-inflicted variant too — gold plating, adding unrequested improvements, is the same problem from the other direction. Either way, the common thread is scope that grew with nothing paid for it.

Why it matters

Scope forms a triangle with schedule and cost. When scope grows and the other two stay fixed, the difference is paid in overtime and degraded quality. Worse is the distortion of measurement: progress and the Schedule Performance Index (SPI) compare actuals against the approved plan, and crept work is not in the plan — so the team does the work and the metrics get worse anyway. The harder the team works, the worse it looks. The damage of scope creep is not that more work was done; it is that the extra work is accounted for nowhere.

Common misconceptions

The common one is treating scope change itself as the sin. Mid-project scope change is natural and sometimes right; the problem is not change but the absence of control. A change that passes impact assessment and approval, adjusting the baseline, schedule, and budget together, is not creep — it is managed change. Nor is procedure the only defense. With the 100% Rule standing — all scope must live inside the WBS tree — creep becomes immediately visible as "work that is not in the tree," and with a baseline from approval time, you can prove by comparison how far today's scope has drifted. Without that structure, catching creep depends on someone's memory.