C2. Roadmap and Rollout
Chapter C1 defines which phases are traversed with which gates.
What this chapter delivers: the translation into a concrete, prioritized implementation plan with milestones: which use case starts when, in what order, with what resourcing, and which enablement work has to run in parallel. The chapter describes how the roadmap is constructed, communicated, and kept alive.
Where the roadmap gets its inputs
The roadmap does not invent a new goal; it plans the delivery of one already decided. Four inputs must be settled before the first wave is planned, and each was worked out in its own chapter. If you find a gap here, close it first: a roadmap built on unsettled inputs is built on sand.
| Input | What must be settled | Worked out in |
|---|---|---|
| Business benefit | Which areas should benefit most and what level of ambition applies | Chapter B1 |
| Technology foundation | Scalable architecture with a data platform, MLOps and LLMOps capabilities, security, and clear integration paths | Chapter B5 |
| Organization and competencies | Operating model, clear roles, and governance for ethics, compliance, and security | Chapters B6 and B7 |
| Culture and acceptance | AI as support rather than threat; enabled employees, active involvement | Chapter B11 |
Prioritized implementation planning: quick wins vs. strategic bets
The prioritization matrix from chapter B2 (value × feasibility) determines not only what gets implemented but also in what order. A simple sequencing rule applies for the roadmap:
| Roadmap horizon | Contains | Purpose |
|---|---|---|
| Short term (quick wins) | Lighthouses first: high value, high feasibility | Secure visible wins, build trust and budget for the next wave |
| Medium term (fillers) | High feasibility, lower value score | Utilize capacity, let platform building blocks mature through reuse |
| Long term (strategic bets) | High value, low feasibility | Prepare deliberately (data, competency, architecture), start only once obstacles are removed |
Rule: every roadmap wave combines mostly quick wins with at most one carefully prepared strategic bet. Never several strategic bets in parallel, since they disproportionately absorb capacity and attention.
From prioritization to roadmap: five steps
The most common weakness of AI roadmaps is not the selection of use cases but the missing logic behind how they are put together: what is desirable gets planned, not what the available capacity can actually deliver. The five steps prevent that.
Step 1: determine capacity honestly. Before anything is scheduled: how many initiatives can the organization carry in parallel? The limiting factor is usually not ideas or budget, but key people (data engineers, product owners with domain knowledge, approval functions) and the absorption capacity of the business units. Rule of thumb for getting started: 2 to 4 parallel pilots, no more. Whoever skips the capacity question builds a wish list, not a roadmap.
Step 2: cut use cases into waves. The prioritized use cases are split into waves (recommended: one wave per quarter), in the order from the previous section: quick wins first, at most one strategic bet per wave. Each wave takes only as many initiatives as the capacity from step 1 allows. Whatever no longer fits moves into the next wave instead of overloading the current one.
Step 3: derive the enablement track from the maturity gaps. In parallel with the use-case track runs the enablement track (see chapter C1): platform building blocks, data governance, the training program, governance processes. Its content comes from two sources: the gaps of the maturity assessment (see chapter A3) and the dependencies of the planned use cases (if wave 2 contains a RAG system, the knowledge-base infrastructure must be built in wave 1). Enablement work that no planned use case needs and that closes no maturity gap gets cut: it is the most common source of the platform-first trap.
Step 4: schedule dependencies and milestones. For each wave, milestones are set, each with a date, a gate point, and a responsible person (fields per wave in the section Roadmap structure). Dependencies between the two tracks are named explicitly. Every dependency without a fixed delivery date is a risk and belongs in the register (see chapter D3).
Step 5: adopt with budget and communicate. The roadmap is adopted together with the budget (see the anti-pattern “strategy without execution” in chapter C1) and communicated per audience: board (waves, investment, expected benefit), business units (what is coming their way when, what is needed from them), employees (what changes, what support exists, see chapter B11).
Roadmap structure
For every wave (recommended: quarterly), the following is captured:
| Field | Content | Example |
|---|---|---|
| Use cases | Taken from the prioritization matrix, with a link to the profile | “Reply suggestions customer service” (lighthouse) |
| Phase in the process model | Assess, Strategize, Pilot, Scale, or Operate per use case | Pilot |
| Enablement elements | Platform, data, governance, and training work of the wave | Ticket history connection, prompt library v1, customer service training |
| Milestones | Concrete, dated outcomes incl. gate dates | Pilot start March 1, go/no-go decision June 30 |
| Dependencies | On platform, data, other initiatives, with delivery date | Requires connection of the ticket history by February 15 (see chapter B4) |
| Owner | Who delivers the milestone? | Product owner service |
| Resources | Budget and capacity per wave | 120,000 euros, 1.5 full-time equivalents |
Example: first roadmap year (condensed)
The example shows how the two tracks interlock across four waves. It is deliberately kept small: a mid-sized company, entry phase, limited capacity.
| Wave | Use-case track | Enablement track | Gate at end of wave |
|---|---|---|---|
| Q1 | Pilot 1: reply suggestions customer service; pilot 2: internal document search | Model access with logging, AI register, AI policy, basic training for pilot areas | Go/no-go pilots 1 and 2 |
| Q2 | Pilot 1 → rollout customer service; pilot 3: quote drafting sales | Knowledge-base infrastructure (for pilots 2/3), evaluation suite, tier 1 support structure | Go/no-go pilot 3; review rollout 1 |
| Q3 | Company-wide rollout document search; preparation of the strategic bet (claims prediction): data quality | Cost reporting per use case, fairness review process, training wave 2 | Interim maturity measurement (A3) |
| Q4 | Start of the strategic bet as a pilot; handover of rollouts to service owners | MLOps standardization, annual governance review | Go/no-go strategic bet; annual review with the board |
Value of a roadmap: orientation for leadership (where is investment going, what should be expected), transparency for employees, a shared steering instrument between IT, business, and finance, and continuity that prevents AI from being treated as a short-lived trend.
Keeping the roadmap alive
An AI roadmap is not a fixed plan: models, vendors, and regulation change faster than any annual plan. Dealing with that is regulated, not left to chance.
- Fixed review cadence: the Portfolio Board reviews the roadmap quarterly in the portfolio review (see chapter D4): what was delivered, what shifts, what gets cut, what is added.
- Defined re-prioritization triggers between reviews: a failed or postponed gate, a substantial model or vendor change, new regulatory deadlines (see chapter B8), a changed business priority. When a trigger fires, the affected wave is re-cut; the whole roadmap is not thrown over.
- Absorb delays wave by wave: if an initiative is delayed, it moves into the next wave and the freed capacity is filled with a filler. Do not push out all dates: that creates the perpetual-construction-site roadmap nobody believes anymore.
- Versioning: every adopted roadmap version is filed with a date. That keeps traceable what was changed when and why, and the annual review can honestly compare plan and actual.
Typical roadmap mistakes
Even a cleanly planned roadmap fails on recurring patterns. The table gives, per mistake, the consequence and the remedy:
| Mistake | Consequence | Remedy |
|---|---|---|
| Overloaded first wave | Everything starts at once, nothing gets finished, the program loses its credibility within six months | Respect the capacity limit from step 1; better to deliver one wave cleanly |
| Roadmap without an enablement track | Pilots succeed, scaling fails for lack of platform, governance, and skills | Plan enablement elements per wave (step 3) |
| Wish dates instead of dependencies | Milestones burst because data connections and approvals take longer than hoped | Capture dependencies with delivery dates; place buffers at the gates |
| Roadmap as a waterfall fixed plan | Every change looks like failure; the program stiffens against learning | Establish the review cadence and re-prioritization triggers (above) |
| Roadmap without a budget decision | Nice slides, no execution | Adopt roadmap and budget together |
| Roadmap stays internal | Business units are taken by surprise, rumors fill the gap, acceptance drops | Audience-specific communication from adoption onward (step 5) |
Checklist: roadmap ready to start
The checklist verifies that the roadmap is ready for adoption, from capacity to communication:
- All four inputs settled: business benefit, technology foundation, organization and competencies, culture and acceptance
- Capacity determined: parallel initiatives capped, key people named
- Use cases from the prioritization matrix sorted into waves (quick wins, fillers, strategic bets)
- At most one strategic bet planned per wave
- Enablement track derived from maturity gaps and dependencies, planned per wave
- Current phase in the process model determined per use case
- Milestones with dates, gate points, and owners recorded
- Dependencies between initiatives made visible with delivery dates
- Budget and capacity recorded per wave
- Roadmap adopted together with the budget
- Communication planned per audience (board, business units, employees)
- Review cadence and re-prioritization triggers defined
- Handling of delays settled: the initiative moves to the next wave, the freed capacity is filled with a filler
- Every adopted roadmap version filed with a date, so plan and actual stay comparable
- Regular alignment of roadmap vs. actual maturity planned