The Shape of a Programme That Actually Reaches Scale

Every programme plan has a last box, and the last box is where the plan quietly tells you what it was for. Most analytics plans I am asked to read end at a recommendation: a prioritised list, a business case, next steps that would happen if somebody funded them later. Those programmes finish on time and produce nothing that runs on Monday.

I have been going back through a data innovation proposal put in front of a European food and consumer goods manufacturer, and its method page is unusual for one reason only. The last thing named on it is industrial scale.

The last box decides the shape of the first one

Read the method page backwards and it stops being a diagram and becomes an argument. If the terminal state is a capability working at industrial scale across the business, the proof case cannot be a one-off. It has to run on data other cases will also need, land in an environment other teams can use, and leave something reusable behind. The destination reaches back up the plan and constrains every earlier choice.

Invert it and the same mechanism works against you. If the terminal state is a report, the proof case is free to be a beautiful special case. Nobody needs the extract repeatable, because nothing runs twice. Nobody documents the transformations, because nothing downstream will consume them. Nobody argues about where the workload should live, because it will not live anywhere for long. Each of those decisions is locally rational and collectively fatal, and none looks like a mistake when it is made.

This is why I have stopped treating a proof of concept as a technical exercise. Pipelines are close to assembly work now, deployment is close to solved in most stacks, and the early language-model pilots crossing my desk stand up in days rather than quarters. What stays hard is that the second use case costs as much as the first, because the first was never asked to leave anything behind. It is why a RealAI Platform engagement is scoped backwards from the second use case, and why our Consult team asks what the terminal state is before it asks what the pilot will be.

The bar before the first case

The proposal is unusually blunt about selection. A candidate qualifies only if it can plausibly return five times the effort it consumes. Below that line the document does not treat the case as a modest win. It treats it as a reason the programme dies, printed in the same list as missing senior sponsorship.

That inversion is worth sitting with. Most prioritisation exercises I see produce a ranking, which guarantees that something is always at the top and therefore always worth starting. A floor permits the answer that nothing currently qualifies, which is the answer that saves the most money. It also does something structural: a case returning five times its effort is large enough to defend three months in, when the sponsor asks why an engineer is still on it.

The rest of the failure list has the same character. Data not available across silos, or actively protected by the people who own it. The organisation lacking the combination of business people who think in data and specialists who can build. No discipline for reporting benefit after the closing meeting. No habit of improving the fact base once it exists. Not one is a modelling problem, which is why not one was ever solved by a better model.

Six to eight weeks, and the condition in the footnote

The time box is drawn as one week, then four to six, then one. A single week at the front to settle what is being tested and what it would be worth, the middle to get the data into a state where the test means anything and then run it, a single week at the end for the benefit conversation.

The shape is doing quiet work. One week at the front keeps the hypothesis falsifiable rather than letting it expand into a discovery phase. One week at the back forces the benefit argument while the sponsor is still in the room. Six to eight weeks in total is long enough that the data work is real and short enough that sponsorship survives it.

Then there is the footnote, which says four to eight weeks is typical for established data analytics environments. That conditional is the entire risk. The organisations that blow through the window rarely have a hard modelling problem. They are the ones where nobody can say which system is the source of record, where two departments hold different definitions of the same measure, where lineage exists only in somebody's memory of a job they wrote. In those estates the middle band is not four to six weeks of analysis. It is four to six weeks of archaeology and whatever is left.

If the terminal state on the plan is industrial scale, that archaeology is not a delay. It is the first instalment of the thing you are actually buying. If the terminal state is a report, it is pure cost, and it gets cut.

The effort table is a map of authority

The densest page in the proposal is a table nobody puts in a sales document unless they have been burned. Fourteen activities, each split as a percentage between supplier and client, published before signature.

The pattern is the content. The supplier takes the grind: 90/10 on getting the data into a form analytics can read, 90/10 on joining and reshaping it so the test can run and then be run again, 80/20 on working out how the source systems fit together and how much of what they hold can be trusted. The client takes everything that requires standing: 10/90 on settling which analytics platform will be used, 10/90 on clearing the security conditions before any data moves, 20/80 on convening the stakeholders who argue about benefit, 40/60 on monitoring whether it arrives. Three rows are genuinely shared at 50/50.

Reading it as a division of labour undersells it. It is a map of which obligations cannot be bought. No supplier grants itself access to a protected system, chooses the client's platform, or convenes an executive committee. Those rows are where programmes stall, and writing them down at proposal stage means the client sees its own workload before it sees the invoice.

One row does not add up: the row covering the working sessions where insights get named and the awkward questions get put on the table is printed as twenty percent and zero. I leave it as it stands, because a table that publishes obligations is more useful with its errors visible than tidied.

5x

Return on effort a candidate case had to clear to qualify

6 to 8 weeks

One week to frame, four to six on data and analysis, one on benefit

90 / 10

Supplier share of getting data analysable and reshaping it

10 / 90

Supplier share of choosing the platform and clearing security

Two prices for the same eight weeks

Two of the options on the commercial page run the same duration. One is a lean team priced on 1.3 full-time equivalents, delivering a first working case on something the client has already identified. The other is priced on 2.1, and the difference is a supplier-provided analytics environment connecting to data sources and warehouses the client supplies, platform and licensing free for the initial trial.

Two things are visible in that gap. The increase in people is proportionally far larger than the increase in the weekly rate, which is where the free trial is absorbed. And the cheaper option promises insight and a first commercial payoff, while the dearer one promises that payoff plus a foundation for further work. That is the industrial-scale phase sold, at proposal stage, as an object rather than an intention.

I would not adopt the commercial mechanics without thinking. An environment given away during a trial has an obvious second act, and the buyer should price the exit before accepting the gift. But the underlying point holds whoever supplies the substrate: the second use case is cheap only if something durable came out of the first, and nobody builds that inside a six-week window unless the plan already said they had to.

Scale is not the thing you attempt once the pilot has worked. It is the constraint the pilot has to be built to fit, and if it is not written into the last box on the plan, nothing upstream will be shaped to reach it.

What I take from a page of boxes

None of this requires the method on that page. The transferable part is the ordering discipline, and it costs nothing to apply.

Write the last phase first, and make it something that runs rather than something that reads. Set a floor for a first case rather than a ranking, and accept the answer that nothing qualifies yet. Time-box the case hard, and say out loud whether your estate meets the condition the time box assumes. Publish who owes what, in percentages, before anyone signs. And name what the first case must leave behind: the definitions, the lineage, the landed tables, the environment the second team inherits.

A programme built that way can still fail. It fails honestly, on a case that did not clear the bar or an estate that was not ready, and both are findable in weeks. A programme whose last box is a recommendation fails differently. It succeeds on its own terms, and there is no phase after it.

Figures and structure are as printed in a data innovation proposal prepared for a European food and consumer goods manufacturer: its method page, its delivery and effort tables, its commercial options. It is a proposal. It produced an offer and recommendations, not delivered results, and the benefits it quotes are proposal-stage claims rather than measured outcomes. The method and the template are the advising firm's work product, not ours. Reading the plan by its last box is mine.