Adoption Is a Measure, Not a Hope

Improvement work is unusually disciplined about measurement. Teams define an outcome measure, collect a baseline, chart the results, and judge the change by the data. This is the strength of the method, and it is taught well.

Then the same teams launch a change and never measure whether anyone is doing it.

The outcome measure is treated as proof of adoption. If the number moves, people must be doing the new thing. If it does not, they must not be. Both inferences are unreliable, and the second one arrives too late to help. The outcome measure tells you the change failed after it failed. Adoption is the thing that fails first, and almost nobody counts it.

Two different questions

“Did the process improve?” and “Are people doing the new process?” are separate questions with separate answers.

A change can be fully adopted and not move the outcome, because the change was wrong. That is a design failure, and the improvement method handles it well: study the data, revise, test again.

A change can be sound and not move the outcome, because people are not doing it. That is an adoption failure, and the improvement method has little to say about it. Teams that cannot tell these two situations apart end up revising a design that worked and retraining people who were never the problem.

The only way to tell them apart is to measure adoption on its own.

What “adopted” looks like

An adoption measure answers a plain question: how often is the new behavior happening, out of the times it should? The definition has to be written before the change launches, because after launch every team discovers that “we implemented it” means different things to different people.

A usable definition has three properties.

It is observable. Not “staff are aware of the new process,” but “the new step was performed at the handoff.” Awareness is not adoption. Attendance at training is not adoption. Only the behavior counts.

It is countable. A share of observed events, a count per shift, a proportion of eligible visits. Small numbers are fine. Five handoffs observed on one unit tell you more than a survey of a hundred people about what they intend to do.

It is predicted. Before the test, the team writes down what adoption it expects by the end of week two or week four. The prediction is what turns a number into learning. A result with no prediction is just a result. A result compared to a prediction is a finding.

Proficiency is not attendance

A related confusion: many organizations treat a training completion report as evidence that people can do the new thing. It is evidence that they were present. Whether they can perform the behavior correctly, under real conditions, is a separate question, and it is the one that matters for survey readiness, for safety, and for the outcome.

A skills check or a brief observation answers it. A completion report does not. Teams that measure proficiency find, reliably, that a portion of the people who completed training cannot yet do the thing, and that this portion is where the outcome measure is leaking. The gap is not a training failure. It is a measurement failure, corrected the moment someone looks.

Measurement without surveillance

The objection to adoption measures is that they feel like watching people. Done badly, they are. Done well, they are the opposite: they are how a team finds out what is getting in the way before anyone is blamed for it.

The difference is in a few choices. Count behaviors, not people. A number on a huddle board that says four of five handoffs happened at the bedside is information. A list of which nurses did and did not is a disciplinary document, and staff will treat the whole measure accordingly.

Let the team see the number. An adoption measure that only the quality department sees is surveillance. One that the team sees every day is a scoreboard, and people play differently in front of a scoreboard.

Use the gap to ask, not to correct. When adoption is lower than predicted, the right response is a question: what got in the way? The answer is nearly always a workflow problem, a timing problem, or a belief problem, and each has a fix that does not involve reminding anyone of anything.

The early warning system

Adoption leads. Outcomes lag. In most changes, adoption starts to slip weeks or months before the outcome measure shows it, which is exactly the window in which a small adjustment can save the improvement. A team watching only the outcome loses that window every time.

This is why an adoption measure belongs next to the outcome measure on every dashboard, in every report to leadership, and in every Flex network or learning collaborative conversation about a measure that moved and then drifted. Two numbers, side by side. One says whether the change is working. The other says whether it is still happening.

Improvement methods are rightly proud of their discipline about outcomes. The people side asks for the same discipline about adoption: define it, predict it, count it, and act on the gap. The tools for doing that at each step are on our PDSA page and our DMAIC page.