We've reviewed a lot of transformation roadmaps that were handed to us mid-programme, usually because the original one had quietly stopped being followed. Almost all of them shared the same shape: a polished slide deck with five strategic pillars, a two-year timeline, and no clear answer to the question 'what happens next Tuesday?'
A roadmap that ships isn't the one with the best vision statement. It's the one that survives contact with a real quarter — competing priorities, a vendor that's three weeks late, a stakeholder who changes their mind. Here's what that actually takes.
Most roadmaps start from an aspirational end state — 'a unified customer platform,' 'data-driven decision making' — and work backwards. That's the wrong direction. Start from the specific, named things that are currently broken: the order system that requires three manual reconciliations a week, the reporting process that takes a finance analyst four days a month, the support queue nobody owns after 6pm.
Naming the actual problem does two things a vision statement can't. It gives you a way to measure whether the transformation worked, and it gives the people doing the work something concrete to aim at instead of a slogan.
The default way to structure a roadmap is by department — a workstream for sales, one for operations, one for finance. It looks organised on a slide, but it hides the thing that actually determines your timeline: dependencies between systems and teams that don't respect department boundaries.
If the new CRM depends on a data migration that depends on a legacy system being decommissioned that depends on a vendor contract renewal — that's your critical path, and it cuts across three departments' roadmaps. Map dependencies before you assign workstream owners, or you'll discover the real sequencing six months in, usually at the worst possible time.
'Phase 1: Discovery — Q1' is not a milestone, it's a calendar entry. A milestone that means something has a named owner accountable for it, and a demonstrable output — something a stakeholder can look at and say 'yes, that's done' without taking anyone's word for it.
This sounds like a small change in wording. In practice it's the difference between a status report that says 'on track' for three straight months and one that actually tells you something.
The build is usually the easier half. The harder half is getting the people affected by the change to actually use it — and it's the half that gets cut first when a programme runs over budget. If your roadmap doesn't have a line item for training, communication and a rollout plan with a fallback, the software will ship and adoption won't happen, which from the business's perspective is the same as not shipping at all.
A rule of thumb we use: if a change affects how more than twenty people do their job day to day, plan for change management to be at least fifteen to twenty percent of the total programme effort, not an afterthought squeezed into the final two weeks before go-live.
The single most common reason we see programmes stall isn't a technology problem — it's that no one person is accountable for how the pieces fit together. Each team owns their workstream, delivers their piece competently, and the integration between pieces falls into a gap nobody was watching. A programme lead whose only job is the whole picture — dependencies, vendor coordination, stakeholder reporting — is not overhead. It's usually the cheapest insurance against a six-month slip.
If you're staring at a roadmap that's stalled, the fix is rarely 'work harder on the current plan.' It's usually naming the actual blockers, re-sequencing around real dependencies, and giving someone clear accountability for the whole thing rather than their slice of it.
This is what our project management & digital transformation work covers day to day. Tell us where you're stuck and we'll give you an honest read on it.
