More Than 65% of Strategic Initiatives Miss Their Goals. Not Because the Strategy Was Wrong.

Translate each ambition into blockers and success conditions, then run every success condition through all 8 business domains before sequencing anything, Proposition Development, Process & Technology, Resources & Capabilities, Partners & Suppliers, Commercial Effectiveness, Value Communication, Customer Insights, and Relationship & Retention. Sequencing before this step just produces a plausible-looking timeline built on assumptions nobody has tested against the whole business, which is exactly what causes roadmaps to unravel a few months in.

Usually a capacity problem, not a strategy problem, roadmaps get built on desired capacity instead of the real, already-committed capacity of the team. The people expected to drive a new initiative are frequently the same people keeping the current business running, and a roadmap that doesn't account for that collision stalls the moment the day job gets busy, which is almost always sooner than the plan assumed.

Sequence by impact, effort, mandatory dependencies, and which actions can run in parallel within the same domain, rather than by whichever initiative has the most vocal sponsor. Mandatory dependencies matter more than most prioritisation exercises give them credit for, an initiative that looks high-impact and low-effort in isolation can still be blocked for months if it secretly depends on three other actions finishing first.

Map dependencies explicitly during the theoretical roadmap stage, before any business cases are built, so the sequencing reflects what actually has to happen first rather than what would be most convenient to start first. Dependencies discovered after a business case is already built and resourced are far more expensive to resolve than dependencies caught while the roadmap is still just a sequencing exercise on paper.

An owner, a deadline, required capacity, dependencies, and a definition of done for every single action, not just a list of initiatives with rough timeframes attached. A roadmap missing any one of these five elements per action isn't actually executable; it's a wish list with a nicer layout, because nobody can be held accountable for delivering something that was never specified precisely enough to check.

Assign an owner at the six-week sprint stage, when each action or cluster gets its full business case built, not earlier, when the action is still too abstract for anyone to meaningfully own it. Assigning ownership too early tends to produce vague accountability for a vague action; waiting until the business case stage means the owner inherits something concrete enough to actually be responsible for.

Label each action as task, project, or programme, add an effort estimate in days, weeks, or months, and sequence numbers where dependent on other actions, so the roadmap reflects realistic timelines rather than optimistic ones. Most roadmap slippage traces back to effort estimates made without this level of specificity, a one-line action item hides wildly different amounts of real work depending on its actual scope.

Consolidate the validated roadmap into one document, after board review, with owner, deadline, capacity, dependencies, and definition of done per action, so nobody is working from a slightly different version circulated three weeks ago. Multiple roadmap versions floating around an organisation is one of the most common, and most avoidable, causes of teams quietly working toward different priorities.

Run every success condition through all 8 business domains; if any domain has zero actions, something is being missed or the target state is too narrow to begin with. A roadmap that never touches, say, Partners & Suppliers or Customer Insights isn't necessarily wrong, but it's worth explicitly confirming that's a deliberate scoping choice rather than a blind spot nobody noticed.

Lock the sequenced order from the theoretical roadmap, it follows from dependencies, not from whoever argues loudest that quarter for their initiative to move up the list. Priorities that shift constantly usually aren't responding to genuinely new information; they're responding to whoever has the most political capital that particular month, which a dependency-based sequence is specifically designed to resist.

Tie every action to a specific success condition, which is itself tied to a specific strategic ambition, so the chain from action to outcome is traceable end to end, and anyone can ask why a given action exists and get a direct answer. Initiatives that can't be traced back to an ambition this way are usually the first candidates for being quietly dropped when capacity gets tight.

It's likely missing real business cases, effort, resources, risk, and a named owner turn a plan from an intention into a decision, and a roadmap without them is really just a list of good ideas nobody has committed to yet. The gap between a roadmap that looks complete and one that actually drives action is almost always in this level of operational detail, not in the strategic logic.

Each sprint takes one action or cluster and builds it into a full business case: effort, resources, risk, start date, owner, and definition of done, turning a roadmap line item into something a team can actually start executing on day one. Running these sprints sequentially across the roadmap is what converts the theoretical, dependency-based sequence into a set of resourced, owned, and scheduled pieces of real work.

Detail exact effort in time, money and people, required resources and skills, execution conditions, risks and mitigations, start date, owner, and definition of done, the same level of rigour a board would expect for a capital investment decision, applied to every meaningful initiative on the roadmap rather than reserved for the largest one or two.

Run a roadmap review workshop where the CEO and board compare the theoretical and feasible roadmaps and adjust task scope and driver priority, the sequenced order itself stays fixed, since it follows from dependencies rather than preference. What the executive team actually adjusts in this workshop is scope and resourcing, not the underlying logic of what has to happen before what.