The order you do things matters more than what you do

Last week I made the case for domain-level focus: each function choosing a few well-aligned initiatives rather than the organisation spreading thin across scattered experiments. But there's a second dimension most organisations skip: the order you pursue them in.

Second and final post in a track on the AI strategy paradox. Last week covered why focus applies at the domain level, not the company level. This week: why even the right initiatives fail when pursued in the wrong order. This also closes the ten-week core series.

The invisible dimension

Most organisations pick their AI initiatives, then run them. The sequencing, when it exists, usually follows executive priority or budget cycles. Whatever has the strongest sponsorship starts first. The next one goes when it clears procurement.

The result is that initiatives run into dependencies nobody planned for. A customer service AI needs clean, consistent data across three systems, but the data quality initiative that would have fixed those inconsistencies is scheduled for next quarter. An automated approval workflow needs governance protocols that the compliance team hasn't built yet because their own AI initiative was deprioritised. Each failure looks like a technology or resourcing problem, but usually it's a sequencing one.

The information gap I wrote about in week two shows up here in a specific way: the knowledge about which initiatives depend on which foundations is distributed across teams who rarely coordinate at the planning stage. The team building the customer service AI knows they need better data, and the data team knows they need to standardise across systems. Nobody connected those two timelines.

Foundational versus dependent

AI initiatives fall into two broad categories that most portfolio planning ignores.

Foundational initiatives create capabilities that other initiatives need: data standardisation, governance frameworks, team skills, integration layers. They're rarely the most exciting projects, don't demo well, and almost never get executive sponsorship ahead of revenue-facing use cases.

Dependent initiatives require those foundations to work. An AI-powered pricing engine needs reliable data pipelines. Automated compliance needs a governance framework that defines what "compliant" means for AI decisions, and predictive maintenance won't go anywhere without sensor data integration that somebody has to build first.

When dependent initiatives launch before their foundations exist, they either stall waiting for prerequisites or build workarounds that become technical debt. Both waste resources, and both are preventable with sequencing that accounts for dependencies.

OpenAI's own deployment framework treats dependency mapping as a core step, alongside scoping and prioritisation. The sequencing question is the infrastructure question.

The cascade in reverse

In week eight I described how AI changes cascade through connected processes, one initiative's effects rippling upstream and downstream through teams and systems. Dependency-aware sequencing uses the same logic, but in planning mode rather than damage assessment.

Instead of tracing how a deployed change propagates, you trace how a planned change depends on conditions that another initiative creates. What produces the data quality that three other initiatives need? Where does a governance framework have to be in place before autonomous decision-making can operate, and how do team capabilities need to develop before a process redesign makes sense?

Value chain understanding makes this concrete. When you can see how processes connect across functions, you can see which initiatives create conditions for others. The dependency structure follows the operating model.

PE-backed companies that systematically build AI capabilities across functions see nearly 2x returns compared to those without systematic approaches. "Systematic" in that finding means initiatives that build on each other in a coherent sequence, where each success creates the conditions for the next.

What sequencing looks like in practice

Organisations that focus narrowly on technology or short-term ROI struggle to scale. The ones that succeed treat AI adoption as five interconnected dimensions: organisational capability, human-AI collaboration, data quality, unified platforms, and responsible practices. That word "interconnected" does a lot of work. You can't build any one dimension independently; each depends on progress in the others.

Sequencing turns this into a practical question: given where you are across those dimensions, what do you build next?

Start with what enables the most. Data standardisation that feeds three downstream initiatives does more work than a standalone pilot, even if the pilot has a faster ROI projection on paper. A governance framework that clears the path for five use cases across three functions is more valuable than any single initiative it enables.

Then let each completed initiative create the foundation for the next. This is how a scattered portfolio becomes a building sequence; momentum compounds rather than each initiative starting from zero.

Where this leaves us

If your function is carrying three AI initiatives right now, the sequencing question is whether the second and third are waiting on capabilities the first one should have built. The cost of getting that wrong isn't the failed initiative. It's the eighteen-month delay before the team is ready to try the next one, and the credibility hit the function takes in the meantime.

That's also how the paradox from the track title resolves. Doing less per function, with more deliberation behind each initiative and the dependencies understood, compounds into more total impact than spreading everything thin. The same organisation that was running scattered pilots starts building compounding capability. This closes the arc the series has traced over ten weeks: the adoption crisis is an information problem before it's a technology problem; the knowledge needed for good decisions lives in the people doing the work; understanding your value chain reveals how processes connect and how changes cascade through them; focus at the domain level, sequence by dependencies, and adoption compounds.

Before your next initiative

List what it depends on: data, governance, team capability, another team's output. Then mark which of those foundations exist today and which don't. If more than one is missing, the initiative you're about to start is two initiatives in the wrong order.

Expect the portfolios that ship reliably in 2026 to look narrower on paper and deeper in foundations than the ones that stalled through 2024 and 2025. The sponsorship pressure is still on revenue-facing use cases, but the organisations that join the next 7%-scaled cohort are the ones whose data, governance, and skills work sits on the same roadmap as the pilots, not on somebody else's backlog.

AI Readi's value chain impact analysis makes the dependencies visible by going to the contributors who live inside each process. Phase 5 feeds Phase 7: once you can see how processes connect upstream and downstream, the dependency order between initiatives falls out of the operating model rather than out of a planning meeting.