Nobody Announces It
A WMS project rarely dies on a particular day. There is no meeting, no decision, no post-mortem.
The go-live date moves once, then stops being discussed. A parallel spreadsheet appears for one client because the configuration isn't ready and the orders still have to ship. The weekly call gets moved to every other week. Someone leaves and their piece of the project doesn't get reassigned.
Eighteen months later the license is still being paid and the operation is running the way it ran before, on the workarounds that were supposed to be temporary.
Almost nobody in the building would describe the project as failed, which is exactly why nothing gets examined.
The Sentence That Gets Written Instead
What does get produced is an explanation, and it is remarkably consistent across operations that have never spoken to each other.
The system was too rigid. It wasn't built for how we work. Our operation is more custom than most. Good software, wrong fit.
That explanation is comfortable because it is nobody's fault, it requires no further action, and it contains just enough truth to survive scrutiny. The system genuinely could not do what the operation needed. That part is real.
The explanation quietly relocates the problem into the software, where it can be filed, rather than into the process that chose the software, where it would have to be answered.
What Actually Happened, Usually
I have been on the delivery side of these, and the pattern from that seat is different from the one written in the post-mortem that never gets written.
The system was chosen against a description of the operation that nobody had verified. Not a dishonest description. A partial one, assembled quickly, by people describing what they believe happens rather than what happens.
Configuration is the first moment anyone compares that description to reality. Everything that surfaces then arrives as a surprise, priced as a change, and framed as the system falling short. The gap is real, and the gap was created before anyone signed.
The system did not turn out to be wrong for the operation. The operation turned out to be different from the one the system was selected for.
The Bill Arrives Years Later
The wasted license fee is the cheapest part of this, and it is the only part anyone counts.
The real cost lands on the next attempt. The person who championed the first system has learned what championing costs and will not do it again. Finance has a number attached to the last one. Anyone proposing a new evaluation is proposing to repeat something the company already believes it tried.
And the conclusion outlives the people who drew it. Three years on, staff who were not there will tell you the business looked at WMS and it didn't work, as settled fact, sourced from nobody.
A failed implementation doesn't leave you where you started. It leaves you with organizational evidence for a conclusion that was never true.
Which Is Why the Second One Matters More
Operations arriving at a second evaluation are in a stronger position than they think, and they almost never use it.
They have something no first-time buyer has: a documented list of everything configuration surfaced that nobody knew about. Every change order, every exception that broke the flow, every question the team couldn't answer consistently. That artifact is the operational reality the first evaluation lacked.
Most of it gets thrown out with the software, because it is filed under a project everybody wants to forget rather than under evidence about the business.
The most accurate description of your operation that has ever existed was produced by the implementation you would rather not discuss.
Second attempts that went well tended to share one move at the very start. The first attempt got treated as discovery already paid for, somebody went back through what it exposed, and the next evaluation began with an operation nobody had to guess about.
The software in the graveyard was mostly fine. What got buried with it was the only honest account of how the place actually runs.
