Composite, drawn from patterns across engagements, not one specific client.
A four-week project was in week seven, with no clear end in sight, and nobody on either side had consciously decided to extend it that far. That's what scope creep actually looks like in practice: not one big decision, a series of small, reasonable ones that add up.
How it happened, addition by addition
Week two: a "quick" additional field on a form, reasonable, small. Week three: a related report nobody had asked for originally, but seemed useful once the field existed. Week five: an integration with a second system, because the report was more useful if it pulled from there too. Each addition, on its own, was a five-minute conversation that felt too small to formally re-scope. Together, they nearly doubled the project.
What actually stopped it
Not a hard "no more changes" rule, that tends to create friction without fixing the underlying pattern. Instead: every new request, however small, got written down against the original scope document and explicitly marked as in-scope or out-of-scope, in writing, before any work started on it. The act of writing it down, not the decision itself, is what broke the drift. Small requests that felt free in conversation looked different once they had to be named explicitly against a boundary.
What happened once that habit started
Two of the next three requests got explicitly deferred to a phase two, priced and scheduled separately. One got approved as in-scope because it genuinely was, a bug fix, not new scope. The project closed two weeks later, with everyone aligned on why it took as long as it did.
The lesson, generalized
Scope creep rarely announces itself as scope creep. It shows up as individually reasonable small requests, and the only real defense is forcing each one through a visible boundary, in writing, at the moment it's asked, not weeks later when the drift is already large enough to see.