Shipping the model is a quarter of the job. We have watched technically excellent systems go live and get used by almost nobody, and we have watched unremarkable ones become load-bearing within a month. The difference is almost never the model.
People do not abandon a workflow they are judged on
If someone is measured on a number, and your tool changes how that number is produced, they will not adopt it until they trust it more than they trust their own process. That is rational. The cost of being wrong lands on them, not on the project.
The fix is not training. It is running the new system in parallel, visibly, long enough for the person to check it against their own work and find that it agrees. Two weeks of that does more than any amount of enablement. Skipping it is why rollouts stall at the people who matter most.
The first bad output gets remembered forever
Trust is asymmetric. A system that is right ninety-five times and wrong five times is not experienced as ninety-five percent accurate. It is experienced as unreliable, especially if one of the five was memorable and reached a customer.
This argues for launching narrow. Pick the slice of the workflow where you can be near certain, prove it there, and expand. The instinct to launch broad so the business case looks bigger is the instinct that kills the business case.
Nobody reads the announcement
Most rollout plans assume attention that does not exist. An email, a lunch and learn, a page in the wiki. None of these change behaviour in a busy team.
What works is putting the thing where the work already happens. If the team lives in a ticketing system, the output belongs in the ticket. If they live in a shared inbox, it belongs in the thread. Every click you ask someone to add is a place where adoption leaks, and the leak compounds daily.
Budget for the part after launch
Most programmes are funded through go-live and then thin out. Adoption happens after go-live. The weeks when someone is watching output, fixing the cases that embarrass the system, and sitting with the team that has to use it are the weeks that decide whether any of it sticks.
If the plan has no named owner for the ninety days after launch, the plan is to build something and hope. We have seen enough of those to say plainly that hope does not work here.
A short checklist
- Run in parallel until the sceptics check it and stop checking.
- Launch on the narrowest slice you can be confident about.
- Put the output inside the tool people already have open.
- Name an owner for the first ninety days after go-live.
- Fix the embarrassing cases before you expand the scope.
None of this is about change management as a discipline. It is about accepting that the people who have to use the thing have their own incentives, their own memory of the last tool that was forced on them, and no particular reason to trust you yet.