Adoption Is the Project: The Phase Everyone Skips

Adoption is not attendance. It is not the number of people who logged into the new system, or the percentage that finished the training module, or the town-hall that had good energy. Those are proxies, and cheap ones. The actual measure is whether the business is running on the new thing on Monday morning — the orders flowing through the redesigned workflow, the inspector filling out the new checklist rather than the old one, the operations review using the new operating cadence instead of the pre-launch one that everyone still has muscle memory for.

The distinction matters because attendance and completion are easy to hit. Ninety-eight percent of the frontline completed the e-learning. Every supervisor signed the acknowledgment. Every user has an account. All of that can be true in a business where nothing has changed. The old spreadsheet is still open on the second monitor. The paper checklist is still in the clipboard. The Friday call runs off the old report because the new one takes an extra step and nobody has time on Friday. The system is live. The business is not on it.

Real adoption has a physical signature. Transactions in the new tool as a share of total transactions, holding above ninety percent past the point where the launch team goes home. Exception volume falling from the week-two peak toward a stable baseline instead of quietly climbing. The operating rhythm — the standup, the S&OP call, the executive review — running against the new numbers, not the old ones. When those signals hold for six months without a coach in the room, the initiative has adopted. Before that, it has launched, which is a different thing.

The reasons are always the same, in every industry and every kind of initiative. The funding runs out before adoption starts. The calendar treats go-live as the finish line. Executive attention moves to the next headline the day after the ribbon is cut. And the people who own adoption are usually not the people who owned the build, which means the handoff happens exactly when continuity matters most.

Funding is the loudest of the four. A capital program with a defined scope, a vendor contract, and an integration partner has a clean number on it. Adoption — floor-level coaching for eight to twelve weeks, a stabilization team through month six, executive routines through month twelve, the small army of process owners who quietly rewrite work instructions as reality diverges from the design — is harder to bound and easier to cut. When the program budget gets pressured in the final quarter before launch, the line that gets thinned is almost never the vendor line. It is the change work, because the change work has no external contract behind it.

The calendar problem is quieter but just as reliable. The plan shows a go-live date. Everything upstream of that date is scheduled to the week. Everything downstream is a rectangle labeled “hypercare,” usually thirty to sixty days long, sized to match how long the integrator’s people are contracted to stay. Real adoption peaks in load around week three — when the launch adrenaline is gone, the first ugly month-end is landing, and the workarounds people invented in week one are calcifying into permanent habits — and needs sustained attention through month six. Hypercare almost never lasts that long, and executive attention almost never lasts past the first clean weekly report.

The attention problem is the one leaders would fix if they saw it. A CEO who chairs a steering committee weekly for eighteen months of build will typically attend one or two adoption reviews after launch before the calendar reclaims the slot. The signal that sends is unambiguous. The middle of the company is very good at reading which programs the top still cares about, and it allocates its own scarce attention accordingly. Programs that lose executive presence in month two lose the middle in month three.

A real adoption plan has a shape that does not match the build plan, and that mismatch is why it gets squeezed. The build plan tapers toward go-live. The adoption plan ramps from it. Peak load is not launch week. Peak load is week three, when the workarounds are hardening and the exceptions are stacking up and the people who were quiet in training start asking the questions they were embarrassed to ask before. Sustained support runs through month six, when the system has to survive its first quarterly close and its first change of season without a launch team in the room.

The plan has named owners at three levels. A process owner in each functional area who is on the hook for the operation running on the new thing — not the tool working, the operation running — and who has the authority to change work instructions, reassign people, and escalate. A program owner who runs the leading-indicator review and holds the process owners to a cadence. And an executive sponsor who shows up to the review, in person, on a schedule that does not slip. Adoption without named owners at all three levels is a hope. It is not a plan.

The plan measures leading indicators, not lagging ones. Usage inside the redesigned workflow, week over week. Exception rate and its trend. Cycle time on the transactions the initiative was supposed to move. And the outcome number itself — the one the business case named — tracked from week one, even when the value is small, so the curve is visible when it starts to bend. A dashboard that only reports the outcome number will show a flat line for four months and then a panic in the fifth. A dashboard that reports the leading indicators will show the trouble in week three, when it is still cheap to fix.

