We have seen it more than once. A business invests months and a healthy budget in a new ERP or CRM. Launch day goes smoothly, the data is clean, the screens look great. Six months later, half the team is back on spreadsheets and WhatsApp, and the system is used mainly to print invoices. The software worked. The rollout didn’t. Here is why, and how to avoid it.
Why good systems get quietly abandoned
People rarely reject a new system out loud. They simply drift back to what they know, because the old way feels faster and safer, and nobody stops them. In our experience, the causes are remarkably consistent across industries and countries, from a trading company in Deira to a manufacturer in Ajman.
- It was designed for managers — reports look great, but daily data entry takes longer than before.
- Nobody asked the users — the people doing the work met the system for the first time at training.
- Training was a one-off — a single session in a meeting room, weeks before anyone used it for real.
- The old way stayed open — spreadsheets and paper forms kept working, so there was no reason to switch.
- Problems went unanswered — early bugs and questions took days to resolve, and trust evaporated.
There is also a quieter, human reason. A new system can feel like a judgement on how people worked before, or a threat to the expertise that made them valuable. The colleague who knew every customer’s credit terms by heart may not welcome software that makes that knowledge available to everyone. Ignoring those feelings does not make them go away.
Involve the people who will use it
The single most effective fix is also the cheapest: bring frontline users into the project from the start. Invite a warehouse supervisor, a sales coordinator and an accounts assistant to discovery sessions. Show them early designs and clickable prototypes. Let them try to break things in testing. Their objections are far cheaper to hear in week three than in month six.
Appoint champions in every team
Pick one respected person per department, not necessarily the most senior, to act as a champion. Give them early access, extra training and a direct line to the project team. Colleagues are far more likely to ask a champion at the next desk than raise a support ticket, and champions spot problems long before they reach management.
Explain the why, not just the how
People accept change more readily when they understand the reason for it and what it means for them personally. Be specific: no more retyping orders, no more chasing approvals on WhatsApp at 10pm, fewer month-end late nights. If the honest answer is that a task will take a little longer for one team so another saves hours, say so plainly.
Lead by using it yourself
Teams watch what leaders do far more closely than what they say. If the managing director still asks for the weekly figures in a spreadsheet, everyone learns that the old way is the real one. Approve requests in the new system, open its dashboards in meetings and ask questions based on its data. That signal carries more weight than any launch email.
The software works on launch day. Whether people use it is decided in the weeks that follow.
Training that actually sticks
Generic training on every feature is forgotten within days. Training works when it is short, based on each role’s real tasks and delivered close to go-live. A sales executive needs to know how to log a lead and send a quote, not how the inventory module calculates landed costs.
- Role-based sessions — 60 to 90 minutes covering only the tasks that role does every week.
- The team’s own language — in multilingual workplaces across the UAE and the Gulf, sessions in Arabic, Urdu, Hindi or English make a real difference.
- Short how-to videos — two-minute screen recordings people can rewatch at their desk or on a phone.
- Practice with real data — a training environment using familiar customers and products, not invented examples.
Go-live and the first 90 days
Go-live is the start of adoption, not the end of the project. Plan two to four weeks of hypercare, when the project team is on hand daily to answer questions, fix small issues fast and sit with anyone who is struggling. Quick responses in this period build the trust that keeps people on the new system.
Agree a firm switch-off date for the old spreadsheets and forms, and stick to it. Then measure adoption honestly: how many people log in each day, how many orders are entered directly rather than afterwards, and where people still work around the system. Those workarounds are not disobedience; they point to features that need fixing.
Share progress openly as well. A short weekly update listing the issues fixed, the tips people have discovered and the improvements on the way shows that feedback leads somewhere. Celebrate early wins with real numbers, such as quotes sent in half the time, so the benefits feel tangible rather than promised.
The bottom line
New systems rarely fail because the code is bad. They fail because the people expected to use them were left out, rushed through training or abandoned after launch. Budget around 10% to 15% of your project for change management, give it a named owner, and treat the first three months after go-live as seriously as the build. That is what turns a working system into a used one.
If you are already living with a system that never quite took off, it is rarely too late. Talk to the people who avoid it, fix the three biggest frustrations they name, retrain by role and set a new switch-off date. A relaunch done this way often succeeds where the original launch stalled.
