The slide is beautiful. Four quarters across the top, twelve rounded boxes underneath, each colored by theme, each carrying a use-case name and a projected value in bold. It took the strategy team nine days to build and it will take the executive committee ninety seconds to approve. Then the chief financial officer, who has been quiet, puts a finger on the first box in Q1 and asks the only question that matters: "What has to be true before this one can start?" Nobody answers, because nobody built the answer. The boxes were sorted by value, not by logic, and the difference between those two sortings is the difference between a program that compounds and a program that spends two quarters waiting on a data-access approval nobody put on the calendar.

The Roadmap That Is Just a Sorted List

In the last lesson you built the portfolio: eleven funded items surviving a value-by-readiness screen, three quick wins, three capability builds, one deep bet, and a reserve. The portfolio answers one question well: what deserves money. It says nothing about time. And the moment time enters, you are answering a much harder question with far more ways to be wrong: what must be true before each item can succeed, and what does each item make true for the next one?

Most enterprise AI roadmaps never ask that. They are produced by an operation that feels rigorous and is not: sort the scored list descending by projected value, cut it into quarters at a rate the team thinks it can sustain, add dates. This produces the classic pathology. The highest-value item goes first and blocks in month two on a dependency nobody sequenced, while the capability build that would have unblocked it sits in Q4, labeled "after we see results," a sentence with a logical loop inside it: the results cannot arrive until the enabler lands, and the enabler will not be funded until the results arrive.

Sequencing is not prioritization with a calendar bolted on. It is dependency logic plus evidence logic plus organizational-capacity logic, resolved onto a calendar. Get all three right and the roadmap becomes self-reinforcing, each wave paying for the next. Get one wrong and you produce the most expensive artifact in enterprise transformation: a plan that looks like a commitment and behaves like a wish.

The failure story: fourteen use cases, sorted by value

A healthcare services organization of roughly 4,000 people finishes a serious readiness assessment: fourteen use cases scored on value and feasibility, honest work. The program office then sorts the fourteen by projected annual value and schedules them three at a time in that order.

Item 1 is a clinical documentation assistant with a projected $2.1 million annual value (illustrative figures throughout). It is genuinely the most valuable item on the list. It starts in week 1 with a kickoff, a vendor, and a named owner. In week 3 it stops, because the model needs a clinical data store governed by a committee that meets monthly and requires a privacy impact assessment nobody had started. Approval lands in week 14: eleven weeks of a nine-person team idling or busy-working.

Now the part that turns a delay into a disaster. Items 2 and 3, launched in parallel for momentum, need the same data store and the same committee. The dependency was not merely unmapped, it was correlated, the sequencing failure with the largest blast radius. One blocker, three projects, all stalled at once. The status report cannot show this, because it has a red-amber-green column and all three are technically "in flight, on plan, dependencies pending." Three green lights, zero movement. The team later calls this green-but-blocked, and by the time anyone says it aloud, a quarter is gone.

Here is the part that should hurt. Item 9 on the value-sorted list was an "access fast-path": a standing pre-approval pattern for de-identified analytic extracts, negotiated once with the privacy committee, reusable by every later project. Cost: 15 IT effort-days. Projected annual value: nearly zero, because enablers do not generate revenue, which is exactly why the sort put it ninth. It was scheduled for Q4 with the note "once we understand our needs better." Fifteen days of work, placed forty weeks after the three projects waiting on precisely what it would have delivered.

Two quarters later the program has produced no evidence: no verified before-and-after number, no proven replication, nothing a finance business partner would accept as a result. The roadmap gets replanned, correctly this time, but in a room where the CFO has stopped extending patience and started asking about run rate. This is how programs join the 42 percent of companies that S&P Global found scrapped most of their AI initiatives in 2025. Nothing here was a technology failure. The models were fine. The use cases were real. The order was wrong.

Value ranking tells you what is worth doing. Only the arrows tell you what can be done. A roadmap without arrows is a wish list with dates on it.

The Four Sequencing Logics, in the Order They Constrain

Sequencing looks like art until you decompose it. Then it becomes four passes over the same portfolio, applied in a fixed order, each narrowing the space of legal calendars. Run them in this order, because each pass respects the constraints of the one before it.

