Most first-quarter AI plans are lists. Thirty or forty activities under four or five headings, spread across a timeline that gets more crowded the nearer it comes to the present. A list is easy to write because nothing in it has to be traded against anything else. Everything can be in the first quarter if nothing has a limit.
The mobilisation page I want to describe does the opposite. It is a grid: four rows, three columns, twelve cells. Four workstreams, three thirty-day sprints, one deliverable per workstream per sprint. The useful property of that page is not what it contains. It is the arithmetic that decides what it cannot contain.
A consumer and SME banking group operating across several European markets commissioned a board deliverable setting out an enterprise AI target operating model. One page of it is the ninety-day mobilisation plan. Nothing on that page had been run when it was written, so every figure below is something the design commits to rather than something anyone measured.
Each workstream carries one executive owner, written on the row rather than left to be inferred. Governance and risk belongs to the chief risk officer. Platform and data belongs to the CIO and CTO. Pilots belong to the product owners. People and scale belongs to the chief human resources officer. Beneath that, each of the twelve cells carries its own two-letter owner code for that one deliverable in that one month. Four owners for the lanes, twelve codes for the cells, and no cell left to the lane owner by default.
- 4
- Workstreams, all live from day zero
- 3
- Thirty-day sprints
- 12
- Cells, each with its own owner code
- 1
- Deliverable per lane per sprint
The challenge
The received advice about a first quarter, including advice I have given, is to run it as a sequence. Redesign one process, make its operational data trustworthy, put governance around it, then register and manage the agents that run it. I argued that case from market evidence in a separate piece on building infrastructure that agents can run, and the reasoning holds where the four pieces of work all pull on the same scarce team.
This plan runs its four workstreams in parallel from day zero, and it is worth being precise about why that is defensible here rather than treating it as a contradiction.
Look at what the first sprint actually asks each lane to produce. Governance produces an approved charter and policy. Platform stands up a cloud landing zone. People run executive fluency sessions. Pilots run design and prototyping. Only one of those four is on the critical path of a model, and it is the one that needs the least infrastructure to start. Sequencing this particular set would idle three lanes for a month each in order to protect a path that only one of them stands on. The lanes are parallel because their first month barely intersects, not because someone wanted a busier chart.
The second reason is that a regulated bank's compliance clock does not wait for its engineering. Obligations attach to systems the business switches on, and the business will switch things on during the ninety days whether or not the policy exists. Putting the charter and policy in the first thirty days is what makes governance a lane with a delivery date instead of a gate at the end that everyone eventually agrees to widen.
Parallel lanes do not remove dependencies. They move them inside the sprint, where there is no month of slack in front of them.
The cost of the choice is real, and it arrives later in the grid rather than at the start of it. That is the part worth reading closely.
The approach
Sprint one, days zero to thirty, is titled mobilise and MVP. Governance approves the charter and the policy. Platform sets up the cloud landing zone. Pilots do design and prototyping. People run fluency for the executive layer.
Sprint two, days thirty-one to sixty, is pilot execution. Governance runs the EU AI Act gap analysis. Platform builds the pilot data pipelines and the sanitisation on them. Pilots build the two named cases. People staff the key roles.
Sprint three, days sixty-one to ninety, is automation and scale. Governance automates the control library. Platform ships the first version of an MLOps registry. Pilots run user acceptance testing and validation. People launch the academy.
Two milestones are marked on the timeline. One is Policy Live. The other is Go-Live. A governance artefact and a production release given equal weight on the same line is a small piece of layout and a hard one to argue with three months later, when someone proposes that the policy can follow the release.
Read along a row rather than down a column and the sequencing inside each lane turns out to be doing work. Governance goes charter, then gap analysis, then automated control library. The order means the automation in month three is derived from an assessment completed in month two, so the library encodes what this bank was actually found to be missing. Control libraries usually arrive the other way round, as a generic list acquired first and mapped to a regulation afterwards, which produces controls nobody can trace to a finding.
The people row goes fluency, then staffing, then academy, and the academy is deliberately last. A curriculum written in month one can only teach a vendor's material. A curriculum written in month three can teach what two of the bank's own pilots ran into.
The pilots row is where the plan makes its sharpest reduction. The workstream is described as covering two to three cases, and on the page it resolves to exactly two: SME credit and fraud. Both sit on the lending and financial crime side of the bank. Neither is a customer-facing assistant. The wider portfolio designed in the same engagement is spread evenly, three cases in each of four business areas, as described in Three AI Use Cases in Each of Four Business Areas, So No Function Owns the Programme. The first ninety days are not spread evenly at all. Two of the four business areas get nothing, and the two that do are the two where a mistake is a regulatory event rather than a bad customer experience.
That is a defensible way to open a programme and an unusual one. The easy first pilot is the assistant nobody has to validate. This plan starts where the evidence has to hold up.
The outcome
Nothing described here was executed. There was no sprint one, no landing zone, no pilot and no academy at the point this page was written. It is a board deliverable, and the twelve cells are commitments a bank was being asked to fund rather than a record of anything that happened. The pilot names, the milestone labels and the owner codes are all planning artefacts.
What generalises is the cap, and the fragility that comes with it.
In a sequential plan, slack lives between the phases. In a parallel plan capped at one deliverable per lane per month, there is no slack anywhere, and the dependencies do not disappear. They relocate into the column. Sprint two asks the pilots lane to build SME credit and fraud in the same thirty days in which the platform lane builds the pilot data pipelines and the sanitisation those pilots will run on. Sprint three repeats the shape: user acceptance testing in the pilots lane, the first MLOps registry in the platform lane, same thirty days. Two of the three columns carry a cross-lane handover with no month of buffer in front of it.
A grid cannot express that. Rows say who owns what. Columns say when it is due. Neither can say that the pipeline has to be usable by day forty-five or the pilot build loses a fortnight it was never given.
So the amendment I would make to a plan of this shape is small. For each column that carries a cross-lane dependency, add one line naming the handover date inside the sprint and the two owners either side of it. Twelve cells, twelve owners, and two dates that fall in the middle of a month rather than at the end of one. That costs nothing at planning time and is the only thing standing between a parallel grid and a synchronised scramble in week eight.
The same deliverable carries a longer twenty-four week playbook, and the ninety-day grid is the first three months of it seen at a different resolution. Read against each other, the grid answers who is accountable and the playbook answers what a control actually is; that second question is the subject of The Twelve Weeks in Your AI Plan Where Governance Is Done by People. A programme needs both answers, and most decks supply one and assume the other.
Source: a board deliverable defining an enterprise AI target operating model for a consumer and SME banking group, and specifically the single page setting out the ninety-day mobilisation roadmap. It is a design, not a delivered engagement. The four workstreams, the twelve dated cells, the executive and cell-level owners, the two milestones and the two named pilots are all planned, and the copy we hold carries no evidence that any sprint was run. The twelve owner codes on the grid are two-letter abbreviations and are withheld here; the source does not say whether each stands for a person or a function. The reading that the cap of one deliverable per lane per sprint is the load-bearing decision, and that its price is a cross-lane handover buried inside two of the three sprints, is ours.