A large, multinational CPG company decided it was time to replace its legacy route-to-market platform. IT took the lead: researching the market, selecting a vendor, and assembling a requirements inventory to hand over. The vendor built against it in good faith. When user acceptance testing started, the gap was obvious. The system matched what had been written down. It didn't match how the business actually ran a route, settled a day, or corrected an order after the fact. The implementation was scrapped before it reached a single route.
It would be easy to read this as a vendor problem, and plenty of companies do. The vendor, though, built exactly what it was asked to build. What's harder to see is what never happened before that request was written. Nobody outside IT had gathered requirements from drivers and route supervisors, and the process itself had been documented as it already existed, workarounds included, rather than redesigned or tested against a real route. None of that is a technology question. A McKinsey study calls out that transformations fail at a rate of roughly 70 percent (Robinson, 2019), and the reasons rarely trace back to the platform itself. With that groundwork in place first, there's a real case the original vendor could have delivered a working system. This wasn't a vendor-capability failure. It was a sequencing one.
A second vendor came in afterward, and it's tempting to credit the turnaround to a better partner. That's not the only thing that changed. Before any system was scoped this time, there was pre-work and a workshop to map how the operation actually ran against how it was supposed to run on paper. The process got redesigned rather than just logged. That redesign was then validated against a real settlement cycle instead of being approved in a conference room and assumed to hold. Only once it survived contact with an actual route did system implementation begin.
Line up the two attempts and vendor quality wasn't the only variable that moved. It mattered. The second vendor brought real capability the first one may have lacked. But it wasn't the decisive difference. What changed most was whether requirement gathering and process redesign happened before technology was scoped, and whether the technology was in place before execution was asked to carry the operation's weight. Process, then technology, then execution. Stated that plainly it sounds almost too obvious to write down. It's also, by the account above, not what most RTM transformations actually do.
Technology being right doesn't automatically mean execution follows, and that's as much good news as it is a warning. The work of making a new system stick stays within the organization's control; it isn't left to chance once the contract is signed. A system built against a properly validated process gives an organization something real to run toward, and deliberate attention to training and timing is what turns that into people actually running through the system rather than around it.
What separated the two attempts wasn't luck, and in the end it wasn't really the vendor either. It was a proper design methodology, disciplined enough to turn a platform decision into a real implementation plan rather than a best guess. The workshop that mapped how the operation actually ran, and the validation against a real settlement cycle before anything was built, are what that methodology looked like in practice, not an abstraction bolted on afterward. The companies getting this right aren't the ones avoiding technology. They're the ones who've learned to earn it first.
References
Robinson, H. (2019, July 10). Why do most transformations fail? A conversation with Harry Robinson. McKinsey & Company. https://www.mckinsey.com/capabilities/transformation/our-insights/why-do-most-transformations-fail-a-conversation-with-harry-robinson