Change Management for Technology Rollouts
The popular change-management frameworks are frequently cited as settled science. Most of the specific statistics behind them come from the vendors selling the framework — which doesn't make them useless, but does mean they should be read as marketing-adjacent rather than independently verified.
A technology rollout can be technically flawless and still fail, because the people expected to use it were never brought along. This is a companion piece to our guide on digital transformation.
A note on the popular frameworks
Frameworks like ADKAR (Awareness, Desire, Knowledge, Ability, Reinforcement) are widely taught and widely cited, including with specific statistics about their effectiveness. Worth knowing before relying on those statistics: Prosci, the organisation that developed and popularises ADKAR, is also the primary source of the research supporting its own framework's effectiveness. This does not mean the framework is wrong — a genuinely useful, practical structure for thinking about individual change is valuable regardless of who developed it — but it means citing "ADKAR-backed research shows X% improvement" should be read as vendor-produced evidence, not independent academic validation, in the same way we caution against treating any single vendor's benchmark as settled fact elsewhere on this blog.
Use ADKAR and frameworks like it as an organising structure for thinking about change, not as a source of precise, independently-verified effectiveness statistics.
What tends to actually predict adoption, based on the broader pattern
Involvement before launch, not just communication at launch. People who had a say in how a new process or tool would work are measurably more invested in its success than people who were simply informed of a decision already made. This is consistent with the sourcing literature's finding, covered in our piece on in-house vs agency vs offshore, that joint decisions outperform unilateral ones — the same logic applies to internal change, not just vendor selection.
Visible leadership commitment, sustained past the launch date. Enthusiasm at a kickoff meeting that evaporates once the technical delivery is complete signals to everyone watching that this initiative was not actually a priority, and adoption follows that signal.
Addressing the specific fear, not a generic reassurance. "This will make your job easier" is a generic claim that experienced employees have heard before, often inaccurately. Naming the specific change to someone's role, honestly, is more credible and more actionable than a blanket reassurance.
Removing the old way, deliberately, on a schedule. A new system running alongside an unretired old one gives people permission to default to the familiar option under any pressure. Our piece on the strangler fig pattern covers the technical version of managed transition; the same discipline applies to the human side — a defined date after which the old way is genuinely gone, communicated in advance.
Why this connects to the workflow redesign finding
If the rollout has not actually redesigned the underlying workflow, as covered in workflow redesign: the step everyone skips, no amount of change management technique will produce a good outcome, because there is no genuinely better way of working to bring people toward. Change management amplifies a good redesign. It cannot substitute for one.
A practical sequence
Before build: Involve representative users in defining what the new process should look like, not just in testing the finished tool.
During build: Communicate progress honestly, including setbacks, rather than only positive updates — credibility built here pays off at launch.
At launch: Provide hands-on support disproportionate to what feels necessary. The first two weeks of real usage surface problems no amount of testing catches, and visible, responsive support during that window shapes whether people trust the new system going forward.
After launch: Retire the old way on a communicated schedule, and measure the outcome metrics covered in our piece on measuring whether a technology project worked — not just adoption, but whether the underlying result actually improved.
What we do
We build change management into project scope as a distinct workstream with its own budget and timeline, not an assumed byproduct of good technical delivery. If you are planning a rollout and want the human side managed as deliberately as the technical build, that is a conversation we are glad to have.
Kaizen Spark Tech designs and delivers software, AI, automation and digital infrastructure for businesses and institutions.