Why most AI roadmaps die in committee
The typical AI roadmap is a slide with twelve initiatives grouped into horizons. It fails review because it answers the question “what could we do with AI” when the committee is asking “what should we fund next quarter, and how will we know it worked”.
A roadmap that survives is short, ordered, and priced. It names the workflow, the current cost, the expected saving, the build cost and the sequence dependency. Three projects specified like that beat twelve described as opportunities.
The method
Four weeks, five steps. This is the process we run in discovery, and it works whether or not we do the build.
-
Inventory the work, not the technology
Interview the people doing the job. Map what actually happens, including the workarounds nobody documented. The gap between the official process and the real one is usually where the largest savings hide.
-
Quantify each candidate
Hours per week, people involved, error rate, cost of an error, and volume trend. Anything you cannot quantify goes in a parking list, not the roadmap. This step eliminates about a third of candidates on its own.
-
Score on effort and payback
Two axes, plotted honestly. Effort accounts for integration count, data condition and compliance surface. Payback is annual saving divided by build cost. The top-left quadrant, low effort and fast payback, is your first project regardless of which one is most exciting.
-
Sequence by dependency, not by enthusiasm
Some projects unlock others. Consolidating product data is dull, and it is often the prerequisite for three downstream automations. Put the unglamorous enabler first if it shortens everything after it.
-
Attach a measurement plan before building
Define the baseline metric and how you will re-measure it. Do this before the build, because measuring afterwards means arguing about what the baseline was.
A scoring frame that holds up
Score each candidate one to five on these, then sort. Crude, transparent, and far more defensible than intuition.
| Factor | Weight | What a 5 looks like |
|---|---|---|
| Hours saved per week | High | More than 20 across the team |
| Payback period | High | Under 6 months |
| Integration complexity | High | One or two systems, modern APIs |
| Data readiness | Medium | Data exists, structured, accessible |
| Compliance exposure | Medium | No regulated data involved |
| Team appetite | Medium | The people doing it asked for this |
| Reversibility | Low | Easy to switch off without disruption |
Team appetite is weighted higher than most frameworks allow. An automation the affected team wants gets adopted; one imposed on a sceptical team quietly gets bypassed, and you will not find out for two quarters.
Red flags in your own roadmap
If any of these are true, the roadmap is not ready:
- No project has a named owner in the business, only in IT.
- The first project is the most technically interesting one rather than the fastest payback.
- Nothing on the list is a process fix or a report. A roadmap where every answer is AI has not been assessed honestly.
- The baseline metrics are estimates rather than measurements.
- There is no decision point where you would stop. A roadmap without a kill criterion is a wish list.
Frequently asked questions
How long should an AI roadmap cover?
Should we hire internally or use a consultancy?
What if we have no clean data?
How much should we budget for a roadmap engagement?
For implementation support, explore our AI strategy consulting or discuss your workflow in a free consultation.
A 30-minute call. Bring one process that costs you real time and leave with an honest answer on whether automating it is worth the money.
