I have been in the room when a project team celebrates a successful go-live. The system is live. The data migrated. The training sessions happened. Everyone claps.
Three months later, I go back and look at the usage data. Adoption is at 40%. People are back on spreadsheets. The system the business spent months and significant budget implementing is sitting mostly unused.
This is not unusual. Research consistently shows that 70% of digital transformation initiatives fail to meet their objectives, and that the leading cause is not the technology, it is adoption. According to studies of CRM and ERP implementations, between 50 and 63% of these projects fail primarily due to process misalignment and poor usage, not technical problems.
After two decades working inside organisations on both the IT and business side, I have seen this pattern enough times to understand why it happens, and more importantly, how to prevent it.
The five reasons technology adoption fails
1. The team was not involved in the decision
The most common starting point for adoption failure is a decision made without the people who will be affected by it. Leadership or IT selects a system. A vendor demos it to a small group. The contract is signed. And then the team whose work is about to change finds out about it when the training invitation lands in their calendar.
People do not resist change because they are difficult. They resist it because they were not part of it. When I work with organisations on adoption, the first question I ask is not about the technology. It is about who was in the room when the decision was made.
2. Training happens once and then stops
Research from organisations studying digital adoption challenges consistently finds that around 45% of employees say new software is introduced without adequate training. But the more telling statistic is what happens even when training does occur: a single training session, however well designed, is not sufficient.
People learn by doing, with support available when they get stuck. A two-hour training session delivered three weeks before go-live, followed by a user guide nobody reads, is not training. It is box-ticking. And according to the same research, 63% of employees will stop using a new tool if they do not see its relevance or cannot get help when they need it.
3. The process around the tool was never fixed
This is the one I see most often and the one most organisations least expect. You can implement the best tool in the world, but if the process it is supposed to support is broken, the tool will not fix it, it will just make the broken process run faster, or expose its flaws more visibly.
I have seen this with warehouse management systems where the physical layout of the warehouse made the system's picking logic irrelevant. I have seen it with CRM platforms where salespeople had no incentive to enter data because reporting was done manually anyway. The tool was fine. The process around it was not.
4. Nobody owns adoption after go-live
Implementation projects have project managers. Go-lives have hypercare teams. But adoption, the long-term, sustained use of a tool at the level the business case assumed, almost never has a named owner. The project closes. The team moves on. And if adoption dips, there is no mechanism to detect it early or respond to it.
5. The change affected people who were not supported through it
This is particularly relevant in manufacturing and industrial environments, and in any organisation with a significant number of people who are older or less comfortable with technology. These team members are not opposed to working better, they are worried about being left behind. And if nobody takes the time to address that worry directly, they will find ways to work around the new system rather than through it.
What actually works
The organisations I have seen achieve high, sustained adoption share several practices:
Involve the team before the decision is made. Not just in the training. In the requirements, the process design, and the vendor selection. People support what they helped build.
Design the process first, then select the tool. The tool should fit your process. If your process needs to change to accommodate the tool, change the process first, deliberately and with the team, rather than discovering the misfit after go-live.
Build a support structure that outlasts the project. Super users, champions, regular check-ins in the first three months. Not a hotline number, real, accessible support from people who know the system and know the business.
Measure adoption explicitly. Define what good adoption looks like before go-live. Track it weekly in the first two months. Address drops early, before they become habits.
Address resistance directly. Find the people who are not using the system. Sit with them. Understand why. The answer is almost never that they are lazy or difficult. It is usually that something in the process does not work for their specific role, and nobody asked.
"The system is ready" and "the team is ready" are two completely different things. Most go-lives confuse them.
The honest truth
Technology adoption is a people problem that organisations try to solve with technology. You cannot train your way out of a process problem. You cannot configure your way out of a change management failure. And you cannot go-live your way out of a team that was never brought along.
The good news is that all of these problems are solvable. They just require doing the work that is less visible and less celebrated than the technical implementation, and starting that work earlier than most organisations do.
If any of this resonates with a challenge you are facing, I would be happy to have a direct conversation. No commitment, no agenda.