Adoption Is the Project: Why Good Systems Fail at Go-Live

The system went live on a Monday. Training happened the week before, the data came across cleanly, and the launch went smoothly enough that everyone relaxed. Three months later, the sales team is quoting from a spreadsheet again, two people never log in, and the reports the whole thing was bought for cannot be trusted because half the transactions never made it into the system.

The software was never the risky part. It was always the fifty people who had to change how they work on a Monday morning while still doing their jobs.

Why people go back to the spreadsheet

It is tempting to file this under resistance to change, which is comforting and almost always wrong. People revert for concrete, rational reasons.

• The new way is slower for them. Often the system is faster for the business and slower for the individual, because it asks for data they never used to capture. If nobody explains why, they optimise for their own day, exactly as you would.
• It does not fit the real process. The system was designed around the official process, not the one with the exception everyone deals with weekly. The first time reality does not fit, out comes the spreadsheet.
• Nobody made it stop. The old method still works, is still accessible, and is still accepted by the people who receive the output. Two paths remain open, so people take the familiar one.
• Training was a demonstration, not practice. Two hours of someone clicking through screens teaches almost nothing. People learn systems by doing their own work in them, with help nearby.
• They never saw anything come back. Capture without visible benefit feels like admin invented to inconvenience them. When the data returns as something useful to them, the effort makes sense.

People do not abandon a new system because they dislike change. They abandon it because on a busy Thursday the old way still works and nobody has explained what they get for the extra thirty seconds.

What actually makes it stick

Adoption is not a phase at the end of a project. It is most of the project, and it should be visible in the plan and the budget rather than assumed to be free.

The single most effective step is to design the new process with the people who will live in it, before the software is configured, including the awkward exceptions they handle every week. It costs a few workshops and it removes the most common cause of failure, which is a system that quietly cannot do something the business does routinely.

The second is to close the old door deliberately, on a date, with warning. Not out of severity, but because parallel running that never ends is the most reliable way to kill a system. Set the date, communicate it, and make sure the reports and approvals downstream only accept the new source afterwards.

The third is to give people something back early. A report that saves the branch manager an hour. An automatic reminder that stops a supervisor chasing. Adoption arrives much faster when the system is visibly useful to the people typing into it, rather than only to the people reading the dashboards.

Training that survives the week

Classroom sessions weeks before go-live are forgotten by launch. Better is short, role-specific training close to the date, using real work rather than demonstration data, followed by floor support in the first week, when every genuine question surfaces. Written help should be one page per role covering the ten things that person actually does, not a hundred-page manual nobody opens. And there needs to be an obvious way to ask for help that is faster than reverting to the old method, or people will revert.

Measure use, not just delivery

Projects are usually declared successful at go-live, which is the one moment when nothing has been proven. The honest measures come later: what proportion of transactions go through the system, how many people log in weekly, how long a task now takes, and whether the number the system produces is the number the business argues about. Check those at thirty, sixty and ninety days, and fix what they show while there is still momentum and budget.

Good software badly adopted is worse than no software at all. It costs money, it costs credibility, and it makes the next attempt considerably harder to sell internally. The technology is rarely what decides it.