Eventually the decision gets made: the system has to go. The value never came, the frustration is universal, and the organization resolves to replace it. There is relief in the room, and a particular kind of optimism — the clean-slate feeling of a fresh start, a new vendor, a new budget, a chance to finally get it right. That optimism is genuine, and it is also the most dangerous moment in the entire cycle, because it is precisely what stops anyone asking the only question that matters: why did the last one fail?
Here is the pattern, repeated in organization after organization. A system underdelivers. It is blamed, and replaced. The new system is selected in a hurry, implemented on a timeline set by the go-live date rather than the work, configured by people who were not freed up to do it, loaded with data treated as a one-time cleanup, tested on the happy path, launched without an adoption plan, and handed to no one in particular to own. Two years later it underdelivers, is blamed, and the cycle begins again. New vendor. Same organization. Same result.
The replacement is not a way out of the problems. It is a fresh opportunity to recreate them — faithfully, expensively, and with the same people who are quietly certain that this time the software is better, so this time it will be fine.
The Software Changed. Nothing That Caused the Failure Did.
When a system is replaced, almost everything that actually produced the first failure stays exactly where it was. The replacement swaps the one variable least likely to have been the root cause, and leaves every other one untouched.
The same organization still has no single owner accountable for the system's value. It still sets implementation timelines backward from a promised date rather than forward from the work. It still treats configuration as a technical afterthought, data quality as a one-off migration task, testing as a formality, and adoption as a training session. It still has no baseline, no roadmap, and no honest measure of whether the last investment paid off.
None of these are properties of the software. They are properties of how the organization buys, builds, and runs systems — and a new vendor inherits every one of them on day one. This is why the second implementation so often fails in the same shape as the first. The failure was never really about the product; it was about the conditions the product was dropped into. Change the product and leave the conditions, and you have run the same experiment twice and acted surprised by the same outcome. The only thing a reimplementation reliably changes is the logo on the login screen and the size of the invoice.
"The Software Was the Problem" Is the Lie That Guarantees the Next Failure
Every reimplementation rests on a story the organization tells itself about why the last one failed, and the comfort of that story is inversely related to its usefulness. The comfortable story is that the software was the problem. It is comfortable because it points outward — the vendor oversold, the product was clunky, the fit was wrong — and because it requires no one inside the building to examine their own part in it. It is also, most of the time, a lie — or at least a small truth standing in for a large one.
The product may well have had real flaws. But a capable organization with an owner, a realistic timeline, clean data, and a serious adoption plan extracts value from a mediocre product, while a dysfunctional one wastes an excellent product. If your last implementation failed, the uncomfortable probability is that a meaningful share of the cause was yours, not the vendor's — and that is precisely the share you will carry into the next one unless you name it.
This is why the most important work of a replacement happens before the shortlist, before the demos, before a single vendor is called: an honest post-mortem of your own role in the first failure. Not a vendor blame exercise, but a clear-eyed account of what the organization did and did not do — who owned it, how the timeline was set, whether the data was maintained, whether anyone measured the value. A replacement that begins with that reckoning has a real chance of being different. A replacement that begins with "the software was the problem" has already guaranteed it will not be.
What Has to Change Is the Thing No Vendor Sells
If the conditions are the cause, then fixing them is the actual work of getting a replacement right — and none of it is something a vendor can provide, because none of it is on the price list. A vendor sells software. The things that determine whether that software succeeds are all yours to supply.
Before choosing the next system, the organization has to install what the last one lacked: a single accountable owner for the system's value, named before the project starts and kept long after it ends. A timeline built from the work rather than from a date promised to leadership. Configuration, data, testing, and adoption treated as the decisive activities they are rather than phases to compress. A baseline captured before go-live and a roadmap owned after it.
These are not new ideas — they are, in fact, the whole of what this series has been about — and not one of them requires a new vendor. They require the organization to become the kind of place where a system can succeed, which is the only change that actually breaks the cycle. Do that, and even your existing system might have been salvageable. Fail to do it, and your next one won't be.
A Final Thought
A reimplementation feels like a second chance, and it can be one. But a second chance is only worth having if you use it to do something different, and buying different software is not doing something different — it is doing the same thing with a new counterpart and hoping the outcome changes on its own. The organizations that break the cycle are the ones brave enough to conclude that the problem might have been looking back at them in the post-mortem, and disciplined enough to fix that before they fix the software. Everyone else just buys their next failure on a longer contract.
From selecting a system, through implementing it, running it, and measuring whether it was ever worth it, the same truth surfaces in every stage under a different name: the technology is almost never the hard part. The hard part is the ownership, the honesty, the discipline, and the willingness to do the unglamorous work around the system — the part no vendor sells and no demo shows. Get that right and almost any decent system will serve you. Get it wrong and the best software on the market will fail you, twice.
Build the organization that deserves a good system, and the rest tends to follow.
A new system is not a way out of the old system's problems. It is a fresh, expensive chance to rebuild them — because the software was rarely the problem, and the organization is the one thing a reimplementation leaves unchanged.