Six Ways a Data Programme Dies, Named on the Slide Selling It

Risk sections in proposals are decoration. They name hazards the buyer already knows about, worded carefully enough that nothing lands on anyone. I read them fast and I have never once changed a plan because of one.

Which is why I keep returning to one delivery slide inside a data programme proposal written for a European food and consumer goods manufacturer. It runs the engagement left to right across five stages: framing the question, preparing data, analysing it, testing whether the answer holds, and following the money it was supposed to release. Above the stages sits one sentence, repeated three times across the run: these are challenges to overcome. Underneath it, six ways the work fails.

Not six risks to the client's business. Six ways this engagement, priced two slides later with a weekly rate and three purchase options, produces nothing. A supplier printed them inside the document asking to be paid. I have used that list more often than I have used the method beside it.

The six, in the order they can kill you

The list is grouped by where in the run the damage happens, and the grouping does more work than the items.

At the front, before anyone touches data, two things have to be true. Somebody senior has to want the answer. And there has to be a candidate worth the trouble, where worth is given a number: a case that cannot plausibly return about five times the effort it consumes does not qualify. Read that as a floor rather than a ranking. Most prioritisation exercises produce a sorted list and start at the top regardless of what the top is worth. This one says that if nothing clears the bar, the correct move is not to begin.

In the middle, the first of the two failures is written with two halves joined by an and-or. The ordinary half: the data lives in systems that do not talk, so assembling it is a project of its own. The other half is not ordinary, and most suppliers will not print it. The data is available and its owners will not hand it over. That is a sentence about power inside the client, placed in a document the client is being asked to sign. The second failure is a staffing one with a specific shape: not a shortage of data scientists, but the absence of the pairing, people who know which answer would change a decision working alongside people who can build the thing.

At the far end, both failures are about attention after the exciting part finishes. Nobody keeps reporting whether the benefit arrived. Nobody keeps improving the fact base once the first results land. These are the two consultancies have least incentive to raise, because both happen well after the invoice clears.

Six items. Five stages. Two at each end and two in the middle, which means the pipeline is more fragile at its boundaries than in its technical centre.

Not one of them is a modelling problem

Line the six up and look for the word model. It is not there. No accuracy, no algorithm choice, no feature engineering, no compute. The technical middle of the run, the part everyone in my field spends a career on, contributes nothing to the list of ways the programme dies.

That was not humility. It was accurate, and it has become more accurate since. A retrieval-augmented question-and-answer layer over a document set is an afternoon now, not a quarter. A copilot pilot on a well-understood workflow stands up in days. The things that used to justify a programme's existence have become its cheapest part.

None of that touches the access failure. A retrieval layer needs read access across exactly the silos whose owners defend them, and it needs that access continuously rather than once, which makes the political question harder rather than easier. Nor the sponsorship one: a running demonstration can create a sponsor, but it cannot create the authority to redirect a budget.

The slide next door explains why the supplier printed them

What makes the list a finding rather than a nice piece of candour is the slide that follows, which takes the same run through a worked example case and divides it activity by activity, fourteen of them across three tables, each carrying a percentage split between supplier and client.

The pattern is clean. Where the work is technical grind, the supplier takes almost all of it: making raw data usable for analysis and reshaping it to test and refine the hypotheses are both ninety percent supplier and ten percent client, and working out what the data model actually means sits at eighty to twenty. Where the work requires authority, the client keeps almost all of it. Choosing the analytics platform and putting the security safeguards in place before any data is gathered are both ten to ninety. The stakeholder conversation about the business case is twenty to eighty, and watching whether the benefit arrives afterwards is forty to sixty. Three activities are genuinely shared at fifty-fifty: writing the hypotheses, sitting with the engineers to source the data, and analysing and validating the result.

The banding is one week to frame, four to six weeks in the middle, one week at the end, and a footnote elsewhere puts a typical case at four to eight weeks for an established data analytics environment. That conditional is a failure mode wearing a different coat: the organisations that overrun are the ones that did not have such an environment and had not noticed.

One row is broken. Engaging stakeholders to make the key issues visible reads twenty percent and zero percent, which sums to twenty. I am leaving it rather than repairing it, because a proposal that publishes its own failure modes and also ships an arithmetic error is a fair picture of how these documents get made.

Put the two slides side by side and the candour explains itself. All six are conditions inside the buyer rather than the supplier, and the rows that carry them are the ones the client holds at sixty to ninety percent: the platform decision, the security clearance, the stakeholder conversation about the business case, the monitoring afterwards. The supplier cannot fix those by working harder, buy past them, or subcontract them. Naming them in writing is the only instrument it has.

6

Failure modes printed inside the proposal, across a five-stage run

90% / 10%

Supplier to client, on making raw data usable for analysis

10% / 90%

Supplier to client, on clearing the security position before data moves

6 to 8 weeks

The planned run, one week to frame and one week to argue the benefit

What has changed, and what has not

Take the last two items, the ones about discipline after delivery, and read them against how a generative system is actually run. Continuous benefit reporting and continuously improving the fact base are the same muscle an evaluation set requires. Somebody has to write down what a good answer looks like, keep the examples current as the business shifts, and rerun them when anything changes. Every team I have watched fail at evaluation had already failed at benefit tracking on the previous programme, using the same reasoning both times: the interesting work is finished, the thing is live, move on.

Lineage has gone the same way, from a governance nicety to something with a deadline attached. The AI Act text is agreed and not yet in force, so it is nobody's obligation yet, and when the duties arrive they will ask where a system's inputs came from and what they were allowed to be used for. That is a records question about the middle of this exact pipeline, answered easily by whoever kept the discipline at the far end and painfully by whoever did not.

The failure modes have not changed, then, but their weights have. The technical middle got cheap, so the two ends got heavier. The rows a supplier used to own at ninety to ten are the ones tooling and MLOps have largely absorbed. The rows the client owned at ten to ninety are untouched, because nothing has been built that grants itself access to a protected system or convenes an executive committee.

A seller naming the ways its own engagement can fail is not being modest. Those six are the only parts of the job a supplier cannot do on the buyer's behalf, so saying them out loud is the only lever it has.

Reading the list as a buyer

Six questions, answerable before anyone is engaged, none technical.

Who loses something if this does not happen, and are they senior enough to make somebody else lose something too. What effort does this consume, and is the return credibly several times that rather than merely positive. Which systems hold the data, and for each one, name the person who has to say yes. Which of your own people can tell a modeller which answer would change a decision. Who is still reporting the benefit three months after go-live, by name rather than by team. And who is allowed to change the fact base when the first result shows the question was wrong.

Answer those and you have built nothing. You have a decision about whether to start, which is what the list was for. It is also where a RealAI Consult engagement opens, and why we ask which number you intend to move before which use case you want to run. When the answers come back thin, the next step is a RealAI Platform review of the sources rather than a bigger workshop.

The six failure modes, the five-stage run, the effort splits and the durations are as printed in a data programme proposal prepared for a European food and consumer goods manufacturer, including the row whose percentages do not sum. It is a proposal: it produced an offer and a plan, not delivered results. The method in that document is the authoring consultancy's own; reading its list of challenges as the most durable thing in the file is mine.