They Bid for the Smaller Priority

Every portfolio conversation I sit in reaches the same slide. Somebody has written the priorities down one side, put a number beside each, and sorted the list. The sort is the decision. Whatever ends up at the top gets the money and the good people, and the discussion afterwards is about sequencing rather than about whether sorting by size was the right operation.

I have been reading back through older operating-model material for exactly this reason: work from before there was an obvious system to sell tends to show its reasoning. The clearest example on my desk is a capability statement and proposed approach written for an international health insurance group. The client had published six core priorities for its operating model and hung a value at stake on each. Five carried a money figure. The sixth carried the letters TBD.

The proposal did not bid for the biggest number.

Six priorities, five numbers and a blank

The six priorities are the ordinary shape of an insurance operating-model programme. Two of them are what this piece is about: automation and digital service, and the global service model. The other four are the sort of thing every such list carries, and which four they are does not change the arithmetic.

Each carries a monetary tag, which is not how most technology portfolios are presented even now. The tags are not business cases; they are sizes. They say how much of the operating result sits behind each door before anybody argues about which door to open, and once every priority carries a size the investment conversation becomes subtraction rather than advocacy.

Five of the six carry a figure, £265M between them. The sixth, the global service model, is tagged TBD.

The bid asked for two of those six work streams, automation and digital service and the global service model, plus governance across all six.

The arithmetic of the choice

The automation and digital service priority is the £30M one. The priorities slide does not say so, because the value tags sit there as a block, but it resolves a few pages later where the digital service work is sized at £8M and the automation work at £22M. Eight and twenty-two make thirty, and that priority is those two halves in one line.

So the bid targeted £30M of £265M plus a priority nobody had sized: a little over a ninth of the quantified value at stake, and a blank. The largest tag on the slide, £90M, went untouched, and so did the two beneath it.

Read that as commercial timidity and you have misread it. A bid is a claim about what the bidder can actually move. Whoever wrote this had decided the largest tag was not where an outside team changes the number, and that the two smaller items were where an outside team changes everything else's number.

The justification is stated plainly: those two priorities touch large parts of the operating model and carry many dependencies into the other four, so a consistent integrated design needs breadth across the estate and depth in each element. That is not a value argument. It is a plain way of saying these two are load-bearing.

The evidence that the small one was the right one

That claim would be easy to make and hard to check, except that the same deck checks it.

A later slide lays all six priorities against each other as a grid and forces each cell to name the specific thing one work stream owes another. Of the thirty off-diagonal cells, twenty-nine are populated. The one gap is asymmetric: a priority declares nothing back to a priority that declares a dependency on it. That blank is the only cell I would want a meeting about, and you only find it by populating the whole grid rather than the interesting parts.

Read that grid down the global service model column and something uniform appears. All five populated cells open with the same ask: standardisation of process. Not a footprint, not a headcount, not a technology. Five work streams, five owners, one identical requirement, and it is the first thing each of them says. One other column runs uniform, the core system one, where every populated cell ends on analytics and reporting. That uniformity sits at the foot of a list of system requirements rather than at the head of the ask, which is the difference between a platform everything waits on and a line item everybody remembers to include.

The automation and digital service column shows a different pattern. Other work streams reach into it for digital front doors of their own, a separate one each: one for partners and providers to transact through, another for pre-authorisation and case management. The service model work stream adds defined self-serve processes to the same column.

That is a dependency argument instrumented rather than asserted. One targeted priority owes everybody a standard. The other owes everybody a channel. Neither is where the money is, and both are where the money gets stuck.

The blank is the interesting entry

The TBD is the part of this that keeps recurring in agentic work.

The global service model priority has no size, but it has a named benefit driver, productivity gained from customer analytics and support tools, and a specific diagnostic: the regional contact centres are sub-scale, each under a hundred seats, and running several stand-alone units per region will not pay for itself. The deck records rather than smooths over the tension that locally relevant service enables regional growth, so consolidation economics and local relevance pull against each other.

Still no number. The honest reading is not that the value is small, but that nobody yet had a measurement good enough to produce one. The neighbouring priority says it out loud: the ambition is for the digital estate to carry more than nine in ten member interactions, against a current state in which the organisation cannot gather information continuously from its touch points and captures only a few satisfaction scores.

A TBD is a telemetry statement wearing a finance costume. It says: this part of the business is not instrumented well enough to be argued about in money.

Five priorities carried a money figure and one carried the letters TBD. The bid went after the second-smallest number and the blank. Sorting the list by size would have picked neither, and sorting the list by size is what almost everyone does.

What this does to an agentic portfolio

Every insurer I talk to now has a list of candidate agentic use cases with a value column beside it, sorted by that column. The sort does here what it did there: it points at the largest tag, usually distribution or the core system migration, and steers the first agent programme into the two places where a copilot or an agent loop changes nothing on its own.

Three things carry over intact.

The first is that a target belongs to a process, not to a programme. The automation argument here carries a headline ceiling, gains of up to thirty percent, and never turns it into one programme-wide target. It puts the proven range at fifteen to thirty percent across policy servicing and claims, sets a target automation level per process against a benchmark, and names the two drivers behind the £22M as a five percent cut in average cost and ten percent more claims handled per person. Graded autonomy is the same discipline in different vocabulary: you do not grant a fleet of agents one autonomy level, you grant each process the level its evaluation set supports.

The second is that the uniform column is the platform. Five work streams asking for standardised process definitions is, in current terms, five agent teams about to write their own version of what a claim is. Until that standard exists as an artefact somebody owns, every retrieval-augmented service agent grounds itself in a slightly different reading of the same operation, and the disagreements surface only in production. That is the layer RealAI's Agentic OS exists to hold, and no value column ranks it first.

The third is the blank. Under the EU AI Act, a high-risk deployment will have to carry logging, human oversight and post-market monitoring that stand up to inspection. A priority you cannot size is one you cannot monitor, and a priority you cannot monitor is not one to put an autonomous loop into. Model risk management people have known this for years: unmeasured is not the same as low risk, it is the same as unassessable.

£30M of £265M

Value at stake tagged on the bid's targets, against a quantified total the deck never sums

TBD

Value at stake on one of those two priorities

29 of 30

Cross-priority dependency cells populated in the same deck

5 of 5

Cells in the service-model column opening on the same ask

The test

Run two passes over your own list. Put a size on every item, including the ones that come back blank, and keep the blanks on the page. Then, for each item, count how many other items wait on something it owes them, and name the specific artefact rather than writing the word dependency.

The first pass gives you an investment case. The second gives you a sequence. This bid was written against the second while everyone reading it was looking at the first. Nothing in it was delivered. What survives is the choice, which cost the bidder the three largest tags on the page and was, I think, correct.

Figures are as they appear in a capability statement and proposed approach prepared for an international health insurance group: its operating-model priorities and their value-at-stake tags, the sizing of the two halves of the automation priority, the cross-priority dependency grid, and the benchmark ranges quoted alongside. That document produced a proposal and recommendations, not delivered results. The £265M total is a sum I derived; the slide does not state it. Reading the choice of target as a statement about movability is ours.