"Digital transformation" has become one of the most abused phrases in business. It has been used to describe everything from deploying a new CRM to fundamentally redesigning how a company creates and delivers value using technology. The first use of the phrase is a procurement decision. The second is a strategic programme that touches every function of the business. They require entirely different approaches.
This article is about the second type — and the framework we use to execute it without losing sight of the reason the programme exists in the first place.
Why transformation programmes fail
Before describing the framework, it is worth examining why transformation programmes fail. The McKinsey statistic that 70% of digital transformation programmes fail to achieve their goals is frequently cited. Our observation of the failed programmes we have been close to suggests several consistent causes:
- Technology-led, not outcome-led. The programme is defined by what technology will be implemented rather than what business outcomes will be achieved. When the technology goes live, no one agrees on whether it was a success.
- No executive ownership of outcomes. Transformation is delegated to IT. Technology decisions are made without business context. Business leaders disengage when results are slow.
- Big bang delivery. The programme plans to deliver everything at once, 24 months from now. The organisation never develops the muscles for continuous change. When delays hit, everything delays together.
- Change management as a deliverable, not a discipline. A change management plan is written, filed, and never executed. People are not prepared for the changes to their roles, and they resist.
The framework: four phases
Phase 1: Outcomes Definition (4–6 weeks)
Before any technology is selected, the programme team works with business leaders to articulate the desired outcomes in quantitative terms. Not "improve customer experience" but "reduce average customer resolution time from 4.2 days to 1.5 days by Q4 2027, as measured by our support system." Each outcome should have a baseline measurement, a target, a measurement method, and a named business owner.
We typically identify 5–8 priority outcomes in this phase. Each is scored for strategic importance, current performance gap, and technical feasibility. The top three or four become the programme's primary success criteria.
Phase 2: Current State Assessment (3–4 weeks)
With outcomes defined, the assessment phase maps the technology, processes, and organisational structures that currently deliver (or fail to deliver) those outcomes. This is not a general technology audit — it is a targeted investigation of the specific value chains that produce the outcomes you care about.
The output of this phase is a current-state map showing where the largest gaps between current performance and target performance exist, and what the most likely root causes are. In our experience, the bottlenecks are almost never where the organisation expects them to be.
Phase 3: Phased Roadmap Design (3–4 weeks)
The roadmap translates the gap analysis into a sequenced delivery plan, prioritised by impact and delivered in phases of no more than 90 days each. Each phase has defined outcomes, a named delivery team, a defined budget, and explicit go/no-go criteria.
No phase should be longer than 90 days. Longer phases accumulate risk, delay feedback, and allow the organisation's appetite for change to deteriorate. If something cannot be broken into 90-day increments, it is not well enough understood to start.
Phase 4: Continuous Delivery and Adaptation
The delivery phases are where most programmes live or die. The key practices that separate successful delivery from stalled programmes:
- Business outcome reviews every two weeks, not just technology delivery updates. Are the metrics moving? If not, why not?
- Dedicated change management resource embedded in the delivery team, not sitting in a separate workstream. Change management is a daily activity, not a communications exercise.
- Value realisation tracking that connects technical deliverables to business outcomes. The programme is never "done" until the outcomes are achieved.
- Regular retrospectives that are empowered to change the plan, not just document problems.
The organisational structure that works
The governance structure we recommend for mid-market transformations:
- Executive Sponsor — C-level owner of the programme's business outcomes. Makes resourcing and prioritisation decisions. Reviews outcomes every 30 days.
- Programme Director — Accountable for overall delivery. Reports to Executive Sponsor. The single throat to choke.
- Business Domain Leads — Senior business managers responsible for change within their function. Not technology people. Their accountability is user adoption and outcome achievement, not feature delivery.
- Technology Delivery Leads — Senior engineers responsible for technical delivery within each domain. They report to the Programme Director on delivery and to Business Domain Leads on requirements.
If you are at the start of a transformation programme and would like a second opinion on your approach, get in touch. We offer free 30-minute strategy calls for organisations in the planning phase.