Change Management is Dead; Long Live Change Enablement

Why the 18-month waterfall change programme can’t keep pace with 18-day AI update cycles. And what to build instead.

How many times has the AI tool you’re implementing been updated since you started planning the rollout?

I ask because the answer reveals a structural problem that no amount of better planning will solve.

In 2024-2025 alone, there were 43+ major AI model releases. GPT-4.1, Claude Opus, Gemini 2.5, and dozens more. Each release shifts what’s possible. Each shift renders some of yesterday’s training a little more obsolete.

Meanwhile, most organisations are still designing 12-18 month change programmes (if they’re designing them at all). By Phase 2, the target has moved. The Change Manager finds themselves training people on features that no longer exist and workflows that have already been superseded. 

This isn’t a failure of planning. It’s a mismatch between the pace of technology and the pace of traditional change frameworks.

The competitive advantage belongs to organisations that recognise this mismatch and design for it.

The Evidence

Traditional change management has a well-documented problem: 60-70% of change initiatives fail. McKinsey, Prosci, and Gartner have been citing similar figures for over a decade.

What’s changed is the context. 

When technology cycles measured in years, an 18-month change programme made sense. The target was stable. The training remained relevant. The governance structures could keep pace.

Now consider: 71% of employees (and 86% of those aged 16-24) already feel overwhelmed by the amount of change at work. That was measured before the current acceleration in AI capabilities.

The fatigue isn’t caused by too much change. It’s caused by change programmes that don’t match how people actually experience change.

The problem isn’t volume. It’s design.

Agile approaches report a 75% success rate, compared to 56% for traditional project management. Frontline-driven changes boost success rates to 71%. The pattern is consistent: when the people closest to the work have ownership of implementation, outcomes improve.

The organisations achieving better outcomes aren’t trying to control change from the top. They’re enabling it from within.

From Management to Enablement

In 2019, ITIL 4 formally replaced ‘Change Management’ with ‘Change Enablement’. This wasn’t marketing. It reflected a fundamental shift in how mature organisations approach technology transitions.

The distinction matters.

Change Management asks: How do we control this transition? How do we move people from State A to State B? How do we measure compliance?

Change Enablement asks: How do we equip people to adapt continuously? How do we provide guidance in the flow of work? How do we build capability rather than compliance?

The first treats change as an event to be managed. The second treats it as a capability to be developed. This is why I believe we need to give employees time and space to become AI fluent rather than mandating adoption through rigid programmes.

This requires challenging some established thinking:

• The assumption that change needs to be controlled from above.

• The belief that training programmes should have fixed end dates.

• The idea that governance means gates rather than guardrails.

You can guess which approach scales.

What This Looks Like in Practice

The Operations Director rolling out a new AI-assisted customer service tool faces a choice.

Traditional approach: Six weeks of training modules. Competency assessments. Go-live date. Post-implementation review. The tool updates three times during the rollout. 

Enablement approach: Just-in-time guidance embedded in the tool itself. Contextual prompts when users encounter new features. Feedback loops that surface friction points immediately. Continuous iteration.

The first approach optimises for control. The second optimises for adaptation.

The difference starts with understanding what people actually need, not what the programme assumes they need. I saw this firsthand years ago when automating a simple print task met unexpected resistance — not because of the technology, but because of a hidden human need the old process fulfilled. I wrote about it in The ‘Walk to the Printer’ Problem, and it remains one of the clearest examples of what happens when you manage change rather than enable it. The Marketing Manager struggling with the new analytics dashboard may not need more training. They may need the dashboard to stop surfacing irrelevant metrics (and this can point to other issues such as not having asked the right questions in the first place). Understanding the real friction point changes the solution entirely. 

Organisations that track KPIs during change implementation achieve a 51% success rate, compared to just 13% for those that don’t. And involving frontline employees in implementation planning increases success rates by 24%. 

These aren’t abstract principles. They’re measurable differences in outcome.

Building an Enablement Framework

Effective change enablement rests on three principles:

1. Listen first. Understand where friction lives, not where you assume it does. Place the needs of the people doing the work ahead of the elegance of the programme design.

2. Adapt continuously. Design for iteration, not completion. If your change programme has a fixed end date, it’s already obsolete. Build feedback loops that operate in weeks, not quarters.

3. Enable in context. Deliver guidance where work happens, not in separate training environments. The best enablement is invisible. It appears when needed and disappears when it’s not.

None of this requires abandoning structure. It requires a different relationship with uncertainty. Seeing setbacks as data rather than failures. Treating unfamiliar territory as opportunity rather than threat. Building systems that learn from what isn’t working as quickly as they reinforce what is.

Where This Applies

A necessary caveat: enablement isn’t universally superior to structured programme management. It depends on what’s changing.

Capability and tool adoption benefits from iterative, people-centric enablement. The target is moving, the skills evolve with use, and rigid training programmes can’t keep pace.

Regulatory compliance, infrastructure migration, and safety-critical systems still require structured programme approaches. You can’t iterate your way through a data centre move. Healthcare, aviation, and financial services have good reasons for gates and sign-offs. ‘Fail fast’ is not appropriate when failure means patient harm or regulatory breach.

The skill is knowing which type of change you’re dealing with. Most AI capability adoption falls into the first category. Most organisations are treating it like the second.

The Competitive Separation

Most organisations are still running change programmes designed for a slower world. Their governance structures assume stability. Their training models assume fixed targets.

This creates opportunity.

The organisations that shift to enablement frameworks for capability adoption will move faster, adapt more easily, and suffer less change fatigue. They’ll also see clearer commercial results: when people understand how their adaptation contributes to business success, they take more ownership of making it work. 

The velocity mismatch isn’t going to resolve itself. AI development cycles will continue to accelerate. The organisations that design for this reality will outperform those still trying to manage their way through it.

Change management is (mostly) dead. The question is whether your organisation is ready to build what comes next.

The Artisan’s Reflection

There’s a certain irony in writing a change management article that argues against traditional change management. And there’s a risk that ‘enablement’ becomes just another buzzword, another rebrand of the same old approaches.

The difference isn’t in the language. It’s in the orientation.

If you’ve been reading carefully, you might have noticed a pattern in how I’ve structured the argument: understand what people actually need before designing solutions; give ownership to those closest to the work; challenge established thinking when it no longer serves the context; treat setbacks as learning opportunities rather than failures. 

These aren’t principles I invented. They’re Hachette UK’s four strategic pillars: Understanding Consumers, Owner Mentality, Changing the Story, and Growth Mindset.

Notice what’s absent from that list: any mention of specific technologies, platforms, or tools.

These pillars don’t tell anyone which AI to use. They provide the stable human framework for evaluating any tool against enduring values. ‘Understanding Consumers’ guides decisions whether you’re using spreadsheets or machine learning. ‘Growth Mindset’ applies to learning new software and to navigating industry disruption.

This is what enablement architecture actually looks like. Not rigid processes that break when the technology shifts, and not vague principles that provide no guidance at all. Something in between: stable enough to create coherence, flexible enough to absorb change.

The craft isn’t in controlling change. It’s in building the conditions where change can happen well.

For discussion: It’s all good in theory, but what about resourcing and budget? Can or should businesses plan and budget or a never-ending change programme?

Related reading: The Disposable Masterpiece is the same thesis from the build side: treat AI solutions as time-boxed value extractions and measure success by the understanding you accumulate across cycles.