When somebody tells us they already tried a tool for this, they usually mean it as a reason to stop. It is better evidence than anything a discovery workshop will produce, because a tool that was bought, rolled out and quietly dropped has recorded the exact point where the software and the work stopped agreeing.
That point is your requirement. Nobody wrote it down at the time, because at the time nobody knew it was there.
The failure left a record, and it is fairly precise
Go and look at the thing you abandoned. Not the contract. The data.
Which fields are empty. Which screen nobody opened after the second month. What date the updates stop on, and what was happening that week. If half the team still logs in and half does not, the split usually follows a site or a job title, and that tells you which part of the work the software never fit.
A tool nobody uses looks, from a distance, like one large decision that went wrong. Up close it is almost always narrower: one step the system insists on doing in a different order from the way the job happens, one field it demands before it will save a record, one report built for a question nobody asks. The rest may well have been fine. Nobody found out, because people stopped at the first place it did not fit and went back to what worked.
Where these go wrong, and only one of the reasons is the software
Four patterns cover most of what we see.
The sequence was wrong. The system wants the job number before the site visit; the crew gets the job number afterwards. Every entry is then either late or invented, and within a month somebody is keeping a notebook.
Nobody owned it after go-live. There was a launch, some training, and then the person who cared about it moved on to the next thing. Questions started going unanswered, and an unanswered question about a tool gets answered by not using it.
It ran beside the old thing. Two systems live at once, one of them optional. The optional one loses. It always loses, and parallel running is usually sold as the cautious choice.
It was correct and slower. The software does the right thing and takes four minutes where the spreadsheet took thirty seconds. From outside that is a rounding error. To the person doing it forty times before lunch it is the whole afternoon.
Only the first of those is really about the product. The other three are about how it arrived, and a different product does nothing whatsoever to any of them.
An unanswered question about a tool gets answered by not using it.
"Maybe the tool really was wrong"
Sometimes it was, and this is the objection that has weight. "Adoption, not replacement" can be a polite way of blaming a team for software that genuinely cannot do the job. If a system cannot show one customer's work across two branches and you have two branches, no amount of training fixes that, and asking people to try harder is a way of avoiding the conversation.
So the two cases have to be told apart, and there is a plain test for it. Ask the people who stopped using it what specifically the tool would not do. "It cannot show one customer's jobs across both branches" is a product limit, and you may well need a different product — that is the point at which buy, build or integrate becomes a real question rather than a shopping trip. "It was clunky" is not an answer yet, and buying something else will not produce one.
Why the replacement so often fails in the same place
Because the mismatch travels. We have made this argument about cost before: a new system usually moves the workaround rather than removing it.
Three of the four patterns above are properties of your rollout, not of the vendor, and they arrive intact at the next tool. Which is why the cheapest thing you can do next is often not a purchase at all, and why an assessment of software you already own can be worth more than a demo of software you do not.
Questions people ask
Is the answer always adoption rather than a new tool?
No. Sometimes the product genuinely cannot do the work and the honest recommendation is to replace it. What decides it is whether anybody can name the specific thing it would not do — a nameable limit points at the product, and a vague one points at how it was introduced.
What if you think our idea will not work?
We will say so and propose what would work instead. Our recommendations always include what we would not build, and that can mean telling you the system you were about to replace is closer to right than the one you were about to buy.
Where does an assessment of a failed tool start?
With the people who stopped using it, and with the data they left behind.
What to do differently
Before you look at a replacement, write one page about the last one. When did people stop, who stopped first, what do they do instead, and what is the single step where the software and the job disagreed.
Then hand that page to whoever is selling you the next tool and ask them to point at the line they fix. A vendor who can do that is worth listening to. A vendor who tells you the last one was simply the wrong choice has not read your page, and is about to sell you the fourth pattern again.