Technology programmes are routinely judged complete when the system goes live, with change management reduced to a training schedule delivered in the final weeks. The training happens, attendance is logged, the programme closes, and six months later the organisation discovers that half of it reverted to the old spreadsheet, the old process, the old workaround, because nobody actually built the conditions for the new way of working to stick.
This is not a communication failure that a better slide deck would fix. It is a structural failure to treat adoption as an engineering problem with its own design, its own incentives and its own measurement, rather than as a soft afterthought bolted onto the end of a delivery timeline.
Attendance is not evidence of anything
A training completion rate tells you that people sat in a room or clicked through a module. It tells you nothing about whether they can use the system unsupervised, whether they trust it enough to abandon their old workaround, or whether their manager is quietly still asking for the old report in the old format, which undermines every hour of training on day one.
Adoption metrics that matter look at behaviour in the live system weeks after go-live: what proportion of transactions flow through the new process without a workaround, how often the old system or spreadsheet is still being touched, how quickly users recover from an error without escalating. These are harder to collect than a sign-in sheet, which is exactly why most programmes settle for the sign-in sheet instead.
Go-live is not the finish line. It is the point where the actual work of adoption begins, and most programmes stop paying attention exactly then.
Capability has to be built before go-live, not announced at it
Genuine capability building looks less like a training calendar and more like a deliberate ramp: early exposure to the real system with real data well before go-live, a defined group of confident early users who become peer support rather than a helpdesk ticket, and enough repetition that the new way of working becomes the default rather than the effortful alternative.
Where this is done well, the go-live date stops being the moment adoption begins and becomes simply the moment the training wheels come off. Where it is skipped, go-live is the first time most users encounter the system for real, and the resulting confusion gets misdiagnosed as a system problem rather than an adoption design problem.
Incentives quietly decide the outcome
People do not adopt new ways of working because they were told to; they adopt them because the new way is genuinely easier, or because the old way has been made genuinely harder, or because someone whose opinion they care about is visibly using the new system and expecting them to as well. Programmes that ignore incentive design and rely purely on communication are betting against basic human behaviour.
This includes management incentives, not just frontline ones. If a manager's own reporting still runs on the legacy system, or if performance conversations still reference the old metrics, the frontline team will correctly read that the new system is optional and behave accordingly, regardless of what the launch email said.
- 路Retire the old system or process on a fixed date rather than allowing indefinite parallel running
- 路Align manager reporting and performance conversations to the new system before go-live, not after
- 路Identify and equip visible early adopters who can model the new behaviour credibly to peers
- 路Measure workaround usage directly, not just training completion, as the primary adoption signal
Measuring behaviour, not attendance
A serious adoption dashboard tracks the gap between designed process and actual behaviour over time: workaround frequency, error recovery time, the proportion of users who have not logged in for a defined period, and whether that gap is closing or stalling. None of it requires exotic tooling; most of it is sitting in system logs that nobody has bothered to query for this purpose.
Reporting this honestly, including when adoption stalls, is uncomfortable for a programme that wants to declare victory at go-live. But it is the only way to catch a failing adoption curve early enough to intervene, rather than discovering it a year later as a quiet, expensive reversion to the old way of working.
Treating adoption as an engineering discipline, with its own design, incentives and measurement, is more work than running a training schedule and hoping. It is also the difference between a technology investment that changes how the organisation actually operates and one that simply changes what software is installed while the old habits carry on underneath it.
The last mile is rarely glamorous, and it rarely gets the budget or attention that the build phase gets. But it is the mile that determines whether everything before it was worth doing at all.