The Stakeholder Who Keeps Moving the Goalposts
Scope creep in AI projects rarely looks like bad faith. It looks like enthusiasm. Here's how to handle it without torching the relationship.
Every AI project has one. The stakeholder who was thrilled with the original scope, approved the plan, and then — two weeks in — starts asking if the system could also do this other thing. Just a small addition. Won’t take long.
It never takes not long.
Scope creep in AI is different from scope creep in regular software projects. When someone adds a feature to a web app, the worst case is a few extra sprints. When someone adds requirements to an AI system — new data sources, new task types, new output formats, new edge cases to handle — the blast radius is larger. You’re not just adding code. You’re potentially invalidating your evals, retraining your models, rebuilding your prompts, and re-testing assumptions you thought were settled.
And yet, the conversations that lead to scope creep almost never feel adversarial. They feel collaborative. Someone gets excited. They see what you’re building and realize it could solve more of their problems. That enthusiasm is genuinely good — it means you’ve built something worth caring about. The challenge is capturing that energy without letting it run the project.
The fix is a system, not a personality trait.
You don’t beat scope creep by being better at saying no. You beat it by having a clear, shared artifact that makes the tradeoffs visible. At the start of every engagement, we build a scope boundary document — not a contract, just a clear statement of what’s in, what’s out, and what the cost of moving something from out to in actually looks like in time, data, and testing.
When the stakeholder asks “could it also do X?” — you don’t say no. You say: “Here’s what that would add to the timeline and what we’d need to revisit. Want to make that call together?”
Most of the time, people make reasonable choices when they understand the real cost. The problem is they never get that information. They hear “no” or they hear “sure” — and both answers are wrong.
What also helps:
- Milestone-based check-ins where scope is explicitly reviewed, not just assumed stable
- A change log on the scope doc so everyone can see what moved and when
- Keeping a “backlog” for future phases — so good ideas don’t get lost just because they’re out of scope now
The goalposts don’t move because stakeholders are difficult. They move because nobody drew the field.
Draw the field. Then you can play.