What a 12-month AI transformation roadmap actually looks like

Why the roadmap starts with a baseline, not a tool

Most AI roadmaps we see start in the wrong place: a list of tools to roll out, with dates. That ordering guarantees trouble, because until you know how your people currently work, which tasks eat their week, and how capable they already are with AI, you cannot say which tool matters or what a win would even look like.

A realistic 12-month roadmap starts with measurement. Before anything is bought or announced, you establish a baseline: who uses AI today, how well, on what, and where the biggest pockets of repetitive work sit. Everything after that is sequenced against the baseline, which is also what lets you prove progress at the end. This is the core of how we approach AI transformation planning.

One framing note before the month-by-month detail. The roadmap below is a shape, not a script. A 40-person firm can move faster than the quarters suggest; a regulated 2,000-person business will need longer in the activation phase. What stays constant is the order: measure, build foundations, activate department by department, then scale and prove. Reordering those steps is where most of the pain comes from.

Quarter one: diagnose, then win small

The first quarter has two jobs. The first is the diagnostic: a maturity assessment across the teams in scope, interviews with department heads, and an honest inventory of the tools people already use, including the unofficial ones. You are looking for the gap between what leadership assumes and what actually happens at desks.

The second job is quick wins. Pick two or three workflows that are painful, frequent, and low-risk, and get AI working on them within weeks. The point is not the time saved, though that helps. The point is a visible, internal proof that this programme produces results, which buys you patience for the slower quarters. Choosing well matters, and we've written a separate guide on which workflow to automate first.

Quarter two: foundations

With the baseline done, quarter two builds the things that every later quarter depends on:

• A usage policy people can actually follow: what data goes in which tool, where human sign-off is required, and what is banned.
• Tool decisions made against the diagnostic, not against vendor demos. Fewer tools, properly rolled out, beats a wide portfolio nobody masters.
• Core training for the first wave of teams, hands-on and built around their real tasks rather than generic prompting theory. This is where structured AI training earns its place in the plan.
• A named owner with time and authority. A roadmap without a single accountable person is a wish list.

Foundations feel slow from the outside. Skipping them is how organisations end up a year in with wide licence coverage and thin usage.

Quarters two to three: department activation

From late quarter two into quarter three, the roadmap moves department by department rather than everywhere at once. Each activation follows the same shape: map the department's highest-value workflows, train the team on those specific workflows, appoint one or two internal champions, and set a usage and value check four to six weeks out.

Sequencing matters. Start with departments that combine willing leadership and measurable work, often operations, marketing, or finance, and let their results recruit the sceptics. Trying to activate every function simultaneously spreads support too thin, and thin support is one of the main reasons AI pilots fail.

The champions deserve a specific mention, because they are the cheapest lever in the whole plan. One person per department with extra training, a little protected time, and a direct line to the programme owner will surface more use cases than any workshop. Their job is not to be the department's AI helpdesk. It is to notice what colleagues struggle with and feed that back into the next round of training.

Quarter four: scale and prove the return

The final quarter does two things. First it scales what worked: the workflows and training formats that produced results in early departments get rolled out to the rest, with the champions from earlier waves doing part of the teaching. Second, and just as important, it closes the loop on measurement. You re-run the maturity assessment from quarter one and put the before-and-after in front of the board.

The comparison against the baseline is the whole argument for year two funding. Hours saved on named workflows, adoption rates by department, quality and error changes where they can be checked. If quarter one was done properly, this quarter is straightforward. If it was skipped, there is nothing to compare against, and the programme's fate rests on anecdotes.

Quarter four is also when you write the year two plan, and it should look different from year one. The diagnostic phase shrinks, because you now have live measurement. The training shifts from foundations to deeper, role-specific work. And the ambition moves from adoption to redesign: not people using AI inside existing workflows, but workflows rebuilt around what AI makes possible.

What a good roadmap document contains

The document itself should be short enough that people read it. Ours typically fit the essentials on a handful of pages:

• A named owner and a steering rhythm (a monthly review is usually enough).
• The baseline: maturity scores, current usage, and the workflow inventory.
• Per quarter: which departments, which workflows, what training, and what gets measured.
• The guardrails: data rules, sign-off points, and the escalation path when something goes wrong.
• The success criteria agreed up front, so nobody moves the goalposts in month eleven.

What it should not contain is a long tool shopping list or a promise of transformation by a fixed date regardless of what the diagnostic finds. If you want help building one against a real baseline, that is exactly what our transformation planning engagement is for.