Logic one: hard dependency, the physical prerequisite

The first pass is the least negotiable and the most often skipped. A hard dependency is a physical precondition: the pilot cannot start before its data is accessible, the agent cannot be tested before the sandbox exists, the process cannot be measured before the counters are instrumented. These are not preferences. They are the difference between a start date and a start fiction.

Draw the arrows before the dates. Put each funded item on a card and write what it consumes: which datasets, systems, access rights, integrations, controls. Then draw an arrow from every prerequisite to every item that consumes it. Do not open a calendar tool. This pass produces a dependency graph, not a schedule, and the graph is what will overrule your intuitions.

The Critical Dataset Register from your data audit is the richest source of arrows in the portfolio, and its remediation lines are not background maintenance. They are calendar items with beneficiaries. When the register says the vendor master carries 312 duplicate records and has had no owner since the 2022 migration, with a remediation estimate of 40 steward-days, that line is not "a Q3 data initiative." It is a node with arrows pointing out of it. Count them: 7 of the 11 funded items consume the vendor master, for entity matching, spend classification, contract linkage, or supplier risk. Seven arrows out of one node.

Once counted, sequencing that node stops being a judgment call and becomes arithmetic. A capability build with seven downstream dependents cannot sit behind any of them. It is week 1 work, promoted by arrow-counting rather than by enthusiasm or the sponsor's preference, and that promotion is the most valuable sequencing decision in this lesson. It is also the one that feels worst politically, because enablers have no headline value, no demo, and no story. You will be asked why the program's first six weeks go to deduplicating supplier records. The answer is a number: seven of eleven.

Two disciplines keep the pass honest. First, hunt correlated dependencies: when three items point at one node, that node's slippage is not a three-item risk, it is a single point of failure with a three-item blast radius, and it belongs on the roadmap flagged as such. The healthcare collapse was a correlated dependency nobody drew. Second, separate hard from soft. A hard dependency blocks the start; a soft dependency degrades the outcome (the pilot can run on partial data, but the results will be noisy). Hard dependencies become entry conditions; soft dependencies go to the risk register with a named mitigation.

Gartner states the stakes: through 2026, 60 percent of AI projects will be abandoned for lack of AI-ready data, and 63 percent of organizations either lack AI-ready data practices or do not know whether they have them. Read that as a sequencing claim, not a data claim. Those projects were not abandoned because the data was imperfect. They were abandoned because the work to make the data usable was scheduled after the projects that needed it, or never scheduled at all.

Logic two: evidence dependency, the chain that funds itself

The second logic is subtler, and strategists who master it get their programs renewed. Some items do not physically block others; they prove something the others need before they can be funded or trusted. That is an evidence dependency, and it is invisible on a graph drawn only from systems and data.

Consider the chain. The quick win in a build-ready function produces a verified Delta Table: baseline, post-implementation measurement, the honest difference, the confidence label, the controls that rule out obvious alternative explanations. That is not just a result. It is what funds the enterprise training program, because training costs real money and has no measurable output of its own, so it can only be bought on the back of a demonstrated result. The training program, in turn, is what lets the remediate-first functions run their own pilots later without importing the central team.

Read the chain backwards and you have your sequence: pilot, then training, then the harder functions' pilots. Not because of data. Because of proof. Miss it and you get the common version: an enterprise training program in Q1, delivered to 2,400 people, before anyone can point to a single verified result, which makes it a cost with a hopeful narrative attached. BCG's 10-20-70 rule (10 percent algorithms, 20 percent technology and data, 70 percent people and process) tells you training is where most of the value lives. Evidence logic tells you when to spend it.

The sponsors'-eye view. Leadership does not fund roadmaps. Leadership funds waves. What happens in practice is a sequence of budget conversations, each a fresh judgment about whether this program deserves the next tranche, held by people whose memory of the last conversation is shorter than you hope. Every one of those conversations needs a defensible number produced since the previous one.

