It almost always starts with the same sentence, and it sounds harmless: "It's just a small change." Usually it comes from the department, friendly, in passing, often at the end of a meeting where the actual topics were already ticked off. And usually it is even true — for the spot the department can see. One more field in the form. One more column in the export. One more status in the dropdown. From the perspective of the person voicing the wish, that really is small. The problem isn't the change. The problem is everything that hangs off it and, seen from the form, simply isn't visible from there.
Anyone who runs projects knows this sentence not as a rare exception, but as background noise. It drops on a Tuesday at half past eleven and on a Thursday at four. And the project manager's thankless role is to be the one who, at the exact moment when everyone nods and wants it done quickly, says: let me check that briefly. Not out of a love of braking. But because he has learned that the word "small" refers to the wrong size — the visible one, not the real one.
Why "small" refers to the wrong thing
A change has two sizes, and they almost never have anything to do with each other. The first is the visible size: how much changes on the surface, in what the user has in front of them? An additional input field is as small here as a change can be. The second is the size of the consequences: in how many places in the system does something have to be thought through, changed along, tested along, so that this one field isn't just displayed but works — today, in six months, and even when someone types something wrong into it.
The phrase "just a small change" always measures the first size and always means the second. The whole trouble lies in exactly this confusion. A field in the form is visibly small. What it triggers can be large — and the more grown the system, the bigger the wave behind the small stone. On a fresh project with three tables, a new field costs an hour. In a system that has been live for eight years, with integrations, reports, permissions and legacy data, the same field sometimes costs a week. The change is the same. What hangs off it is not.
The most expensive sentence in software projects: "It's just a small change."
One field. And then the wave
In one of our projects it was about exactly such a field. An existing order-entry application, live for years, around 9,000 orders a month. The wish from sales was a one-liner: please add one more field per order for the "delivery status", three stages, Open, In transit, Delivered. "Just a dropdown. It's a trifle." And seen from the form, it was. The dropdown itself was built in twenty minutes — today a developer with AI builds it in ten. That is exactly the trap: when making the change costs no effort any more, thinking about the consequences easily falls away with it.
Then we wrote down who touches this field besides the form. The list grew longer than sales would have thought possible — and it is the real reason why twenty minutes turned into almost two weeks in the end.