Every implementation produces a list of customizations. The standard reading of that list is that it represents the ways the business is special: requirements the off-the-shelf software does not meet. Some of it genuinely is that. But a large share of it, in our experience, is something else. It is the business declining to make a decision, and paying for software to be bent so the decision never has to be made.
How an unmade decision becomes a change request
The pattern is consistent. The software does something one way. Two departments, or two managers, or two old habits, do it two different ways. The standard software forces a choice between them. Making that choice is uncomfortable: someone has to change how they work, and someone has to be told their way is not the way anymore. So instead of making the choice, the project asks for a customization that lets both ways continue. The customization is real, billable, deliverable work. The requirement underneath it is "we would rather not decide."
Why this is the expensive option, not the cheap one
Asking for a customization feels cheaper than the alternative, because the alternative is an internal conflict and the customization is just a line item. But the line item is the more expensive path:
- The customization is code, and code is a permanent liability: it has to be maintained, tested, and carried through every upgrade, forever.
- It preserves the divergence rather than resolving it. The two ways of working continue, and every future change now has to account for both.
- It hides the decision instead of removing it. The disagreement is still there. It has just been buried under software, where it is harder to see and more expensive to revisit.
The honest test for a customization
Before any customization goes on the list, it is worth asking one question: is this a genuine difference in what the business does, or a difference in how people are used to doing it. A genuine difference, a real constraint of the industry, the product, or the regulation, deserves a customization; that is what customization is for. A difference of habit does not. It deserves a decision.
The way to tell them apart: ask what would break if everyone did it the standard way. If the answer is a concrete operational or legal problem, it is a real requirement. If the answer is "people would be annoyed" or "that is not how we have always done it," it is an unmade decision wearing the costume of a requirement.
The position, stated plainly
Standard software is, among other things, an accumulation of decisions someone else already made well. Adopting it is partly a chance to inherit those decisions instead of relitigating them. Every customization that exists only to avoid a choice throws that benefit away and buys a permanent liability in its place. The cheapest customization is the one that turned out to be a ten-minute meeting.