Catalogue › Programme Management › integrated-roadmap

Integrated roadmap

Integrates every AI programme workstream plan - adoption, Champions, learning, knowledge, platform, agent delivery, governance and value - into one dated delivery plan with milestones, a critical path, cross-workstream dependencies and a baseline that changes only by decision. Use when workstreams plan separately, when nobody can say what the next milestone depends on, or when the strategic roadmap needs turning into a plan people can run.

Department

Programme Management

Lifecycle

Mobilise, Enable, Deliver, Launch

Maturity

adopter, builder, scaler, ai-enterprise

Risk tiers

0, 1, 2, 3, 4

Platforms

platform-neutral

Editions

starter, scale, enterprise

Reviewers

none

Status

draft

Copilot Cowork

Programme Management plugin for Copilot Cowork, or this skill on its own: Download SKILL.md

Licence

CC BY 4.0, by Simon Foote

Purpose

The strategic AI roadmap says what will happen in which horizon; a programme also needs a plan that says what happens in which week and what each milestone waits for. This skill integrates the workstream plans into one dated delivery plan with milestones, a critical path and the dependencies between workstreams, and sets a baseline that changes only by decision. Integrated plans go wrong when they are a stapled collection of workstream plans, when the dates come from hope rather than capacity, or when they track activity and lose sight of the outcomes the roadmap serves.

When to use

• A programme has been chartered and its workstreams have drafted their own plans.
• Workstream leads disagree about when something will be ready, or discover late that they were waiting on each other.
• The strategic roadmap needs turning into dated milestones for the next one or two quarters.
• A launch date has been proposed and someone needs to show what must be true by then.
• The plan has slipped and needs re-baselining with the board's agreement.

When not to use

• Sequencing initiatives across horizons against strategic outcomes - use ai-strategy:ai-roadmap.
• Managing an individual dependency with its giver and receiver, including Microsoft release changes - use programme-management:dependency-management.
• Recording the risks and issues the plan reveals - use programme-management:programme-risk-log.
• Planning one Copilot launch in detail by persona and wave - use copilot-adoption:launch-plan.
• Planning the CoE's own launch phases - use ai-centre-of-excellence:coe-launch-roadmap.

Questions to ask first

1. Which strategic roadmap initiatives fall within this programme's charter, and which horizon is committed?
2. What plans do the workstreams already have, at what level of detail, and who owns each?
3. Which dates are fixed by something outside the programme (a licence renewal, a contract, a business event, a regulator), and which are targets?
4. Which scarce roles (business owners, knowledge owners, reviewers, makers) do several workstreams need at the same time?
5. Who can approve a change to the baseline?

Required inputs

• The signed programme charter from programme-management:programme-charter, with workstreams and tolerances.
• The strategic roadmap from ai-strategy:ai-roadmap, showing initiatives, horizons and foundations.
• Each workstream's draft plan, however rough, with its owner.
• Declared capacity for scarce roles from programme-management:budget-and-capacity or the ownership map.
• Programme stage gates from programme-management:stage-gates, so gate dates sit on the plan.

If a workstream has no plan, record its milestones as [To confirm: ...] with the owner who will supply them, and show the gap on the plan rather than inventing dates.

Decision framework

Integrate at the level of milestones, not tasks. A milestone is a verifiable state ("knowledge sources for the HR agent have owners and a review date"), not an activity ("work on knowledge").

Typical cross-workstream links worth checking in every AI programme:

Practitioner approach

Collect the workstream plans as they are and do not rewrite them. Ask each lead for their milestones over the committed horizon, the definition of done for each, and what they need from others. The integrated plan sits above the workstream plans; it does not replace them, and workstreams that feel their plans have been taken over stop maintaining them.

Lay the milestones on a single timeline grouped by workstream, then walk the dependencies. For each milestone ask "what must be true before this can happen, and who makes it true?". Most AI programme slippage comes from the same few links: an agent cannot be tested because knowledge owners have not cleaned the content, a Copilot wave cannot launch because the support route is not ready, a benefit cannot be shown because nobody measured the baseline. Draw these links explicitly and give each one to programme-management:dependency-management to track.

Find the critical path to the next stage gate or launch and say plainly which milestones are on it. These get weekly attention; everything else is reviewed at the workstream meeting. If the critical path runs through a single scarce role, such as the only security reviewer, that is a capacity risk to record, not a scheduling detail.

