Initiatives fail for a lot of reasons. One of the most common, and most preventable, is that behavior change was never part of the design.
It follows a familiar pattern: a process gets redesigned, the new workflow gets documented, training gets scheduled for the week before go-live, and then the project closes. Six months later, the old way is back.
Not because people are resistant. Because no one built the conditions for new behaviors to survive, and no one was measuring whether they were surviving in the first place.
Adoption Is a Design Constraint, Not a Phase
The most persistent misconception in process and technology transformation is treating adoption as something you layer on at the end. A training plan. A communication cascade. A "change management workstream" that kicks off 60 days before launch.
That framing misses the point entirely.
If adoption isn't in scope at the start, you're engineering a solution that has no plan to survive contact with the people who have to use it. What that looks like in practice:
- While the process is being redesigned: the stakeholder engagement plan is already running. The people doing the work are being heard, not just informed.
- While the solution is being built: the people who will use it are helping to shape it, not rubber-stamping it at a UAT session six weeks before go-live.
- When it goes live: the managers responsible for sustaining the change already know what good looks like, how to measure it, and how to recognize when it is slipping.
The Gap Between "Done" and "Working"
Project teams are usually measured on deliverables: the process map is complete, the system is configured, the training is delivered, the go-live happened. Check, check, check, close the project.
But "done" in project terms and "working" in operational terms are not the same thing. A more useful set of questions at close:
Are the people ready, willing, and able to work differently?
Awareness and desire are prerequisites, not outputs of training.
Does the environment make the new behavior easier than the old one?
Tools, incentives, manager reinforcement, and time all factor in.
Do we have the metrics to know whether adoption is holding?
Or are we just assuming it is because the project closed?
These are not interchangeable questions. You can answer yes to the first and no to the last two, and you'll get a solution that looks successful at go-live then breaks down quietly over the next quarter.
The last question, measurement, is where most of the value gets left on the table.
If you don't know what sustained behavior change looks like in measurable terms, you can't manage it. And if you can't manage it, you're relying on goodwill and inertia to hold a change that competing priorities will eventually erode.
What Sustained Adoption Actually Requires
Three things have to be in place and explicitly owned, not by the project team, but by the organization that will run the process after the project closes.
A definition of what sustained behavior change looks like
Not "users are trained" or "system is live." What observable behaviors indicate the process is running the new way? What leading indicators would show slippage before it appears in outcomes?
A measurement approach: simple, but present
Process adherence metrics, error rates, workaround frequency, cycle time variance. Something that tells you, post-close, whether adoption is holding.
Accountability after the project team is gone
The project team disbands, the steering committee moves on, and the operational manager is left holding a process they may not fully understand with no metrics to manage. That's not a people problem. It's a handoff problem.
If Your Initiatives Are Producing Solutions That Quietly Fade
When a well-designed solution fades back to the old way, the instinct is usually to re-examine the process or the technology. Occasionally that's right. More often, the problem is upstream: adoption was treated as an output of good design rather than a parallel workstream with its own requirements.
The question worth asking before the next initiative launches: do we have a plan not just for building the solution, but for ensuring the behaviors it requires can realistically survive in the environment where people work?
If the answer is "we'll figure that out closer to go-live," you already know what the six-month review is going to show.
Adoption runs concurrent to design, not after it.
I built the adoption workstream into FORGE specifically because this is where most improvement efforts leave value on the table. Stakeholder engagement, behavioral readiness, and sustainment metrics are not downstream activities. They are active design inputs from the first phase forward.
Ready to build adoption into the design?
A 30-minute strategy conversation is enough to assess whether your current improvement efforts are structured for sustainable results or quietly set up to fade.
Schedule a Strategy ConversationPart of an ongoing series on operational design, process transformation, and what it takes to make change endure.