Consulting
Transformation measured in
shipped systems, not slides
Most transformation programmes stall because the operating model changes faster than the systems underneath it. We sequence the work so each quarter ends with something in production that a business unit actually depends on.
Overview
Sequenced change programmes that ship working software, not slide decks.
A transformation programme is a portfolio decision before it is an engineering one. We start by mapping which processes carry revenue risk, which carry regulatory exposure, and which are simply expensive habits. That map decides the order of work, and it usually contradicts the order the organisation chart would suggest.
From there the work runs in parallel tracks: a target architecture that is written down and versioned, a delivery cadence with real release trains, and a change track covering role design, training and the decommissioning plan. The decommissioning plan matters most. Programmes that never switch the old system off pay for both indefinitely.
We staff these engagements with people who write code. An architect who has not deployed to your environment cannot judge whether a six-week integration estimate is honest. Expect roughly one principal engineer for every four delivery engineers, and expect them to be in the standups, not just the steering committee.
- 11 months
- from programme start to first legacy system switched off
- 37%
- cut in order-to-cash cycle time at Halden Group
- £2.4m
- annual licence and hosting spend retired across three platforms
Capabilities
What this covers
Six areas we staff properly. If your problem sits outside them, the honest note at the foot of this page says so.
Operating model and value stream mapping
We trace each core process from trigger to cash, timing the handoffs and counting the manual touchpoints. The output is a ranked list of what to fix, with the cost of leaving it alone.
Target architecture and reference blueprints
A written architecture with named boundaries, data ownership per domain, and integration contracts. It is versioned in the repository alongside the code so it stops drifting from reality within a quarter.
Programme delivery and release trains
Quarterly increments with fixed dates and variable scope, run by teams that own their deployments. We publish a burn-down of decommissioned legacy components, not just a list of features delivered.
Data foundation and reporting migration
Reports are usually the last thing migrated and the first thing that breaks trust. We rebuild the reporting layer against the new domain model early, then run both in parallel until the numbers reconcile.
Change management and role redesign
New systems fail on adoption more often than on uptime. We redesign roles, write the actual procedure documents, and train the people who will use the system daily rather than their managers.
Benefits tracking and programme governance
Every workstream carries a measurable claim: hours saved, days off the cycle, errors avoided. We instrument those measures in the system itself so the benefit case is checked monthly, not at closure.
Deliverables
What you get
- Current-state process map with cycle times and manual touchpoint counts
- Versioned target architecture with domain boundaries and integration contracts
- Three-year sequencing plan with quarterly increments and decommissioning dates
- Benefits register instrumented against production telemetry
- Role design pack, procedure documents and training materials
- Programme governance model with escalation paths and a dated decision log
Stack
What we build it with
- Kubernetes
- Terraform
- Apache Kafka
- PostgreSQL
- Camunda 8
- Backstage
- Grafana
- GitHub Actions
- Snowflake
- Keycloak
Process
How the engagement runs
Two-week increments against a written definition of done. You can stop at any increment boundary and keep everything built so far.
Diagnostic
Four to six weeks of process tracing, systems inventory and interviews across the operating layers, ending in a ranked backlog with cost estimates attached.
Architecture and sequencing
We fix the target architecture and the order of work, deciding explicitly which systems get replaced, which get wrapped, and which are left alone until later.
Pilot increment
One business-critical process taken to production in a single quarter, proving the architecture, the delivery cadence and the change approach against real users.
Scaled delivery
Parallel teams run quarterly release trains against the same contracts, with architecture review gates that block work when interfaces drift from the spec.
Decommission and handover
Legacy systems are switched off on dated milestones, licences cancelled, and the platform handed to your teams with runbooks and a supported operating cadence.
When this is the wrong engagement
If your problem is a single underperforming application rather than the way work moves between departments, a focused build or modernisation engagement will get you there faster and for a fraction of the cost.
FAQ
Questions we get asked
- How long before we see something in production?
The first increment lands in production within a quarter of the diagnostic finishing. It will be a narrow process rather than a flagship one, chosen because it exercises the integration, security and deployment paths that everything after it depends on.
- Do you replace our existing systems or work with them?
Both, and the split is decided in the sequencing phase rather than assumed at the start. Systems with a healthy vendor roadmap usually get wrapped behind an API and left in place; systems where the vendor has stopped shipping, or where the data model blocks the target design, get replaced.
- Who owns the platform when the programme ends?
Your teams. We run a handover track from the second increment onward: your engineers sit in the delivery teams, own services in production before the programme closes, and inherit runbooks and on-call rotas rather than a document dump on the final day.
- How do you measure whether the programme worked?
By decommissioning and by cycle time, not by features shipped. Each workstream registers a measurable claim before it starts, the measure is instrumented in the system itself, and the register is reviewed monthly with numbers pulled from production rather than from a status report.
Related
More in Consulting
Consulting
IT Consulting
Short engagements with a written answer, a cost, and someone who will stay to build it.
Consulting
Dedicated Development Teams
A standing squad with its own lead, its own metrics and a memory of your codebase.
Consulting
Staff Augmentation
Named specialists into your existing team, under your management, on your board.