By Ritvars Mētra, Founder of ReadinessCompassChange management has many dialects. Some are elegant, some are practical, some are almost theatrical. A transformation team may talk about urgency, vision, sponsorship, resistance, readiness, engagement, adoption, reinforcement, culture, behaviour, capability, mindset—usually all in the same meeting, which is one reason people outside the discipline sometimes look mildly traumatised.
Still, beneath the vocabulary, there are different types and styles of change management. They don’t all fit the same situation. A small policy update, a culture programme, an ERP rollout, and an AI-enabled operating model shift are not the same beast. They shouldn’t be managed as if they were.
For large-scale software and AI implementations, one style stands out: results-oriented, data-based change management. Not because it sounds modern. Not because dashboards make executives feel safe. But compared with communication-led, activity-led, or purely methodology-led change management, a results-oriented and data-based approach has one decisive advantage: it tests whether the change is actually being adopted in the real work.
That is the point. Or at least it should be.
Why activity-based change management is not enough
Traditional change management often begins with structured models. Lewin gives us unfreeze-change-refreeze. Kotter gives us urgency, coalition, vision, communication, empowerment, short-term wins, consolidation, anchoring. ADKAR brings the lens down to the individual: awareness, desire, knowledge, ability, reinforcement. Agile change approaches favour iteration, feedback, and adjustment. Each has merit.
The problem begins when a style becomes a substitute for evidence. A change team can run town halls, publish FAQs, build training modules, brief managers, launch a champion network, and still fail to produce adoption. Everyone was “engaged,” apparently. Everyone was “enabled.” The programme reports green because the activities were completed.
Then go-live arrives and reality coughs politely. Users don’t enter data correctly. Managers continue asking for old reports. Teams keep shadow spreadsheets alive. AI tools are opened once, tested casually, and then abandoned. From a project-plan perspective, change management happened. From a business perspective, it didn’t.
Results-oriented change management helps leaders:
- see whether people are actually ready to use the new system,
- connect change work to adoption and business outcomes,
- identify where resistance or confusion is concentrated,
- decide where intervention is needed before go-live,
- track whether readiness is improving over time.
What results-oriented change management means
This is where results-oriented, data-based change management changes the conversation. It asks less flattering questions. Not “Did we deliver the training?” but “Can users perform the new task correctly?” Not “Did we send the communication?” but “Do affected groups understand what changes for them?” Not “Did people attend?” but “Are they using the system, with sufficient frequency, quality, and confidence?” Not “Are leaders supportive?” but “Are managers reinforcing the new behaviour in team routines?”
Large software and AI implementations need this discipline because they create measurable traces. That is both a gift and a trap. ERP, CRM, workflow tools, digital adoption platforms, service platforms, AI assistants, and analytics environments all generate signals: logins, feature usage, task completion, error rates, process cycle times, data quality, exception volumes, support tickets, training assessment results, sentiment, confidence scores, and adoption drop-offs by role or region. These signals don’t tell the whole story. They do tell us where to look.
A results-oriented approach starts by defining adoption as an outcome, not an aspiration. “Use the new system” is too vague. “Create 95% of eligible purchase requests through the new workflow within 60 days, with fewer than 5% returned due to incorrect coding” is better. It may be imperfect, but it gives the organisation something real to test.
Why data matters in software and AI implementations
The old style of change management often assumes that if people are informed and trained, adoption will follow. In small changes, perhaps. In large digital changes, that assumption is fragile. Software adoption is behavioural, operational, and political. AI adoption is even stranger because it involves trust, judgement, perceived threat, ethics, confidence, and the redesign of work itself. People may use AI enthusiastically for low-risk tasks while avoiding it where it could actually change productivity. Or they may overuse it without understanding the risk. Both are adoption problems, just in opposite directions.
That’s why activity metrics are not enough. Training completion tells us who sat through the material. It does not tell us who can perform the task. Communication reach tells us who received the message. It does not tell us who changed their routine. Stakeholder sentiment tells us how people feel today. It does not tell us whether they will abandon the old workaround when pressure rises. Usage tells us that someone clicked. It does not tell us whether the business outcome improved.
A data-based change approach combines these signals rather than worshipping one of them. It might track readiness before go-live, then adoption after go-live, then proficiency and business outcomes as the change stabilises. It might compare adoption by region, role, seniority, function, manager, process variant, or user group. It might discover that one country has low adoption not because people resist the system, but because local customer requirements were not built into the template.
Readiness signal
Adoption risk
Leadership decision
Business outcome
Example: data-based change management connects activities to readiness signals, adoption risks, leadership decisions, and measurable outcomes.
The readiness signals leaders should measure
The “clear winner” claim needs some nuance. Data-based change management does not replace human judgement. It strengthens it. Large transformations still need sponsorship, narrative, involvement, training, coaching, empathy, and a decent amount of political sense. Nobody adopts a new AI-enabled process because a dashboard told them to. But without data, large software and AI implementation becomes too dependent on optimism.
Executives hear positive stories from sponsors. Project teams report milestone completion. Managers say their teams are “ready.” Training attendance is high. A few enthusiastic users appear in success videos. Everything looks fine until adoption gaps show up in delayed benefits, operational errors, duplicate work, or frontline cynicism. Data does not remove politics, but it makes denial harder.
It also helps change teams move from generic support to targeted intervention. Suppose system usage is low in one function. A traditional response may be more communication. A better response asks: is the issue awareness, desire, knowledge, ability, reinforcement, access, workload, data quality, manager behaviour, process fit, or fear? Different causes. Different medicine.
How to connect change activities to business outcomes
For AI implementations, this becomes critical because adoption is not binary. Someone can be an “AI user” and still create no business impact. They may use it for summarising emails while the real opportunity sits in service resolution, sales preparation, coding support, knowledge retrieval, document review, demand planning, or quality management. A results-oriented approach therefore looks beyond tool usage to workflow integration. Are people using AI inside the work that matters? Are roles being redesigned? Are review standards clear? Are errors caught? Are cycle times improving?
This is uncomfortable because it forces the organisation to admit that technology deployment is not the same as transformation. ERP success is not system availability. CRM success is not login rate. A planning tool is not adopted because planners open it; it is adopted when planning decisions move into the new process, with trusted data, clear accountability, and fewer shadow routines. Results-oriented change management keeps pulling the discussion back to that behavioural and operational evidence.
Making change management data-based requires a disciplined approach:
- Define the adoption outcome — what specific behaviour change proves success.
- Identify the readiness signals that predict that outcome — clarity, capability, confidence, manager reinforcement, capacity, and process fit.
- Collect baseline and follow-up evidence — surveys, system data, practice results, manager check-ins, support-ticket themes.
- Segment results by audience, process, or workstream to find where risk is concentrated.
- Translate weak signals into mitigation actions — assign an owner and intervention for each gap.
- Review progress in governance meetings — not just status colours but evidence of behavioural change.
What a data-based adoption rhythm looks like
Results-oriented change management changes the role of the change manager. Instead of being the person who “does communications and training,” the change manager becomes a translator between strategy, human behaviour, and measurable adoption. That is a more serious role. It requires comfort with data, but also scepticism about data. It requires asking whether a metric is meaningful, whether the sample is biased, whether usage reflects compliance theatre, and whether the business result can reasonably be attributed to the change.
A dashboard can tell us that 80% of users logged in. It cannot tell us whether the remaining 20% are irrelevant, overloaded, influential, or quietly running the old process. That still requires analysis. Sometimes interviews. Sometimes workshops. Sometimes walking over to the team and asking why the shiny new process makes their day worse. Data points to the bruise. It does not explain the whole injury.
McKinsey’s transformation survey found frontline employees rating the communications they received as markedly less effective than their leaders assumed — a gap that only becomes visible when someone measures both sides rather than reporting activity.
The Project Management Institute recommends that programme governance reviews should focus on outcomes and evidence, not just activity completion—a principle that aligns directly with data-based change management.
Common mistakes in readiness measurement
Among different change styles, the strongest approach for large software and AI programmes is therefore not cold, mechanical measurement. It is a hybrid: structured enough to define outcomes, human enough to understand behaviour, agile enough to adjust, and data-based enough to prove whether adoption is happening. Communication-led change tells people what is coming. Participatory change helps them shape it. Agile change lets the approach evolve. Leadership-led change creates legitimacy. Results-oriented, data-based change management connects all of that to evidence.
That is why it wins. Not because it is fashionable, but because large software and AI implementation is too expensive, too visible, too complex, and too behaviour-dependent to manage through hope, anecdotes, and completed activity plans. The future of change management will not belong to the loudest communicator or the most elegant framework. It will belong to teams that can answer a harder question, repeatedly and honestly: what changed in the work—and can we prove it?