Every replatforming plan that crosses my desk this year has a date on it, and the date is the most confident object in the document. Everything upstream of it carries a range, a caveat, an assumption to be confirmed. Then the date arrives with no error bar at all.
I have started asking one question in those rooms before anything else. What happens on the day after that date if the thing is not there? Not the recovery plan for a bad sprint. The plan for the world where the new platform is late, or partial, or works for some customers and not the rest. The answer is usually a pause, then a sentence about how the team is confident.
There is a line in an independent readiness check I keep returning to, written on a business-customer platform rebuild at a European energy retailer. The review found no back-up plan for the case where the new system did not deliver on time, or at all, and added the qualifier that makes the finding land: the incumbent could serve as a fallback in the short term, at high cost, and in the long run could not deliver the business model the programme existed to build.
That is the whole problem in two clauses. There was a fallback. It bought weeks rather than outcomes, and it was expensive by the hour.
The fallback was the reason for the plan
Read the two findings side by side and the circle closes.
The programme picked its base system in a hurry because the incumbent business-customer solution was expensive. That cost made the replatforming urgent and compressed the selection, which the review says narrowed the field quickly and at a high level, before any detailed gap analysis and with an incomplete view of the delta between the borrowed system and the thing to be built on it.
Then, later in the same review, the incumbent is named as the only available back-up. The escape hatch is the expense you were escaping. Every week the new platform slips, the organisation pays the bill it started the programme to stop paying, and it pays that bill while also paying for the programme. Two cost bases, one of them running precisely because the other one is late.
Nobody designed that. It is what a fallback looks like when it is assumed rather than costed: somebody says the old system is still there, everyone nods, and the sentence never becomes a number, a duration or a decision point.
What the date was actually resting on
The finding I would put in front of a board is not the missing plan B. It is the set of things the review lists as unknown while the date stayed fixed.
The reliability of the base system had not been assessed sufficiently or proven, which the review calls a major liability. Its ability to scale to business-customer functionality, data and performance was not clear, and neither was its maintainability once extended, nor the measures needed to guarantee it. The extension was sized at about thirty percent extra code, including interfaces into sourcing and the general ledger, and the review says in as many words that this was just an estimate needing supporting analysis. The unextended system was already generating fifty or more issues a month, and there was no overall architecture design yet.
On top of that estate, the schedule. New delivery method, teams assembled from individual contractors working together for the first time, velocity therefore unknown, and a plan built on assumed velocity that programme management itself put at roughly fifty percent reliable. The planning followed the happy path, with no slack and no notice taken of the dependencies that eat schedules: a reorganisation in progress, holidays, competing programmes, market events.
A fifty percent reliable plan is not a scandal. It is an honest number for a team learning a new method, and I respect the managers who produced it. What turns it into exposure is the absence of the second document. If your plan is a coin flip and there is no plan B, you have not made a plan. You have made a bet, and only the calendar can settle it.
The two things the review asked for, and why they are different
The recommendations attached to the finding are worth reading closely, because there are two of them and teams routinely deliver only the first.
One: develop a plan B for the case where the new platform does not deliver on time, or at all. Two: assess plan A against its unhappy flows.
These are separate pieces of work. The first is an alternative route with its own cost, decision point and owner. The second is stress on the route already chosen: which dependency, if it moves, moves the date, by how much, and who finds out first. Most programmes I review have done neither, and those that did one almost always did the first, because writing a contingency slide is easier than admitting in writing which parts of your own plan are load bearing.
The review also recommended designing measures and an alternative route in case the base system proved not good enough, alongside an independent assessment of its suitability. Assess the foundation, and prepare in parallel for the answer you do not want. Neither is a vote of no confidence. They are what you do when a date carries commercial weight and its inputs carry a range.
I should be plain about what this document was: a readiness check that produced findings and recommendations, not a record of how the programme ended. The diagnosis is what travels.
- Fifty or more
- Issues a month on the base system before any extension
- ~30%
- New code the extension was sized at, flagged as an untested estimate
- ~50%
- Programme management's own reliability estimate for a plan built on unknown velocity
- Short term, high cost
- Everything the only available fallback could buy
The same question, in the systems we build now
I work on agentic operations now, and the question has not changed shape. It has only got faster.
A team routes a class of work to an agent loop. Volumes move across, the human queue that absorbed that work is wound down, the people holding the tacit knowledge move on. Months later the loop meets a distribution it was never evaluated against, and somebody asks what we fall back to. The honest answer, more often than I would like, is the process that was decommissioned because the loop was working. That is the energy retailer's finding transplanted: a fallback that exists on paper, costs a great deal to restart, holds briefly, and cannot reach where the organisation has already committed to going.
Our version has a better answer available, because the fallback can be a design property rather than a document. Graded autonomy means the loop already runs at a setting you can lower: propose only, act with confirmation, act and report. Lowering it should be a configuration change somebody on shift can make, not a project. An evaluation harness is the unhappy-flow assessment running continuously rather than once, which is what tells you the loop is drifting before a customer does. Keeping a thin human path warm on a sample of live volume costs real money, and it is the insurance the energy retailer lacked, because it keeps skill and capacity alive together.
The AI Act, now in force, pushes the same way for higher-risk uses, and its obligations arrive on a published schedule rather than all at once, with human oversight that works in practice among them. My reading of it is less about the paperwork than the plumbing: oversight you cannot exercise on the day is oversight in name only, and the same goes for a fallback. Our Agentic OS work starts there, specifying the degraded mode before the autonomous one, because the degraded mode is what the organisation lives in on its worst day.
A plan with no plan B is not a plan. It is a bet on a date, and the only party who can settle that bet is the calendar.
What I would ask before signing the date
Four questions, none of which needs a consultant in the room.
What runs the business the day after the date if the new thing is not there, in named systems, processes and people? What does that cost per week, and how many weeks can it hold before something breaks that money cannot fix? Which three assumptions, if wrong, move the date, and who sees them move first? And what would have to be true for us to choose the fallback deliberately rather than fall into it?
That last one matters most. A fallback taken by decision is a managed outcome. The same fallback taken by default, in the week the date passes, is a crisis with identical technical content and none of the control, and the difference is made entirely of work done in advance, before anyone feels the urgency that would justify it.
The review I have been quoting did not say the programme would fail. It said the programme carried a high risk profile requiring a matching risk appetite and matching measures, and that one missing measure was an answer to the simplest question anyone can ask about a plan.
Figures are as recorded in an independent programme readiness check on a business-customer platform rebuild at a European energy retailer, including the estimates the programme supplied to it. That review produced findings and recommendations ahead of a critical delivery phase, not delivered results. Reading it as a question about fallbacks, and applying it to agentic operations, are ours.
“A plan with no plan B is not a plan. It is a bet on a date, and the only party who can settle that bet is the calendar.”
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.