Scope Creep on AI Projects: How a PM Holds the Line

Scope creep is the slow expansion of a project's work beyond what was agreed, and on AI builds it's harder to spot because "can it also just handle this?" sounds tiny and is rarely tiny. The way you hold the line is not by saying no, but by making the cost of each addition visible at the moment it's requested, so the client chooses with eyes open.

Scope creep lands on more than half of all projects. On AI work I'd put it higher, and the reason is specific to how these systems behave. Let me explain why, and what I actually do about it.

Why AI invites scope creep

A traditional feature has visible edges. "Add a report" is clearly more work than the dashboard you scoped. AI blurs those edges. The agent already produces fluent, plausible output, so every new request feels like a small nudge rather than new scope. "It already answers billing questions, can it also handle refunds?" Refunds means a new action, new permissions, new failure modes, and a whole new set of eval cases. But it doesn't feel that way, because the surface looks the same.

There's a second trap. Because AI is probabilistic, "make it a bit more accurate" can be an unbounded request. Going from 80% to 90% task completion might be an afternoon or might be a month, and the client genuinely can't tell. If I don't surface that, I've accepted unbounded work disguised as a tweak.

Hold the line at the moment of the ask

The mistake is letting small additions through and reconciling at the end. By then the schedule is gone and the conversation is adversarial. I handle every request the same way, the moment it lands:

1. Name what it actually touches. Refunds isn't "one more intent." It's an action, a permission scope, a new failure mode, and new eval cases. I say that out loud.
2. Price it in time, not just yes/no. "That's roughly three days including the evals to prove it's safe." A number reframes the request from a favor into a decision.
3. Make the trade explicit. "We can add refunds, or we hold the date. Adding it moves launch by about a week. Your call." Most clients make sensible trades when they can see the trade.
4. Write it down as a change. A one-line change note with the time impact. Not bureaucracy, just a shared record so nobody relitigates it later.

Notice I never said no. I made the cost visible and handed the decision back. That's the whole job. Clients don't resent paying for value they chose. They resent surprises, and surprises are what unmanaged scope creep manufactures.

A few habits that prevent it earlier

• Define the input distribution up front. A lot of "creep" is really scope that was vague to begin with. If we agreed exactly which cases the agent handles, the new case is visibly outside the line.
• Tie scope to the eval set. When "done" is a fixed set of test cases, a new request is obviously a new case, which makes the extra work concrete instead of arguable.
• Keep a parking lot. Good ideas that aren't in scope go on a visible list for the next phase. People let go of a request far more easily when it's captured, not killed.
• Watch the accuracy asks specifically. When someone wants "better," I make us agree the target number and the test set first. Otherwise "better" never ends.

The build-vs-buy decision has shifted partly because AI made custom work cheaper to start, which we cover in The build-vs-buy line just moved. Cheaper to start is exactly why scope discipline matters more now, not less. When building feels easy, the temptation to keep adding is constant.

Key takeaways

• Scope creep hits over half of all projects and is harder to see on AI work, where new requests look deceptively small.
• "Make it more accurate" can be unbounded. Pin it to a target number and a test set or it never ends.
• Hold the line at the moment of the ask: name what it touches, price it in days, make the trade explicit, write it down.
• You don't say no. You make the cost visible and hand the decision back.
• Tie scope to the eval set and keep a parking lot so good-but-out-of-scope ideas aren't lost.

FAQ

Isn't being strict about scope bad for the client relationship? The opposite. Clients trust a PM who tells them the real cost before they commit. They lose trust when work quietly expands and the date slips with no explanation.

How do I price a change I'm unsure about? Give a range and say it's a range, then timebox an investigation if needed. "Two to five days; let me spend an hour confirming" is honest and still actionable.

What if the client insists everything is in scope? Then point back to the agreed input distribution and eval set. Scope is whatever you wrote down together. If it isn't on that list, it's a change, and that's a fact, not an opinion.

---

If your AI project keeps growing a little every week and the date keeps moving, the problem is usually a missing change process, not a difficult client. The team at Shanti Infosoft can help you set scope you can actually defend.