Anatomy of a Project Failure: A Scope Creep Breakdown

Scope creep almost never announces itself as one big decision. It shows up as a dozen small, individually reasonable ones. Here's a teardown of a project I watched go from a tightly scoped six-week build to a five-month slog; decision by decision, so you can see exactly where it could have been stopped.

Weeks 1–2: the scope was genuinely clear. A customer-facing dashboard, three data sources, one export format. Sponsor and team agreed on it in writing. This is the part every project gets right.

Week 3: a stakeholder asked, in passing, 'while you're in there, can we add a fourth data source? It's probably small.' The PM said yes on the spot, without re-checking the timeline or naming the trade-off out loud. It felt like the right call, saying no to a small, reasonable-sounding request seemed pettier than the cost of saying yes.

Weeks 5–6: two more 'quick adds' arrived; a filtering feature, and a second export format for the finance team. Each came from a different manager, each assumed someone else had already weighed the trade-off, and each was approved the same way: informally, quickly, without updating the plan.

Week 10: velocity had visibly dropped and the team was quietly frustrated, but nobody escalated, because no single addition felt big enough to justify raising an alarm. The failure wasn't any one of those requests. It was the absence of a change-control conversation the very first time scope moved, the moment that set the norm for every addition after it.

The fix that would have stopped this at week 3: one sentence, every time scope shifts, no matter how small. 'This adds X — here's what it displaces, and here's who needs to approve that trade-off.' Log it, even informally. That single habit, not a heavier process, is usually the entire difference between scope that evolves deliberately and scope that erodes a timeline nobody agreed to abandon.