The Five Laws of User Adoption
In the last post, I made a simple point: most technology rollouts don't fail because the software doesn't work. They fail because the people the system was built for keep finding ways to work around it instead of through it.
You see it in spreadsheets, second monitors, side processes, and the old tools that never quite go away.
Over the years, I've seen the same patterns repeat across utility, broadcast, government, and retail technology projects. The projects are different, but the adoption problems are often surprisingly similar.
I've narrowed those patterns down to five principles. They're intentionally simple because when a rollout gets difficult, a project team needs something practical enough to remember and use.
 Law One: Readiness Precedes Rollout
You can't change an organization you haven't measured.
Every team starts from a different place. One may have gone through several major system changes in the last few years and be tired of hearing about the next transformation. Another may have been asking for this exact change for years and is ready to move.
Treating those teams the same doesn't create consistency. It ignores where they're actually starting.
Readiness comes down to practical questions. How much change has this team already absorbed? Who do people actually turn to when something new is introduced? Does the team have enough capacity right now to take on a learning curve?
Those answers matter.
McKinsey's 2021 research found that fewer than one in three organizations fully sustained the performance improvements from their most recent transformation. There are plenty of reasons transformations fall short, but one of the biggest mistakes is building a rollout around the organization on paper instead of the organization that actually shows up on day one.
In practice:Â before designing workflows or building a rollout plan, understand readiness by team, not just across the company. A short assessment up front can uncover issues that are much harder to fix six months into an implementation.
Law Two: People Adopt What They Author
The workshop isn't just preparation for the implementation. It's part of the implementation.
Something changes when a designer, GIS analyst, field crew lead, or other end user actually helps build the new workflow.
They're no longer being interviewed about their job and then shown a finished process later. They're helping decide how the new process should work.
At that point, it starts to feel less like "the new system IT is making us use" and more like something they had a hand in building.
That involvement also produces better workflows. The people doing the work every day know where the exceptions are, which steps cause problems, and which shortcuts exist for a reason. Those details don't always make it into a requirements document.
McKinsey's research on transformation has consistently pointed to employee involvement and engagement as important factors in making organizational change stick.
I've also seen the opposite happen. A workflow looks great on a whiteboard, but the people designing it don't actually perform the work every day. Then it reaches the field or production environment and runs into problems nobody in the planning room saw coming.
In practice: ask one simple question before getting too far into design: is someone who actually does this job every day involved in building the workflow?
If the answer is no, that's a gap worth fixing early.
Law Three: Ship Thin, Ship Whole
A broken journey sends people back to the old process.
Almost every project eventually has to make decisions about scope. The important question isn't whether to cut scope. It's where to cut it.
One approach is to remove entire parts of the workflow. Approvals can wait until phase two. Mobile isn't included yet. As-built reconciliation will come later.
The problem is that users don't experience that as "80 percent complete." They reach a point in their normal workflow where the new system stops helping them.
So they go somewhere else to finish the job.
Once spreadsheets, legacy tools, or manual processes become part of the workflow again, bringing users back becomes much harder.
A better approach is to keep the entire journey intact while simplifying what each step does in the first release.
Map the workflow from intake to closeout first. Then decide how much functionality each step really needs on day one.
The full workflow stays intact, even if parts of it start simple.
In practice: before finalizing release scope, walk through the workflow from beginning to end. For every step, ask whether the user can still complete it in the new process.
If an entire step disappears because of a scope decision, you've probably created a reason for users to fall back to the old way.
Law Four: Measure the Workflow, Not the Login
License counts measure purchasing. They don't measure adoption.
It's entirely possible to have strong login numbers while a team still maintains a spreadsheet or uses another system to get the real work done.
Someone can open the new application every morning and still spend most of the day working somewhere else.
That's why adoption needs to be measured at the workflow level.
Which steps are people consistently completing in the new system? Where are they getting stuck? How long does it take a new user to become comfortable enough to work without constant help? And where are people still falling back to the old process?
Those numbers tell you much more than login counts.
They also help explain the value gap that shows up in many transformation efforts. Even when an organization successfully implements new technology, some expected value can disappear because pieces of the workflow never fully move into the new process.
You won't necessarily see that on a license utilization report.
In practice: at each project checkpoint, identify the workflow step with the lowest adoption.
That usually tells you more about the health of the implementation than the overall number of active users.
Go-live is the starting line, not the finish.
Most of the people who eventually use a system weren't part of the original workshops or pilot. They weren't in the room when the project team worked through the design decisions, and they may never hear the executive sponsor explain why the change matters.
They encounter the system later.
By then, the project team may have moved on and the excitement around the launch has faded. Their experience with the new process may come down largely to their manager, coworkers, and whatever training or support is still available.
That's why reinforcement matters.
Prosci's change-management benchmarking has consistently identified active and visible sponsorship as one of the strongest contributors to successful change. Their research has also shown a significant difference in outcomes when sponsorship is considered highly effective.
The takeaway is straightforward: sponsorship can't end with a kickoff meeting or go-live announcement.
Someone needs to keep reinforcing why the process matters, checking whether it's being used, and addressing the problems that appear after the project team leaves.
Most rollout plans include training. Far fewer have a real plan for month eight, month twelve, or the next group of employees who weren't around for the original implementation.
That's where adoption can slowly start to slip.
In practice: decide who owns adoption after the project team moves on. Make it a real person with clear responsibility, and schedule recurring checkpoints to understand where the process is working and where users are starting to fall back into old habits.
 The Five, Together
Readiness precedes rollout. People adopt what they author. Ship thin, ship whole. Measure the workflow, not the login. Adoption decays without reinforcement.
Together, these five laws cover the full life of an implementation: before the rollout starts, while the workflow is being designed, during release planning, after launch, and long after the project team has moved on.
None of them replaces good engineering, a solid data model, or a system that's genuinely fit for purpose. A well-adopted bad tool is still a bad tool.
And following these principles doesn't guarantee adoption.
What they do is address five predictable problems that repeatedly get in the way of otherwise good implementations.
Over the next several posts, I'll take each law individually and look at the research behind it, along with what applying it actually looks like in a GIS rollout, distribution design implementation, or asset management program.
I'll also share a one-page version of the five laws that you can keep nearby during a live rollout.
Next in this series: the statistic everyone quotes about transformation failure, and why it doesn't hold up.
About the Author
More Content by Ryan Jones
