AI Roadmap and Transformation: Sequencing the Work When Budget is Real

The pivot I remember most clearly happened on a Tuesday in October, fourteen months into a fractional engagement with an EU bank. The strategy was sound. The roadmap was wrong. We had sequenced data platform first, MLOps second, the first customer-facing application third, on the rational-sounding argument that the foundations had to come before the building. By month fourteen the data platform was 80% done, the MLOps work was 50% done, and the customer-facing application had not started. The CFO asked, reasonably, what the programme had shipped to customers. The honest answer was nothing. We cut the roadmap that week, brought one application forward, accepted that the platform would be built underneath it rather than before it, and shipped the first version four months later. The platform finished about the same time it would have anyway. The difference was that we had a real customer to design for instead of an imagined one.

That is what a roadmap is for. It is not a Gantt chart of the work in dependency order. It is the sequencing decision that determines which audience you are designing for at each step. Get the audience right and the dependencies sort themselves; get the audience wrong and the most beautiful dependency graph in the world produces a platform with no users. The technology-leadership literature has known this since at least Conway’s law in 1968, but every generation re-learns it on its own AI programme.

Why roadmap is its own cluster, not a section of frameworks

The frameworks cluster decides what an AI strategy contains. The maturity cluster decides where you are. The roadmap cluster decides in what order to do the work, and it is genuinely a different question from the other two. A perfectly written strategy document with a defensible maturity assessment can still produce a failing programme if the sequencing is wrong. The reverse is also true; I have seen two programmes recover from weak strategy documents because the operator running the roadmap was decisive about cutting workstreams when the data turned. The roadmap is where the strategy meets the calendar, and the calendar is unforgiving in a way the strategy document never is.

The other reason this is a separate cluster: the word “transformation” has been doing a lot of work in the AI consulting market for the last three years, and most of what it covers is roadmap work. AI transformation strategy, AI transformation framework, guide to AI transformation — these are different keyword variations on the same question, which is how do we sequence the work. Treating it as a separate hub lets us answer that question directly instead of letting it bleed into the strategy document or the maturity model.

The budget transition that kills programmes

The single most predictable failure point in enterprise AI work, across the dozen programmes I have audited and the three I have run end-to-end, is the transition from discretionary to operating budget. The pattern is uniform enough to be diagnostic.

Year one, sometimes year two, of an AI programme is paid for by something that is not the year-on-year operating cost base. Usually a CEO’s office-of-innovation fund, sometimes a marketing budget that got reframed, sometimes a one-off capex line under digital transformation. The funding is generous, the success criteria are soft, and the team enjoys it. Toward the end of year one or two, the funding source asks the obvious question: can this go into the operating cost base now, or do we keep funding it from this bucket forever. The answer is almost always we cannot afford to keep funding it from this bucket forever. The transition begins. It is the most expensive moment in the programme’s life, and the most under-budgeted.

The mechanism is structural. Discretionary funding tolerates roughly twice the cost-to-value ratio that operating funding does, because discretionary funding is judged on optionality and learning value as well as direct return. Operating funding is judged on direct return alone. Programmes that have been operating on the discretionary cost model — heavy use of premium-tier model APIs, generous consulting spend, no real focus on inference cost per query — suddenly have to halve their unit economics in six months. The teams that anticipated this transition halve them by re-engineering the cost stack: cheaper models for the same task, caching, batch inference where possible, fine-tuned smaller models replacing prompted larger ones. The teams that did not anticipate it lose the programme.

The roadmap document is the place this transition lives. It belongs at month nine of an eighteen-month plan, with the cost-engineering work explicitly funded in months six to nine, the operating-budget conversation explicitly scheduled in month ten, and the success criteria for the transition explicitly stated. Most roadmaps I read treat it as an event that will happen but does not need to be planned for. Then they are surprised when it does.

The detail and the cost-engineering tactics live in the transformation guide and the enterprise roadmap development page. Read those before the month-nine review, not after.

Six months, eighteen months, thirty-six months

The right roadmap horizon for an enterprise AI programme in 2026 is eighteen months at the outside, with a hard checkpoint at six months and a soft refresh at twelve. I no longer believe in thirty-six-month AI roadmaps, and I write them only when the board demands one for accounting reasons. The mechanism is dull: model capability is shifting on a roughly six-to-nine-month cadence, the tooling ecosystem is consolidating on a roughly twelve-to-eighteen-month cadence, and the unit economics of the underlying model providers are shifting more often than that. A thirty-six-month roadmap written in mid-2026 is making three to four full cycles of capability assumptions, every one of which is wrong with high probability.

