Ask ten executives for their AI transformation plan and eight will describe a list of use cases, not a sequence. That's the first mistake, because the order phases happen in matters as much as which use cases you pick. What follows is a realistic, phased roadmap built from the pattern of what actually works: assess before you pilot, pilot before you scale, and prove value before you build a platform.
The roadmap at a glance
| Phase | Realistic duration | What you're proving |
|---|---|---|
| 1. Assess current state & data readiness | 2-4 weeks | Whether the data behind your target process is usable |
| 2. Pick 1-2 pilot use cases | 2-3 weeks | That the use cases chosen are high-value and bounded |
| 3. Build or hire the team | Overlaps with phases 2-4, ongoing | That you have the skills to actually ship, not just plan |
| 4. Measure, then scale or retire | 60-90 days per pilot, then 3-6+ months to scale | That the pilot creates real, measurable value before it spreads |
Phase 1: Assess current state and data readiness (2-4 weeks)
Before any use case gets picked, spend two to four weeks answering an unglamorous question honestly: is the data behind the processes you're considering actually usable, accessible, reasonably clean, not locked in a system nobody can query, and governed enough that using it doesn't create a compliance problem? Most transformation efforts that stall in month three stall because this step got skipped or rushed. The output of this phase isn't a strategy deck, it's a short, specific list of what's actually ready to build on and what needs six months of data cleanup before it is.
- Which systems hold the data this process depends on, and can anyone actually query them today?
- How clean is that data, really, not in theory but the last time someone tried to use it for something new?
- Where in the current process does a human make a judgment call, and is that judgment documented anywhere or only in someone's head?
- What skills does the organization already have in-house, and what is genuinely missing?
Phase 2: Pick one or two high-value pilot use cases (2-3 weeks)
Resist the urge to pick pilots by ambition, pick them by fit. A good pilot use case is high-value enough that success is worth measuring and communicating, bounded enough to ship in 8-12 weeks, not tangled up with three other systems, and not so mission-critical that a rough first version causes real damage if it underperforms. Two pilots, not ten, is usually the right number: enough to learn without splitting the team's attention past the point of doing either one well.
- Clear, measurable business value if it works (hours saved, error rate reduced, revenue influenced), not just 'looks impressive.'
- A bounded scope: one workflow, one team, one clear before/after, not an enterprise-wide rollout disguised as a pilot.
- Data that passed the Phase 1 readiness check, not data you're hoping will be usable by the time you need it.
- An executive sponsor who will defend the pilot's timeline and budget when the first version underperforms, because it will, initially.
Phase 3: Build or hire the team to actually ship them
This is where most roadmaps quietly break. A pilot needs people who can actually build and ship it, not just people who can talk about AI in a strategy meeting. For many organizations, especially outside big tech, the realistic options are: hire permanently for a role that may not exist in this form in two years, bring in forward-deployed or embedded specialists who can ship the pilot and transfer the capability to an internal team, or some mix of both. What doesn't work is hiring a single AI specialist and asking them to single-handedly transform a function, that's a hiring decision, not a transformation plan; a lone specialist has no team to build with and no mandate to change how anyone else works.
Phase 4: Measure and prove value, then scale what works
Define what success looks like before the pilot starts, not after you see the results, otherwise the metrics quietly shift to match whatever numbers you got. Give a real pilot 60-90 days to produce a measurable result: enough time to get past the awkward early weeks, not so long that it becomes permanent without ever being evaluated. When a pilot proves out, scaling it is not a technical copy-paste, it's a second, deliberate change management effort: the workflow that worked for one team has to be adapted, communicated and supported for the next five. When a pilot doesn't prove out, retire it explicitly and say so, a pilot that quietly limps along unevaluated is worse than one that's honestly killed. What worked should get embedded into how the function actually operates day to day, owned by the business unit, not by whatever project team built it, once it's proven, it isn't a project anymore.
The two sequencing mistakes that derail most roadmaps
- Trying to transform everything at once: parallel pilots across five functions with no shared team and no proof of value anywhere yet is not ambition, it's a way to guarantee none of them get the attention needed to actually ship.
- Skipping the pilot phase entirely: going straight from a strategy deck to a platform purchase or an org-wide rollout, without ever proving a single use case at small scale, is the single most reliable way to spend a large budget and end up with nothing anyone actually uses.
