The pattern is consistent enough to be predictable. A pilot runs with a volunteer group, the results are good, leadership approves a wider rollout, licenses go out to two hundred people, and usage climbs for three weeks and then flattens at a fraction of what the pilot suggested.
The diagnosis offered is usually cultural. People are resistant. People need more training. People need to see the value.
Occasionally that is true. More often the pilot was measuring something different from what the rollout is measuring, and the difference was structural rather than attitudinal. Five patterns account for most of it.
The pilot group was self-selected
Pilots run on volunteers, and volunteers are not a sample of the population. They are the segment of the population most inclined to try new tools, most tolerant of rough edges, and most willing to work around a gap in the process rather than escalate it.
Their results are real. They are also the ceiling, not the average. A rollout to the full population includes people who will use a tool if it is faster than what they do now and will abandon it the second week if it is not.
What to do about it: run the pilot with volunteers if that is what is available, but measure a second cohort that was assigned rather than volunteered, even if it is only six people. The delta between those two groups is the single most useful number the pilot can produce, and almost nobody collects it.
Nothing was taken away
An AI tool that gets added to a workflow without anything being removed from it is a net addition to the day. It may be faster at the specific task, but the person still has the old habit, the old system of record, and frequently the old review step running alongside.
Under time pressure, people revert to the path they trust. That is not resistance, it is reasonable behavior under uncertainty.
What to do about it: identify the specific step the new tool replaces and retire it explicitly, with the manager saying so. If nothing can be retired, the tool is a quality improvement rather than a time saving, and it should be positioned and measured that way. Positioning a quality improvement as a time saving is how a genuinely useful tool gets judged a failure.
The review burden landed on one person
Output from an AI tool usually needs checking. In a pilot, the checking is distributed across a small group who are engaged with the experiment and interested in the output quality.
At scale, the checking tends to concentrate. A team lead becomes the person who reviews everything the team produces with the new tool, because nobody has decided who else is qualified to. That person’s queue becomes the constraint on the whole workflow, and their experience of the rollout is that it made their job worse.
What to do about it: decide who reviews what, and at what threshold, before the rollout rather than after. In practice this means defining the categories of output that need review at all, since treating every output as equally risky is what creates the bottleneck. Some outputs need a second pair of eyes. Some need a spot check. Some need neither, and saying so out loud is what makes the workflow viable.
Managers were informed rather than involved
A rollout communicated to managers is a rollout they will comply with. A rollout that changes how their team’s work is measured, reviewed, or paced is one they need to have shaped.
This is the failure mode that looks most like culture and is least about it. A manager who was told about a change on a Thursday and asked to support it on the following Monday has no basis for answering their team’s questions, no ability to adjust the workload while the team learns, and no ownership of an outcome they will nonetheless be held to.
What to do about it: bring the managers of the affected teams into the design of the rollout, specifically the parts about capacity and review. Ask them what they expect will break. They usually know, and the answer is usually cheap to address in advance and expensive to address after.
Nobody said what success looked like at the individual level
Programs get organization-level targets: a percentage of eligible staff using the tool monthly, a reduction in cycle time, a productivity figure. Individuals get none of that translated.
An analyst who has been told the department is targeting a thirty percent reduction in turnaround time has no idea what that means for the report they are working on this afternoon. In the absence of a specific expectation, the safe choice is the old method.
What to do about it: translate the target into a statement about a specific task. “For this category of request, the first draft comes from the tool and you edit it,” is actionable. It also has the useful property of being falsifiable, so when it does not work for a particular category the team can say so and the process can be amended.
The thing that ties these together
None of these five are about enthusiasm. Four of them are about decisions that were never made: what gets retired, who reviews, what managers own, what the individual expectation is. The fifth is about a measurement that was never taken.
That is generally good news, because unmade decisions are easier to fix than attitudes. It does mean the work sits with the program rather than with the people being asked to adopt, which is a less comfortable place to put it.
The practical implication for planning: an adoption plan that consists of training sessions and communications is not an adoption plan. It is a launch plan. An adoption plan names the retired step, the review model, the manager commitments, and the individual-level expectation, and it assigns each of those to somebody before the licenses go out.
Where Velnoro fits
Adoption is one of four areas Velnoro looks at in an engagement, alongside the business case, the process, and the technology. It is included in the diagnosis rather than treated as a rollout activity that happens later, because a recommendation that the team will not run is not a recommendation worth making.
Engagements produce a plan that names the sequence, the owners, and the effort, and they end when the team is confident it can carry the work forward without outside help.