And the plan budgets for refinement. Every initiative meets reality at go-live and discovers what the design got wrong. That is not a defect. It is the beginning of the actual work. A real plan holds a small refinement capacity through month twelve, so the things the frontline discovers in week four can be fixed in week six rather than filed as a wish for the next release.

Adoption failures announce themselves early, in ways that are easy to miss if the review is looking at the wrong dashboard. The first signal is the workaround economy. Two weeks after launch, someone has built a spreadsheet that pulls data out of the new system, cleans it up the way the old report used to look, and emails it around every Monday. Once that spreadsheet exists, the new report is dead. It has a URL. It has a name in the corporate directory. It just has no readers.

The second signal is exception volume that does not decay. In a healthy launch, exceptions spike in the first two weeks — people making genuine mistakes with a new tool — and then fall as the frontline learns. In a launch that is quietly failing, exceptions stay high or climb, because they are not learning errors. They are workarounds, each one an operator routing around a step that does not fit the actual case in front of them, each one hardening into a permanent bypass unless somebody notices.

The third signal is executive language. When the leadership team stops naming the initiative and starts referring to “the new system” or “the project,” the program has lost its identity and is on the path to being folded into background noise. When the operating review opens with the old KPI slide and the new one is added at the end “for context,” the shift has already happened. The initiative is over. It just has not been announced.

Nike learned some of this in 2000. The i2 demand-planning rollout that cost the company north of a hundred million in lost sales and dropped the stock twenty percent was not fundamentally a software failure. The vendor had warned Nike to hold customization to ten or fifteen percent. Nike went well beyond that to accommodate its existing data and process. Planners were, by the company’s own subsequent account, inadequately trained before the system went live. When Nike rebuilt the program, one of the changes it made was to require a hundred and eighty hours of training and to lock people out of the system until they had completed it. That is what an owner who has learned the hard way looks like.

The most consistent structural error in the category is putting adoption inside the function that owned the build. The IT organization that stood up the ERP is asked to run adoption. The transformation office that designed the operating model is asked to embed it. The safety team that wrote the new program is asked to make it stick. In every case, the function that owns adoption has to be the function that runs the business on the other side. Otherwise the accountability points at the wrong door on Monday.

The pattern that works is simple and hard to arrange. A business owner — the executive who runs the operation the initiative was supposed to change — is on the hook for the outcome number from before launch. A program owner runs the cadence, the indicators, and the refinement backlog. The build team stays in support through month six, then hands over cleanly to a steady-state operating rhythm that has been running in parallel since week one.

This structure survives the calendar because the accountability does not depend on the build team staying. It survives budget pressure because the business owner is defending a number, not a project line. And it survives the attention problem because the operating review is the review — not a separate adoption meeting sitting next to twelve other separate meetings. The initiative has become the way the business runs, which is what adoption was supposed to mean.

Every initiative reaches a point, usually somewhere between the business case approval and the first major milestone, where a decision gets made about how the last phase will be funded and staffed. The decision is rarely framed that way. It shows up as a scope conversation, or a budget pressure, or a schedule question. But underneath, it is a decision about whether adoption is a real phase of the project or a rectangle labeled hypercare at the end of the Gantt chart.

The programs that land the outcome make that decision deliberately and early. Adoption gets a named owner, a real budget, and a place on the schedule that starts before go-live and ends around month twelve. The plan carries leading indicators, refinement capacity, and executive routines that are on the calendar in ink. The build team knows from day one that its work is not done at cutover, and the business team knows from day one that the outcome number is theirs.

The programs that miss the outcome make the same decision by not making it. Adoption stays a rectangle. Hypercare is thirty days because the contract said thirty days. The executive review moves on. The frontline invents its workarounds and the workarounds harden and by month four the new tool is a screen people open when someone asks whether they are using it. The initiative was delivered. The business did not change. The technical thing worked, exactly as promised. That was never the point. The point was the operation running on the new thing on Monday, and the only phase of the project that produces that outcome is the one everyone skips.