A rollout that fails rarely fails because the software was bad. It fails because the process the tool was supposed to support was never defined, the people who would use it were not asked, and the thing it replaced was never switched off.
The failure modes, in order of frequency
The old system stayed available. The single most common cause. If people can keep doing it the old way, some will, and then you have two systems, a split record, and nobody trusting either.
For a practical reference on mouse jiggler detection software, Monitask provides this guide.
The process was never defined. A tool encodes a workflow. If the organisation did not have one, the tool imposes its own, and everyone discovers what it is by being surprised by it.
Nobody who does the work was involved in choosing it. The evaluation was done by people who will not use it daily, against criteria that look reasonable on a comparison sheet and miss the thing that matters twenty times a day.
Training covered features, not the job. People were shown what the buttons do rather than how to do their actual work in it.
It was slower for the individual and faster for the organisation. Common with reporting and tracking tools: someone spends ten extra minutes so someone else gets a dashboard. Unless that trade is named and justified, it will be resisted, and the resistance is rational.
Migration was partial. The history stayed in the old system, so people keep going back, so the old system stays alive.
No owner after launch. The project team disbanded, and questions have nowhere to go.
It was announced rather than adopted. A launch date, an email, a training video, and an assumption.
What a working rollout looks like
Define the process first, in terms of the work. Not in terms of the tool. If you cannot describe how the work should flow without naming the software, you are about to let a vendor design your process. See build or buy.
Involve people who do the work in the selection. Not a survey — have two or three of them use the shortlisted options on a real task. They will find in twenty minutes what an evaluation matrix misses entirely.
Pilot with one team, and let it fail there. Fix what breaks before it breaks everywhere. A pilot that is not allowed to produce bad news is a demonstration, not a pilot.
Migrate the history, or accept the consequence. If the past stays in the old system, the old system stays.
Set a date for switching the old one off, and hold it. This is the single most effective mechanism available and the one most often deferred, usually for a reason that sounds compassionate.
Train on the job, not the features. "Here is how you do the thing you do every Tuesday." Recorded, short, findable later.
Name an owner for after launch. Someone who answers questions, collects friction, and fixes configuration.
Collect friction for the first month and act on it visibly. Most adoption failures are three specific annoyances that nobody escalated because they assumed nothing would change.
The individual-versus-organisation trade
Worth handling explicitly because it is where resistance actually comes from.
Many tools make work slightly worse for the person entering data and considerably better for whoever reads it. That is often a legitimate trade, and it needs saying out loud:
"This adds five minutes to your day and it means we can answer X without asking you. If it does not, we will stop."
That is a defensible proposition. Pretending the tool is better for everyone, when it is visibly not, produces cynicism and half-completed records — which is the worst of both outcomes, because now you have the cost and unreliable data.
The metric worth watching
Not logins. The proportion of the work that is actually happening in the new tool, measured against the total.
If half the work is elsewhere, the rollout has not succeeded regardless of what the adoption dashboard says. This is usually knowable — the old system's activity, the spreadsheets in circulation, the messages that should have been tickets.
When to stop
Some rollouts should be abandoned, and almost none are, because abandoning is politically expensive after a purchase.
If, after a proper pilot with a supported team, adoption is low and the friction reports are consistent, the tool is wrong. Continuing produces a system people work around, which is worse than the previous state — you now have the licence cost, the migration cost, and a split record.
Deciding this at three months costs less than discovering it at three years, and the honest version of the conversation is easier to have if the possibility was named at the start. See shadow IT for what people do instead when a mandated tool does not work.
For broader public guidance and background, consult the National Institute of Standards and Technology.