The Drift Thesis
Most programmes don't break. They drift. And drift is preventable. A long-form perspective on why transformation vision quietly stops fitting execution, what the data has been telling us for two decades, and what to measure to catch drift before it costs the dial.
The programme that delivered, but didn't.
Twelve months past go-live. The system is running. Adoption is green on the dashboard. Three sprints are queued for the next release window. The COO sits in front of the board with a slide that says, on every metric the programme team measured, the implementation was a success.
Then the FD asks why the operating margin hasn't shifted.
There is no clean answer. The forecast model that justified the business case assumed a fifteen percent productivity uplift in the customer-facing teams. The teams say they're working harder than before. The new platform's adoption metrics agree, the logins are there, the records are being created. But the work is taking longer, the data going in is patchier than it was eighteen months ago, and the team leads have started keeping their own spreadsheets again.
Nobody owns the answer. The implementation partner has demobilised. The internal programme team has been re-tasked. The vendor account manager wants to schedule a Q4 roadmap call. The board is asking the COO when the dial will move, and the COO doesn't know.
This is not failure. The programme delivered. The system works. Users log in.
This is drift. And once you start looking for it, you will see it everywhere.
Aligned at go-live. Drifting between releases. Held only on purpose.
What we mean by drift.
Drift is the structural gap between the process that was designed and the process being lived in. It is not the same as failure, under-delivery, poor adoption, or change resistance, though it is often mistaken for each of those.
Failure is loud. Drift is quiet. Failure shows up in red status reports. Drift shows up nowhere, because nothing in a typical programme governance pack is built to detect it. Adoption metrics tell you whether people are using the system. They do not tell you whether the system is being used the way the design assumed. Audit logs tell you what changed. They do not tell you whether the changes follow the operating model the business case was built on.
Drift is the slow erosion of fit between vision and execution. It compounds stage by stage. By the time it becomes visible, usually as a missed target, an unexplained efficiency drop, or a sponsor's frustration that "we did everything we said we'd do, and the dial isn't moving", it has been opening for months, sometimes years.
It is structural, not behavioural. People aren't drifting. The programme is.
The numbers nobody wants to look at.
Drift is not a string of unlucky programmes. It is a pattern. Patterns have causes, and the data has been telling the same story for two decades.
McKinsey's own Transformation Practice has stated, on the record, that roughly seventy percent of corporate transformations fail when measured against the change they set out to achieve.[1]Gartner reports the same number for finance transformation specifically: seventy percent of initiatives fail to deliver the forecast benefits to the business.[2]CRM, the most-implemented enterprise platform category in the world, sits in the same band. Failure rates across analyst studies cluster between fifty and sixty-three percent, with individual studies ranging from eighteen to seventy percent depending on definition.[3]
Adoption is meant to be the success metric, but the adoption numbers are themselves the warning. The G2 Winter 2025 Grid Report puts average CRM user adoption among sales professionals at seventy-two percent, meaning more than a quarter of users with paid licences are not using the system consistently.[4]Validity's research finds seventy-six percent of CRM users report less than half of their organisation's CRM data is accurate and complete.[5]CSO Insights documents that forty-three percent of CRM customers use fewer than half the features they have paid for.[6]
And on the human side, Prosci's longitudinal benchmarking data, tracked since 2007, now finds seventy-three percent of organisations report being near, at, or beyond the saturation point.[7]The capacity for change is gone before the change has finished landing.
Read these numbers as a single picture. The system delivered. The users have access. The licences are paid. The features exist. Most of them are unused. The data is mostly wrong. The people are exhausted. The board is asking why the dial hasn't moved. Nobody has the language to explain.
This is drift, surfacing late, expressed as a hundred different symptoms.
Why drift opens.
The mechanism is not mysterious. It is built into how transformation programmes are structured, and once you see it, you cannot unsee it.
Programmes are delivered in stages. Stage one ships against a set of assumptions about how the business will operate when it goes live. Stage two is then designed against assumptions about how stage one is operating, assumptions which are almost never verified, because the team that designed stage one has moved on, and the only people who could verify the assumptions are the users, who are too busy living with the new system to be asked. Stage three inherits the compound. By stage four, the original L3 process design, if it ever existed in a form that survived contact with delivery, is several steps removed from what is actually happening in production.
The vision is intact. It is on the slide deck the sponsor presented to the board. It is intact in the business case. It is intact in the implementation partner's case study.
It is no longer intact in the system.
This is the part nobody wants to say out loud, because saying it implicates everyone: the partner who delivered, the team that signed it off, the sponsor who approved the next phase. The honest answer is that no one verified, because no one was looking. The governance frameworks did not require it. The contracts did not require it. The programme management tooling did not measure it. The implementation partner's commercial incentive ended at go-live.
Drift opens in the silence between stages. It widens because the silence is structural.
Go-live is halftime.
Here is the reframe.
Every domain that has solved this problem treats the launch as halftime. Not the final whistle. Halftime. The point at which you have data on how the first half went, an opponent who is also adjusting, and a second half in which the score is genuinely moved.
The first half, design, build, deploy, is where the system is created. The second half is where the system is bedded in, where the original process design meets the people who have to live in it, where the gap between "what we built" and "what we wanted" either closes or widens.
The industry-default belief is that go-live is the finish line. Declare success at the milestone the contract paid for. Hand the keys to BAU. Demobilise. Move on. The implementation partner's commercial model rewards this. The sponsor's narrative is cleanest when the programme "lands". The board reporting cycle aligns to it. Everyone has an incentive to call full-time at halftime.
This is the single largest cause of drift in enterprise transformation. Not change resistance. Not poor design. Not technical failure. The collective decision, across the industry, to stop measuring at the moment the second half begins.
The programmes that hold their vision are the ones that recognise the second half exists, instrument for it, and play it deliberately. The programmes that drift are the ones that walked off the pitch at halftime believing they had won.
Why the industry defaults don't catch it.
The reason drift is structural, not behavioural, is that the entire toolkit the consulting industry has built around transformation is calibrated to measure delivery, not alignment. We need to be honest about that, and Ionyze includes itself in this, because the alternative is pretending the problem is somebody else's fault.
Programme management frameworks measure milestone delivery. They tell you whether the build hit its dates. They do not tell you whether what was built still serves the vision the business case was written against.
Change management frameworks measure adoption. They tell you whether users have completed training, whether logins are happening, whether sentiment surveys are positive. They do not tell you whether the people now using the system are following the operating model the design specified, or quietly working around it.
AI and automation, the current category of silver bullet, are sold as transformation accelerators. In practice they are applied on top of processes that have not been diagnosed. Automating a process that was already drifting from its design accelerates the drift. Machine learning models trained on operational data that is, on the industry's own evidence, less than half accurate, will reach high confidence on the wrong answer.
And then there is the consulting commercial model itself. The Big 4, the second-tier system integrators, the boutique platform specialists, all of them. The deliverable is the system, not the business outcome the system was meant to enable. This is not malice. It is what the contract structure rewards. But it is the reason the second half is rarely instrumented and almost never paid for.
We are saying this clearly because the alternative, pretending the industry has been measuring the right things and merely needs to do them harder, is not credible. The numbers in the section above have been stable for twenty years. The methods have not changed. The pattern is structural. Until somebody measures alignment, not delivery, the pattern will continue.
The good news is that measurement against intent is not a new problem. It is a solved problem in every domain that takes outcomes seriously.
Three disciplines have already worked through this.
They did not arrive at the same tooling, but they arrived at the same principle: design specifies what should happen, telemetry reveals what is happening, the gap is the asset.
Ecommerce solved it with analytics-against-funnel. Before Google Analytics, marketers argued about whether a campaign worked. After it, they didn't. They looked at the funnel and saw. The discipline that emerged, growth hacking, exists because the dial ended the debate. The same instrumentation logic applies cleanly to enterprise process: a designed flow has stages, users move through them or drop off, dwell time and abandonment reveal where the design is meeting friction, and the funnel is comparable to itself over time. The technology exists. The methodology exists. It is not in widespread use inside the model-driven applications where the actual business processes live.
Site reliability engineering solved it with observability against SLO. Google's SRE practice is built around a simple commitment: every production system has a Service Level Objective, a measurable definition of "working as intended", and the system is continuously instrumented to surface deviation from that objective. When the system drifts from the SLO, alerts fire, owners are paged, and the gap is closed before customers feel it. Crucially, SLOs are written by the team that designed the system, then enforced against the system in production. The design is the reference frame. The transformation industry has nothing equivalent. There is no operational SLO for "the customer onboarding process should complete in under four minutes against the L3 design". There should be.
Elite sport solved it with telemetry against game plan. The technical staff of a Premier League side, an NFL franchise, or an Olympic team do not assess performance by asking the players how they felt. They measure execution against the game plan in granular, instrumented detail: distances run, passes completed in designed zones, decisions made at specific moments, and the post-match review is built around the gap. The design is sacred. The execution is observable. The conversation is about the delta. This is the cultural model that enterprise transformation lacks: a leadership rhythm in which the question after the game is did we play the way we designed?, asked of evidence rather than memory.
The unifying principle is straightforward. Measurement-against-intent is not a research problem. It is a solved problem with mature methodologies in every domain that takes outcomes seriously. Enterprise transformation is the conspicuous exception, and the cost of the exception is the seventy-percent number that opens this article.
What closes drift.
If drift opens because nothing measures alignment, drift closes when something does.
This needs a careful caveat, because the failure mode here is real and worth naming. Most transformation programmes that attempt to instrument themselves get measurement wrong in one of three predictable ways, and the wrongness is usually fatal within two quarters.
The first wrong move is to measure too much. A KPI dashboard with sixty metrics is not measurement, it is decoration. Nobody acts on sixty metrics. Within a quarter the dashboard becomes wallpaper, visible and unread, and the programme reverts to running on instinct. The signal is buried in the noise that was supposed to surface it.
The second wrong move is to measure the wrong thing. Activity metrics (logins, records created, tickets closed) are easy to capture, which is exactly why they get captured. They tell you the system is running. They do not tell you whether the system is running the way it was designed. The data looks reassuring while drift opens underneath it.
The third wrong move is to measure episodically. A health-check at six months, another at twelve, a board review at eighteen. By the time the episodic check fires, the drift has been opening for months and the trail is cold. Drift is a gradient, not an event. Episodic measurement misses gradients by definition.
The Ionyze method is built around four moves, in sequence, designed to avoid each of those failure modes.
- 01ExposeInstrument the system against the original L3 process design, not against a generic dashboard. Surface, for the first time, where actual user behaviour and designed behaviour diverge. Few metrics, each one connected to a specific design intent. The first output is uncomfortable. It is also the only honest starting point.
- 02TraceFind where the gap opened, and why. Drift has provenance. It can be traced back to a specific stage transition, a specific design assumption, a specific decision that was made under pressure and never revisited. Tracing converts drift from a vague feeling into a specific finding a sponsor can act on.
- 03RealignClose the gap structurally. Sometimes the system changes. Sometimes the process changes. Sometimes the original design changes, because the assumption underneath it is no longer right. The structural fix is the one that does not depend on continued vigilance to hold.
- 04SustainMake measurement continuous, not episodic, and narrow rather than wide. The instrumentation that exposed the gap the first time is the instrumentation that keeps it closed. Three or four metrics that map directly to vision, monitored continuously, beat sixty metrics monitored quarterly every time.
These four moves are the second half. Played deliberately, they convert a programme that delivered into a programme that delivered the vision.
What this means for your programme.
If you have read this far, you have either recognised your programme in this article or you haven't.
If you have, the next step is exposure. See, with evidence, where your vision and your execution have drifted apart. The programmes that hold their vision are the ones that decided, at some specific moment, to stop walking off the pitch at halftime.
That moment is available to you whenever you choose to take it.
See where your programme has drifted, and what it would take to realign.
A structured, fixed-price engagement designed to be completed in weeks, not quarters. The output is a clear-eyed picture of where drift has opened in your programme, traced to its causes, with realignment options sized for decision.
Start a Diagnostic conversationReferences
- McKinsey & Company, Transformation Practice. "Why do most transformations fail?" Conversation with Harry Robinson; "Common pitfalls in transformations", conversation with Jon Garcia. mckinsey.com
- Gartner. "Avoid These 4 Finance Transformation Traps"; "Finance Transformation: A Guide to Success". Cited finding: 70% of finance transformations fail to deliver forecast outcomes or cost objectives. gartner.com
- Aggregated CRM failure-rate evidence across two decades: Gartner (50%), Forrester (47%), CSO Insights (~63%), AMR Research, Butler Group, Economist Intelligence Unit. Range broadly 30-70% depending on definition of failure. Synthesis: CRM Search, "Why CRM Implementations Fail".
- G2. Winter 2025 Grid Report for CRM. Average user adoption among sales professionals: 72%. Cited in Nutshell, "CRM Statistics That Prove CRM Helps Increase Revenue".
- Validity. The State of CRM Data Health. 76% of CRM users report less than half of their organisation's CRM data is accurate and complete. Cited via Cyntexa CRM Statistics 2026.
- CSO Insights. Sales performance and CRM utilisation benchmark. 43% of CRM customers use fewer than half the features they have. Cited via Nomalys, CRM Statistics.
- Prosci. Best Practices in Change Management, longitudinal benchmark since 2007. Most recent figure: 73% of respondents report being near, at, or beyond the saturation point (rising from 59% in 2007). prosci.com