Scope creep is a communication failure with a project-management name

A customer asks for something in week three. Your team's reaction is immediate and shared: that is not in scope.

They are right, in the sense that it is not in the scope document. The customer is also right, in the sense that they were told during the sales process that it would work this way and nobody has told them otherwise since.

Both parties are now in a dispute in which each believes the other is behaving badly. Neither is. The record failed.

Three kinds of creep, and only one is real

Genuine new scope. The customer's requirements changed, or they thought of something. This is normal, it should be priced, and a functioning change process handles it. This is the only category the phrase "scope creep" actually describes.

Undocumented commitment. Something was promised in a call, an email or a demo and never made it into the scope document. From the customer's side, this is not new scope — it is the thing they bought. Fighting it damages the relationship and usually loses anyway.

Ambiguity resolving unfavourably. The scope said "reporting". The customer assumed that included the three reports they mentioned in the demo. You assumed a standard report set. Nobody was wrong; the words were not specific enough. This is the biggest category by volume and the one most likely to poison a project, because both sides feel misled.

Treating all three as the same thing is the mistake. The change-control process you use for the first makes you look obstructive when applied to the second and third.

How to separate them in the first week

Run a commitments review at kick-off, with the salesperson in the room, and write down every commitment that exists outside the contract. Anything said in a demo. Anything answered verbally during due diligence. Anything promised about timelines, integrations or support response.

This is a twenty-minute conversation that is genuinely uncomfortable, because it surfaces the difference between what was sold and what was bought while there is still time to do something about it. That discomfort is the value. Every one of those items is going to arrive later as a dispute if it is not surfaced now.

Then publish the resulting list back to the customer. Not as a contract amendment — as "here is our understanding of what we have agreed, including things outside the paperwork". Customers respond to this well. It is also the cheapest insurance you will ever buy.

Where the record has to live

Not in the kick-off deck. Decks get archived.

These commitments need to be items against the customer, in the same system as the project, visible to whoever picks up the account in month nine, with an owner and a state. A promise is only useful as a record if the person who needs it can find it without knowing it exists.

This is the practical argument for keeping the customer record, the project, the workplan and the escalations together. PlaNath is structured that way — commitments, tasks, defects, tickets and escalations all attach to the same customer, so the answer to "did we promise them this?" is a lookup rather than an argument.

Scope creep is real. But most of what gets called scope creep is a filing problem wearing a project-management name.