Executive Roadmap

An executive roadmap is a document about money and commitment, drawn as a timeline. It's read in ten minutes by people who weren't in any of the working sessions, and it succeeds or fails on whether those people leave with the right facts. This template is built for that constraint: group rollups three lanes deep, a standing governance track, and a structure that follows the funding rather than the work.

Who this executive roadmap template is for

This is for a programme sponsor, a PMO lead, or a project manager reporting into a steering committee. It assumes an initiative with a business case, an approval gate, a delivery phase, and an organisational change at the end — the shape of most funded corporate projects, whether that's a system implementation, a vendor-delivered platform, or an internal transformation.

The audience is explicitly non-operational. They're deciding whether to keep funding this, not how to run it.

What are the phases of an executive roadmap?

Four top-level lanes, one nested three deep, plus a standing track alongside them.

Scope contains two sub-lanes. Business Case holds the work of building the case itself. Budget Approval holds the wait for the decision, running alongside a finance committee review. Separating them is one of the template's most important structural choices — it distinguishes work you control from time you don't.

Execution splits into Vendor & Procurement, Core Build — itself split into Engineering and Integration — and Quality Assurance. Engineering's user acceptance testing starts before the build finishes, which is realistic and usually contentious.

Launch splits into Training and Cutover.

Governance stands apart from the phases entirely: steering committee reviews and executive readouts run the full length of the programme, with the risk register handed off partway through.

Seven milestones: budget approved, vendor selected, build complete, UAT sign-off, the go/no-go decision, cutover complete, and hypercare exit.

How long does each phase take?

About seven and a half months, weighted heavily toward execution.

Scope runs about six and a half weeks: roughly two weeks building the business case, then just over two weeks waiting for budget approval. That second bar is the one people delete, and it's the one that most reliably makes plans late.

Execution is the long middle at roughly twenty-seven weeks. Vendor selection and contracting take about six and a half weeks, the engineering build and its testing run in an overlapping eight and a half weeks, integration takes about five weeks after that, and the independent QA audit sits in a tight five-day window once integration testing is underway.

Launch runs about seven weeks: change management and training for four weeks, then a three-week cutover sequence.

The proportion worth defending in front of a steering committee is that execution alone is more than half the programme. Organisations routinely underweight it in the plan they show executives, front-loading the slide with scoping detail and compressing the build into a single bar — and it's the most reliable predictor of a steering pack that stops matching reality by month three.

Which dependencies matter here?

Nineteen links. Eleven are finish-to-start and form the funding chain: business case finishes then approval starts; approval finishes then the RFP starts; the RFP finishes then vendor selection starts; vendor selection finishes then contracting starts, which finishes before the build starts. Nothing about this chain is negotiable — you cannot select a vendor with unapproved budget.

Six links are start-to-start. Two are worth naming: user acceptance testing begins about three weeks before the core build finishes, and the independent QA audit begins five days after integration testing starts rather than waiting for it to complete — both save real time without skipping the check itself.

One link is start-to-finish: legacy system decommissioning's completion is gated by when cutover starts, not by cutover finishing. This is the link that makes retirement a precondition rather than an aspiration.

One link is finish-to-finish: post-launch hypercare's completion is tied to when decommissioning finishes, keeping support live until the legacy system is genuinely gone.

What to change for your own programme

Common mistakes on executive roadmaps

Treating approval as instantaneous. It has duration, it's outside your control, and omitting it is why so many programmes are late before they start.

Flattening the rollups. The whole point of a three-deep structure under one visible bar is that the executive view stays short while the detail survives underneath. Show all twenty-two tasks at once and the chart stops being an executive document.

Under-scheduling change management. The technical delivery is rarely what makes an implementation fail.

Optimistic progress. Executives remember numbers. A task that's been at seventy per cent for two months is a credibility problem that a chart with no percentages wouldn't have created.

Presenting the current plan with no history. Without a baseline the committee can't tell whether this is the third version of a slipping plan or a stable one, and they'll assume the former.

Getting it in front of the committee

Steering packs are circulated in advance, read on phones, and forwarded to people who weren't invited. Export a PDF for the pack and a PNG for the slide, and regenerate both before each meeting. No recipient needs an account, a login, or any familiarity with the tool — which is what keeps the chart in the pack rather than described second-hand in the minutes.