Contents
The short answer
Run a piece of transformation as a bounded programme when the outcome holds after you stop paying attention to it. Run it as a standing capability when the outcome decays without maintenance.
Almost every enterprise transformation contains both kinds of work, and the most common structural error is applying one governance model to all of it. A platform migration, a legal restructuring or a site consolidation reaches a genuine end state; once done, it stays done. Pricing discipline, data quality, model performance and workforce skills reach no such state. They degrade from the moment nobody owns them.
Adaptive transformation, properly understood, is not the belief that everything should be continuous. It is the discipline of sorting which is which, then giving each type the governance, funding and ownership it actually needs.
What adaptive transformation actually means
Adaptive transformation is an approach to enterprise change in which the organisation maintains a permanent ability to re-plan and re-allocate, rather than executing a fixed multi-year roadmap to completion. The distinguishing feature is not speed, or agility as a value statement. It is that the plan is expected to change, and there is a standing mechanism for changing it.
The term is often used loosely, as a synonym for being responsive or open to change. That usage is not useful, because no executive will argue for being unresponsive. The version worth adopting is narrower and testable. An organisation is running adaptively when it can do three things: name the cadence at which its transformation portfolio is re-baselined, name who holds the authority to stop or re-scope work at that cadence, and point to a decision in the last two quarters where that authority was actually exercised.
If those three things cannot be named, the organisation is running a fixed plan with adaptive language layered on top.
Two structures, not one philosophy
The practical choice is between two governance structures. Both are legitimate. Each fails in a characteristic way when applied to the wrong work.
| Bounded programme | Standing capability | |
|---|---|---|
| Ends when | The defined outcome is delivered | Never by default, reviewed on a cycle |
| Right when | The outcome persists unattended | The outcome decays without maintenance |
| Authority | Escalates to a steering group | Delegated within stated boundaries |
| Funding | Business case, fixed envelope | Standing budget line, re-baselined |
| Measured by | Delivery to scope and benefit realisation | Decision quality and decision cycle time |
| Characteristic failure | Declares victory, benefit quietly erodes | Outlives its purpose, consumes attention |
Note the last row. Both structures fail, and they fail in opposite directions. A programme closed too early leaves an outcome nobody maintains. A capability left standing too long becomes an internal institution that generates activity to justify its existence. Neither failure is an argument for preferring the other structure universally.
Four tests for what should persist
Apply these to each workstream separately, not to the transformation as a whole. The output is usually a split, not a verdict.
1. The decay test
Ask what the state of this outcome will be in twelve months if nobody actively maintains it. If the honest answer is that it holds, the work is a project and should close. If the answer is that it drifts, degrades or reverts, it needs a standing owner regardless of how the work was originally funded.
This test is unusually reliable because it is empirical rather than aspirational. Data quality, supplier terms, model performance and skills currency all fail it. Completed migrations, decommissioned systems and executed legal changes all pass it.
2. The decision load test
Count how often this domain forces a decision that genuinely reallocates money or people. Standing structures exist to carry standing decision loads. If a domain produces a consequential decision every few weeks, routing each one through a steering committee introduces a delay that is itself the problem, and the domain needs delegated authority within stated boundaries. If real decisions arrive once or twice a year, normal line management absorbs them and a permanent function is overhead.
3. The ownership test
Ask whether there is already a line owner whose existing job covers this outcome. If there is, the programme's job is to transfer the work and close, not to hold it indefinitely.
This test surfaces something uncomfortable. Permanent transformation offices are frequently a symptom of unassignable accountability: the office persists because no executive in the line will accept the outcome on their own scorecard. That is a reason to fix the accountability, not to institutionalise the workaround. A capability that exists because nobody else will own it is not a capability. It is a holding pen.
4. The sunset evidence test
Ask what evidence, stated in advance, would tell you this function should stop or shrink. A standing capability that cannot describe its own sunset conditions is not a capability, it is an entitlement. The answer does not need to be a date. It needs to be a condition: a defect rate below a threshold for four consecutive quarters, a skills assessment that stops finding gaps, a decision backlog that clears without intervention.
Requiring this answer at the point of creation is what prevents the second failure mode in the table above.
What the failure statistics actually tell you
Any discussion of transformation governance eventually meets the claim that 70 per cent of transformations fail. It is worth being precise about this figure, because it is repeated widely across the industry and it does not mean what it appears to mean.
In a peer-reviewed review published in the Journal of Change Management in 2011, Mark Hughes traced five separate published instances of the 70 per cent organisational change failure rate and concluded that while a popular narrative of 70 per cent failure exists, there is no valid and reliable empirical evidence to support it. The number circulates through citation rather than measurement.
The figures that do survive scrutiny are definitional rather than universal. McKinsey's long-running survey research reports that fewer than a third of transformations succeed, but that figure is self-reported and rests on a specific and demanding definition: success means both improving performance and sustaining the improvement. More recently, Gartner reported in July 2025 that just 32 per cent of business leaders report achieving healthy change adoption among employees.
Why this matters for the structural decision. Notice what the credible definitions have in common. They fail transformations on sustaining the improvement, not on delivering it. That is the decay test appearing in the data. The measured problem is not that organisations cannot execute change. It is that they close the programme and the gain erodes, because nothing was left standing to hold it.
Read that way, the statistics stop being a reason for anxiety and become an argument for a specific design choice: decide what persists before you close anything.
The cost of making everything permanent
The corrective to closing too early is not making everything permanent. Continuous change carries a measurable cost, and it is paid by the workforce.
Writing in Harvard Business Review in May 2023, two Gartner researchers reported that the average employee experienced ten planned enterprise changes in 2022, up from two in 2016. Over a comparable period, Gartner's analysis of what it termed the transformation deficit found that the share of employees willing to support enterprise change fell from 74 per cent in 2016 to 38 per cent in 2022.
A fivefold increase in change events alongside a halving of willingness to support them is the signature of change treated as a permanent condition without a corresponding discipline about what earns a place in the queue. Every standing capability consumes organisational attention, and attention is the genuinely scarce resource in a transformation. The four tests are as much a defence against over-permanence as they are a defence against premature closure.
How to run the part that stays
For the workstreams that pass into standing capability, three mechanisms do most of the work.
A named re-baselining cadence. Set an interval at which the portfolio is genuinely re-cut, with the explicit expectation that some work will be stopped. Quarterly suits most enterprises. The test of whether the cadence is real is simple: if nothing has been stopped or materially re-scoped in the last two cycles, the cadence is a reporting ritual rather than a decision point. Matching the planning interval to the confidence you actually have is the subject of adaptive planning horizons.
A single accountable owner per domain. Not a committee. The ownership test above fails most often at this point, and a standing capability with distributed accountability reverts to a coordination forum within about two cycles.
An evidence loop the owner does not control. If the function that runs the capability also reports on whether it is working, the sunset criteria will never trigger. Separate the measurement from the delivery. This is the same structural principle that decides whether enterprise AI initiatives move beyond pilots, and it becomes more important, not less, as more of the work is carried by systems rather than people.
Where the work being sustained is AI-enabled, these mechanisms are what an AI operating model formalises, and the people side of holding the change in place is covered separately in our guide to managing change during enterprise AI transformation.
Where MASSIVUE fits
MASSIVUE is an enterprise transformation and AI consultancy headquartered in Singapore. Our relevance to this particular question is specific, and worth stating plainly rather than broadly.
The MASSIVUE Enterprise Transformation engagement model is built in three stages: Consult, Upskill and Sustain. The third stage exists because of the decay test. What remains owned inside the client organisation after an engagement ends is treated as a design decision made at the start, not as an afterthought at handover. That is the same decision this article describes, applied to the boundary between a consultancy and a client.
Where the standing capability involves coordinating AI systems alongside people, Protum, MASSIVUE's AI operating model, names Adaptive Structures as one of its six capabilities, alongside Data Culture, Augmented Craft, Responsible Intelligence, Flow Based Interactions and Impact Prioritisation. Adaptive Structures is the component that addresses this governance question directly: where decision authority sits when operating conditions keep moving.
What we do not claim is a proprietary measurement of transformation failure rates. The external figures cited in this article belong to Hughes, McKinsey and Gartner, and each is linked to its source so you can check the definitions yourself.
Building the capability internally. For executives who need to make the structural call described here and then own it, MASSIVUE Academy offers the Certified Enterprise Leader in AI & Digital Transformation, which covers setting direction and leading the organisation there. For a shorter route focused on transformation frameworks with a leadership capstone, the Digital Transformation Lead micro-credential is the closer fit.
Frequently asked questions
Is adaptive transformation the same as agile transformation?
No. Agile transformation usually refers to adopting a specific set of delivery practices, most often within technology and product teams. Adaptive transformation is a governance and portfolio question that sits above the delivery layer: how often the enterprise re-decides what it is doing, and who holds the authority to change it. An organisation can run agile delivery inside a fixed three-year plan, which is a common and largely self-defeating combination.
Should we make our transformation office permanent?
Usually not as a whole. The better question is which capabilities the office currently holds must survive it, and where each should live. Apply the ownership test to each one. Capabilities that pass to an existing line owner should transfer, and the office should shrink accordingly. What typically justifies a permanent central function is portfolio re-baselining and arbitration across business units, not delivery.
How often should an enterprise re-baseline its transformation portfolio?
Quarterly works for most enterprises. It is frequent enough to respond to material change and infrequent enough that teams can deliver something between cycles. The interval matters less than whether the cycle has teeth. If no work has been stopped or materially re-scoped across two consecutive cycles, the cadence is not functioning as a decision point regardless of its frequency.
Do 70 per cent of transformations really fail?
There is no reliable evidence for that specific figure. A peer-reviewed review published in the Journal of Change Management in 2011 examined five published sources for the 70 per cent claim and found none of them supported by valid empirical evidence. Figures that do hold up are narrower and definitional. McKinsey's survey research finds fewer than a third of transformations both improve performance and sustain the improvement, and Gartner reported in 2025 that 32 per cent of business leaders achieve healthy change adoption. Both fail transformations on sustaining the gain rather than on delivering it.
What is the first step if our transformation is already running?
List the workstreams and run the decay test on each one. The exercise usually takes an afternoon, and it typically reveals two things: a small number of streams that should have closed some time ago, and one or two outcomes that everyone assumes someone owns and nobody actually does. Fix the second finding first.