The order you build in matters more than what you decide to build
We take a shortlist of automation candidates and turn it into a sequence across two or three quarters. Which project unblocks which. What has to be true before each one can start. What your team stops doing to make room.
In short: A roadmap is an order of work, not a wish list. We sequence your AI projects across two or three quarters, write down every dependency and precondition, and choose a first project whose real job is to earn the credibility the second one will need.
Sequencing beats ambition, and it is not close
The usual way an AI program dies is not a model that failed. It is a first project chosen because it was the most impressive one on the list. It took two quarters, shipped something the team did not trust, and used up the goodwill that everything after it needed. The second project never gets funded, and the reason given in the meeting is that AI did not work here.
So we pick the first project for a different reason. Its measurable output matters less than the sentence somebody says about it six weeks later in a room we are not in: that thing worked, it does what they said, nobody has had to fix it. Everything downstream runs on that sentence. Choose a first project that cannot produce it and you have chosen a program that ends after one attempt.
Dependencies, not just priorities
A valuable project that is blocked sits behind a smaller one that is ready. We map what feeds what: the data extract three later projects all need, the naming cleanup that has to happen before any search or retrieval behaves, the approval step that must exist before anything is allowed to write to a customer.
Preconditions written down
Each project carries a short list of things that must be true on day one. A named owner with time in their week. A place the output goes. Someone with the authority to say an answer is wrong. If a precondition is not met, the project does not start early and hope. It moves.
A first project chosen to work
Narrow scope. Data that already exists. A failure mode somebody notices immediately and can shrug off. And a team that actually wants it, which matters more than the size of the saving. Not the biggest number on the audit. The one most likely to still be running in three months.
An honest horizon
The plan covers two to three quarters properly. Past that it says so instead of pretending. Anything further out is a placeholder with a review date attached, because both the tooling and your own operations will have moved by then, and a confident eighteen-month plan is a work of fiction with a Gantt chart.
What is written next to each project
Every item on the roadmap gets the same short block, so they can be compared without anyone having to remember what was said in a workshop. The problem, in the words of the people who have it. The shape of the solution, at the level of what goes in and what comes out. The preconditions. The effort, expressed as a range with the assumptions that produce it. What it unblocks, if anything.
Then two things that most plans leave out. First, the measure, taken before the work starts rather than reconstructed afterwards, because the number you gather after launch is always argued about. Second, the kill criterion: the specific result that means this should be stopped rather than extended. Agreeing that in advance is much easier than agreeing it in month four when somebody’s reputation is attached.
Quarter boundaries are decisions, not deadlines
A quarter is not a promise that four things will be finished by March. It is a scheduled moment to look at what actually happened and decide the next order. Keep going. Reorder. Stop something. Three outcomes, considered on purpose, with the evidence in front of you.
This is the part that makes the difference between a roadmap and a poster. A plan that has not changed after two quarters is not stable, it is unread. Reality supplies new information constantly: a vendor changes its pricing, an integration turns out to be a two-week job instead of two days, a team reorganizes and the willing owner is gone. The plan should absorb that in an hour, and it can, because the dependencies are already written down and you can see what moves when you pull one piece.
Where roadmaps usually go wrong
Three failures cover most of it. The first is parallelism: four projects scheduled at once, all quietly depending on the same two engineers, so everything is eighty percent done at the review and nothing is in use. Sequential is slower on paper and faster in practice.
The second is choosing the platform in month one. A tool bought before the first project ships locks in assumptions nobody has tested yet, and the following two quarters get spent bending processes to fit a decision made when you knew least. Platform choices belong after the first build, not before it. We keep them out of the early plan deliberately, and there is a whole page on that argument under AI tool selection.
The third is a plan written for a company with different people in it. Roadmaps that assume two hires, an internal data team that is fully booked, or a level of enthusiasm that only exists in the sponsor. We build against the team you have this quarter, and note separately what would change if the hires land.
What we won’t do
Put two hard projects in the first quarter
Two ambitious builds at once means one engineer split in half and two systems that are nearly working at the review. We will sequence them and put the second one in the next quarter. If you think we have called it wrong, the quarter boundary is where you get to say so, with evidence from the first one.
Write a plan that depends on approvals you do not have
If the roadmap only works with headcount you are hoping for, a budget line that is not signed, or access to a system whose owner has not agreed, it is not a plan. It is a proposal wearing a plan’s clothes. We will write it against what exists and flag the conditional parts as conditional.
Schedule a project we cannot describe a failure mode for
If we cannot say what a bad output looks like and who would notice it, we do not understand the work well enough to give it a slot. That item goes back to the audit stage instead of onto the plan, even when the sponsor is keen and the idea sounds good in a sentence.
What should you build first, and why that one?
Send us the list you already have, however rough. We will tell you what we would put first and what we would move, and you can argue with the reasoning before anyone signs anything.
The audit answers what is worth doing and what each item costs. The roadmap answers in what order, with what dependencies, and under what conditions each project can start. Plenty of clients run them back to back, and plenty arrive with their own shortlist and only need the sequencing.
Can you build a roadmap from a shortlist we already have?
Yes. We do check that the items were scored on a comparable basis first, because lists assembled from different departments usually mix hours saved, revenue hoped for and irritation felt. Where an item rests on an untested assumption about volume or data availability, we test it before it gets a slot. Occasionally that removes something from the list, and we will say so plainly.
How often should the roadmap change?
At every quarter boundary, at minimum, and immediately whenever a dependency breaks. A plan that has not changed in two quarters is not a sign of discipline. It is a sign nobody has opened it. The structure is built so a change takes an hour rather than a rewrite.
What happens if the first project fails?
That is planned for. The first project is scoped so failure is cheap and arrives early, and it carries a kill criterion agreed before the work starts. A failure still teaches you something concrete, usually about your data or your approval process, and that goes straight into the sequencing of the next one rather than into a postmortem nobody reads.
