When governance gaps become delivery and business-case problems
Ownership Before Mobilisation | Part 2 of 3
Previous in the series: Part 1: Why transformation governance problems are discovered too late
Cato Rockne-Meyer
25 September 2026
Previous in the series: Part 1: Why transformation governance problems are discovered too late
Cato Rockne-Meyer
25 September 2026
A programme can keep reporting progress while weak ownership, untested assumptions and client-side constraints gradually erode scalability, cost and benefits.
Governance problems rarely appear under that label. They usually surface as delivery friction.
- A decision takes weeks because several stakeholders believe someone else owns it.
- A Product Owner is named but lacks the authority or time to make the decisions the role requires.
- A process is redesigned for one business unit, only for another region or function to later challenge the assumptions behind it.
- A data issue remains unresolved because responsibility is spread across several teams and no one has the authority to settle the dispute.
- A solution is designed around the current organisation because the future operating model is still unclear.
- A temporary programme responsibility is created to keep delivery moving, but nobody has decided who will own it after transition.
- Decisions are escalated.
- Extra forums are created.
- SMEs are pulled into meetings.
- Temporary workarounds are agreed.
- Additional governance is introduced.
- Local exceptions are accepted to protect milestones.
The first implementation is also a test of assumptions
This is particularly important where the transformation is intended to expand across business units, functions or countries. Starting in one area can sensibly reduce initial complexity and test the approach. The risk arises when limited involvement from future areas leaves assumptions unchallenged.
Those assumptions may concern process consistency, data structures, local regulatory requirements, integration patterns, organisational responsibilities, customer or workforce needs, technology maturity and expected levels of standardisation.
The first implementation may look coherent and economical because it reflects the characteristics of the initial area. Complexity appears later. A process that looked standard contains legitimate local variations. A data model does not support another business unit. An integration pattern does not scale as expected. Regulatory requirements introduce additional controls. Historic operating practices prove harder to unwind than assumed.
Legacy data can create an enduring dependency
Some historic data may have little value in the new operational solution and therefore make no sense to migrate. At the same time, regulatory, legal, audit or operational requirements may mean that it cannot simply be discarded.
If the new platform does not provide a suitable archive, the organisation may have to retain parts of the legacy estate solely to preserve access to historical information. That creates new ownership questions:
At that point, cost, timescale and benefits can start to move away from the assumptions used in the original business case. The programme may still be delivering successfully against its immediate milestones while becoming less capable of delivering the economics on which the wider transformation was approved.
Can the organisation scale with the solution?
The first implementation should test more than whether the solution works. It should test whether the assumptions behind the wider transformation remain valid and whether the client-side capabilities needed to support the transformation are strong enough.
That includes providing knowledgeable Product Owners and SMEs, making decisions at the required speed, governing architecture and data, managing suppliers, absorbing change, supporting testing and deployment, and building the enduring capabilities required to transition to the target operating model.
This is particularly important where the transformation is intended to expand across business units, functions or countries. Starting in one area can sensibly reduce initial complexity and test the approach. The risk arises when limited involvement from future areas leaves assumptions unchallenged.
Those assumptions may concern process consistency, data structures, local regulatory requirements, integration patterns, organisational responsibilities, customer or workforce needs, technology maturity and expected levels of standardisation.
The first implementation may look coherent and economical because it reflects the characteristics of the initial area. Complexity appears later. A process that looked standard contains legitimate local variations. A data model does not support another business unit. An integration pattern does not scale as expected. Regulatory requirements introduce additional controls. Historic operating practices prove harder to unwind than assumed.
Legacy data can create an enduring dependency
Some historic data may have little value in the new operational solution and therefore make no sense to migrate. At the same time, regulatory, legal, audit or operational requirements may mean that it cannot simply be discarded.
If the new platform does not provide a suitable archive, the organisation may have to retain parts of the legacy estate solely to preserve access to historical information. That creates new ownership questions:
- Who owns the retained data?
- Who controls access?
- Who supports the legacy environment?
- How long must it remain available?
- Who funds it?
- What is the eventual decommissioning plan?
At that point, cost, timescale and benefits can start to move away from the assumptions used in the original business case. The programme may still be delivering successfully against its immediate milestones while becoming less capable of delivering the economics on which the wider transformation was approved.
Can the organisation scale with the solution?
The first implementation should test more than whether the solution works. It should test whether the assumptions behind the wider transformation remain valid and whether the client-side capabilities needed to support the transformation are strong enough.
That includes providing knowledgeable Product Owners and SMEs, making decisions at the required speed, governing architecture and data, managing suppliers, absorbing change, supporting testing and deployment, and building the enduring capabilities required to transition to the target operating model.
Can the solution scale? And can the organisation scale with it?
If either answer is uncertain, the next phase should not simply replicate the first implementation faster.
Why the business case can drift
Transformation programmes are often approved based on a business case developed before the full complexity of delivery is understood. That creates a natural risk of drift.
Some transformations are primarily opportunity-led. They may aim to support growth, improve customer experience, create new products, increase productivity or open new markets. Others are driven by necessity: replacing ageing technology, responding to regulatory change, improving resilience, reducing an unsustainable cost base or protecting future viability.
Between these sit many other cases, including mergers and acquisitions, divestments, technology expiry, structural simplification and major changes to operating models. The underlying driver matters because it changes the economics of the decision.
For an opportunity-led programme, the organisation may genuinely be able to decide not to pursue the opportunity. For a regulatory, technology-expiry or resilience programme, the apparent “do nothing” option may simply defer the cost while increasing future risk, urgency or complexity.
The status quo deserves the same scrutiny
The cost of transformation is usually analysed in detail. The cost of continuing as-is is often under-analysed or assumed to be understood because it represents the status quo.
A thorough analysis of the current operating model can expose uncomfortable truths.
Some transformations are primarily opportunity-led. They may aim to support growth, improve customer experience, create new products, increase productivity or open new markets. Others are driven by necessity: replacing ageing technology, responding to regulatory change, improving resilience, reducing an unsustainable cost base or protecting future viability.
Between these sit many other cases, including mergers and acquisitions, divestments, technology expiry, structural simplification and major changes to operating models. The underlying driver matters because it changes the economics of the decision.
For an opportunity-led programme, the organisation may genuinely be able to decide not to pursue the opportunity. For a regulatory, technology-expiry or resilience programme, the apparent “do nothing” option may simply defer the cost while increasing future risk, urgency or complexity.
The status quo deserves the same scrutiny
The cost of transformation is usually analysed in detail. The cost of continuing as-is is often under-analysed or assumed to be understood because it represents the status quo.
A thorough analysis of the current operating model can expose uncomfortable truths.
Many of the real costs of “doing nothing” sit below the waterline.
Legacy systems may require more support than expected. Manual processes may absorb significant hidden effort. Fragmented integration can create recurring inefficiency. Scarce technical skills may command increasing premiums. Workarounds, reconciliations and local fixes can accumulate into a material operating burden. Poor data quality may be common knowledge and still remain economically invisible until later in the programme.
Capacity can be an even less visible constraint. If the organisation is already operating close to maximum capacity, the current cost base does not capture the opportunity cost of being unable to absorb additional demand. Growth opportunities may be declined, service improvements deferred and new initiatives delayed because there is simply no capacity available to support them.
Operating close to the edge also carries a risk premium. A small operational issue, staff absence, system failure, demand spike or regulatory requirement can trigger a cascade of additional costs because there is little spare capacity available to absorb the disruption.
Capacity can be an even less visible constraint. If the organisation is already operating close to maximum capacity, the current cost base does not capture the opportunity cost of being unable to absorb additional demand. Growth opportunities may be declined, service improvements deferred and new initiatives delayed because there is simply no capacity available to support them.
Operating close to the edge also carries a risk premium. A small operational issue, staff absence, system failure, demand spike or regulatory requirement can trigger a cascade of additional costs because there is little spare capacity available to absorb the disruption.
Keep the business case aligned as the programme evolves
The business case can also drift as delivery assumptions are tested. A common process may prove less common than expected. Historic data may need to remain accessible in legacy platforms. Internal capability may need to be built earlier than planned. Supplier and client-side resourcing may increase. Benefits can arrive later than expected while costs rise sooner. The original business case may still appear numerically intact, but the path from investment to benefit has changed.
The narrative also matters. A growth-led transformation will be perceived differently from a programme associated with cost reduction, restructuring, regulation or technology expiry. Staff, managers, suppliers and partners will interpret the programme according to what they believe it means for them, and that perception can influence engagement, resourcing, decision speed and willingness to support change.
The business case should therefore remain a living governance tool throughout the transformation. It should provide the reference point against which material changes, trade-offs and course corrections are assessed.
As scope evolves, assumptions are tested, legacy retirement changes, delivery costs move, or benefits shift in timing or certainty, the programme should revisit the investment case and maintain explicit alignment with the sponsor and other key stakeholders.
That alignment keeps changes in direction consciously approved rather than allowing them to accumulate through local delivery decisions. It also keeps senior stakeholders current on the programme narrative: why the transformation still makes sense, what has changed, which assumptions have been revised, and why the latest course of action remains justified.
Where important assumptions remain uncertain, ranges and scenarios may provide a more useful basis for maintaining that alignment than a single apparently precise forecast.
The business case can also drift as delivery assumptions are tested. A common process may prove less common than expected. Historic data may need to remain accessible in legacy platforms. Internal capability may need to be built earlier than planned. Supplier and client-side resourcing may increase. Benefits can arrive later than expected while costs rise sooner. The original business case may still appear numerically intact, but the path from investment to benefit has changed.
The narrative also matters. A growth-led transformation will be perceived differently from a programme associated with cost reduction, restructuring, regulation or technology expiry. Staff, managers, suppliers and partners will interpret the programme according to what they believe it means for them, and that perception can influence engagement, resourcing, decision speed and willingness to support change.
The business case should therefore remain a living governance tool throughout the transformation. It should provide the reference point against which material changes, trade-offs and course corrections are assessed.
As scope evolves, assumptions are tested, legacy retirement changes, delivery costs move, or benefits shift in timing or certainty, the programme should revisit the investment case and maintain explicit alignment with the sponsor and other key stakeholders.
That alignment keeps changes in direction consciously approved rather than allowing them to accumulate through local delivery decisions. It also keeps senior stakeholders current on the programme narrative: why the transformation still makes sense, what has changed, which assumptions have been revised, and why the latest course of action remains justified.
Where important assumptions remain uncertain, ranges and scenarios may provide a more useful basis for maintaining that alignment than a single apparently precise forecast.
What comes next
The lessons from delivery and business-case drift point back to the same question: does the organisation have effective owners for the processes, products, data, benefits, decisions and risks on which the transformation depends?
COMING SOON: Part 3 turns that question into a practical pre-mobilisation Ownership Readiness Check and a simple maturity test for distinguishing nominal ownership from effective ownership.
The lessons from delivery and business-case drift point back to the same question: does the organisation have effective owners for the processes, products, data, benefits, decisions and risks on which the transformation depends?
COMING SOON: Part 3 turns that question into a practical pre-mobilisation Ownership Readiness Check and a simple maturity test for distinguishing nominal ownership from effective ownership.