The roadmap is a sequence of decisions rather than a schedule
A transformation programme is usually planned as a calendar, and the calendar is then discovered to be fiction. A twelve-month plan is presented as a commitment when it is actually a sequence of dependent decisions: what to build first depends on what discovery found, the pilot scope on what the data assessment found, and deployment on what the pilot exposed.
The stages below are therefore ordered rather than dated. The months indicate a plausible distribution of effort for an organisation starting from a modest base, and they are a starting point for planning rather than a promise. The duration of each stage depends on organisational readiness, the scope you choose, regulatory obligations on the data and the decisions involved, and the complexity of the implementation. An organisation with settled operations may reach production in a quarter; one facing an unclear ownership picture may spend a year on stages others finish in a fortnight.
Stage one: discovery that produces evidence rather than a list
The first stage is spent inside the operating environment. The purpose is not to identify use cases but to establish the shape of the problem: where work is re-entered, where decisions are made on incomplete information, where exceptions accumulate, and where the cost of error lands on a named person. The output is documented processes with owners.
Baselines are established in the same period, because a process without a baseline cannot later be shown to have improved. A defensible baseline is a transaction count, a correction rate, a cycle time and a rework hour count, gathered from records rather than interviews. The method is in calculating the value of enterprise AI.
Stage two: selection, data readiness and process redesign
Candidates gathered during discovery are scored against five dimensions — measurable value, operational readiness, implementation effort, risk and organisational sponsorship — with value and sponsorship acting as gates rather than weights. The portfolio is then shaped rather than ranked, and it should contain at least one project that does not use AI at all. The method is in selecting the right first enterprise AI project.
Most delay in enterprise AI programmes is not caused by model difficulty. It is caused by discovering, after a build has started, that the business does not agree on what a customer, a contract or a claim is. So the data assessment is separate: for each concept the project needs, is there a definition, an owner, an authoritative source, and a way to reconcile two records that disagree? Process redesign follows immediately: pick the process, write down its states, which decisions are procedural and which are judgement, and who owns each outcome.
Stage three: a pilot with a production-shaped boundary
A pilot that will lead to production is built like the first increment of production: with the controls it will keep, the evidence it will retain, and the owner who will carry it. Its scope is narrow and its tests are real. It also has to sit on a reusable footing if the organisation intends to repeat it, which is the argument of reusable enterprise AI capabilities.
Stage four: governance established around the pilot
Governance is usually placed after the pilot on the assumption that it is paperwork. It is not. It determines which decisions the system may make without a person, what evidence is retained for each action, how an exception escalates, and who may authorise a change in behaviour. Deciding these while the pilot runs is cheap, because the volume is small and the people affected are available. See enterprise AI deployment.
Stage five: deployment into the process, not beside it
Deployment is where most programmes lose their result, and the cause is almost always the same: the new way is introduced and the old way left in place, because removing it was nobody's explicit responsibility. For the first weeks two processes run in parallel, the measured result reflects only the population that adopted the new way, and the committee concludes the technology did not work. Deciding in advance which steps are retired, when, and by whom is the most valuable thing a deployment plan holds.
Stage six: adoption and continuous improvement as one capability
The same stage carries the operating arrangement that follows launch: monitoring in production, a regression suite that catches changes to shared components, a review cadence, and a clear answer to what happens when the system drifts from the process it was built for. Organisations that establish this treat the first project as the beginning of a portfolio; the others treat it as the end of a project with a maintenance problem attached. See continuous testing and change management.
What the year should produce and how to know
Twelve months of this kind of work should leave four things behind: a portfolio with a measured baseline on each item, reusable components with named owners, a production system with a permanent owner and a review date, and an organisation that has changed how it decides.
- Record the baseline for each selected process before any build begins: transaction count, correction rate, cycle time and rework hours.
- Name one owner per project outcome, and put the agreement in writing before the pilot starts.
- Retire the previous way of working on a stated date, and record the decision.
- Measure adoption as a number every month, reported alongside the quality measures.
- Hold the review at a fixed date with the baseline, the delivery and the adoption data together, and decide to continue, reshape or stop.
The honest statement about the timetable is this. Twelve months is a planning frame that suits an organisation starting from a modest base, and it is achievable for a narrow scope with settled data and a willing process owner. It is not achievable for a broad scope, for a regulated data landscape, or for an organisation whose ownership picture is unresolved, and a plan that assumes otherwise loses the programme's credibility in the month it slips.