The Inevitability of Scope Creep

Scope creep is inevitable. A project starts with a small mandate and ends with an enormous, uncontrolled scope. What was a small change is now a complete rewrite. It’s easier to visualize scope creep with software projects — you can easily see the number of services or areas of code that a change touches. And it’s sometimes easier to measure (which changes aren’t in the critical path of the goal feature or product?). But it happens in almost every project. I don’t think it can be eliminated entirely, but understanding the sources and the consequences might help limit its reach.

Why does scope creep happen?

1. Unclear requirements. Not all the requirements are known ahead of time. As new ones are discovered, it’s easy to misunderstand which are essential to delivering the project and which ones aren’t. Sometimes, it’s as complicated as backtracking an existing solution to find a simpler path once more data is collected.

2. Stakeholder pressures. Clients, customers, and other stakeholders will often push to increase the scope of a project after it’s underway.

3. Overconfidence / overestimation. We’re bad at making estimates of how long things will take. A quick refactor or alteration can be much more costly than it seems. It’s hard to balance the relative short-term benefit (e.g., modifying an area of code and deciding to refactor it simultaneously) to long-term (or even medium-term) maintenance, regressions, and other unforeseen work that the change creates.

4. Alternative (sometimes competing) incentives. It’s easy to want to try out the latest technology or framework. In many cases (side projects), it’s probably a great excuse to learn a new skill. But for the most part, it's perhaps not the most efficient tool unless the new technology specifically enables the product or feature.

Why it’s bad

1. Inefficient resource allocation. Increased scope usually isn’t given the same scrutiny when it comes to resource allocation as the initial requirements.

2. Hard to measure. Changing too many variables at once makes effects hard to measure. Too many features bunched into one release makes it difficult to know what worked from an external (what do customers like?) and internal (how long did each feature take?) perspective.

3. Delayed timelines. Delayed timelines have real consequences within organizations. Flexible deadlines and stakeholder pressures create a negative flywheel — if deadlines don’t matter, there’s always room for another feature.