A staged AI adoption roadmap connecting use cases, data readiness, governance, platform choices, workforce capability and measurable outcomes.
Most AI roadmaps fail for the same three reasons
Before the structure, the failure modes — because a roadmap that does not address these is decoration.
- Starting with technology rather than a problem. "We need an AI strategy" produces pilots nobody asked for. "Quotes take four days and we lose deals because of it" produces something that gets used.
- No owner with authority. AI projects cross IT, legal, operations and a business function. Without someone who can decide, they stall in consultation.
- No measurement baseline. If you did not measure the process before, you cannot demonstrate improvement afterwards, and funding evaporates at the first budget review.
The shape of a roadmap that works
| Phase | Duration | Goal | Deliverable |
|---|---|---|---|
| Orient | 2–4 weeks | Know what you have and what hurts | Use-case list, ranked; shadow-AI audit |
| Foundation | 4–6 weeks | Make safe use possible | Approved tooling, policy, training, ROPA entries |
| First value | 6–12 weeks | One workflow measurably better | Working change plus before/after numbers |
| Expand | Ongoing quarterly | Repeat on the next-ranked workflow | Portfolio of small, evidenced wins |
| Operate | Continuous | Keep it working and governed | Ownership, review cadence, cost control |
The important structural choice: first value before expansion. Organisations that run six pilots simultaneously usually finish none.
Phase 1 — Orient
Two activities, run in parallel.
Find out what is already happening. Ask staff, without blame, what AI tools they use. Every organisation discovers unapproved use. This is useful data, not a disciplinary matter — it tells you where demand actually is.
Rank candidate use cases on three axes:
| Axis | Question |
|---|---|
| Value | How much time, cost or delay does this consume today? |
| Feasibility | Is the process defined? Is the data available and decent? |
| Risk | Does it touch personal data, money, employment or safety? |
The first project should be high value, high feasibility, low risk. Resist the temptation to start with the most exciting idea — start with the most winnable one.
Phase 2 — Foundation
This phase is unglamorous and skipping it is the most common cause of trouble later.
- Choose approved tools and licence them at business tier
- Block consumer equivalents at the identity or network layer
- Publish a short acceptable-use policy — one page, plain language
- Train on failure modes, not features
- Record processing in your ROPA with lawful basis and retention
- Decide the escalation route — who answers "can I use AI for this?"
For most organisations this is four to six weeks and mostly administrative. It is also what makes everything afterwards defensible.
Phase 3 — First value
Pick one workflow. Do it properly.
- Measure the current state. Cycle time, error rate, volume, cost. Without this number, nothing that follows can be proved.
- Define what "better" means and by how much, before starting.
- Involve the people who do the work. They know the exceptions that will break it, and their buy-in determines adoption.
- Build the smallest version that could work.
- Run it in parallel with the old way initially — this catches failure modes without customer impact.
- Measure the same things again.
- Decide honestly: expand, adjust, or stop. Stopping a project that did not work is a success for the roadmap's credibility, not a failure.
Six to twelve weeks is realistic. Anything promising transformation in two weeks is a demo, not a deployment.
Phase 4 and 5 — Expand and operate
Expansion is repetition, not scale-up: take the next-ranked use case and run the same loop. A portfolio of five small evidenced improvements is worth far more than one large unevidenced programme, and it survives leadership changes.
Operating discipline that is easy to forget:
- Cost control. Usage-based AI pricing can drift badly. Set alerts and review monthly.
- Model changes. Providers update models; behaviour shifts. Re-test critical workflows periodically.
- Content maintenance. Anything grounded in your documentation degrades as the documentation ages.
- Access review. Remove licences and integrations when people or projects end.
Who needs to be involved
| Role | Contribution |
|---|---|
| Executive sponsor | Removes blockers, protects funding |
| Product/process owner | Owns the workflow being changed and the outcome |
| IT | Identity, integration, tooling, security |
| Data protection / legal | Lawful basis, DPIA where needed, contracts |
| The people doing the work | Design input and, ultimately, adoption |
The most under-resourced of these is consistently the last. AI adoption is a change management exercise wearing a technology costume.
Measuring it at portfolio level
Report on outcomes, not activity:
- Good: hours returned, cycle time reduced, error rate, cost per transaction, customer response time
- Weak: licences deployed, prompts run, staff trained, pilots launched
If your AI reporting consists of adoption statistics, you are measuring the project rather than the benefit — and that is exactly the reporting that gets cut.
Frequently asked questions
How long before we see real value?
A well-chosen first workflow should show measurable improvement within a quarter. Organisation-wide change is a multi-year exercise; do not promise it in a business case.
Should we hire an AI specialist?
Usually not first. Most early value comes from applying existing tools to well-understood processes, which needs process knowledge more than model expertise. Hire when you are building rather than adopting.
What if the technology changes and we picked wrong?
At the assistant and tooling layer, switching costs are low. Avoid deep lock-in early — keep your data portable, and treat vendor choice as a two-year decision rather than a ten-year one.