Most technology transformations start too big

Big programmes often deliver their value last. How to start with one result you can measure, and let each delivery earn the next.

Large technology programmes often open with a target architecture, a multi-year roadmap and an impressive number of workstreams. The plan looks thorough, and that is part of the problem. A plan of that size defers most of its value to the end, and the end date tends to move.

For a PE-backed or mid-market business, the timetable is not open-ended. The value-creation plan has dates in it, and every quarter spent on foundations is a quarter without a result. The better question is what the business can have in its hands first.

Why big starts slow delivery

A 2012 McKinsey study with the University of Oxford looked at more than 5,400 IT projects. Large ones, with budgets above $15 million, ran 45 per cent over budget on average and delivered 56 per cent less value than predicted.

Size works against a programme. The most important decisions come first, when the business knows least. Workstreams depend on each other, so one late dependency holds up several teams. And the programme runs long enough that the people who made the early decisions may have moved on before anyone uses the result.

Size also hides progress. Status reports can show every workstream on track while nothing reaches a customer or a user. By the time the first release lands, the business has changed, and the plan describes the business as it was.

Start with one result you can measure

• Pick one outcome that matters to the plan and that a user will notice:
  The time to issue a quote, the share of orders that need manual work, the days it takes to bring an acquired business onto the group's systems. Each names a result someone could check.

• Then define it precisely:
  Who uses it, what they need to do, which systems it touches and how you will know it worked. A thin slice through the real systems teaches more than a broad layer of foundations, because it meets the data, the integrations and the people as they are.
  
  

• The first result also tests the way you work:
  You find out how the business makes decisions, where access stalls and which assumptions in the roadmap hold up. That evidence is worth more than another month on the roadmap.

Define it, then build it in a straight line

Precision matters more now than it did. AI writes code quickly, so a vague brief no longer costs weeks of discussion; it costs a finished product that does the wrong thing. Spend the effort up front. Put a senior business lead and an engineer with the people who decide, write down what the result must do, and test it on a prototype before the full build starts.

Once the brief holds, keep the build in motion. Agree milestones that each deliver something usable, and tie the commercial terms to them, so the supplier carries more of the risk of delay. When something needs to change, put the change straight into the work rather than into a queue.

A small, senior team can carry a result like this from definition to launch. More engineers help most once the work is clear.

Let each result earn the next

When the first result is live, decide the next one from what it taught you. Some of the roadmap will look more urgent, some less. Keep a target architecture as a direction, and let real use shape the detail.

This is not a case against ambition. A business can still change a great deal over a hold period, one measurable result at a time, and let each step fund the next. The difference is that the plan no longer rests on one large delivery at the end.

Before you approve the next multi-year roadmap, ask what the business will have in its hands at the end of the first quarter. If the answer is a design document, start smaller.