Software implementations rarely fail because the wrong product was chosen. They fail in the gap between a system being installed and a system being used. The most common cause is under-resourcing the human side: too little training, delivered once, with no return visit after people hit real problems.
Most writing about implementation failure and change management is by people who watched from outside. I chose the platform, designed the screens, wrote the training manual and delivered it myself. Then I got the most important part wrong.
A five-brand rollout across 17 branches
The Hercules Group had grown by acquisition into five brands: industrial products, rigging, marine supply, sold across 17 branches. My scope was Atlantic Canada, about $50 to $55 million of a roughly $100 million national business, with twelve to fifteen sales and business development people.
The problem was structural. Each brand had its own sales team, calling on nearly the same customers, out of the same inventory, at the same prices. Two of my own reps would occasionally visit one customer on the same day. Customers had worked out that they could play us against each other, and were doing exactly that.
What I got right, and it mattered
I did not start with software. I started with the business.
If 80% of a customer’s spend sat under one brand, that brand owned the whole relationship, except where a genuine specialist was needed. Then I rebuilt the commission structure so it stopped paying people to do the old thing, and gave every customer a single point of contact.
Only then did I evaluate platforms. That sequence is not a nice-to-have. A CRM installed over the original mess would have digitised the conflict rather than removed it, and everyone would have blamed the software.
I evaluated several major platforms, chose on price, configurability and the ability to roll five brands up into one dashboard, designed the system and the screens my reps would use every day, wrote the training manual myself, and took it around the country.
Why the reps pushed back
My reps pushed back hard, because a new system feels like being watched, and because what they were already doing worked. For them.
Both halves of that matter, and the second one is the half most people miss.
The resistance was not irrational. A rep who has carried his territory in his head for fifteen years is not being difficult when he resents typing it into a form. From where he sits, the system adds work to his day and visibility to his manager’s, and delivers him nothing on the day it goes live. He is not wrong about that. The benefits are real and they are almost entirely somebody else’s, at least at first.
Some of my reps were older and pushed harder. That is worth naming plainly rather than tiptoeing around, because it is predictable and you can plan for it.
One day of training was not enough
I gave each location one day of training.
It needed two or three. And it needed a second visit a few weeks later, once people had stopped nodding along and started hitting real problems with real customers in front of them.
One day is enough to show people where the buttons are. It is not enough to change how somebody works, and it is nowhere near enough to equip a branch manager to support their team once I had driven away.
It was rough for months. Full adoption took about six.
I have never put a clean dollar figure on it and I am not going to invent one now. What I can say is the shape of it: I ended up funding two further rounds of training I had not budgeted, at worse timing and higher cost than if I had simply bought them up front, and for half a year I was running a $50 million business on reporting I did not fully believe. The under-spend on training was smaller than what it cost to recover from the under-spend on training.
I would make the same platform choice again without hesitating. I would triple the training budget, and I would go back a second time.
| What I budgeted | What it needed | What it cost |
|---|---|---|
| 1 day per location | 2 to 3 days | Six months of partial data, so six months where I could not trust a report enough to act on it |
| One visit | A second, weeks later | Every branch solved the same problems separately, by phone, at my expense |
| Training the reps | Training the local managers to coach | Escalations came to me personally for months instead of stopping at the branch |
| Adoption at go-live | Adoption over ~6 months | Two extra rounds of training I had to fund anyway, later, at worse timing |
The wider evidence is more careful than my anecdote, and worth stating accurately. Panorama Consulting’s 2025 ERP Report found that most enterprise software projects came in on or under budget: 53.5% on budget and 15.1% under, against 23.8% slightly over and 7.6% significantly over. So the industry does not fail as often as the war stories suggest.
But look at what undoes the ones that do go over. Underestimated project staffing is the second most common cause, at 46.3%, behind only needing technology nobody had planned for at 51.9%. Not the wrong product. Not the wrong vendor. Not enough people budgeted for the human side of it.
Two caveats I would rather give you than have you find. That is a study of 172 organisations with a median 750 employees, so it describes companies far larger than the one I am writing for. And it measures budget overrun, not adoption. My rollout did not go over budget. It went slowly, which that study would not have caught at all.
Source: Panorama Consulting 2025 ERP Report, pages 23 to 24. Sample of 172 organisations, median annual revenue $400.5 million, median 750 employees.
What I would tell you to do instead
Five things worth doing before go-live
- Fix the process before you buy the tool, then treat that as necessary and not sufficient. A system installed over a broken process makes the process faster and worse. I did fix the process first, and the rollout still nearly failed, because a clean process does not make anyone want to type into a new box.
- Budget training as a multiple of what the vendor suggests. Their figure assumes a user who already wants the system. Plan for two or three times it, and book the second visit before you need it.
- Train the managers, not just the users. The person who unsticks somebody in week six is their branch manager, not you and not the vendor. If that manager cannot answer the question, adoption stalls quietly and nobody tells you.
- Answer “what do I get out of this” for the person typing. Not for the business. For them, personally, on the day it launches. If the honest answer is “nothing yet”, say so and be specific about when that changes.
- Expect month four. Enthusiasm carries the first weeks, and the real test comes once the novelty has gone and the old way is still available. Plan a check-in there, before you need one.
Adoption is the risk, not the software
The decision on paper was defensible. The platform was right, the sequencing was right, and I still nearly lost it, because I resourced the software properly and the people barely at all.
The software was never the risk. Adoption was, and it always is.
Which is why, when someone tells me their last system was a failure, my first question is not which product they bought. It is how many days of training they ran, who supported it afterwards, and what happened in month four. That finds the answer faster than any review of the software would. If a rollout you already paid for never landed, that is one of the situations Navigator exists for.
Whether you are about to buy, or already did
If a rollout has already stalled, the advice above is too late and the question changes: what is recoverable, what is not, and whether the problem is the system or everything around it. That diagnosis is what Blue Harbour Navigator does. Seven to ten days, fixed fee, for owner-led businesses. Sometimes it means replacing the system. More often it does not.
I sell no software and I do not implement it, and I take no commissions from any vendor. $5,000 flat, in your own currency.
Book a 20-minute fit call Or tell me what you’re facing, no call needed
Two minutes to write, I read them myself. Or see how Navigator works first.
Sources. The Panorama Consulting 2025 ERP Report, pages 23 to 24, for the budget adherence split and the overrun causes. Everything else here is first-hand. The Hercules Group rollout ran 2013 to 2018. No vendor is named, deliberately: products change, and the lesson does not depend on which one it was.
Trevor Jamieson is the founder of Blue Harbour Solutions in Halifax, Nova Scotia. He has spent twenty years across the vendor and buyer sides of technology, at Dayforce, The Hercules Group, TELUS and Xerox. He currently holds a contract role in partner marketing at Amazon Web Services, and is co-founder and CEO of PhoneStack. Neither pays Blue Harbour anything inside a client assessment, and both are declared in writing on the site. Blue Harbour sells no software and takes no commissions from any vendor.