Scope creep doesn't start in execution

By the time you are arguing about a change request, the mistake is already months old. Scope creep gets diagnosed during execution, but it is almost always caused at initiation, and the specific causes are predictable enough to prevent.

The argument is a symptom

The conversation goes like this. A client asks for something. You say it is out of scope. They say it was always implied. Neither of you is lying, and neither of you can prove it.

That is not a discipline problem in execution. It is evidence that scope was agreed in words vague enough for two intelligent people to have understood them differently, and that ambiguity was baked in before a line of code was written.

Cause one: deliverables described as themes

"A reporting module." "Improved onboarding." "Admin dashboard."

Everyone nods, because everyone is picturing something, and the pictures do not match. Six weeks later the client sees the reporting module and asks where the scheduled email exports are. They genuinely believed those were included, and nothing in the agreement says otherwise.

The fix is acceptance criteria, written at initiation, in the client's own language. Not a specification document — a short list of what the thing must do to be considered done. Reporting: users can filter by date range and export the visible table to CSV. Fifteen words that would have prevented the argument.

Cause two: no named decision-maker

When it is unclear who decides, everyone decides. A stakeholder mentions a preference in passing, a developer accommodates it, and scope has moved without anyone processing a change.

Name the person who can approve a change on the client side and the person who can approve one on yours, and say so at kick-off. A RACI chart is one way. A sentence in the charter works too. The mechanism matters far less than the fact that it exists.

Cause three: phase two is never written down

Good discovery generates ideas beyond the current scope. If those ideas have nowhere to go, they either get absorbed silently into the current phase or they get refused, which sounds like obstruction.

Keep a visible parked list from day one. When something arrives that is genuinely good but not now, it goes on the list rather than into the sprint. That turns a refusal into a deferral, which is a much easier conversation, and it is honest, because the item really is worth doing later.

Cause four: change has no price attached

If a change costs nothing to request, requests are free and infinite. Not every change needs a formal control board, but every change needs a visible consequence: this adds four days, or it displaces that item from the release.

Trade, do not refuse. "We can add that. It moves the launch to the 12th, or we drop the bulk import. Which would you prefer?" puts the decision where it belongs, and stops the project manager being the person who says no.

What to write down at initiation

Not much, and it does not need to be a document nobody reads:

• Deliverables with acceptance criteria, in plain language
• What is explicitly out of scope — this section is worth more than the in-scope one
• Who approves changes, on both sides
• How a change gets requested, and what happens to the schedule when one is accepted
• Where parked ideas live

Half a page. It will not stop clients wanting more, which is normal and often entirely reasonable. It will stop the argument about whether they were promised it, and that argument, not the change itself, is what damages projects and relationships.