Test the plan against capacity before anyone sees dates. Add up what each scarce role is committed to by month and compare it with what they have declared. Business owners and knowledge owners are usually more constrained than makers. Where demand exceeds supply, move milestones or reduce scope; do not assume people will stretch, and keep time for supporting what has already been released.

Show confidence honestly. Fixed external dates appear as dates; everything else gets a target with a range until the work is understood. Product-dependent milestones carry a note of the capability relied on and the source record checked, because Microsoft release timing is outside the programme's control.

Agree the plan at the programme board and baseline it. From then on, report progress against the baseline, forecast honestly, and bring changes beyond tolerance to the board as decisions rather than quietly moving dates. Re-baseline at each stage gate, and keep the link back to ai-strategy:ai-roadmap so a change in the plan that affects an outcome is visible to the people who own the strategy.

Outputs

• An integrated delivery plan: milestones by workstream with owner, definition of done, evidence, fixed or target date and confidence, built from the initiatives in the ai-roadmap template.
• A critical path to the next gate or launch, with the milestones on it named.
• A capacity check by scarce role and month, with the actions taken to resolve overload.
• A baseline record and a change log of approved re-baselines.

Microsoft platform considerations

Milestones that depend on a Microsoft capability, a release wave or a licence change are marked as such, with the capability relied on and the source record checked. Do not schedule against a feature's expected availability from memory; check references/sources.md and track the link through programme-management:dependency-management.

Adoption considerations

Give adoption milestones the same standing as build milestones. Plans dominated by technical go-lives tend to schedule launches without the communications, Champions and manager enablement that make them land.

Knowledge considerations

Treat knowledge readiness as milestones with owners, placed before the agent and Cowork milestones that need it. Content clean-up routinely takes longer than build, so give it its own confidence range.

Security and privacy considerations

Reviewer slots for security-privacy and, where needed, privacy assessment are booked milestones on the plan, not assumed. Store the plan with programme records; it should name roles, not individuals.

Responsible AI considerations

For tier 3 and 4 solutions, schedule the responsible-ai review and any risk acceptance decision as milestones on the critical path. A plan that leaves them to the week before launch invites pressure to waive them.

Evaluation requirements

Not applicable to the plan itself; it must show the evaluation milestones each solution needs (evaluation set agreed, results reviewed) before its release milestone, held by evaluation-quality from risk tier 2.

Value measures

Track milestone predictability (share of milestones met within their confidence range) and critical path stability at programme level, reported by the AI Programme Manager to the board. Baseline capture milestones protect the later value case.

Scale notes

Starter

One page: a dozen milestones across three or four workstreams over a quarter, with the main dependencies drawn and a monthly check at the working group.

Scale

A milestone plan per workstream rolled up into one integrated view, a named critical path, a capacity check by month and a formal baseline agreed at the programme board.

Enterprise

Integrated plans per tranche and business unit rolled up to a programme view, with a planning office maintaining the baseline and cross-unit dependencies reviewed at the portfolio board.

Hand-offs

• To programme-management:dependency-management for each cross-workstream and external dependency.
• To programme-management:programme-risk-log for risks and issues the plan reveals.
• To programme-management:programme-board-cadence for baseline approval and change decisions.
• To programme-management:programme-health for schedule health reporting.

Reviewer gates

Not applicable, because the plan releases no solution; it schedules the security-privacy, evaluation-quality, responsible-ai and design-authority reviews its solutions need, from the risk tiers those departments set.

Failure modes

• Workstream plans are stapled together and nobody owns the links between them.
• Dates are set top-down from a launch announcement and the capacity check is skipped.
• Knowledge readiness is missing from the plan, so agent testing stalls on content nobody has cleaned.
• The baseline moves quietly every month and the board loses any sense of slippage.
• Milestones depend on a Microsoft feature assumed from memory that arrives later than planned.

Sources

references/sources.md in this skill lists the source records behind this skill, what each is authoritative for, how volatile it is and what you may do with it. Product availability, licensing, limits and preview status change often, so check the current source before stating them, and cite what you used.

Never

• Invent dates or milestones for a workstream that has not supplied them.
• Commit a scarce role beyond its declared capacity.
• Move the baseline without a recorded decision.
• Schedule against Microsoft product availability from memory.