Skip to content
1961 Digital TransformX

Service

A roadmap nobody executes is an expensive document

Transformation programmes rarely fail at the strategy. They fail in the third quarter, when the plan meets the people who were already fully occupied. We plan against real capacity, sequence the work, and stay while it is delivered.

You will recognise this

  • There is a transformation deck from two years ago, and you would struggle to name a single thing it changed.

  • The steering committee meets monthly, reviews a status report that is always amber, and decides nothing that binds anyone.

  • Each department bought its own tool, and the finance team now reconciles between four systems that were meant to save time.

  • The programme has a budget for the year but no order of work, so everything starts at once and nothing finishes.

  • The same three capable people are named on every initiative, and they already have full-time operational jobs.

How the work runs

  1. Assess the current state

    We document what actually runs the business today: the systems, the manual bridges between them, and the load each process places on people. This is done by observation, not by questionnaire. Where a process depends on one person's memory or one undocumented file, we record it as a dependency rather than a detail.

  2. Define the target model

    The target is described as an operating model, not a technology stack: which decisions are made where, which team owns which record, and what the month-end looks like when it is finished. Technology choices come after that, because the same result is often reachable with less software than expected.

  3. Sequence by dependency

    The gap between current and target is broken into quarters ordered by what must be true before the next thing can start. Data cleanup precedes automation. Ownership precedes reporting. Each quarter carries a budget, a named owner and a measure that will be checked whether or not it is comfortable.

  4. Deliver the first quarter

    We stay and run the first tranche with your people, because a plan that has never met the organisation is a hypothesis. The first quarter is deliberately something that visibly finishes. Its purpose is partly to prove the sequence and partly to show a sceptical organisation that the programme completes things.

  5. Review and re-sequence

    Every quarter the plan is tested against what happened: what was delivered, what slipped and why, what the measures say. Items are dropped when the business has moved on, and the plan is re-sequenced in writing. A roadmap that survives two years unchanged was never being executed.

What you are handed

  • Current-state assessment naming systems, bridges and dependencies
  • Target operating model with owners per record
  • Quarter-by-quarter roadmap with budget and named owners
  • Measures defined before the work starts
  • Capability plan for the roles you will need internally
  • Quarterly review pack with variance against the plan

Why roadmaps stall in the third quarter

The first two quarters of a transformation usually go well, because the early work is visible and the organisation is curious. The third is where it stops. The initiatives that remain all need the same handful of capable people, and those people have day jobs that were never reduced. Nobody cancels the programme; it simply stops being scheduled. We plan against the capacity that genuinely exists, which means fewer parallel workstreams than a consultancy deck would show and an explicit statement of what each named person is being taken off. If nothing is being taken off, the plan is fiction and we will say so before you approve it.

Sequence is the whole argument

Most transformation plans are a list of desirable things with dates attached, which is not a sequence. A sequence states what has to be true before the next item can begin. Automating an approval before anyone owns the underlying data produces faster wrong answers. Building a dashboard before the definitions are agreed produces a new venue for the same argument. Consolidating systems before the process is mapped moves the mess into a more expensive place. The order is not a matter of preference, and getting it wrong is why programmes with adequate budgets deliver very little.

Name what stops being true

The part almost every plan omits is the negative half: what will no longer happen once a quarter is delivered. Purchase requests will no longer arrive by phone. The costing file will no longer be maintained by hand. Nobody will re-key a delivery note. Written that way, each quarter has a test that anyone can apply, and a benefit that is checkable rather than asserted. It also exposes the changes that will be resisted, early enough to negotiate them. A benefit expressed only as an improvement is unfalsifiable, and an unfalsifiable benefit is always reported as achieved.

Questions we get asked

We already have a strategy document. Why another one?
If it names owners, quarters, budgets and measures, you do not need another and we will tell you that. Most of the documents we are shown describe a destination without a route, which is why they have not moved anything. In that case we do not rewrite the strategy. We take its intent and build the sequence underneath it, then run the first quarter so the organisation sees something finish.
How long does a transformation programme take?
Long enough that the honest answer is uncomfortable. Meaningful change in a company with physical operations is usually a two to three year sequence, with something visibly completed each quarter. Anyone promising a full transformation in six months is either describing a software installation or planning to leave before the difficult part. The plan is written in quarters precisely so you can stop after any one of them.
What does this cost before anything is delivered?
The assessment and the plan are a fixed, bounded piece of work, and they are useful on their own: the sequenced roadmap is written so your own people, or another firm, can execute it without us. Delivery cost is then stated per quarter rather than as one programme figure, so you approve each tranche knowing what the previous one produced.
Do we need to hire a CIO or build an internal team?
Usually you need less seniority and more continuity than expected. What fails is not the absence of a chief anything; it is the absence of one person with authority to decide across departments and enough time to do it. Sometimes that is an existing operations manager given the mandate in writing. The capability plan states which roles must be internal permanently and which we should be doing ourselves only until someone is ready.
What happens if the business changes halfway through?
It will, and the plan is built to be edited rather than defended. Each quarter is reviewed against what actually happened and re-sequenced in writing, with dropped items recorded as dropped rather than quietly carried forward. The value is in the ordering logic, which survives a change in priorities. A plan that cannot absorb a new factory or a lost contract was never a plan.

Tell us what is not working

Send one line about what is going wrong. On the first call we will tell you whether it is a system problem, a process problem or a governance problem — and which one to fix first. That call is free and it is not a sales meeting.

Book a consultation