Digital transformation that survives its first year: sequencing over ambition

The central idea

A transformation programme is a sequencing problem before it is a technology problem. The order in which work is attempted decides whether the difficult parts are ever reached at all.

Programmes are usually planned as portfolios: a list of workstreams, each with a business case, running in parallel under a steering group. The plan is defensible and the failure is predictable. Parallel workstreams compete for the same scarce resource, which is not budget but the attention of the few people who understand how the current system actually works. Those people are finite, they are already fully committed, and no amount of funding creates more of them within the programme's lifetime.

What changed, and why it matters now

The shape of the failure is consistent. The first two quarters produce visible progress: a new portal, a migrated report, a redesigned journey. Around month nine the programme reaches something structural — an identity model, a data contract, a process that spans three departments — and slows sharply. By then the early wins have been reported as evidence that the approach works, the sponsor has moved on, and the difficult work has to be justified again from a weaker position. The programme is not behind because the hard part is hard. It is behind because the hard part was scheduled after the credibility was spent. There is usually a documentary trace of this. The month-nine steering pack introduces a new workstream for foundations or enablement, which is the programme discovering, in public, that the thing it deferred is now blocking everything else. That pack is worth reading closely in any organisation about to start a second attempt, because the second attempt almost always repeats the sequence while changing the delivery partner.

Build the operating model

Sequence the programme so that one structural constraint is removed early, funded by a narrow visible win rather than by a portfolio of them.

Identify the constraint that the most workstreams depend on and do it first, even though it demonstrates poorly. This is usually identity, a canonical data definition, or the release process itself. The test is mechanical: list every planned workstream, mark which ones cannot finish until a given change lands, and start with whichever change has the most marks. It will not be the item with the best business case, because structural work never has one — its benefit is that it makes eight other things possible, and no single business case can claim that without double-counting.

Measure what the decision produced

Measure lead time for a representative change, the number of teams that can ship without coordinating, and the proportion of work blocked on a single team.

Lead time is the honest measure because it cannot be improved by reporting. Pick one representative change — a price update, a new field, a permission grant — and measure it end to end before anything begins. Re-measure the same change quarterly. If it has not moved, the programme has been delivering artefacts rather than capability, regardless of how many workstreams show green. The blocked-work proportion is the companion measure: when it falls, coordination cost is genuinely dropping, and that is the only durable form of transformation value.

Where execution breaks

The dominant risk is a programme that optimises for demonstrable progress, which systematically selects the work that shows well over the work that unblocks.

A second risk is treating the operating model as a deliverable. New team structures and decision rights are published, the org chart changes, and the actual routing of decisions does not, because the informal path was faster and nobody removed it. The published model then becomes a source of confusion rather than clarity: two routes exist, one official and one real, and new joiners learn the real one within a fortnight. If the old path is not closed, the new one has not been adopted, and no amount of communication substitutes for closing it.

What this looks like in practice

In practice a programme that works often looks slow for two quarters. One constraint is removed, one narrow customer-facing improvement ships to prove the route end to end, and the rest of the portfolio is explicitly deferred rather than run in parallel at reduced staffing. The deferral is the discipline. It is also the part that is hardest to defend in a steering meeting, because deferring six workstreams reads as lack of ambition, and running all six at a third of the required capacity reads as delivery. The defence that tends to work is arithmetic rather than rhetorical: name the three people every workstream depends on, show their committed hours, and let the steering group allocate them explicitly. Once the constraint is visible as a named individual rather than as an abstract capacity figure, the conversation changes from what should we do to who is doing it, which is the question the plan was avoiding. It is worth writing the deferral down as a dated decision rather than leaving it as an omission from the plan. Workstreams that were never formally deferred tend to reappear halfway through the quarter with partial staffing attached, and nobody can point to the moment the decision was reversed because there was never a decision to reverse.

The strongest argument against this

The serious objection is that sequencing this way concentrates risk. If the structural change is wrong, the programme has spent its early credibility on an invisible bet and has nothing to show. Portfolios exist precisely to spread that risk, and in organisations where sponsorship is unstable or leadership turns over frequently, visible early wins are not vanity — they are what keeps the programme alive long enough to matter.

That objection is strongest where the sponsor is weak and weakest where the constraint is well understood. The honest position is that sequencing structural work first requires a sponsor who can absorb two quarters of unimpressive reporting. Where that sponsor does not exist, the portfolio approach is not wrong; it is a rational response to a political constraint, and it should be named as that rather than defended as a delivery strategy.

A 30-day implementation sequence

List every planned workstream, mark the dependencies, and start with the single change that unblocks the most. Defer the rest explicitly and in writing.

Month one, measure lead time for one representative change and publish the number. Month two, map dependencies across the portfolio and identify the most-blocked constraint. Months three to five, remove that constraint and ship one narrow user-facing improvement through the new route to prove it works end to end. Month six, re-measure lead time against the same change, publish the comparison, and use it to re-open the deferred workstreams in dependency order.

Re-measure the same change, not a new one

Keep one representative change as a fixed instrument for the life of the programme. The temptation each quarter is to choose a newer, more favourable example, and it should be resisted, because a moving benchmark makes progress unfalsifiable. Record the measurement conditions alongside the number: who made the change, which approvals were needed, how long each wait was. When the total falls, the record shows which wait disappeared, which is the difference between an improvement you can repeat and one you observed.

Review quarterly, and read lead time next to blocked-work proportion and change failure rate. A lead time that falls while failure rate rises is not speed; it is deferred cost, and it will return as incident volume within two quarters. Change one part of the route at a time so the measurement stays attributable, and keep the previous route documented until the new one has carried a full quarter of real work.

Editorial conclusion

Transformation programmes are not usually short of ambition, budget, or technology. They are short of sequence. The organisations that finish are the ones that spent their first two quarters on something that demonstrated badly and unblocked everything, and were able to survive the meetings in which that looked like slow progress.