Every project overruns and the usual explanation is scope creep, framed as a client failing to stick to what they agreed. That framing is comfortable for suppliers and mostly wrong. Requirements change because building software teaches everyone things they did not know at the start — including the client, who could not have described the right thing before seeing the wrong one. A process that treats learning as misbehaviour is fighting the nature of the work.
What actually causes the damage is not change but unpriced change. A request arrives mid-sprint, seems small, and is absorbed without a conversation because refusing feels obstructive and estimating feels bureaucratic. Twenty of those, each genuinely small, is a month. Nobody decided to spend that month and nobody can point to when it was spent, which is why the overrun feels mysterious to both sides.
So the mechanism that works is not resistance, it is visibility. Every change gets an estimate and a decision: add time, remove something else, or defer it. That decision belongs to the client, stated plainly — this is two days, we can add it and move the date, or drop the export feature to make room, which would you prefer. Clients presented with that trade make sensible choices. Clients never presented with it assume the additions are free, and are then genuinely surprised at the end.
Some of the fix is upstream, in how the work was defined. A specification listing screens and features invites change because it describes a solution nobody has validated. A brief describing the problem, with a first slice defined tightly and the rest held loosely, sets an expectation that the details will be worked out as you go — which is what will happen regardless, so it is better to have agreed it.
Watch for the two disguised forms, because they never appear in a change request. Requirements clarification that turns out to be new work — we always assumed it would also handle bulk uploads — and gold plating from your own team, where an engineer builds a configurable version of something that needed one behaviour. The second is your own scope creep and it is invisible unless someone is asking what was built against what was asked for.
The relationship consequence is worth naming. A supplier who absorbs every change silently and then delivers late is judged on the lateness, because the absorption was never visible. A supplier who prices each change, gets a decision, and delivers on a date that moved for reasons the client chose, is judged as reliable. The work is identical; only the visibility differs, and it is the difference between a project that damages a relationship and one that builds it.
