Your rollout didn’t fail. Nobody told you it was failing.
No one in your organization has ever stood up in a meeting and said "we're not going to use the new system." That conversation doesn't happen. It doesn't need to.
Instead, someone keeps a spreadsheet open on a second monitor, just in case. A designer exports a drawing back into the old CAD environment because it's three clicks instead of nine. A field crew fills out a paper form because the tablet app takes too long to load out at the substation, and the paper form always worked. None of these are acts of rebellion. They're just what happens when a system doesn't fit the way work actually gets done, and the person doing the work has a deadline today, not a change-management objective.
That's the vote. It happens every day, in small decisions nobody announces, and it's the only vote that actually counts.
The Number Everyone Quotes, and the One That's Actually True
You've probably heard some version of the claim that most transformation projects fail — 70 percent is the number that gets repeated most often, usually with a shrug, like it's just the cost of doing business. We're going to take that specific number apart in a future post, because it turns out to be shakier than almost everyone citing it realizes. But the underlying problem it's gesturing at is real, and there's solid research behind it.
McKinsey surveyed more than a thousand people in 2021 who had personally gone through a transformation effort in the prior five years. Fewer than one in three said their organization managed to both improve performance and hold onto that improvement. And the ones that did succeed still only captured about two-thirds of the value they'd expected going in.
Read that again: even the wins leave a third of the value on the table.
If you work in utility technology — GIS, distribution design, asset management — this isn't an abstract statistic about corporate strategy. It's the gap between the project plan you presented at kickoff and what your team is actually doing eighteen months after go-live.
What This Actually Looks Like in a Utility
A few patterns show up often enough that they stop feeling like coincidences.
The GIS system that's technically accurate and practically ignored. Data gets updated, the map is current, and the field crew still calls dispatch to confirm what's already sitting in the app, because that's faster than trusting a system they've been burned by before.
The distribution design tool that half the team lives in and the other half quietly avoids. Same license, same training, wildly different adoption — and it's rarely about who's more technically capable. It's usually about who was in the room when the workflow got designed, and who wasn't.
The asset management system that's current for exactly as long as the project team is watching. Six months after the consultants leave, the update cadence slows, then stalls, and nobody's really accountable for it, because accountability was never built into anyone's actual job description.
And the pattern that makes all three of these self-perpetuating: the new hire who gets trained on the workaround instead of the system, because that's what the person training them actually uses. Adoption debt doesn't just persist. It gets passed down.
None of this shows up in a status report. It shows up as a slow drift back toward however things worked before, and by the time it's visible in the numbers, it's already been happening for months.
What It Actually Costs
The direct cost is the easiest part to see and usually the smallest part of the real number. Licenses paid for and barely used. Training budget spent on a curriculum half the room quietly ignores within a quarter. A second system — the workaround — that someone has to build and maintain informally, on top of the one that was supposed to replace it.
The larger cost is harder to put a line item on. It's the redundant data entry nobody accounted for, because two systems of record means someone is reconciling them by hand. It's the field time lost to double-checking information the new system was supposed to make instantly available. It's the executive sponsor who championed the rollout two years ago and now can't produce a straight answer when someone asks whether it actually worked, because nobody set up a way to measure that beyond "did we go live on schedule."
None of that gets billed anywhere. It just accumulates, quietly, as the gap between what the business case promised and what the organization is actually getting.
Why This Keeps Happening
The honest answer is that most implementations are scoped and measured around deployment, not adoption. Did the software get installed. Did the data migrate. Did everyone sit through training. Those are real milestones, and they're also not the same question as: did this change how people actually do their jobs, and is that change still holding a year later.
Deployment is a project, with a start date and an end date and a budget line. Adoption is a behavior change, sustained over time, inside an organization that has a dozen other priorities competing for the same people's attention. Treating the second problem like the first one is one of the most common mistakes in this industry, and it's an easy mistake to make, because deployment is the part everyone already knows how to plan for. Nobody hands a project manager a Gantt chart for "make sure people still trust this in eighteen months."
It also doesn't help that the systems utilities are implementing — GIS, distribution design platforms, EAM — are frequently sold and measured on features and licenses, not on whether the field crew opens the app instead of calling dispatch. You can hit every deployment milestone on schedule and still lose the adoption fight, because nobody was measuring the fight that actually mattered.
What This Series Is Going to Do
Over the next several months, this space is going to dig into what actually separates the rollouts that stick from the ones that quietly don't. Not more process for its own sake — five specific, testable principles, drawn from published change-management research and from watching this exact pattern repeat across utilities, broadcast, government, and retail technology projects.
The next post lays all five out in full. After that, we'll take each one apart individually, with the research behind it and what it actually looks like to apply it to a GIS rollout, a distribution design implementation, or an asset management program.
If you want a head start, here's the question worth asking about your own most recent rollout before the next post arrives: what percentage of the time are people still doing it the old way? Not zero, probably. Whatever that number actually is — that's the real adoption rate, and it's usually a very different number than the one in the project closeout report.
Is Your Rollout Really Working?
Going live is only the beginning. The real measure of success is whether new workflows become the way work actually gets done. In the next post, we’ll introduce the Five Laws of User Adoption and the principles that can help technology investments deliver lasting value.
Stay Tuned.
About the Author
More Content by Ryan Jones
