A roadmap is the document that turns a decision into a sequence. It answers what happens first, what cannot start until something else finishes, what each stage costs, who owns it, and what would cause the plan to change.
It is not a strategy, and it is not a backlog. A strategy says what you have chosen and why — that is the subject of building an AI strategy, and it needs to be settled before this exercise is worth doing. A backlog is an unordered list of things somebody wants. A roadmap is the commitment in between.
What has to be settled first
Sequencing is only meaningful once four things are decided. If any is still open, the roadmap will be rewritten every time it is discussed:
- The business objectives, and which are more important than which.
- Which uses are in scope and which are explicitly excluded.
- Whether each area is being bought, built, or deliberately deferred.
- What success will be measured by, with a recorded baseline.
Alongside those, the roadmap needs the findings from a readiness assessment — because most of the real sequencing constraints are gaps, not ambitions.
Map the dependencies before you draw any timeline
This is the step that distinguishes a roadmap from a wish list in date order, and it is usually skipped.
Take each intended outcome and work backwards, asking repeatedly: what has to be true for this to work? An assistant over internal documentation requires that the documentation is current, that it lives somewhere with an API, that access is scoped, and that someone owns its accuracy. Each of those is a piece of work with its own duration, and at least two of them will not be AI projects at all.
Three kinds of dependency are worth separating, because they behave differently:
- Hard technical. B genuinely cannot start until A is done — the integration needs the data model that the migration produces.
- Capacity. A and B could run in parallel in principle, but the same two people would have to do both. In a smaller organization this is the binding constraint far more often than the technical one.
- Decision. B cannot be scoped until someone chooses between two options. These are the cheapest to resolve and the most commonly left to drift.
Write the dependency map down before any dates. Almost always it reveals that the thing everyone is enthusiastic about sits three prerequisites deep, and that the first quarter is unglamorous groundwork.
Phase around dependencies, not around quarters
Calendar phases are convenient and produce plans that slip as a unit. Better to define a phase by what it makes possible, and let its duration be whatever it is.
A shape that works for most smaller organizations:
Phase one — foundations
The prerequisites that unblock more than one later item: access control tightened, one authoritative source established for the data that matters, the governance position agreed, the inventory built. Nothing here is visibly “AI”, which makes it the phase most at risk of being cut — and cutting it is what causes phase two to fail.
Phase two — first value
One use case, one team, deliberately narrow. The purpose is a real result on a real process, plus the organizational learning: whether people use it, whether the review step is workable, what it actually costs at true usage. Choose the candidate with the best ratio of value to dependency, which is often not the most exciting one.
Phase three — scale or extend
Either the same capability to more teams, or the next use case using the foundations already built. This is where the phase-one investment pays back, because the second deployment does not repeat the groundwork.
Two or three phases is usually enough for a twelve-to-eighteen month horizon. A roadmap with seven phases is a backlog with headings.
A roadmap is not a project plan
The distinction matters because the two are often conflated and then the roadmap inherits the wrong level of detail.
A project plan schedules known work: tasks, durations, assignments, a critical path. It is right for something already scoped, and it goes out of date the moment the scope moves. A roadmap operates a level up. It says which outcomes are being pursued in which order and what has to be true between them; it does not schedule the tasks inside a phase, because those are not knowable until the phase is close enough to scope.
Practically: if your roadmap contains items measured in days, it has become a project plan and will need rewriting monthly. If it contains items measured in quarters with no stated dependency between them, it is a wish list. The useful granularity is an outcome with a rough duration and an explicit prerequisite.
A worked first year
The brokerage from the strategy example — forty people, one objective, quotation turnaround — produces something like this:
- Phase one, roughly two months. Consolidate policy documents into one system with an owner; tighten access so the pilot account cannot reach HR or finance; agree the data rules and the review standard. Owner: operations manager. Nothing visible to a client.
- Gate. One authoritative document store exists, access is scoped, and the review standard is written. If not, phase two does not start.
- Phase two, roughly one quarter. Document extraction on renewals for one team of four, manual path kept open, baseline recorded beforehand. Owner: the team lead who will live with the result.
- Gate. Median quotation time down by an agreed margin, no increase in errors at review, per-quotation cost below the current one. Outcomes: proceed, adjust, or stop.
- Phase three. Either the remaining teams, or the drafting half of the objective — decided on the evidence, not in advance.
Note what phase one is: access control and document management. That is what most first phases turn out to be, and it is the reason a roadmap built from ambitions rather than dependencies slips.
Budget by phase, not by year
An annual figure invites the whole amount to be spent on whatever is in front of the organization in month two. A per-phase budget forces the more useful conversation.
Each phase should carry: implementation effort (internal and external), recurring platform cost at realistic volume, and the cost of the review step, which is real work and is routinely omitted. It is also worth recording an explicit contingency for phase one, because groundwork phases are where discovery happens.
Note the recurring costs separately from the one-off ones. A plan that looks affordable as a project can be unaffordable as an operating commitment, and that is much better discovered on the page.
Decision gates that can actually stop things
Between phases, a gate: a written statement of what must be true to proceed, agreed before the phase starts.
A gate is only real if failing it is a permitted outcome. “Review results and plan rollout” is not a gate. “Median handling time reduced by at least fifteen per cent with no increase in escalations, at a per-transaction cost below the current one” is, because it can return a no.
Each gate should name three possible outcomes and who decides: proceed, adjust and re-test, or stop. Recording “stop” as legitimate in advance is what makes it available later, when momentum and sunk cost are pushing the other way.
Owners
Every phase and every dependency needs one named person — not a department, not a shared mailbox. The owner is accountable for the item happening, which usually means they must be able to obtain time from people who do not report to them; if they cannot, the roadmap has recorded an aspiration rather than a plan.
The roadmap as a whole also needs an owner, typically the executive who holds the strategy, supported by whoever carries the technology brief.
What the document contains
Short, and readable by the leadership team rather than only by the people building it:
- The objectives it serves, referenced rather than restated.
- The dependency map.
- Phases, each with the outcome it makes possible, its items, its owner, and its rough duration.
- Budget per phase, one-off and recurring separated.
- The gate criteria between phases.
- What is explicitly deferred, and to when.
- The review date.
That last-but-one item earns its place. A roadmap that lists only what is being done reads as a plan to do everything eventually; one that says what is deferred and why is a plan someone has actually made.
Keeping it alive
A roadmap is a living document or it is wallpaper. Review it quarterly, and at each gate. The quarterly review asks: what has moved, what has slipped and why, what has changed in the business, and does the sequence still hold.
Expect it to change — the market for these tools moves faster than an eighteen-month plan. What should not change every quarter is the objective set. If it does, the strategy was never settled and the sequencing work will keep being wasted.
Communicating it
A roadmap that only the people building it have read will not survive its first budget conversation. Two audiences need different versions of the same document, and producing both is a few minutes' work.
Leadership needs the outcomes, the phases, the money, and the gates — one page. The people doing the work need the dependencies and the owners, because that is what tells them why the boring phase comes first. Publishing the deferred list to both is what prevents the quarterly reappearance of an idea that was considered and declined.
Signs the roadmap is not working
- Nothing is ever crossed off. A plan unchanged after two quarters describes an organization that is discussing rather than executing.
- Phase one keeps getting deferred. The groundwork is boring and invisible, and deferring it is the most common way these programmes fail eighteen months later.
- Every gate passes. Either the criteria were set to be met, or nobody is willing to say no.
- Items have no owner. They will not happen, and the roadmap will not say so.
- The recurring cost was never separated out. The programme will be judged affordable until the renewal arrives.
The governance decisions that phase one usually contains are covered in practical AI governance at this scale, and the adoption sequence for an individual use case inside a phase is set out in taking one use case from idea to deployment.
Need a roadmap you can take to your board? Schedule an AI & Technology Readiness Assessment — the phased roadmap is the deliverable, and it is yours to keep. More on our Virtual CIO and IT consulting services.