An intake form I inherited on a rescue engagement started with twelve fields. By the time I got the file, eight months later, it had thirty-one. Nineteen fields had been added one at a time, each one small enough that whoever approved it never thought to route it through change control. Not one of the nineteen showed up in a formal scope amendment. The schedule, meanwhile, still assumed twelve.
That's the shape scope creep actually takes. It isn't a client walking in and doubling the requirements. It's a hundred small yeses, each one reasonable on its own, that nobody added up.
Why change control misses it
Most change-control processes are built to catch the request that's obviously big: a new module, a new integration, a new region. They're not built to catch "can we also capture the customer's secondary phone number while we're in there," because that request doesn't look like scope. It looks like a two-minute favor. The threshold for triggering a formal review is usually a size test, and almost nothing individually clears it.
The Standish Group's long-running CHAOS research still puts outright project success at roughly 31%, with about half of projects landing in the "challenged" category. Large projects succeed less than 10% of the time. Unstable requirements have been one of the standing reasons behind those numbers for as long as the research has run, and drift below the change-control threshold is a large part of why they stay unstable even on programs that think they have a rigorous process.
The cost shows up somewhere else
Here's the part that makes drift expensive rather than just messy. Nobody bills the nineteen fields against the schedule, because nobody logged them as scope. So when the program slips, the postmortem looks at the twelve fields everyone agreed to and can't find the cause. The actual cause is sitting in a database migration script, a validation rule, a QA test plan that grew to match a form nobody remembers approving.
I've seen a QA plan run 40% longer than its original estimate on a program where the requirements document was, on paper, unchanged since kickoff. The team wasn't padding the estimate. They were testing a product that had quietly become a different product.
What to check instead of trusting the requirements doc
Signs scope has drifted without anyone formally approving it
- The requirements document hasn't been reopened in months, but the build has features that were never in it.
- Every small addition got a yes from whoever happened to be in the room, not from whoever owns the budget or the date.
- Ask three people on the team to describe what's in scope right now. You get three different answers, and none of them match the doc.
- The QA test plan or the acceptance checklist has grown since kickoff, but the schedule attached to it hasn't.
- There's a change log, technically, but its most recent entry predates the most recent actual change by weeks.
None of this requires blaming the people who said yes. Most of those yeses were the right call in isolation. The failure is structural: there's no mechanism that adds up a hundred small yeses and asks whether the twelve-field plan still describes the thirty-one-field product.
Tell me what's actually in scope
If the requirements doc and the actual build have quietly stopped matching, I'll help you find out how far apart they've gotten and what it's costing.
Tell me what's actually in scope