AI implementation roadmap
An AI implementation roadmap is the ordered plan that comes out of a diagnostic. It lists the use cases worth building, each specified precisely, and sequences them by commercial value, feasibility, data readiness, governance requirements and delivery complexity. A roadmap that names tools before it names steps is a purchase order. A useful one states what will be built, what will be retired instead, and what cannot yet be specified at all.
What is an AI implementation roadmap?
It is an output of the assessment rather than an input to it. Once each step in the mapped process has been marked retire, automate, assist or person, the roadmap orders the work that follows and states the conditions each item depends on.
It should be legible to a finance function and to an engineering function at the same time. If only one of them can read it, it will not survive the first budget cycle.
How is the roadmap prioritised?
- Commercial valueWhat the change is worth, expressed in the terms the business already reports against.
- FeasibilityWhether the step can be specified precisely enough to be built now.
- Data readinessWhether the evidence exists, at sufficient resolution, and can be refreshed.
- GovernanceWhat approvals, controls and constraints the change triggers.
- Delivery complexityWhat has to be built, connected to the systems around it, and then maintained.
An item that scores well on value and poorly on data readiness is not dropped. It is sequenced behind the work that makes it ready, and the dependency is stated.
How is a use case defined precisely?
- what it must support;
- what it must be gated from supporting;
- the quality threshold it must meet;
- the evidence and research it relies on;
- how often that evidence must be refreshed;
- where human review is required; and
- what assurance gates and audit trails are needed.
A use case that cannot be written in those terms is not ready to be built, and the roadmap says so rather than starting it.
What belongs in the first phase?
Usually the retirements. A step removed costs nothing to run and reduces the surface that everything else has to connect to. More often than not, the gain is in fewer steps rather than in new software.
After that, the work with high value and settled data, and the shared components that several later items depend on. The crossovers between functions frequently sit here: the same data, the same controls and the same decision points recurring in several places, where one piece of work resolves several objectives at no additional cost.
What does a roadmap not contain?
It does not contain a platform selection made before the use cases are specified. Tools are chosen against a requirement, and the requirement is an output of the assessment rather than an input to it.
It does not contain a pilot chosen for convenience. A pilot selected because a function volunteered will usually optimise a stretch of work that a wider map would have retired.
It does not contain a target for how much should be automated. A percentage set in advance is a commitment made before the evidence, and it will be met by automating steps that should have come out.
And it does not contain a promise about the steps that could not be specified. Those are listed as they are, together with what would have to become true for them to move. What the roadmap does contain, for every item, is the value, the feasibility, the data it needs, the governance it triggers and the complexity of building it. That is enough to defend an order.
What happens to the steps that could not be specified?
They are listed. How much of a process will yield to specification is not known at the outset, which is why the work is conducted as research and reported as such.
That list is not a failure of the diagnostic. It is the honest boundary of it, and it is the natural agenda for a later phase, once evidence that does not exist today has been accumulated.
Common questions
-
What is AI implementation?
Building and putting into service the use cases a diagnostic has specified and prioritised. Implementation is a separate decision from Discovery, and it is scoped against the specification rather than against a general ambition to adopt AI.
-
How do you build an AI roadmap?
Map the work, assess every step, specify the use cases that survive, then order them by commercial value, feasibility, data readiness, governance requirements and delivery complexity. A roadmap assembled in the other order, from a list of available tools, records what could be bought rather than what should be built.
-
Do we need a roadmap before we start building?
You need a specification before you start building. The roadmap exists so that the order of building can be defended, and so that a use case is not started before the data and the governance it depends on are ready.
-
How far ahead should a roadmap look?
Far enough to show the dependencies and no further. Items beyond the point where the evidence supports them are recorded as candidates rather than commitments.
-
How does the roadmap relate to Discovery?
Discovery produces it. Discovery is a paid, data-driven diagnostic across the functions in scope, typically three to six months, and closer to three where strong operational data already exists.
-
What if priorities change mid-programme?
The five criteria are applied again. Because each item already carries its value, feasibility, data readiness, governance and complexity, re-ordering becomes an arithmetic exercise rather than a negotiation.
-
Is the roadmap ours to take elsewhere?
Yes. What is produced for you is yours: the diagnostic, the specification and the reasoning behind it. The firm retains the intellectual property in its own methods and systems. A managed service is a convenience, not a dependency.