Who Owns What in Change Management for Digital Transformation

We can handle the IT. Our portfolio shows it.

But the outcome you want (faster decisions, cleaner operations, better service…) only shows when people change how they work. 

That part (change management) cannot be outsourced.

Quick takes

• If there isn’t a named internal decision-maker for adoption, you don’t have change management. It’s just new software and hope.
• Large-scale transformations fail about 70% of the time. The failure is usually about execution and people, not the software.
• Europe’s own AI benchmarks point to a change issue. In 2025, 20% of EU enterprises (10+ employees) used AI, only up from 8.1% in 2023.
• A vendor can build, integrate, migrate, and support rollout. Your organisation still has to decide what “good usage” means and get people to be supportive.

What does “who owns what” mean (really)?

It means someone inside your organisation has the mandate to decide.

They can make trade-offs when business-as-usual fights back. They can also set the standard for what changes, and hold the line when teams try to keep the old way alive.

If ownership is unclear, the programme turns into a polite, dragging negotiation. Every side is just protecting its siloed interests and targets. 

Adoption becomes a problem instead of a solution.

McKinsey’s benchmark is that around 70% of transformations fail. Lack of organisational engagement and insufficient change management are among the main contributing factors. 

What can you delegate and what can’t you?

You can delegate execution tasks. You cannot delegate internal leadership responsibilities.

The leadership “disappear after announcement” pattern is a documented failure mode in change efforts.

Which decisions must have a named internal owner?

If you want the definition of “who owns what,” it’s this: 

Who inside your organisation has the authority to make adoption non-optional (in priorities, in process, and in day-to-day habits)?

From the vendor side, we see the same pattern repeat again and again. The technical work can be excellent, but no one internally owns the decisions that change how work gets done.

If you want to see the ROI, we ask you to answer these six questions. If you can’t, the transformation is structurally under-owned.

1. Priority and trade-offs: When daily work clashes with adoption, who decides what gets deprioritized?
2. Process standard: Who can say “this is the way we do it now” and end unnecessary debates quickly?
3. Legacy shutdown: Who decides when old tools/processes stop being acceptable paths?
4. Definition of “good usage”: Who sets the practical standard and keeps it stable?
5. Time protection: Who can carve out real time for learning and transition work?
6. Adoption governance: Who reviews adoption signals weekly and triggers action?

Rule of thumb: if nobody can make a yes/no call within 48 hours, that area isn’t owned. It’s probably negotiated. 

How do you define “good usage” in digital transformation?

Here’s a mini-framework that’s easy to audit:

Good usage = Behaviours + Quality + Outcome

• Behaviours: What people do, consistently (not “they attended training”).
• Quality: What “correct” looks like (clean data, right workflow, right approvals).
• Outcome: What improves (cycle time, error rate, service levels, compliance, etc.).

Mini example: CRM rollout 

The sales team is “using the CRM”. They log in, a few notes go in, maybe some deals get updated right before the forecast call. 

And yet the forecast is still off. 

Every month, you’re surprised. Every quarter feels like roulette. That’s usually a “good usage” problem, not a CRM problem.

So you tighten the definition with clarity:

• Behaviours: every deal must have a next step and an owner, updated regularly
• Quality: stages mean the same thing to everyone, and required fields aren’t optional
• Outcome: forecasts become credible because the CRM stops being a lazy contact list

The point isn’t to police people. It’s to stop pretending that a CRM login is a minimum requirement for change.

How do you protect time for adoption when everyone is already overloaded?

Acknowledging the collision with work and deciding what matters for a period is a good first step. 

From what we’ve seen, this is where a lot of transformations struggle. Leaders approve the change, but the organisation is still expected to hit the same targets at the same pace. For most companies we worked with, that’s unrealistic. It creates frustration and friction.

Also, capability isn’t evenly distributed. In 2025, only 60% of EU citizens aged 16–74 had at least basic digital skills. This is a useful reminder that “one training and done” isn’t a plan.

So, we prefer our clients to sequence the change, define the minimum “good usage” that unlocks value, and keep leadership attention on adoption even after they go live.

Common mistakes in transformation change management

Here’s what we keep seeing when transformation meets reality:

• They celebrate go-live like it’s the outcome. Then leadership attention moves on, and adoption decays in week two. Go-live is a technical milestone; behaviour change takes longer.
• Nobody is empowered to settle “how we do it now.” So every team tweaks the process, standards drift, and the system stops being a shared source of truth.
• They assume leadership buy-in equals organisation buy-in. It doesn’t. If the people doing the work don’t have a reason to change (time, recognition, simpler workflows, less rework, bonuses, fewer escalations), they’ll protect themselves with the old way. Incentives need to exist at the people level.
• They track clicks instead of compliance. Logins look healthy, dashboards look busy. But the core habits that create value (clean data, consistent stages, complete workflows) never stabilize.
• The old way stays “temporarily,” forever. Spreadsheets, side channels, and legacy tools remain an escape hatch. People take it the moment things get hard.
• They assume capability is evenly spread. In reality, some teams adapt fast, and others need repetition and support. Pretending otherwise just guarantees uneven adoption.

What to do next: write a one-page Ownership Brief

Before you ask anyone to adopt the new system, you could write a single page that removes ambiguity. 

Here’s what we’d include if it was us:

• What outcome are you trying to move (one metric that matters)
• What “good usage” looks like (3–5 observable habits, not “use the tool”)
• What decisions must be made (and by when)
• How you’ll handle the old way of working (what changes, and what exceptions are allowed)
• How you’ll know adoption is working (a few signals, reviewed weekly)
• What happens if adoption drops (who steps in, what gets adjusted)

Without staying conscious of this, everyone fills the gaps with their own interpretation. Transformations lose momentum in these situations.

Get this page right, and you’ll be surprised to see that transformation is not a buzzword your vendors just throw around.

FAQs about change management

Can a vendor run change management for us?

We can support it heavily with coaching, enablement materials, rollout structure, and adoption measurement, but we can’t own it. 

Real change management requires internal authority. If that ownership stays external, adoption becomes optional.

Who should own adoption: IT or the business?

The business has to own its adoption because it’s the business that’s changing how they work. IT should own the platform health, integration, security, and the technical operating model. 

But the business must define what “good” looks like in the workflow and reinforce it. The failures happen when both sides assume the other one has it.

What if teams refuse to change?

Treat that as data. Most resistance is practical. People don’t trust the new workflow yet, don’t have time, or don’t see what improves for them. 

The fix is usually clearer standards, better enablement, and leadership that’s willing to make the old way less attractive.

How do we define “good usage” without over-controlling teams?

Define a small set of non-negotiables that protect the system’s value, then leave room everywhere else. 

For example: consistent stages, required fields for critical work, and one agreed way to track ownership. If you try to control everything, people will work around it. If you control nothing, you’ll never get a reliable source of truth.

What metrics matter most in the first 30 days?

Focus on signals that show real behavior change, not activity. Look at workflow completion (are people finishing work in the new system?), data quality (is it clean enough to trust?), and how much work still happens in side tools. 

If those three improve, the rest usually follows.