Transformation stalls on people and approvals.

With one domain that has a named owner and a problem worth fixing. Breadth in the first phase is what kills these programmes: budget goes on coordination, nothing reaches production, and the case for continuing rests on a slide. Starting narrow gives you something running inside a quarter, and a working system is a far better argument for the next phase than a business case.

The deliverable is running software. Strategy is part of it, but what you receive is a system your staff use, and the same team does both. That matters because a plan written by people who will never have to build it tends to underestimate exactly the parts that turn out to be hard.

Usually less than you expect. The systems that feel oldest are often the ones quietly working; the constraint is more often an integration, a manual handoff or a reporting gap. We look for what is actually blocking the business before proposing replacement, because a rewrite spends a year buying back the position you already hold.

The first domain should reach production inside a quarter, and if a plan cannot show something running by then it is usually too wide. Longer programmes are structured as a series of those, each one delivering on its own, so the value does not sit behind a single distant date.

Then the programme has failed, whatever the software does. Adoption is designed in from the start: we work with the people doing the job, keep the change small enough to learn in a day, and agree in advance what the old way stopping actually looks like. Where a workflow cannot survive contact with the people using it, better to find out in week three.

Yes, and it is common. The split usually falls between a partner running long-cycle platform work and us taking the parts that need to move faster or sit closer to the business. What matters is that ownership of each interface is written down, because unowned boundaries are where these programmes lose months.

Against something the business already tracks, agreed before the build starts. Cycle time, cost to serve, error rates, the volume of a manual process removed. We take the baseline first, which is the step most often skipped and the reason so many programmes cannot say afterwards whether they paid for themselves.