The go live email went out on a Friday. Champagne emoji included. The steering committee had a slide with a green tick on it. Somewhere in that email was a sentence that gets written every time. "The system is now live for all users."
Six months later I sat with the same team. Nobody was celebrating anymore. The system was still live, technically. Nobody had turned it off. But half the team was still emailing approvals to each other. There was a spreadsheet nobody talked about in steering meetings, sitting quietly outside the new platform, doing most of the real work. Someone had built a little macro in it, to make it look almost like the new system, just faster and without the extra clicks.
The programme did not fail. It succeeded completely, by every measure anyone had agreed to track. Budget on target. Timeline held. System live. Nobody ever asked the question that actually mattered. Did the way people work change, or did the system just get expensive to ignore.
That gap has a name now. Adoption. It shows up everywhere. A new ERP. A digital sourcing platform. An AI tool someone built inside the business or bought from a vendor with a good deck. Even a redesigned operating model, no software involved at all. The thing gets delivered. The behaviour never moves.
Twenty two years into this work, I have stopped being surprised by which programmes struggle here. What still surprises me is how rarely anyone plans for it in advance, as if adoption were a nice bonus rather than the entire point of doing the work.
Go live is not the finish line. Most programmes are built as if it is.
Every transformation I have worked on has a moment where the project plan ends. There is a line item called go live, and after it, usually, nothing. Maybe a support period, staffed thinly, wound down within a quarter. Maybe a lessons learned session that nobody reads twice.
The plan treats go live as the destination. It is not. It is the point where the real work actually starts.
Before go live, adoption is not really being tested. People are in training rooms. They are being watched. There is a project team in the building, ready to help, checking in every few days. Everyone is on their best behaviour, because everyone knows they are being observed, and because for a few weeks the new system is simply the thing everyone is talking about.
The real test happens after that project team disbands. It happens in week twelve, when nobody is watching anymore and the old spreadsheet is still sitting on someone's desktop, one click away, familiar in a way the new platform has not earned yet.
Most transformation budgets end just as this test begins. That is not a coincidence. It is a structural problem in how these programmes get funded and measured. Money and attention are aimed at building the thing. Almost none is aimed at whether people actually use it once it exists. The business case gets written around licence costs and implementation fees. It rarely includes a line for the ninety days after launch, when the habit either forms or quietly does not.
I have sat in more steering committees than I can count where the final report showed a beautiful chart. System live. Budget on target. Timeline held. Nobody in that room asked how many transactions were still happening outside the system. Nobody asked because nobody had agreed, at the start, that this was the actual measure of success. The measure everyone agreed on was simpler, and it was already sitting comfortably in the green.
The same pattern, wearing different clothes
I want to be specific here, because adoption problems get talked about mostly in the context of ERP rollouts. That is too narrow. I have seen the identical pattern in four very different settings, and once you see it once, you cannot unsee it anywhere else.
ERPs. This is the classic case, and the one most people picture first. A new system goes in. Purchase orders, invoices, approvals, all meant to flow through one platform. Six months later, procurement is using it for the transactions it cannot avoid, the ones with a hard system control behind them, and running everything else through email and spreadsheets, because that is faster and nobody is checking closely enough to notice.
Digital sourcing and S2P platforms. These often adopt worse than core ERP, not better, because they usually sit on top of a process people already had a perfectly workable way of doing. Sourcing events happened before the platform existed. Negotiations happened before the platform existed. If the old way was faster, even slightly, the new platform becomes something people log into once a week to keep compliance happy, not something that runs the actual work of the category.
AI tools, built or bought. This is the newest version of the same story, and it is happening faster than the others, because the tools themselves ship faster than ERPs ever did. A team builds an internal AI assistant, or buys one from a vendor demoing impressive results in a well rehearsed session. It gets rolled out with genuine excitement. Three months later, usage numbers are quietly disappointing, and everyone assumes the model was not good enough. Usually the model was fine. Nobody built a habit around it. People forgot it existed, because nothing in their daily routine reminded them to open it, and asking a colleague was still one habit ahead of asking the tool.
Target operating models. No software at all, and still the exact same failure. New roles get defined on an organisation chart. New reporting lines get drawn. New meeting structures get scheduled into everyone's calendar. Then, quietly, people keep doing their old jobs under new titles, because the actual incentives and habits underneath were never touched, and a new title on an email signature does not, by itself, change what someone spends their Tuesday doing.
Four different investments. Four different technical shapes. One identical failure mode. Something got delivered. Nobody's actual behaviour moved. I find that consistency more interesting than any single case on its own, because it means the answer is not really about the technology at all.
The explanations everyone reaches for, and why they are not wrong, just incomplete
Ask anyone why adoption failed and you will hear two answers almost every time. Training was not good enough. Change management did not get enough budget.
Both are usually true. Neither is usually the real answer.
I have seen beautifully resourced change programmes fail just as often as underfunded ones. I have seen training that was genuinely excellent, delivered by people who knew what they were doing, well attended, well reviewed on the feedback forms, followed by exactly the same slide back into old habits three months later, as though the training had never happened at all.
Training and change management are necessary. They are not sufficient. Treating them as the whole answer is how organisations end up running the same failed playbook twice, once for the ERP, once for the AI tool that came after it, wondering why the second attempt did not go any better than the first, and quietly commissioning a third round of training as the fix.
What is actually sitting underneath
After enough of these, three things show up again and again. Not always all three together. But rarely just one alone, and rarely in a shape that is obvious from the steering committee deck.
The old way is still easier. This is the quiet killer, and the one I have watched catch out the most experienced teams. If the workaround takes less effort than the new system, people will use the workaround, regardless of what the training said or what the mandate claimed. Nobody sits down and decides to sabotage a transformation. They just take the path that costs them less time on a Tuesday afternoon when they are already behind on something else. Multiply that choice by a thousand small moments a week, across a whole function, and you get a spreadsheet nobody talks about in steering meetings, quietly doing the work the new system was supposed to have taken over months ago.
Nobody actually owns adoption. Someone owns the build. Someone owns the budget. Someone owns the timeline. After go live, ownership usually just evaporates, along with the project team that used to check in every week. There is no single person whose job it is to notice that usage is quietly dropping and to do something about it before it becomes permanent. By the time anyone official notices, the workaround has already become the process, and unwinding a year old habit is a genuinely different problem to catching a six week old one.
The metrics were measuring the wrong thing. Most programmes track go live as the success event. Fewer track what happens in the ninety days after. Even fewer track it honestly, because the people reporting progress are often the same people whose bonus depended on a green status update the previous quarter. A programme that measures compliance at launch and never checks again is not measuring adoption. It is measuring a single moment, dressed up as an ongoing state.
None of these three things are technology problems. That is worth sitting with for a moment. The platform is very rarely the actual issue. I have watched genuinely excellent systems fail to get adopted, and genuinely mediocre systems get embraced completely, because the second one solved for these three things and the first one simply assumed they would sort themselves out.
If you are trying to work out which of these three is actually going on in your own case, the Platform Adoption Honest Check will give you a direct read.
The cost compounds quietly, which is why nobody stops it in time
Here is the part that rarely makes it into a business case. A partially adopted system does not just deliver half the value. It often costs more than either the old way or full adoption of the new way, because now the organisation is running two processes at once, and paying for both.
Someone still has to reconcile the spreadsheet against the system periodically, because auditors will eventually ask why the numbers in each do not match. Someone still has to explain, in every steering meeting, why usage is not higher yet, and someone has to write that explanation in a way that does not read as an admission of failure. The licence cost for the new platform does not go away just because half the organisation is quietly avoiding it. Neither does the maintenance cost of the workaround it was meant to replace.
I have seen this run for years in some organisations, not months. A platform that went live, technically, half a decade ago, still running alongside the process it was meant to retire, both maintained, both budgeted for, neither one fully trusted. By the time anyone senior asks the honest question, the answer involves unwinding habits that are now older than some of the people being asked to change them.
There is a reputational cost too, quieter than the financial one but just as real. Every partially adopted system makes the next one harder to sell internally. People remember the last platform that was meant to change everything and mostly did not. That memory shows up as scepticism in the next kickoff meeting, and scepticism is a genuinely difficult thing to budget for or plan around, even though it shapes how the next eighteen months actually go.
What good adoption actually looks like
It is less dramatic than the failure stories, which is probably why it gets talked about less at conferences and in vendor case studies.
Someone is named, explicitly, as owning adoption after go live. Not the project manager who moves on to the next programme the following month. Someone whose job continues past the point where the ribbon gets cut, with adoption written into what they are actually measured on, not treated as a nice addition to a broader role.
The measurement continues past launch. Real usage, thirty, sixty, ninety days out, reported honestly in the same steering forum that celebrated go live, even when the number is not flattering, and especially when it is not flattering, because that is exactly the moment the information is most useful.
The workaround gets studied, not banned. If people are avoiding the new system for a specific reason, that reason is data, not defiance. It tells you exactly what the new system got wrong, or what the old way still does better, in terms specific enough to actually fix. Punishing the workaround without fixing the underlying reason just pushes it further underground, into a version even harder to see from a steering committee seat.
And the organisation accepts, going in, before a single line of the business case gets written, that adoption takes longer than the build. The build has a plan and a deadline, and both are genuinely achievable with the right team. Adoption has a curve, and it bends slowly, through repetition and small reinforcement, not through a single training day and a slide with a green tick on it.
Where I would leave this
Go back to that Friday email. The champagne emoji. The green tick on the slide.
The sentence that got written was, the system is now live for all users. It is a fine sentence, and it is not untrue. The sentence that should have been written alongside it, the one that actually matters, is a different one entirely. We will check back in ninety days, and again after that, and we will keep asking until the answer is genuinely yes, not just technically true.
Live and adopted are not the same word, even though the go live email tends to use them as if they were. Most programmes are built and measured as if they are interchangeable. That gap, the one nobody names in the celebration email, is where I would start looking first, on any transformation, of any kind, technology involved or not.
