Transformation Is a Sequencing Problem Before It Is a Technology Problem

Every workstream in your programme is individually viable. The programme can still fail — because the risk was never in the projects. It was in the order.

Every workstream in your programme is individually viable. The programme can still fail — because the risk was never in the projects. It was in the order.

Each project in the programme was approved on its own merits. Each one is sound. And the programme is still at risk — because nobody has decided the order in which the dependencies must resolve, and the order is the whole game.

A transformation programme rarely fails because one of its projects is bad. It fails because individually viable projects are forced onto a single timeline without anyone mapping how their dependencies collide. A platform decision waits on a board ratification. The board ratification waits on a business case. The business case waits on a data-migration estimate. The migration waits on the platform decision. Each project is fine. The sequence is impossible — and the sequence, not the projects, is where the programme lives or dies.

The instinct to force everything onto one headline go-live date is the specific error that produces this. Transformation is a sequencing problem before it is a technology problem, and treating it as the latter guarantees the former will remain unmanaged until it becomes a crisis. The Jersey AI Playbook already points in the right direction here — its 'managed transformation' principle calls for real stage gates from proof of value through proof of concept to pilot and scale, each a genuine stop-or-go decision rather than a milestone everyone waves through. A stage gate is a sequencing instrument. The Playbook names the discipline; what firms then have to do is actually operate it, workstream by workstream, instead of collapsing every gate onto one date.

Viable projects, impossible order

The trap is that every individual project can survive its own business case while the programme built from them cannot survive contact with reality. A regulated transformation typically depends on a lattice of things that must happen in a particular order: board approval, sometimes a grant or funding process, a core-platform selection, a data migration, and the implementation capacity to do any of it. Each is legitimate. Each is approvable. But they are not independent, and approving them independently creates the illusion that the hard part is done when it has not yet begun.

The pattern I return to is that the real question in a transformation is almost never whether to proceed. It is in what order, and against what entry criteria for each step. A firm that has answered whether but not in what order has answered the easy question and left the hard one open — and the hard one is where the money and the timeline are actually decided. Sequencing is not programme administration. It is the core strategic decision, wearing the costume of a Gantt chart.

A transformation programme is not a set of projects. It is a dependency graph — and the graph, not the projects, is what you are actually managing.

Manage the dependency graph, not the go-live date

The correction is to stop managing to a single date and start managing the dependency graph explicitly. Managed to a headline date, projects proceed regardless of readiness and collide, and the risk stays hidden until something stalls. Managed as a graph, each workstream has entry criteria it must meet before it can responsibly start, the sequence flexes around blockers rather than pretending they do not exist, and a single delay is contained instead of toppling everything downstream of it. The organising question changes from whether to proceed to in what order, and against what preconditions.

Making that concrete requires an instrument, not a Gantt chart. For each workstream, name four things: its entry criteria, what it is blocked by, what is blocked by it, and who owns it. A workstream with a blank entry-criteria cell is a workstream nobody has decided how to start; a dependency with no owner is exactly the gap where sequencing risk hides. Table 1 is that worksheet, with a worked line — copy it and complete one row per workstream before the programme plan is signed off.

Table 1 — The dependency worksheet: complete one row per workstream before committing to a plan

The discipline this imposes is uncomfortable but productive. It forces the firm to admit, early, that some things genuinely cannot start yet — and to say so out loud rather than booking them into a plan that everyone privately knows is fiction. A programme that flexes around real dependencies is slower to draw but faster to deliver, because it is not repeatedly halted by collisions that were visible from the start.

Sequencing failures are quiet until they are not

The insidious thing about a sequencing problem is that it produces no early warning. Every status report is green, because every project is individually on track. The dependency collision is not on any single project's risk register, because it is not any single project's risk — it belongs to the space between them, which nobody owns. So the programme sails along, apparently healthy, until two workstreams reach the point where one needed the other to have finished first, and the whole thing stops at once.

This is why sequencing has to be owned centrally and explicitly, as a distinct discipline, rather than assumed to emerge from the sum of well-run projects. The dependencies between workstreams are precisely the things that fall through the gap when everyone is managing their own scope diligently. Someone has to own the graph — the whole graph — and their job is to watch the edges between projects, not the projects themselves. Without that role, sequencing risk is nobody's job right up until it becomes everybody's crisis.

Enterprise AI is the sequencing problem, intensified

Enterprise AI makes this discipline more important, not less, because an AI portfolio depends on more prerequisites than almost any other kind of transformation. A pilot that works cleanly cannot scale until identity and access are sorted, until the data foundation is governed, until the platform decision is made, until the outsourcing and legal position is clear, and until the workforce is ready to exercise oversight. Each of those is a dependency, and the order in which they resolve determines whether the pilot ever becomes production or dies in the gap between proof and scale.

Series 2's work on foundations made the case that AI does not scale until the underlying capabilities are in place. Sequencing is the programme-management expression of exactly that finding: the foundations are not just things you need — they are things you need in an order, and getting the order wrong strands even a technically successful pilot. The firms that will convert AI experiments into operating capability are not the ones with the best models. They are the ones that treated their transformation as a dependency graph, decided the order deliberately, and gave someone the explicit job of managing the edges. The technology was never the hard part. The order always was.

Jersey has a structural advantage in this that larger jurisdictions do not, and it is worth using. The Playbook's 'island advantage' principle — active coordination through the Jersey AI Forum, Jersey Finance, Digital Jersey and the JFSC — means that some of the heaviest shared dependencies, from data-protection expectations to common infrastructure, can be sequenced at a jurisdiction level rather than reinvented inside every firm. A programme lead who knows which foundational questions the island is already working through can sequence around them, rather than treating every dependency as purely internal. The advantage is only real if it is used, but for a firm mapping its dependency graph, some of the upstream nodes may already be someone else's workstream.

Look at your transformation programme's plan. Does it show you the order in which your dependencies must resolve and who owns the space between the projects — or just a set of individually healthy workstreams all aimed at a date that assumes none of them will collide?

This is the tenth in a practitioner run extending AI Strategy in Jersey FS from AI governance into AI-enabled operating-model transformation.

Sources: AI Strategy in Jersey FS, Series 2 Part 4 (foundations that determine whether AI scales); Government of Jersey et al., Jersey AI Playbook (2026) — 'managed transformation' (real stage gates: POV, POC, Pilot, Scale) and 'island advantage' (coordination via the Jersey AI Forum, Jersey Finance, Digital Jersey and the JFSC); JFSC, Guidance on the use of AI in Jersey's financial services sector (2026) — Principle 1 (governance, oversight readiness).

Professional disclaimer: The views expressed are my own and are shared for general informational purposes. This content is intentionally non-confidential and does not include proprietary, client-specific, or employer-sensitive information. It is not legal, regulatory, investment, or professional advice; readers should seek appropriate advice for their circumstances.

Financial services leader (20+ years) | Lean Six Sigma Green Belt | London School of Economics (LSE) AI Leadership Accelerator

A version of this article was first published on LinkedIn as part of the Sequence body of work. This is the canonical version.

The views expressed are the author's own and shared for general information. This content is intentionally non-confidential and does not include proprietary, client-specific or employer-sensitive information. It is not legal, regulatory, investment or professional advice. © 2026 Paul Soares. Sequence is the trading name of Sequence Advisory Limited (in formation) · hello@sequenceadvisory.com