This is not a counsel of despair, and it is not a counsel of perpetual agility theatre. Long-horizon planning is real and necessary. But the long-horizon document should be the strategy, which holds for two to three years because it is about decisions (posture, cost ceiling, timeline pressure, failure tolerance), not about specific capabilities. The roadmap should be six months in detail, eighteen months in outline, and refreshed every six. The decisions hold; the work plan turns over.

The transformation-strategy framework piece at /transformation/framework/ lays out the six-month milestone shape I use, with the four required checkpoints and the two optional ones. The short version: a six-month roadmap should ship at least one capability that a real customer or operator uses by month four, with the remaining months reserved for either scaling that capability or building the next one. Six months with no shipped capability is a research project, not a roadmap.

Phasing by use case, not by workstream

The most common architectural mistake in AI roadmap development is phasing by workstream — first the data platform, then MLOps, then governance, then the applications layer — on the argument that the foundations have to come before the building. The argument sounds right and is wrong. Phasing by workstream produces platforms with no first customer. By the time the applications team has something to ship, the platform was built for an imagined application that no longer matches the real one. The platform is then either retrofitted at considerable cost or quietly abandoned and rebuilt under the actual application’s requirements.

The alternative is to phase by use case. Pick the application that is going to fund the first year of the programme — usually an internal productivity tool, sometimes a customer-facing assistant, occasionally a credit-decision or fraud-detection use case — and build the platform underneath it. The application has a real customer, real performance requirements, real cost constraints. The platform shaped around it is the right shape, even if it is not the architecturally pure shape. The second use case extends the platform; the third use case is where you start refactoring for genuine reuse. By use case three, you have a platform with three real applications running on it, which is the only honest way to know what reuse means.

This is not new advice — Conway and Brooks and most of the platform-engineering literature have been arguing it for forty years — but the AI variant of it gets re-disputed every programme because the data-platform vendors have an interest in arguing for foundation-first sequencing. The structural conflict is the same one you see in governance tooling: the vendor selling the foundational layer benefits from the foundational-first roadmap, regardless of whether the foundational-first roadmap benefits the buyer.

The enterprise AI roadmap development page goes into the use-case-first sequencing in detail, with the three patterns I have seen work and the two that fail.

Mid-programme pivots and how to make them cheap

Every AI programme I have run has pivoted at least once mid-flight. The good ones pivot cheaply because the roadmap was designed for it. The bad ones pivot expensively because the roadmap was designed as a contract.

The design choice that makes pivots cheap is this. Each six-month roadmap chunk should have a single load-bearing assumption that, if it turns out to be wrong, kills the chunk. The assumption should be written down in the roadmap document. The data that would falsify it should be named. The decision-maker who would make the kill call should be named. If, at month three of the six-month chunk, the data shows the assumption is wrong, the chunk ends — and the team has already been told this might happen, so the news is not a betrayal. The pivot costs three months of work, not nine, and the team’s trust in the document survives.

The bad version of this is the roadmap as a contract between the AI team and the board. The team commits to a deliverable at month six. The data turns at month three. The team continues to month six because cancelling would be a political loss. The deliverable ships, lands flat, and the next roadmap conversation is more cautious and worse. The contract framing produced exactly the failure it was supposed to prevent. The fix is to write the assumption-kill criterion into the roadmap at the start, before any commitment has been made, and to make stopping a programme look like operational discipline rather than failure. Most boards I have seen accept this framing when it is offered honestly. The few that do not are the boards you should not be running an AI programme for.

Where to go next

If you have a strategy document and are now sequencing the work: read the transformation guide, then the enterprise roadmap development page, then the transformation framework for the milestone shape.

If you are mid-programme and the month-nine budget transition is approaching: the cost-engineering section of the transformation guide is the place to start, and probably should have been started six months ago. It is not too late, but it is later than ideal.

If you are pre-strategy and reading this because somebody told you to write an AI roadmap: stop, write the strategy first using the four-question diagnostic, then come back. A roadmap without a strategy is a Gantt chart pretending to be a plan, and the gap will surface in the first board review.

If you have been handed an “AI transformation” mandate and are not sure how it differs from the AI strategy work that already exists: it does not differ in any meaningful way. Treat the two as the same project, with the transformation language reserved for the sequencing-and-execution half. The roadmap cluster is where that half lives.

---

Sources & methodology

• Microsoft Cloud Adoption Framework — AI workloads — sequencing patterns
• Gartner, “AI Roadmap Templates and Use Case Sequencing,” 2026 refresh
• Conway, M. E. (1968), “How do committees invent?” — the law underneath every platform-vs-application sequencing argument
• Brooks, F. (1975), “The Mythical Man-Month” — still the right reference for late-programme staffing decisions on AI work
• Methodology: the six-month checkpoint shape and the assumption-kill criterion template are CC-BY-4.0, linked from /transformation/framework/

If a claim looks wrong, send it and I will publish the correction with attribution.