How to Sequence a Data and AI Roadmap: What Goes First, and What Waits

A data and AI roadmap should start with three funded business decisions, not with a platform or a model. Sequence the data foundations those decisions need, then the platform capability, then AI in production. Fund it in waves over 90 days, 12 months and 24 months, and release each wave only when the previous one has produced a measurable result.

Most roadmaps that reach a board are lists. They name every initiative the organisation would like to run, shade them across three years, and attach a single large budget. The list is rarely wrong about what matters. It is wrong about order, and order is where the money is lost.

#Why Most Data and AI Roadmaps Fail on Order, Not Ambition

What this means for you: if your roadmap can be read in any order without anything breaking, it is a catalogue, not a plan.

The evidence on outcomes is sobering. McKinsey's 2025 State of AI survey found that nearly nine in ten organisations use AI regularly, but only about 6% qualify as high performers attributing 5% or more of EBIT to it. Those high performers were nearly three times as likely as others to have fundamentally redesigned workflows around AI, rather than adding AI to workflows unchanged.

Gartner adds two forecasts that point at sequencing directly. In February 2025 it predicted that through 2026 organisations will abandon 60% of AI projects unsupported by AI-ready data. In June 2025 it forecast that over 40% of agentic AI projects will be cancelled by the end of 2027, citing cost, unclear value and weak risk controls.

A roadmap is a dependency graph with a budget attached, and most organisations publish the budget without the graph.

Neither forecast describes a technology failure. Both describe work started before the conditions for success existed: models before data, agents before controls, platforms before anyone had agreed what they were for.

#What a Data and AI Roadmap Actually Is

What this means for you: define the roadmap by the decisions it improves and the dependencies it respects, or it will be judged by the projects it starts.

A data and AI roadmap is a sequenced, funded plan that links named business decisions to the data, governance, platform and AI capabilities they depend on, ordered so that each investment builds on one already proven. It is distinct from a technology strategy, which says what you will standardise on, and from a project portfolio, which lists work without stating what each item depends on.

The test is simple. For every item on the roadmap, someone should be able to say which decision it improves, what has to exist before it can start, and what measurable result will release the next item. Items that fail all three questions are wishes. A data strategy that cannot answer them is not yet a strategy either.

#What Goes First: Decisions, Then Foundations

What this means for you: the first 90 days should produce agreement and evidence, not infrastructure.

Start with decisions, because they make every later choice testable. Pick three, no more, where better data or AI would change a material outcome: a pricing decision, a working-capital forecast, a claims triage queue. For each, record the owner, the current baseline and the result that would count as success.

Foundations come next, scoped to those three decisions rather than to the whole estate. That means the specific source systems, the definitions the decisions rely on, quality rules with owners, and lineage good enough to explain a number to an auditor. The reasoning behind putting this layer first, and the four phases it moves through, is set out in our guide to AI-ready data foundations.

#Why the Platform Is Not Step One

Platform procurement is the most common first step and the most expensive one to get wrong. Buying before workloads are known commits the organisation to a cost model, a skills profile and a catalogue design before anyone has tested them. The choice between engines is real, as our Snowflake versus Databricks guide shows, but it should follow ranked workloads rather than precede them.

Governance runs alongside foundations rather than after them. Policies that only exist as documents will be bypassed the first time a deadline is close. Encoding them as checks in pipelines, with data contracts between producers and consumers, is what lets the roadmap scale later without a governance rewrite.

#The Three Horizons: 90 Days, 12 Months, 24 Months

What this means for you: each horizon has a different job, and judging an early horizon by a late horizon's goals kills good programmes.

The 90-day horizon is about evidence. Its output is one decision measurably improved, a data quality baseline for the others, and a credible estimate of what the 12-month horizon needs. If the first 90 days cannot produce one improved decision, the roadmap has a scoping problem that more money will not fix.

The 12-month horizon builds what will be reused. Shared definitions, ideally held in a semantic layer that survives a change of tools, platform capability for the workloads now proven, and the operating disciplines that keep a model working after launch. The last of these is routinely underfunded; our account of what keeps a predictive model running in production covers what it involves.

The 24-month horizon scales. New domains reuse patterns rather than reinvent them, and agents enter only where the controls in our agentic AI readiness framework are in place. This is also the horizon in which legacy systems are switched off, which is where much of the financial case is realised.

#Dependencies That Cross Horizons

Some dependencies take longer than a single horizon and have to start early even though they pay off late. Data ownership is the clearest example. Naming owners is quick; getting them to act on quality breaches, approve definition changes and attend a monthly review takes most of a year. If ownership only starts when the 12-month horizon needs it, the foundations will be built without anyone accountable for keeping them true.

Skills follow the same pattern. A team that will run a new platform, or support models in production, needs hiring or training lead time that rarely fits inside one wave. Contract and procurement cycles do too, particularly in the public sector. The roadmap should show these long-lead items explicitly, starting in the first 90 days with a small budget, so that they are ready when the work that depends on them arrives rather than months afterwards.

#Funding in Waves Tied to Measured Outcomes

What this means for you: fund the next wave when the current one proves its result, and boards will keep funding you.

A single multi-year budget invites a single multi-year judgement, usually made too late to change course. Wave funding replaces it with staged releases: each wave has a defined scope, a measured outcome and a decision gate. Passing the gate releases the next wave; missing it triggers a rescope rather than a write-off.

