Scope Is a Choice
Every project slips for the same reason. Not because of bad estimates — because scope wasn't treated as a decision.
Every software project that ran late did so because someone added scope without removing something else.
This isn't a controversial claim. Ask anyone who's shipped a project behind schedule and they'll tell you the same story: the original plan was reasonable, then things got added, then the deadline didn't move.
The interesting question isn't why this happens. It's why teams keep acting surprised when it does.
Scope creep isn't an accident
Scope doesn't creep. It gets let in. There's always a person who said yes, a meeting where the decision got made, a feature that seemed small at the time.
The reason teams treat it as accidental is that no single addition ever looks like the thing that will sink the timeline. The problem is cumulative. By the time it's obvious, you're three weeks from launch and six weeks behind.
The default is always addition
When someone raises a new requirement mid-project, the default response in most teams is to figure out how to fit it in. The burden of proof is on exclusion, not inclusion.
This is backwards. The right default is: does this belong in the current scope, or does it belong in the backlog? What comes out if this comes in?
Treating every addition as a trade-off makes the cost visible. Most additions don't survive that question. The ones that do are genuinely important.
Fixed dates are a feature, not a constraint
The teams that ship on time aren't better at estimating. They're better at scoping. They commit to a date early and treat it as fixed. When something has to give, it's scope — not quality, not the date.
A fixed date forces prioritization. It makes the question "what actually matters?" unavoidable. Without it, everything matters equally, which means nothing gets cut, which means nothing ships.
What good scope decisions look like
Scope isn't set once at the start of a project. It's a live decision that gets revisited constantly. The best teams do this explicitly — a standing conversation about what's in, what's out, and what changed since last time.
When a new requirement comes in: is this in the core job the product needs to do? If not, it waits. If yes, what moves to make room for it?
That's not a process. It's just a choice, made consciously instead of by default.