Every dependency exercise I have sat in starts as a scheduling conversation and turns into an architecture conversation, and it turns at a predictable moment. It turns when somebody stops listing which programme depends on which other programme and starts writing, inside each cell, what is actually being handed over.
A list tells you about sequence. A filled-in grid tells you about substance, because the same words begin to appear in cells that have nothing else in common.
The cleanest example I have kept is a dependency matrix drawn across a portfolio of six transformation programmes at an international health insurance group. Six programmes give you thirty pairings once you take out the diagonal. Twenty-nine of them are filled. Exactly one cell came back empty, and the mirror of that cell on the other side of the diagonal is not, so even the one gap runs one way.
Be clear about what the document is. It is a proposal, written by a firm bidding for the design work, and the matrix was offered as analysis rather than reported back as a finding. Nothing here is a delivered outcome. It is a picture drawn before the work, which is precisely why it is worth reading: even a seller's own drawing, made to win a mandate, could not avoid showing what the portfolio was really waiting on.
A filled matrix is an architecture drawing that nobody commissioned
The discipline is in the filling. A list lets a programme describe its neighbour in one word. A cell forces you to name the artefact, and the artefact is where the argument lives.
Read the whole grid and most of it behaves as expected. A portal for partners and providers to reach and execute processes. A platform for online sales. A quotation engine. A data exchange arrangement for outside parties. A telephony platform. Workflow and business rules for pre-authorisation and case management. Each of those turns up once, or twice at most, in the cells where two specific plans meet. Local, particular, ownable.
Two items refuse to sit still.
The two that kept coming back
The first is analytics and reporting. It is named in ten cells. Nothing else in the matrix comes close.
Its distribution is more interesting than its count. All ten of those cells pair with one programme, the one consolidating the estate onto a single system, and they run in both directions. Every other programme in the portfolio needs a reporting capability out of that consolidation, and the consolidation needs reporting requirements back from every one of them. That is not a dependency between two plans. That is five plans asking one plan to carry something on their behalf and one plan asking five plans what to carry.
The second is standardisation of process. Five cells name it, in wording that barely changes between them, including a definition of which services will be supported globally, regionally and locally. A sixth asks for the automation of standardised processes, which is the same requirement approached from the automation side rather than the design side. Where analytics clustered around the platform programme, standardisation clustered around the service model work.
The third repeated item is a single and complete view of the customer, in four cells, phrased variously as the view, as a customer relationship system, and as the requirements that such a system would need. I do not count it separately. A single view of a customer is what you get when process data is defined the same way everywhere and can be joined. It is the outcome of the other two, appearing in the matrix as though it were a system you could buy.
Neither of them was anybody's job
The part that matters is what the two recurring items were not.
Neither was a programme. Analytics and reporting entered the portfolio as an attribute demanded of a platform migration. Standardisation entered as a design task inside a service model exercise. The proposal's own programme structure chart bears this out: it hangs six workstreams off the board, and neither recurring item is among them. So the two things nearly every plan depended on had no box of their own, no team, and no date. They existed only as obligations running between other people's plans, which is the weakest form of existence a piece of infrastructure can have.
The proposal's answer to that situation is governance. Dependencies contracted between provider and receiver, with a programme office accountable for orchestrating the traffic. Solution dependencies routed through a design authority so that anything spanning workstreams is assessed end to end. Requirements tracked through a traceability matrix. Benefit dependencies documented and watched through change control so they are not eroded by incremental change. Timing dependencies driven out through one integrated plan.
Every one of those is sensible, and not one of them builds anything. Put the matrix and the governance design side by side and you see a portfolio that has diagnosed a shared platform and prescribed bookkeeping. The document does not draw that conclusion, and it was not asked to. The reading is mine.
Why I keep this one on the desk
Nobody is running a six-programme service model portfolio and calling it artificial intelligence. But the shape of the portfolio on my desk today is the same shape, and the exercise produces the same answer.
The typical list: a copilot for claims handlers, retrieval-augmented search across policy wordings and clinical guidance, a document intake model for the post room, a lapse model in the actuarial team, and one or two carefully scoped autonomous experiments in low-risk back office work where a human still signs. Five or six initiatives, five or six owners, each with its own sponsor and its own pilot.
Give them rows and columns and make somebody fill in every cell. The model will not be what the cells name. Model quality has become the most purchasable thing in the stack, and getting a decent one is now a procurement decision rather than a research programme.
What the cells name instead is familiar. A definition of the process the assistant is operating inside, so its suggestion can be judged against something. Event data recorded the same way in every region, because a claim that means one thing in one hub and another in another cannot train or evaluate anything. Labels somebody agreed and wrote down. Lineage, so that when an output is challenged you can say which system the input came from. And a way to know whether the answer was right, which is an evaluation set, and an evaluation set is standardised process data with human judgment attached.
The retrieval work makes the point sharpest. A vector store is a filing decision before it is a technical one. Retrieval quality follows from whether documents are versioned, owned, dated and current, because a well-built index over three overlapping copies of a policy wording returns the wrong one with total confidence. The infrastructure conversation is easy to have and cheap to buy. The definitional conversation underneath it is neither, and it is the one that decides the outcome.
- 29 of 30
- Cells carrying content in the proposal's dependency matrix
- 10
- Cells naming an analytics and reporting capability
- 5
- Cells naming standardisation of process
- 4
- Cells naming a single and complete view of the customer
What the exercise is worth
Political agreement on Europe's artificial intelligence rules has been reached and nothing is yet being asked of anyone. That gap is the useful window. The questions that regime will eventually put to an insurer, about what a system was trained on and why it decided what it decided, are answerable only by organisations that can trace a value back to a definition. That capability is built at the same layer this matrix was pointing at, and it takes longer than any model swap.
So the order I argue for is the order the matrix implies rather than the order the portfolio was funded in. One definition per counted thing, written down, with the query that produces it stored beside it. One named system of record per metric, with any second path declared as derived. A process design that is the same in every hub, or an explicit statement of where and why it differs. One owner per number, a person rather than a committee. Do those and you have shipped no models at all, and every model afterwards gets cheaper, including the ones nobody has thought of yet.
Nobody would have funded analytics and standardised process as a programme. They only became visible once somebody was forced to write, in every cell, what one plan was actually waiting on from another.
The matrix was drawn to manage a portfolio, and it worked as a management artefact. Read as an architecture drawing, which nobody asked it to be, it says something blunter. Two capabilities were load-bearing for the entire portfolio, both were treated as somebody else's deliverable, and the plan for both was coordination. That is how a shared platform stays unbuilt for years while six teams each pay a fraction of the cost of not having it.
Detail is as recorded in a consulting proposal prepared for an international health insurance group: its cross-workstream dependency matrix, its proposed programme governance and its staged delivery approach. The document is a bid. Its matrix was offered as analysis ahead of a decision, not delivered as a result, and no outcome from that work is claimed here. Reading it as a statement about shared data infrastructure is ours.
“Nobody would have funded analytics and standardised process as a programme. They only became visible once somebody was forced to write, in every cell, what one plan was actually waiting on from another.”
Get in touch
Put RealAI’s applied-AI team on your hardest data problem.
We help enterprises move from pilots to production: sovereign models, governed data, and agents you can audit. Start with a value-first assessment.