Gate metrics should be business measures where possible: forecast error on the working-capital decision, hours removed from a manual reconciliation, claims triaged within a service level. Platform measures such as data ingested or dashboards built are useful operationally but prove little to a finance committee.

The gate itself needs a small, stable group to run it: the business owner of each decision, the finance partner, and the person accountable for the data. Keeping that group the same across waves matters more than its seniority, because the people judging wave three should remember what wave one promised.

Wave funding also changes the conversation about cost. Consumption-priced platforms reward exactly this discipline, and FinOps practice built in the first wave keeps the second and third from surprising anyone.

Release money against measured results, and the roadmap defends itself at every funding review.

#What to Stop Doing When the Roadmap Starts

What this means for you: a roadmap that only adds work will stall on capacity before it stalls on money.

Every roadmap competes for the same scarce people: data engineers, data owners, the few analysts who understand the definitions. Starting new waves without stopping anything spreads them thinner until nothing finishes. Three kinds of work usually deserve to stop.

The first is duplicate reporting, where several teams maintain their own version of the same metric. Consolidating onto shared definitions frees capacity and removes arguments about whose number is right. The second is pilots with no owner prepared to change a process; they consume engineering time and never reach production. The third is maintenance of systems the roadmap will retire, beyond what is needed to keep them safe until switch-off.

Stopping work is a political act, and it needs the same sponsorship as starting it. Naming what stops in each wave, alongside what starts, is what makes the plan credible to the teams who will deliver it. It is also part of the digital transformation work that is easy to leave out of a technology plan.

#When a Big-Bang Programme Is the Wrong Shape

What this means for you: wave funding suits most estates, but a few situations justify a larger, faster commitment.

A single large programme is defensible when an external deadline fixes the scope and the date. A regulatory obligation with a commencement date, a vendor end of support that cannot be extended, or the separation of a business after a sale can all justify committing more up front, because the cost of being late exceeds the cost of moving in larger steps.

Even then, the dependency order still applies inside the programme. The difference is that waves run in parallel under one budget rather than in sequence under several. Where that is the case, a clear reference architecture agreed early matters even more, because parallel teams will otherwise make incompatible choices.

Wave funding is also the wrong tool for a very small estate. An organisation with one data team and a handful of sources does not need horizons and gates; it needs a prioritised backlog and a quarterly review. Applying programme machinery to a small problem adds overhead without adding control.

#Where to Start on Monday

What this means for you: the first month should end with three decisions, three owners and one funded wave, not a finished three-year plan.

Begin by collecting the current initiative list and asking, for each item, which decision it improves. Items that cannot answer go to a holding list rather than the roadmap. From what remains, choose three decisions with willing owners and measurable baselines.

Next, trace each decision back to the data it needs and record what is missing: sources, definitions, quality, ownership. That trace is the scope of the first wave. Cost it, set the gate metric, and name the work that stops to make capacity for it.

Finally, write the 12-month and 24-month horizons as hypotheses rather than commitments, stating what the first wave must prove for each to proceed. If you are bringing in outside help for any part of this, our buyer's checklist for choosing a data and AI consultancy sets out what to ask before signing. The sequence itself, from governed data to semantic intelligence to agents, is the subject of our autonomous enterprise architecture, and the reasons programmes stall without it are covered in why AI pilots stall on data.

#Frequently Asked Questions

#What should come first in a data and AI roadmap?

Business decisions should come first. Choose three decisions where better data or AI would change a material outcome, name an owner for each, and measure the current baseline. Data foundations scoped to those decisions follow, then platform capability sized to proven workloads, then AI in production workflows. Starting with a platform or a model commits money before anyone knows what it is for.

#How long should a data and AI roadmap cover?

A practical roadmap covers about 24 months in three horizons. The first 90 days prove value on three decisions and baseline data quality. The first 12 months build reusable foundations and put a first AI use case into production. The second year scales proven patterns to more domains, introduces agents where controls exist, and retires replaced legacy systems.

#How should a data and AI roadmap be funded?

Fund it in waves rather than as one multi-year budget. Each wave has a defined scope, one measured business outcome and a decision gate. Meeting the gate releases the next wave, and missing it triggers a rescope instead of a write-off. This keeps boards confident, exposes weak initiatives early and makes consumption-priced platforms easier to control.

#When is a big-bang transformation programme justified?

A large single programme is justified when an external deadline fixes both scope and date, such as a regulatory commencement date, an unavoidable end of vendor support, or a business separation after a sale. The dependency order still applies inside it, but workstreams run in parallel under one budget. For most other estates, staged wave funding carries less risk.

#Why do so many enterprise AI projects get abandoned?

Most are started before their conditions for success exist. Gartner predicted in February 2025 that through 2026 organisations will abandon 60% of AI projects unsupported by AI-ready data, and in June 2025 that over 40% of agentic AI projects will be cancelled by the end of 2027. Sequencing data, governance and controls before AI addresses both causes.

Unolabs is a Data and AI first engineering consultancy, headquartered in the United Kingdom with engineering operations in Pune and active engagements across the UK, Australia, and Hong Kong. We help enterprises build the architectural foundation for autonomous AI execution — governed data platforms, semantic intelligence, and agentic systems that enterprises can stand behind.

If you are weighing how to sequence your data and AI roadmap, book a discovery call and we will work through it with you.