The Fallback With a Date On It

Every programme I have worked on is quietly waiting for one input. A reconciled cost base. A cleaned customer table. A finished lineage exercise on the source systems that feed the warehouse. Everyone knows which one it is, everyone agrees it matters, and everyone has priced the plan as though it will arrive.

Then it does not arrive, and the conversation that follows is always the same one. It happens late, in front of a steering group, with the people who own the missing input in the room. Somebody proposes moving the date. Somebody else proposes proceeding on whatever is to hand. Both are arguments about competence rather than method by that point, because the missing input has a name attached to it, and choosing the worse alternative reads as a judgment on whoever owed you the better one.

I have been going back through a phase-two proposal I worked on for a European travel and tourism group, and it does something I have almost never seen a plan do. It has that conversation in advance, in writing, months early, and settles it with a calendar date.

What the document actually says

The group was standing up a new central digital function inside a group-wide reorganisation. The structural blueprint for the function was due to be finished by the end of August, and the next phase existed to turn a structure into something operable: three further streams of activity covering the design of the wider technology model, the organisation structure and the people it implies, and a way of ranking the portfolio against what a customer goes through.

The first of those streams is where the interesting sentence sits. The blueprint for the wider technology model was to be designed, in the document's own framing, informed by a fact-based cost and resource review. That is the good input. It tells you what the function costs, where the capacity actually sits, and which of the numbers on the organisation chart are real.

Then comes a parenthesis. If that piece of work is not completed by mid-September, the organisational structure will be designed on headcount and job-title data from the personnel records instead.

That is the whole mechanism. One preferred input, one named substitute, one date, and no third option written anywhere.

The most consequential sentence is in brackets

I want to sit on the punctuation for a moment, because it is not an accident of drafting.

Put the fallback in the body text and it becomes a topic. Somebody will want it discussed, somebody will want it softened, and a reviewer will suggest that naming a degraded path this early sends the wrong signal to the team who owe you the good one. Put it in a bracket, attached to the sentence that commits to the good input, and it reads as a clarification of scope rather than a vote of no confidence. It travels with the commitment instead of competing with it.

The effect is that the fallback goes on the table at the same moment as the ambition, in front of the same people, when nobody is late yet. That is the only condition under which an organisation voluntarily accepts a worse input. Ask six weeks later and you are asking somebody to sign their own missed deadline.

A date removes the hostage, not the ambition

The common objection to writing a fallback down is that it lowers the bar: name the substitute and everyone relaxes into it, and the good input never gets finished.

A dated substitute does something narrower. The plan still gave the review its full run at the problem, and finishing it by the middle of September was still the better outcome by a distance. What the date removes is the review's ability to hold the rest of the plan hostage.

Consider what the alternative buys. Without the bracket, an unfinished review is a blocker, and a blocker has to be escalated. Escalation takes a meeting, the meeting takes a fortnight to convene, and the decision out of it is usually to wait a bit longer, because waiting is the option nobody has to defend. Two weeks of drift on this plan pushes the priority wave of reporting-line mapping past the end of September, which pushes the remainder past October, which puts the governance and operating model work into the month it was meant to be finished in. The staff communication and the first moves in the first quarter move too, and those are dates real people have been told about.

The fallback is not there to protect the organisation design. It is there to protect everything downstream of it.

Mid-September

Date the preferred cost and resource input must be complete by

Headcount and job titles

The named substitute, written into the scope

End Sept, end Oct

Two planned waves of role mapping the date protects

November

Governance and operating model activities due to complete

The substitute is worse, and the plan knows it

The two inputs are not equivalent, and nobody pretended they were.

Headcount and job titles tell you who reports to whom and what they are called. They do not tell you what anything costs or where effort is actually being spent, and they carry every historical accident of naming a large group accumulates: two identical roles with different titles in different parts of the business, and two different jobs sharing one title. Design a structure on that and you get something defensible on reporting lines and silent on cost.

The plan accepts that in advance rather than discovering it in October. And it does one further thing that I think is the real tell: it carries a provision of effort to work the personnel data in detail, with its own confirmation date later in the same month, days after the gate would have fired. The substitute was not a shrug. It was scoped, sized and given a decision point of its own.

Naming a fallback without resourcing it is theatre. The degraded path almost always needs more work rather than less, so the plan has to carry that work as a live option with an expiry on it.

The substitute was written down in August, by people who were not yet late. That is the only condition under which anybody picks a worse input on purpose.

What this looks like on a machine learning plan

I read this document as an organisation-design artefact for years. I now read it as the missing paragraph in most model deployment plans I see.

The pattern is identical. A programme commits to a use case resting on an input that is not ready: a feature store that will exist once three teams agree on a customer key, a labelled history usable once somebody reconciles the ticket categories, a lineage exercise that will settle which of two reporting paths is the source of record. The plan assumes that work lands on time. It rarely does, because data readiness work sits with people who have day jobs and no deadline pressure from your programme.

So write the bracket. For each dependency, three things: the preferred input, the named substitute, and the date the substitute takes over. The substitutes are not exotic. Coarser features instead of reconciled ones, with the accuracy loss accepted in writing. A shorter history, the older and dirtier part excluded rather than repaired. A rules baseline in production so the operational change happens on schedule and the model replaces it later. A narrower scope, one region or one product line, where the data already reconciles. Each is worse than the good version and each of them ships.

The same discipline belongs on the cautious language-model pilots now arriving in volume. Most are waiting on a document set somebody has promised to clean, tag and permission properly. The pilot that names its date and its substitute, a smaller corpus with a human reviewing every output, reaches users while the other sits behind a content project.

None of this is a licence to run on bad data. It is the opposite: dating the substitute means you decided, calmly and early, exactly how much worse you are willing to go, instead of discovering under pressure that you will accept almost anything rather than miss a date.

What I would write down

Pick the one input your plan is quietly waiting for. Write the date it has to be finished by, chosen so everything downstream still fits. Write what you will use instead, and who does the extra work the substitute creates, with a date on that decision too. Put all of it in the scope document rather than the risk log, because a risk log is where sentences go to be reviewed monthly and never acted on.

Do it in the first week, while everybody still believes the good input will arrive. That belief is what makes the substitute acceptable, and it has a short shelf life. Dating the dependencies this way is the opening block of a RealAI Platform engagement, because we would rather argue about the substitute in week one than about the schedule in month four.

Drawn from a phase-two proposal for the target operating model of a new central digital function at a European travel and tourism group: its scope statement, its dated decision points and its plan for the quarter that followed. The gate described here was written into a plan. The document carries no account of whether it was ever triggered, and none is claimed. Reading a dated fallback as the missing paragraph in a data readiness plan is ours.