Most delivery dates are a negotiation you are having with yourself. Somebody proposes a date, somebody argues it down, and the number that survives settles what the plan supports against what the sponsor will accept. Which is why so much delivery advice is really negotiation advice: how to defend an estimate, how to make a slip land quietly.
Then you meet a programme where the date is not yours to trade, and the apparatus stops.
I keep coming back to a readiness review of a platform rebuild at a European energy retailer for that reason. The programme was replacing the systems its business-customer sales, contracting and billing ran on, and its ready-by date was set by the selling season, the weeks when its customers actually buy. Nobody on the steering committee had chosen that date and nobody could move it. It sat outside the programme the way weather sits outside a construction site.
The season does not take a meeting
A market-owned date removes the sentence every large programme is quietly built around: we will need another six weeks. It removes the softer version too, where nobody asks for the six weeks but everybody plans as though they will be granted.
What is left is a fixed endpoint and an unknown rate of travel, and the review found both. The programme was still in start-up at a moment when its own plan had it delivering. That is a more precise finding than "behind schedule": the question is not how many weeks late a programme is, it is which phase it is in, because a start-up organisation and a delivery organisation have different reporting and different people.
The rate of travel was the honest part. A new method had been adopted, the teams had been assembled recently from individual contractors working together for the first time, and no measured cycle had completed. Programme management put the plan's reliability at 50 percent and footnoted it as their own estimate. That is creditable to write down, and it means that for the first stretch of the run to the season, the plan's unit of account did not exist yet.
Fixed endpoint, unmeasured velocity. There is one free variable left, and it is scope.
The one lever nobody was pulling
Three strategic questions were still open while the clock ran: whether a class of sourcing arrangement was in scope at all, whether the system had to be reusable beyond its home market, and how modular the products, services and system itself needed to be. None is a schedule question. Each determines the shape of the build, which means each was silently setting the size of the thing due on a date nobody controlled.
Alongside that, five benefit types rode on the same programme: lower cost to serve, lower cost to acquire, higher market share, higher revenue, higher profit. A business case in five currencies is one you cannot fail and cannot steer by. The review put the consequence plainly: the steering committee had no levers to monitor and control the benefits case, and the benefits had no clear linkage to the programme's phases. So nobody could say which parts of the scope carried which part of the value, which is exactly the knowledge you need on the day somebody asks what can come out.
That is the failure mode I want to name. When a date is immovable, scope is not a fallback lever, it is the only lever. Yet it takes the most preparation to use, because using it means knowing in advance, and in writing, what can be deferred without breaking the season. Programmes squeezed by a market date are rarely squeezed for being slow. They are squeezed because when the moment came, nobody could say what to drop.
The plan had no unhappy flow
A market-owned date punishes optimism quickly, and the review was direct about how optimistic this plan was. It was built on the positive scenario only. No slack. No allowance for the reorganisation the same people were living through, for holidays, for other programmes competing for the same staff, or for market events. None of those omissions is exotic and all are certain. A plan that models only the happy path is a best case presented as a commitment, and when the commitment is to a season rather than a sponsor, the gap becomes visible in public.
There was also nothing behind the plan. The review recorded no back-up plan for the platform not delivering on time, or at all; the only short-term retreat was the incumbent system the programme existed to escape, costly and structurally unable to carry the target model. Meanwhile the platform being extended already carried more than 50 issues a month before anyone added to it, and the estimate of new code the extension needed, around 30 percent, was flagged in the review as an estimate wanting supporting analysis.
Read together: a programme running toward a date it did not set, on a base of unproven reliability, with an unsized increment and no route off the road.
Somebody had to argue the deadline into the report
The date was not handed to the reviewers as an agreed fact, which is the reason I trust this review more than a tidier one. Working notes inside the file show the review team expecting the deadline to be contested by the programme, weighing whether the selling season really was the binding constraint, concluding from their own evidence that it was, and deciding to leave the statement as hard as they had written it.
A fixed date in an assurance report is often the reviewer's assertion of what ought to be immovable rather than a fact the delivery organisation accepted. The assertion does real work, because it converts an open-ended build into a scope-cutting exercise. If the programme quietly disagrees, the conversion never happens: everyone nods at the date and plans as though it will yield.
So the practical test, before any of the above is worth running, is whether the people building the thing believe the date binds them. Ask them separately from the sponsor. If the answers differ, you have two programmes, not a scheduling problem.
A date you cannot move converts every planning conversation into a scope conversation, whether or not anyone in the room notices. The programmes that survive one are the programmes that noticed early and wrote down, in advance, what they were willing to leave out.
What early findings actually buy
The review issued twelve recommendations, each traced to one of its four headline findings, and marked each one addressed or not addressed by the time it reported. Three were addressed. Nine were not.
The three that moved were the plan approval, the design and roadmap work, and the phased planning artefact. All three are documents. Nothing needing money, an outside party, or a reversal of the platform bet moved: the independent assessment, the alternative route if it came back badly, and the fallback for non-delivery were all outstanding, as were the recommendations on quality assurance and on keeping the few people who understood the system.
That is not a criticism of reporting early. It is a measurement of what reporting early buys. Tell a programme something while it is cheap to act on and you get artefacts inside a month; findings that require a commitment to be unwound need a different mechanism, with a budget line and a named decision date, or they sit where these sat. The assurance plan made the same point by accident: of its eight continuous checkpoints across the year, six were still marked to be decided.
Why I am writing this down now
Because the shape recurs, and it is about to recur in a place with much thinner instrumentation.
Machine learning work is arriving attached to commercial calendars: a renewal season, a quarter close, a policy date. Retrieval-augmented assistants and copilots for service, sales and underwriting teams are scoped against dates their sponsors took from a market event rather than an estimate, and the estimate is weaker than the one above, because nobody has a measured velocity for building, evaluating and correcting a system whose behaviour is statistical. That review's plan reliability figure was 50 percent, and written down. For most AI programmes I see, the equivalent is unstated and worse.
The regulatory version is visible too. With the European AI Act having reached political agreement, timetables are being drawn against a date no programme controls, the identical structure with a different owner. The right response is the one a selling season demands: decide now what the smallest defensible delivery looks like.
Most of that work is unglamorous, and on a RealAI Platform engagement it is what we do before anyone scopes a model. A benefit bound to each deliverable, so a cut has a price tag. An evaluation set assembled before the build, so "good enough to ship" is a measured claim rather than a meeting. Lineage on the inputs, and a vector store whose contents you can account for, so the day an answer is wrong you can say where it came from. The MLOps and data readiness groundwork that decides whether your second release takes days or a quarter. And a written fallback: what people do if the system is not ready, or is ready and wrong. Early autonomous experiments belong there too, scoped narrowly and behind a person, because they are the part nobody can estimate.
The date will arrive on time. It is the only thing in the programme that will.
Figures are as recorded in an independent readiness review of a platform rebuild at a European energy retailer: its method statement, its findings, its recommendation status grid and its assurance calendar. That review produced findings and recommendations ahead of a delivery phase, not delivered results, and the plan reliability figure was the programme's own estimate rather than the reviewers'. Reading a market-owned deadline as a scope-governance problem is ours.
“A date you cannot move converts every planning conversation into a scope conversation, whether or not anyone in the room notices. The programmes that survive one are the programmes that noticed early and wrote down, in advance, what they were willing to leave out.”
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.