Field Note: Scope Creep
Date: 2025-01-28 Sector: PROJECT MANAGEMENT Read Time: 4 minutes
It started as a simple website redesign. Six months later, it was a full platform rebuild with a mobile app, user accounts, an admin dashboard, and an AI chatbot. Nobody remembers who asked for the chatbot.
The Observation
A small agency was hired to redesign a client's marketing website. Clear scope: new visual design, improved navigation, mobile responsiveness. Budget: $25,000. Timeline: 8 weeks.
Week 2: "While we're at it, can we add a blog section?" Week 3: "The CEO wants a customer portal." Week 5: "Sales needs a lead scoring feature." Week 7: "What about integrating with our CRM?" Week 10: "We need an analytics dashboard."
Each request was small and reasonable in isolation. The client wasn't being malicious. They were excited. But each "small addition" added complexity, dependencies, and time.
Final delivery: 7 months, $80,000, and a product that tried to do everything and did nothing well. The original goal — a clean marketing site — was buried under features nobody used.
The Mechanism
Scope creep works through four forces:
1. The "While We're At It" Fallacy
Every new feature feels cheap when the team is already building. "We're already in the codebase, just add this one thing." But each "one thing" interacts with every other thing. Complexity isn't additive — it's multiplicative.
2. Stakeholder Expansion
The project starts with one decision-maker. Then their boss has opinions. Then the sales team has requests. Then the CEO sees it in a meeting. Each new stakeholder brings new requirements. None of them see the full picture.
3. Yes-Culture
Many teams default to "yes" because saying "no" feels uncooperative. But every "yes" is a "no" to something else: the timeline, the budget, the quality of existing features, or the team's sanity.
4. Unclear Success Criteria
If "done" isn't defined, the project is never done. There's always one more feature, one more improvement, one more stakeholder request.
The Damage
Scope creep doesn't just cost money. It:
- Destroys focus: The team can't do deep work when requirements keep changing
- Kills quality: Rushed features have more bugs, worse UX, and higher maintenance cost
- Burns trust: Timelines slip, budgets balloon, and everyone blames everyone else
- Demoralizes teams: Nothing is ever "done" — the goalpost keeps moving
How to Fight It
Define Scope in Writing
Before starting, document exactly what's in scope and what's out of scope. Both lists matter. "Out of scope" is not a rejection — it's a "not this time."
Use a Change Request Process
New requests don't get added — they get evaluated:
- What will this add to the timeline?
- What will this cost?
- What will it delay or replace?
- Is it worth more than what it displaces?
The overhead of the process is the point. It creates friction that separates "nice to have" from "actually important."
Apply MoSCoW
Categorize everything as Must/Should/Could/Won't. When new requests arrive, they enter as "Could" or "Won't" by default. They must justify their way to "Must."
Time-Box the Project
"This project ships on March 15. The scope is whatever we can finish by March 15." Fixed time, flexible scope is healthier than fixed scope, flexible time — because time always expands.
Practice Saying No (Or "Not Yet")
"That's a great idea. Let's add it to the V2 backlog." This isn't a no. It's a "yes, later." The feature gets captured, the stakeholder feels heard, and the current scope stays clean.
The Paradox
The projects with the tightest constraints often produce the best results. Constraints force prioritization. Prioritization forces clarity. Clarity produces focus. Focus produces quality.
The project that tries to do everything does nothing well. The project that does three things excellently ships on time and delights users.
See also: Prioritization Matrix | Time-Boxing | Constraint Mapping