Why Organizations Keep Buying Software for Systems Problems
Organizations substitute a procurement decision for a design decision, because only one of the two fits through the process that has to approve it.
The pattern
An organization notices that something is slow. Work sits. Handoffs stall. Nobody can say where a request is without asking three people. A category of software exists for exactly this, so the organization evaluates vendors, picks one, and rolls it out.
The rollout completes on schedule. The work is still slow. It is slow inside a better interface now, with more reporting available about the slowness, and there is a line item for it. The constraint did not move, because the constraint was never in the tool.
What follows is the part that makes the pattern self-sustaining. Nobody concludes that the purchase was wrong. The conclusion is that the implementation was incomplete, or the configuration needs work, or adoption is lagging, and each of those has a remedy that costs more money and further commits the organization to the original diagnosis. Two years later the same complaint reappears in the same words and is met with a replacement of the same tool, on the reasoning that the last vendor underdelivered.
A purchase is legible. A redesign is not.
This is not a failure of intelligence. The people making the decision are usually right about the symptom. It is a failure of what an organization is structurally able to approve.
A software purchase has a price, a date, a vendor, an owner, and a comparison matrix. It can be defended in a meeting by someone who was not in the room when the problem was found. A systems redesign begins with ambiguity, has no vendor, no fixed scope, no obvious owner, and the first honest answer to what it will cost is that nobody knows yet.
Given those two options, an organization approves the one it can describe. The substitution is not cynical and it is rarely conscious. It is simply the only one of the two that fits through the process.
The asymmetry is also personal. A manager who buys a well-reviewed platform and gets a disappointing result has made a defensible decision that did not work out, and the vendor absorbs most of the blame. A manager who proposes changing how approvals work, and is wrong, has spent political capital on their own judgment in front of the people whose authority was being rearranged. The expected value calculation is not close, and it does not depend on either option's actual chance of working.
What the purchase does buy is motion. Rollout plans, training sessions, migration, a steering committee, a launch date. All of it is real work performed by capable people, and all of it is measurable, which makes it feel like progress.
What it does not buy is a change in how the work moves, because none of that activity touched the place where the work was stalling.
The loss lives at the seams
In the operations I have traced, the recoverable loss has not been inside functions. It has been between them. Intake, handoff, approval, exception, review. The points where responsibility changes hands and nobody owns the transition.
Inside a function, people are usually competent and the work moves. At the seam, ownership is ambiguous, status is inconsistent, and the work waits for someone to notice it. That waiting is invisible in every functional report, because no function is failing.
Software is bought by function. Seams belong to nobody, so nobody procures for them.
The procurement structure makes this worse than it needs to be. Requirements are gathered from each function, so the resulting specification is a union of what each side of the seam wants, with the seam itself represented by nobody. The system is then configured by each function to suit its own half. The handoff is implemented twice, slightly differently, and the discrepancy between the two implementations becomes a new category of exception that a person handles by hand.
The tool inherits the arrangement
A platform does not arrive with an operating model. It arrives with defaults, and those defaults get configured to match how the organization already works, because that is the fastest path to adoption and the least disruptive to the people being asked to change.
So the broken handoff is faithfully reproduced in the new system, now with better logging. The organization has paid to encode the arrangement it was trying to escape.
A dashboard that reports on a broken handoff is not a fix. It is a more legible version of the same loss.
There is a particular irony in how this happens. Most platforms ship with an opinionated default flow that embodies a reasonable design, often a better one than the customer currently runs. The configuration phase is where that opinion is systematically removed, one exception at a time, each justified by a real local circumstance, until the system matches the organization exactly. The customization budget is spent reproducing the problem, and the resulting configuration is then too specific to upgrade cheaply.
Visibility is the most common version of this and the hardest to argue with, because it is genuinely useful and it does feel like the thing. Knowing precisely how long work waits at a handoff, in real time, on a screen, does not shorten the wait. It converts an unmeasured problem into a measured one. That is worth doing. It is not the same as having done something about it.
What the diagnosis looks like
I spent time on marketing operations reporting at Adobe, across roughly six billion dollars of marketing spend. The complaint was turnaround. Reports arrived too late to be useful for the decisions they were supposed to inform, which is a complaint that points directly at a reporting tool.
The intervention was not a new category of software. It was restructuring the reporting and the data flow underneath it around the decisions they actually fed, which removed most of the manual assembly sitting between the data and the decision. Turnaround fell by 86 percent. The useful part was not the number. It was that the constraint turned out to be the shape of the flow rather than the capability of the tool, and no vendor evaluation would have surfaced that.
It is worth noting what the vendor evaluation would have surfaced instead. Every serious reporting product on the market could have produced those reports faster than the incumbent, and a comparison matrix would have shown exactly that, accurately. The evaluation was not wrong. It was measuring the step that was not the constraint, and it had no mechanism for discovering that, because a vendor comparison takes the shape of the problem as given.
The alternative
The alternative to buying first is a diagnosis, and a diagnosis is cheap. Trace one real unit of work from arrival to completion and the distance between the documented path and that one is your design brief. In my experience it is almost never a feature gap.
The cost comparison is not close, which is the part that should make this easy and does not. A trace is one person for a week or two. An enterprise platform decision is a year of committed spend and a multi-year contract. The diagnosis is cheap enough to run before every significant purchase and is almost never run, because it sits before the point where a budget exists, and there is no process for funding the work that determines what should be funded.
What that diagnosis actually involves
When the purchase is right
Sometimes the constraint really is capability. The work is designed correctly, the seams are owned, and the organization is genuinely limited by not having a thing it could buy. That happens, and in those cases buying is fast and correct and the rollout does exactly what rollouts are supposed to do.
The test is whether anyone traced the work first. An organization that has done the diagnosis and then buys software is making a design decision. An organization that buys first is making a procurement decision and hoping it turns into one.
If this describes an operation you are responsible for, the diagnostic is where that conversation starts.
How engagements begin
