The Last Mile of Adoption: Where Projects Die on the Way to the Desk
The system is live, training is done, access is granted. A month later the manager opens a report and finds half the team working in the system — and the other half working around it: in a spreadsheet, in chat threads, in their heads. Formally, the project is closed. In practice, it stalled ten percent short of the goal.
That ten percent is the last mile of adoption — the stretch between a working system and work that has actually changed. It is never designed, never budgeted, and almost never owned, even though it is exactly where the project's return on investment gets decided.
The last mile fails not because people are unwilling, but because of three manageable gaps: the new way of working carries no obvious payoff for the person doing it, help isn't available at the moment of difficulty, and there's no social proof from peers. All three are measurable, and all three get closed before launch, not after.
What actually breaks in the final ten percent
The problem almost never looks like outright refusal. It looks like partial use, which is exactly why it goes unnoticed for so long: reports get generated, records get created, and decisions still get made outside the system.
The new way costs the user more than the old one. The system asks for four fields filled in where a one-line message used to suffice. The payoff from those fields goes to the manager and to an adjacent department; the person who pays in time is the user. As long as that exchange looks unfair from where they sit, they will find a workaround — and that's rational behavior, not sabotage.
Help isn't available at the moment of difficulty. Training happened three weeks ago, the instructions sit in a shared folder, and the question comes up right now, needing an answer in two minutes. The employee isn't choosing between the system and the manual — they're choosing between the system and whatever method they know will work.
There's no social proof. People watch their colleagues, not the memo. If two experienced employees keep working the old way and nothing happens to them, the new rule reads as optional, no matter what the policy document says.
The old route stayed open. As long as the previous method is still physically possible, some share of the work will keep flowing through it. This is the easiest cause to fix and the most often ignored: closing the old route feels harsh, but it's the only measure that works without daily enforcement.
| Cause | What it looks like from outside | What actually fixes it |
|---|---|---|
| The exchange doesn't pay off for the user | "The system is clunky" | Cut the fields, or return the payoff to the person who pays the cost |
| Help isn't available in time | "People weren't trained" | An answer within minutes, at the point of work |
| No social proof | "Resistance to change" | Visible peers who have already switched |
| The old route is still open | "Some work still bypasses the system" | Close the route — don't just remind people about it |
The second column is what a manager hears and writes into the report. The third is what actually needs doing. The distance between the two explains why last-mile projects get treated with training, year after year.
What actually determines whether people use a system
User adoption of technology isn't a soft, unmeasurable thing. There's a model that unified eight competing theories and was tested in the field.
The Unified Theory of Acceptance and Use of Technology explains roughly 70% of the variance in intention to use a system — substantially more than any of the eight prior models on its own (which ranged from 17% to 53%). The key factors: performance expectancy, effort expectancy, social influence, and facilitating conditions.
A caveat: the work is over twenty years old, and it measures intention to use, not actual use — a gap that does exist between the two. Age doesn't undercut it here: the set of factors has held up, and that set is exactly what's practically useful. Three of the four factors — performance expectancy, social influence, and facilitating conditions — map directly onto the causes broken down above.
How large the adoption gap is in practice
Recent data shows the gap between those who decide to roll out a tool and those who are supposed to use it persists well into the AI era — and in measurable form.
Regular generative AI use among frontline employees has plateaued at 51%, while among executives and managers, more than 75% use it several times a week. The authors point to three drivers of the gap: insufficient support from leadership, lack of suitable tools, and insufficient training.
A necessary caveat: this is self-reported frequency of use, not behavioral logs, and the survey was run by a consulting firm that sells AI implementation services. Exact fieldwork dates aren't disclosed. What's useful here isn't the absolute level but the persistence of the gap across hierarchy levels — it lines up with the "exchange doesn't pay off for the user" mechanic.
The other side of the same coin is shadow AI. When the approved tool is inconvenient, the work doesn't stop — it moves into unmonitored channels.
Eight out of ten surveyed employees use unapproved AI tools that bypass corporate-sanctioned solutions. Among security leaders themselves, 68% admitted to using unapproved tools.
The study was commissioned by a vendor that sells risk-management solutions — the commercial motive to make the problem look acute is obvious. But the direction of the finding matches the last-mile mechanic: workarounds show up wherever the approved route costs the user more, and they show up even among the people who are themselves responsible for enforcing the ban.
How to build the last mile before launch
All four causes are closed by work done before the system goes live, not after. That work is cheap, but it needs a process owner — and usually doesn't have one, because the project is treated as a technical one.
The first commitment is easy to check: ask the user to name what they get from the new process. If the only answer is "I was told to," the exchange is negative for them, and no amount of communication will change that.
The fourth commitment is the only one with a date. Closing the old route gets announced in advance, not sprung on people, and it's precisely the date that turns the transition from a wish into a plan. A way to measure adoption in more depth — through process events rather than surveys — is covered elsewhere.
Four questions to ask before launch
What does the person filling in the fields get out of it
If only the manager benefits, the exchange is unfair, and a workaround will appear within the first week.
Who do you message the moment something's unclear
A specific person or channel with an answer in minutes. Instructions in a shared folder don't fill that role.
Who switched first, and is it visible
Two or three respected colleagues working the new way in plain sight of everyone else carry more weight than a memo.
When does the old route close
A date, named in advance. Without it, the transition never finishes — it just drags on indefinitely.
As long as the old way of working stays physically possible and costs nothing, adoption isn't finished — no matter what the sign-off document says.
Frequently asked questions
Why don't employees use a system that's already been rolled out?
In most cases, because the new way of working costs them more than the old one, and someone else gets the payoff. Check it with a single question to the user: what do they get from the new process. If the answer boils down to "because I was told to," you've found the cause — and it's fixed by changing the exchange, by cutting required fields or returning part of the payoff to the user, not by re-running training.
How do you measure adoption of a new system?
Not by counting active users — that metric is always inflated, because it counts logging in as using. Track the share of processes that go through the system end to end: if the outcome is produced but the decision was made in a chat thread, that process bypassed the system. The second metric is the share of records with required fields actually filled in.
Should you force the old way of working to shut down?
Yes, but on a date announced in advance and only after the first three commitments are already in place. Closing the route while the system is still inconvenient and help is still unavailable doesn't produce adoption — it produces conflict and shadow channels. The right order: make the new way cheaper for the user, guarantee fast help, show colleagues who've already switched, and only then name the date.
How long does the last mile take?
In my experience, anywhere from a few weeks to a quarter, and that time needs to go into the project plan as its own line item with its own owner. Projects that don't plan for a last mile don't get through it faster — they just end before the work actually changes, and the gap shows up in the first reporting period.
The list of four causes and four last-mile commitments is my own synthesis from CRM rollouts at three companies (a digital agency, a seasonal corporate-gifts manufacturer, and an online-booking platform) and from training and coaching work at those same companies. No quantitative measurement of the share of work bypassing the system was taken at the time of these rollouts; the "a few weeks to a quarter" range is my own estimate from those projects, not a measured figure.
- Venkatesh V., Morris M. G., Davis G. B., Davis F. D. User Acceptance of Information Technology: Toward a Unified View. MIS Quarterly, 2003. aisel.aisnet.org
- Boston Consulting Group. AI at Work: Momentum Builds, but Gaps Remain, June 26, 2025 (survey of more than 10,600 respondents across 11 countries). bcg.com
- UpGuard. New Research Reveals 68% of Security Leaders Admit to Unauthorized AI Usage, November 2025. upguard.com