Business
Outcomes and operating model
What the organisation is trying to become, which capabilities that requires, and who will own each of them afterwards.
- Capability model
- Value-stream mapping
- Operating-model design
- Investment prioritisation
Consulting · Digital Transformation Strategy
A transformation plan you can stop between phases.
Enterprise transformation fails on commitment structure more often than on technology. We sequence the work into phases that each deliver something in production and each end at a decision gate — so you are never asked to fund five years on a single early guess.
- Systems that each hold part of the answer One data fabric the whole organisation reads from
- Projects justified by technology Phases justified by a business case with a stop point
- Modernisation as a single big bang Capabilities carved out and cut over one at a time
Where programmes stall
Six failure modes we are usually called in after.
None of these are technology problems. All of them are decided before procurement starts, which is why the strategy work comes first.
- 01
The roadmap is a list of systems
Transformation planned as procurement — five platforms in a sequence — with no statement of which business outcome each one moves.
- 02
Nobody owns the process, only the system
Each department owns its application; the end-to-end process that crosses four of them has no owner and therefore never improves.
- 03
Legacy is treated as a single problem
The estate is discussed as "the old system" when in reality a minority of it blocks the business and the rest is cheap to leave alone.
- 04
Cloud migration without a target state
Workloads lifted as-is, so the operating cost rises, the architecture does not improve, and the promised agility never arrives.
- 05
Data quality discovered late
Reporting and AI ambitions collide with data nobody owns, usually after the platform contract is signed.
- 06
Change fatigue
The organisation has absorbed several partial rollouts and now assumes the next one will also be abandoned halfway.
The framework
Four pillars, assessed together or not at all.
Treating any one of these in isolation is the most reliable way to produce a plan that cannot be executed. Technology chosen without process ownership is the classic example.
Process
How work actually flows
The real path a request takes, including the spreadsheets and phone calls, measured before anyone proposes a system to replace it.
- As-is process capture
- Cycle-time and rework baseline
- To-be process design
- Control and approval mapping
Technology
Target architecture and estate
Which applications are retained, re-platformed, rebuilt or retired, and what has to exist underneath to make that possible.
- Application portfolio assessment
- Target-state architecture
- Integration and API strategy
- Cloud and hosting decisions
Data & AI
Foundations for decisions
Ownership, definitions, quality and access — the unglamorous prerequisite that every analytics and AI ambition eventually depends on.
- Data ownership and definitions
- Quality remediation plan
- Reporting and KPI design
- AI readiness alignment
Process analysis
We map the process people actually run.
Not the one in the procedure manual. The real path includes the exported spreadsheet passed between two departments, the WhatsApp message that authorises the exception, and the person who knows which of two conflicting reports to trust.
That version is the one a new system has to accommodate or deliberately replace. Designing against the documented process is how organisations end up with a platform that everybody works around.
- Walk it — with the people who run it, not only their managers
- Measure it — cycle time, wait time, rework, exception rate
- Find the decision points — where judgement is genuinely required
- Redesign, then automate — in that order, never the reverse
Enterprise architecture
The integration layer is the one most estates never built.
Everything else is usually present in some form. It is the absence of documented interfaces that makes every new system a bespoke bridge and every AI ambition stall at "how do we get the data out?".
- 01
Experience
Employee, customer and citizen-facing surfaces — portals, mobile, self-service and the channels each audience actually uses.
- 02
Process & orchestration
Cross-department workflow, approval authority and case handling, modelled once rather than re-implemented per application.
- 03
Applications
Core line-of-business systems, with an explicit position per application: retain, re-platform, rebuild or retire.
- 04
Integration
The layer most estates lack. Documented APIs and events instead of point-to-point bridges and nightly file drops.
- 05
Data & platform
Where records live, who owns each definition, how they are secured and classified, and what the residency constraints are.
The roadmap
Four phases. Three places to stop.
Each phase ends with something running in production and a gate question. If the answer at gate two is no, the programme stops at phase two — and that is a success, not a failure.
Establish what is true today and agree what "better" means in measurable terms.
Work in this phase
- As-is process capture across the priority value streams
- Application portfolio assessment and technical-health scoring
- Data ownership and quality baseline
- Stakeholder alignment on target outcomes
Outputs
- Current-state assessment
- Prioritised capability gaps
- Agreed KPI definitions
Gate question Do the gaps justify a programme, or a series of contained improvements?
Define the destination precisely enough to sequence toward it — and cost it.
Work in this phase
- Target-state enterprise architecture across the five layers
- To-be process design with control points
- Integration and API strategy
- Hosting, residency and sovereignty decisions
Outputs
- Target-state architecture
- To-be process designs
- Costed phase plan with dependencies
Gate question Is the target state affordable, and is the first phase deliverable inside one budget cycle?
Deliver working capability in production, one bounded slice at a time.
Work in this phase
- Carve out the first capability behind a documented API
- Run legacy and new paths in parallel until behaviour matches
- Migrate and reconcile data with a signed-off validation run
- Cut over on agreed criteria with a rehearsed rollback
Outputs
- Capability live in production
- Reconciliation evidence
- Updated architecture records
Gate question Did the slice deliver the measured outcome? If not, why continue to the next?
Make the new way the default, and keep the estate from re-accumulating debt.
Work in this phase
- Extend the pattern to remaining capabilities and sites
- Retire the duplicated legacy functions the migration made redundant
- Establish architecture governance and change control
- Embed KPI reporting in management review
Outputs
- Retired legacy footprint
- Architecture governance in place
- KPIs in management reporting
Gate question Is the improvement holding without the programme team present?
KPIs & success metrics
Eight measures, defined before the first phase starts.
We deliberately publish no target values here. Baselines are measured from your own operations in Phase 01 — a benchmark borrowed from another organisation is not a target, it is a guess with a decimal point.
| Area | Measure | Why this one |
|---|---|---|
| Process | End-to-end cycle time | The single most honest measure of whether a process actually improved, rather than moved. |
| Process | Rework and rejection rate | Rising rework after a rollout usually means the design skipped a real exception. |
| Technology | Change lead time | How long a small change takes from request to production — the best proxy for estate health. |
| Technology | Unsupported components | Counts what is running past end-of-support. Auditors and insurers ask; most estates cannot answer. |
| Data | Contested measures | The number of KPIs where two reports disagree. Should trend to zero and rarely does. |
| Adoption | Active use vs licensed use | Distinguishes a deployed system from an adopted one, which is where most value is lost. |
| Financial | Run cost per capability | Makes the retire decision arguable with numbers instead of loyalty. |
| Programme | Phase gate outcomes | Records what was decided at each gate, including the phases deliberately not funded. |
Industries
The sequence changes with the sector.
A ministry's procurement calendar and an operator's shutdown window are hard constraints on phasing, not details to work out later.
FAQ
What executives ask before committing.
How is a strategy engagement different from just starting the project?
Starting the project commits you to a sequence chosen before anyone measured the current state. The strategy engagement produces the sequence, the cost per phase and the decision gates — so the first phase is funded on evidence and the fifth is not funded at all until the fourth has proven itself.
We already have a digital transformation plan. Is this redundant?
Not necessarily, and we will say so if it is. Most existing plans are strong on technology selection and thin on process ownership, data definitions and the integration layer. A short review against those three areas usually tells you whether the plan needs replacing or only completing.
Do we have to move everything to the cloud?
No. Cloud, hybrid and on-premises are all valid endings, and for organisations with residency or sovereignty requirements hybrid or on-premises is frequently the correct answer. The hosting decision belongs in Phase 02 as an output, not in the brief as an assumption.
How long before we see anything working?
Phase 03 delivers a capability into production, and it is deliberately scoped to a bounded slice for that reason. If the first working outcome is further away than a couple of quarters, the slice was drawn too large and we would rather redraw it than defend the plan.
Who from our side needs to be involved?
Leadership for outcome alignment and the phase gates, process owners for the as-is capture, and whoever actually keeps the current systems running — that last group holds the undocumented knowledge that determines whether a plan is realistic.
What if the assessment says our problem is not technology?
That happens, and it is a legitimate finding. Sometimes the constraint is process ownership or decision rights, and installing a platform on top of it will produce an expensive version of the same problem. We will put that in writing rather than sell around it.
Get started
Start with Phase 01 only.
Six weeks, a measured current state, a prioritised gap list and agreed KPI definitions. Commit to the rest afterwards, on evidence — or not at all.
