WorkforgeNo organisation decides to run fifteen systems. Tool sprawl is not a decision, it is a residue. Every individual choice was defensible, and the aggregate is something nobody would have designed.
Understanding how it accumulates is more useful than resolving to stop it, because the mechanism is structural rather than a failure of discipline.
Every tool is adopted to solve a real problem
Sprawl does not come from buying software nobody needed. It comes from buying software that someone genuinely needed.
Recruitment was painful, so a hiring tool arrived. Procurement had no audit trail, so a procurement system followed. Payroll was error-prone, so it went to a specialist provider. Each purchase fixed the problem it was bought for.
What nobody was accountable for was the cumulative shape. There is rarely a person whose job is to ask what the eleventh tool does to the whole, and the answer would be inconvenient anyway, because the alternative to buying it was leaving a real problem unsolved.
Local optimisation produces global mess
Decisions are made where the pain is felt. The recruiting lead picks the hiring tool, finance picks the payables system, operations picks the vendor management platform. Each chooses well for their own function.
None of them is optimising for the handoffs between functions, because handoffs do not belong to anyone. The cost of a bad seam is paid in small increments by whoever happens to be moving information across it, usually manually, usually without recording that they did.
This is why sprawl survives cost-cutting exercises. Each tool has an owner who can justify it, and the expensive part — the seams — has no owner to defend or eliminate it.
Point solutions are easier to buy than platforms
A tool that solves one clear problem is straightforward to evaluate, cheap enough to approve, and quick to deploy. A platform that addresses several problems requires more stakeholders, a larger commitment, and a longer decision.
Procurement processes therefore have a structural bias toward point solutions. The narrow tool passes easily; the consolidating one gets scrutinised. Over several years this bias alone produces fragmentation, with no bad decisions required.
Switching costs accumulate faster than value
Once a system holds history, it becomes difficult to leave regardless of how well it performs. The data has to migrate. Integrations have to be rebuilt. People have to relearn a workflow. Someone has to be responsible if something is lost.
The result is that tools are added far more readily than they are removed. Consolidation is always available in theory and rarely undertaken in practice, because the payoff is diffuse and the cost is concentrated on whoever proposes it.
Integration promises more than it delivers
The standard remedy is to connect the tools. This helps, and it has a ceiling.
Each integration is a dependency on someone else's release schedule, data model, and business decisions. Connect a dozen systems and you own a dozen relationships that can break independently. The integration layer becomes its own thing to maintain, with its own failures, and it needs an owner who usually was not budgeted for.
Integration converts a fragmentation problem into a coupling problem. That is often an improvement, but it is a trade rather than a solution.
The part that stays invisible
The real cost of sprawl does not appear in the software budget. It appears as:
- People acting as data transport between systems
- Reconciliation work when two systems disagree
- Decisions made on stale figures because the current ones live elsewhere
- Access management across many tools, and the security exposure when that lapses
- Onboarding that takes longer because there are eleven systems to learn
None of these have line items. All of them are real, and they scale with the number of seams rather than the number of tools.
What this suggests
If sprawl is structural, then resolving to be more disciplined about purchasing will not fix it. Two things help more:
Give the seams an owner. If nobody is accountable for what happens between systems, the cost will keep accumulating invisibly. Making it someone's explicit responsibility at least makes it measurable.
Count seams, not tools. The question is not how many systems you run but how many handoffs a normal piece of work crosses. Two tools with a clean boundary are cheaper than two tools that each hold half of the same process.
Most organisations do not have a tools problem. They have a boundaries problem, and it happens to manifest as a long list of software.