That sets wave length from outside your project plan. A wave must be short enough that the funding audience never goes a full budget cycle without evidence, and long enough that the evidence is real rather than anecdotal. In practice, 8 to 14 weeks: not because projects naturally take 8 to 14 weeks (they do not) but because that is the rhythm at which enterprise money is re-examined. A 26-week wave is a bet that nobody will ask a question for half a year, and in a year when 42 percent of companies scrapped most of their AI work, that bet loses. The corollary: every wave must be designed so that something ends inside it, with a number. "We made good progress on the platform" is not a wave exit; it is a quarter of expenditure.

Logic three: capacity and collision, the arithmetic of real people

The third pass is where roadmaps go from optimistic to fictional. It has two parts: how much change-capable capacity exists, and what is already consuming it.

The capacity arithmetic. The people audit gave you a number nobody enjoys: transformer capacity, meaning people who can actually lead a process redesign rather than attend one. In the enterprise storyline that number is 2.5 full-time equivalents (FTE, one person's full working capacity for the period). Two and a half people carrying redesign across a business of thousands. That is not a morale problem to argue with; it is a constraint to plan around, like a machine with a fixed cycle time.

Lay it on the calendar the way the replication playbook taught you: with phase offset. An item does not consume transformer capacity evenly. The heavy weeks are design and redesign at the front and the adoption push at the end; the middle, once the workflow is stable, is light. Two items whose peaks are offset by five or six weeks can share one transformer; two starting the same Monday cannot. That is the difference between "we can run three items at once" (false, if they all start together) and "we can run three at once if their front-loaded weeks do not overlap" (true, and a real plan). Build the capacity view as a week-by-week load chart. When it shows 3.4 FTE of demand in weeks 12 to 16 against 2.5 available, you have found a date that will slip before it is announced.

The collision inventory. The second part is organizational, and it is mandatory input rather than optional context. Your people atlas contains a collision calendar: every major initiative already competing for the same attention. Systems cutovers, regulatory deadlines, audits, reorganizations, peak seasons, the annual planning cycle. In the enterprise storyline the headline row is an enterprise resource planning (ERP) go-live in fiscal Q3, sitting squarely on the finance controllers and the IT integration bench that three portfolio items need.

Two things must be said about that row, and neither is "add contingency." First, sequencing around collisions is not padding. Padding is slack added to a plan you still believe. Collision sequencing is admitting that a named person will be inside a cutover war room in week 20 and therefore cannot be your process owner in week 20. Second, collisions resolve at the level of people, not functions. A go-live that consumes the controllers and the integration engineers does not necessarily consume the contract administration team three desks away. Blanket-blocking a function throws away available capacity; blanket-ignoring the cutover throws away the plan.

What the inventory buys you is the most credibility-generating sentence available to a strategist: the contingent plan, stated before anyone asks. "Item four starts in week 24 because ERP hypercare ends in week 23. If the cutover slips a month, item four moves with it, the reserve absorbs the gap, and here is what we do instead in that window." Executives have heard a hundred plans. They have heard very few that named a dependency on somebody else's schedule and priced the alternative.

Logic four: political and momentum logic, honestly named

The fourth pass gets left out of methodology documents because it sounds like manipulation. It is not, and pretending it does not exist is the surest way to do it badly. Adoption is a social process, and the order in which an organization sees things happen changes what it believes is possible. Three placements matter.

• Put a visible win where the funding audience will see it. Not the most valuable win: the most legible one. An item whose result can be stated in one sentence to a non-specialist, inside the first wave, in a function the executive committee touches. The strongest evidence in the world is wasted if it lands where nobody on the committee has ever visited.
• Sequence champion recruitment before the pilot that needs it. Your champion coverage map found two functions with an empty bench, in this storyline Legal and HR. The wrong move is to schedule their pilots later and hope a champion appears. The right move is to make recruitment its own dated item, one wave ahead of the pilot slot, with a named owner and a definition of done (identified, trained, given time in their objectives). A pilot landing in a function with no local advocate is a pilot run by visitors, and visitors leave.
• Give the skeptical function a neighbor's success to watch. When a culture read says the last transformation cost people their standing, that function should not go first. It goes second or third, after a comparable team nearby has run the same play and can be visited, questioned, and disbelieved in person. MIT's autopsy of the 95 percent of enterprise generative AI pilots that produced no measurable profit-and-loss return keeps returning to adoption without transformation: people used the tool while the work stayed the same. Sequencing a skeptical function behind a demonstrated peer is one of the few levers that changes that outcome in advance, and it costs nothing but order.

Say it out loud in the planning room: "We are putting Customer Operations before Legal because Legal watched two change programs punish early adopters, and a neighbor's verified result will do more there than any amount of my presenting." That is change sequencing described accurately. The version that gets called manipulation is the one that stays unsaid.

Wave Design: The Roadmap's Working Unit

Four logics produce constraints. Waves turn constraints into a plan people can hold in their heads. A wave is deliberately not called a quarter, because a quarter is an accounting boundary and a wave is an evidence boundary. Forcing the two to align is how an item ends up scheduled to finish on December 31 for reasons unrelated to the work.

Anatomy of a wave. Two to four items. One gate at the end. Explicit entry conditions and exit evidence, written before the wave starts. The range is not arbitrary: below two items the gate is just a project review; above four, nobody can hold the dependency picture and the gate degrades into a status meeting where nothing is decided because nothing can be compared. Every item inside the wave carries three fields, and this triplet is the heart of the artifact:

• Entry conditions. What must be true for this item to start: data accessible at named quality, owner named and released from other duties, baseline captured, control in place, budget released. Entry conditions are binary and checkable. "Data mostly ready" is not one; "vendor master deduplicated, verified sample error rate under 2 percent, owner named" is.
• Evidence output. What this item proves for the items behind it. Not what it delivers: what it proves. "A verified Delta Table showing exception-handling cycle time" is an evidence output. "A deployed tool" is not, because a deployed tool proves only that deployment happened.
• Effort and capacity draw. Effort-days by role, and the weeks in which the transformer draw peaks. This is what makes the load chart possible.

The wave gate. At the end of each wave sits a gate, and it is the portfolio's stage gate rather than a project's. A project gate asks whether this project continues. A wave gate asks a larger question with three legal answers: continue as planned, reallocate, or stop. Continue means the evidence landed and the next wave's entry conditions are met. Reallocate means something learned this wave changes what the next wave should contain, which is not failure but the point of gating. Stop means the evidence failed to support the thesis, so you end the work, harvest the learning, and return the capital. Chapter 4.5 builds the gate's mechanics in full; for now, design waves so a gate is possible at all, which means ensuring each wave ends with a number rather than a feeling.

The reallocation reserve. Hold roughly 15 percent of capacity unallocated. Not 15 percent of budget in a contingency line finance will sweep at year end: 15 percent of your effort-days and, critically, of your transformer capacity, left visibly uncommitted on the load chart. Experienced planners recognize this instantly; everyone else wants to fill it, because an empty column looks like slack and slack looks like waste.

Here is the argument that wins that fight. A roadmap that is 100 percent committed cannot absorb the finding that always arrives, and one always does: the pilot outperforms and deserves acceleration, the dataset is worse than the register said, a function volunteers, the ERP slips. In a fully committed plan each of those forces a replan, and replans cost credibility even when correct. With a reserve, the same event becomes a decision at the next gate: "we are deploying six reserve days to extend the Customer Operations pilot by two weeks, because the exception-rate curve has not flattened." That sounds like control. The alternative sounds like a plan coming apart.

The Roadmap's Honesty Conventions

Now the convention that separates a strategist's roadmap from a project manager's Gantt chart, and it comes down to three lines in a legend.

A four-quarter roadmap drawn with equally confident dates is read as four quarters of promises and audited as such. This is the false-precision failure, and it is self-inflicted. Nobody actually believes a date eleven months out is a commitment, but nobody says so, the boxes all look identical, and the roadmap enters organizational memory as twelve dated promises. Nine months later, when six have moved for excellent reasons, the story is not "we learned and replanned." It is "they missed." Credibility does not survive that, and credibility is the currency that funds wave four.

The fix is the confidence-word discipline you already applied to measurement, applied now to time. In the Delta Table you labeled each finding verified, indicative, or anecdotal, and that labeling is what let you report an honest mixed result without being accused of hedging. Do the same to the calendar, in the legend:

• Wave 1 dates are commitments. Scoped, resourced, entry conditions met or on a dated path. If a wave 1 date moves, that is news and it arrives with an explanation.
• Wave 2 dates are plans. Scoped against today's information and contingent on wave 1's gate. Expect movement in weeks, not quarters, and expect the content to be adjusted by what wave 1 teaches.
• Wave 3 and beyond are intentions. Direction and sequence, not dates. They show where the program is heading and what the earlier waves are earning the right to do. They will change, and the roadmap says so in writing.

Two counterintuitive things happen when you publish this legend. Nobody objects: executives never believed your Q4 dates, so labeling them accurately reads as a relief and signals that the rest of your numbers can be trusted. And labeled confidence buys the right to replan without losing credibility. When wave 3 changes shape at the wave 2 gate, you are not missing a commitment, you are doing exactly what the legend said. Same trade as the Delta Table: an explicit limit on the claim is what makes the claim durable.

Replanning cadence: living document or dead document

The roadmap refreshes at every wave gate with what was learned. Not annually. Not when someone notices it is stale. At the gate, as a standing agenda item, using the gate's own evidence. Then say the diagnostic out loud: a roadmap that has not changed in three quarters is not stable, it is unread. If nine months of pilots, gates, and remediation produced zero changes to sequence, either the program is not learning or the roadmap is not connected to the program.

Pair the refresh with the readiness heat map's quarterly update, because the two feed each other. The heat map records the terrain; the roadmap records the plan against it. When a function's data score moves from 1.9 to 3.0 because a remediation line closed, that is a heat map event and a roadmap event on the same day: two items' entry conditions are now met, and those items become eligible for the next wave. Run both on one cadence and the program stops being a series of projects and starts being a system that reallocates itself toward readiness.

The Artifact: The Sequenced Roadmap, Worked

Here is the deliverable, rendered for the enterprise storyline: 2,400 people, six functions (Finance, Customer Operations, Supply Chain, Sales, Legal, HR), eleven funded items, a 210 effort-day remediation backlog, 2.5 FTE of transformer capacity, an ERP go-live in fiscal Q3, and two functions with no champion bench. All numbers are hypothetical and illustrative; the shape is the transferable part. Program week 1 falls in fiscal Q2, so fiscal Q3 runs from week 12 to week 24, with the ERP cutover in week 20 and hypercare through week 23.

Reserve: 15 percent of effort-days and transformer capacity unallocated across all waves (roughly 0.4 FTE and 22 effort-days per wave), deployable only by decision at a gate.

Legend, printed on the roadmap: Wave 0 and Wave 1 dates are commitments. Wave 2 dates are plans, contingent on the Wave 1 gate. Wave 3 is an intention: sequence and direction, not dates.

What to notice in that table

Hard dependency did the heaviest work. Wave 0 exists because arrow-counting put a 55 effort-day housekeeping bundle at the front of a multi-million-dollar program. No committee chooses that ordering from a value-ranked list; the arrows chose it. Note that wave 0's exit evidence is stated as a count of unblocked items, which is how you make an enabler legible to people who fund outcomes.

Wave 1 starts in week 4, not week 7. Overlap is legitimate when the overlapping item's entry conditions do not depend on the earlier item finishing. Quick win A has only a soft dependency on the vendor master, mitigated at pilot scope by manually linking about 60 contracts. Two weeks of calendar bought for four hours of manual work: that is what separating hard from soft dependencies pays.

The collision moved one item, not a function. On dependency logic alone the Finance instrumentation item could start in week 18. It starts in week 24 because the two controllers and the integration engineer it needs are inside ERP hypercare until week 23. Note what did not move: quick win A, also in Finance, running weeks 4 to 18 with the contract administration team, nowhere near the cutover. A function-level collision rule would have blocked both and cost the program its earliest evidence. And the contingency is written into the roadmap's notes in advance: if the cutover slips a month, the Finance item moves to week 28 and the reserve extends the Customer Operations pilot so the wave 2 gate still has evidence to weigh.

Evidence logic funded the expensive thing. The training program, the largest line in the portfolio and the one BCG's 70 percent says matters most, sits in wave 2 and is explicitly funded by wave 1's Delta Tables. In wave 0 it is a $400,000 act of faith. In wave 2 it is a proven multiplier being scaled, which is a different conversation with the same finance business partner.

The deep bet is gated at discovery, not at build. The greenfield Sales engagement buys a decision rather than a system: discovery-complete is the deliverable, with tool spend as a separate downstream decision. McKinsey's finding that high performers are roughly three times more likely to fundamentally redesign workflows is the reason a greenfield redesign must be understood before it is bought. Legal and HR, meanwhile, appear nowhere as pilot slots; they appear as bench-building, one wave ahead of their turn.

One honest caveat: MIT found that only about 5 percent of custom enterprise AI tools reach production, and the roadmap above does not beat that base rate by being well drawn. It improves the odds because it puts evidence checkpoints early, keeps the committed horizon short, and makes stopping a legal outcome at every gate. A sequenced roadmap does not guarantee success. It guarantees that failure is found while it is still cheap.

Every wave in that table needs funding, and funding means walking into a room with a business case a finance team will attack line by line. That is the next lesson, and it decides whether this roadmap becomes a program or stays a nice document.

What to Do Monday Morning

Five moves, in this order. The order is the lesson.

1. Draw the arrows before you touch a date. Put your funded items on cards, write what each consumes (datasets, systems, access rights, integrations, controls), and draw an arrow from every prerequisite to every consumer. Ninety minutes with a whiteboard beats a week with a planning suite, because the suite will happily let you enter a date for an item that cannot start.
2. Count the arrows and promote the winner. Find the node with the most outbound arrows, usually a data-remediation line rather than a project, and move it to wave 0. State its value the way it deserves: not by its own return but by the count of items it unblocks. Then find every correlated dependency and flag it as a single point of failure with a named blast radius.
3. Build the collision calendar from your people atlas, at person level. List every cutover, audit, close, peak season, and reorganization in the next four quarters, and name the specific people or roles each consumes. Overlay your items' owner requirements. Every overlap is either a moved date or a documented contingency, and you should be able to say which, out loud, before anyone asks.
4. Label your wave confidences in the legend and print it. Wave 1 commitments, wave 2 plans, wave 3 intentions. Do this before the roadmap circulates, because you cannot retroactively downgrade a date that has already been read as a promise.
5. Hold back 15 percent of capacity before anyone asks for it. Take it off the load chart now, name it the reallocation reserve, and write the rule that it deploys only by decision at a wave gate. Wait until the plan is full and you will never get it back.

Key Takeaways

• Reject the value-sorted list as a roadmap: composition answers what to fund, sequencing answers what must be true first, and the classic failure is the highest-value item blocked in month two by a dependency scheduled in Q4.
• Run the four sequencing logics in order (hard dependency, evidence dependency, capacity and collision, political and momentum), because each pass narrows the calendars the next pass may consider.
• Draw the dependency arrows before any dates and let arrow-counting promote enablers: a remediation line that 7 of 11 items depend on is week 1 work, and correlated dependencies are single points of failure that must be flagged as such.
• Sequence the chain of evidence, not just the chain of data: each wave must earn the next wave's budget with a defensible number, which is why waves run 8 to 14 weeks, matched to the funding rhythm rather than to project convenience.
• Lay real capacity on the calendar with phase offset, build the collision inventory at person level, and state contingencies in public, because that conversation is what separates a plan from a fantasy.
• Design waves as the working unit: 2 to 4 items, explicit entry conditions and evidence outputs per item, one gate that can decide continue, reallocate, or stop, and a reallocation reserve of roughly 15 percent held back before anyone asks.
• Publish the confidence legend (wave 1 commitments, wave 2 plans, wave 3 intentions) to defeat false precision, and treat that labeling as what buys the right to replan at a gate without losing credibility.
• Refresh the roadmap at every gate alongside the heat map's quarterly update, and remember the diagnostic: a roadmap that has not changed in three quarters is not stable, it is unread.