latest / Scope creep is a feature of how reality works

We talk about scope creep like it’s a moral failing. Someone, somewhere, should have held the line. The brief said five things, and now there are nine things, and this is a Process Problem.

It is not a process problem. It is the central fact about software projects, which is that you discover what you’re building by building it. The five things at the start were a guess made by people who did not yet have the information that building reveals. The nine things at the end are what the problem turned out to be. That isn’t creep — that’s learning, which we’d otherwise pay good money for.

What’s actually worth tracking isn’t whether scope changed. Of course it changed. What’s worth tracking is whether the changes were:

• Discovered. The customer’s actual workflow needed a step nobody mentioned in kickoff. Fine. This is what discovery looks like.
• Negotiated. We swapped feature X for feature Y because Y turned out to matter more. Fine.
• Bolted on. A senior stakeholder remembered something on the day of the demo and wedged it in unbudgeted. Not fine. Bolted-on scope is the one that actually hurts.

The bolted-on category is what people mean when they complain about scope creep, but the word “creep” makes it sound like a slow geological process rather than a specific decision someone made. Naming the decision is half the fight. “We’re adding X” is a discussion. “It’s just scope creep” is a shrug.

The most useful project management move I’ve learned, and the one I most often fail to actually do, is to ask, every time a new thing appears: which of the three buckets is this, and what’s coming out to make room. The second half is the hard part. There is always room, in theory; the date, in practice, does not move.