Most delivery plans I am asked to review contain a contingency. Very few of them contain a mechanism, and the two get confused because they occupy the same slot on the page.
The pattern turns up across engagements that have nothing else in common: an outsourced service desk re-tender at a large European public-sector organisation, a European travel and tourism group standing up a central digital function, a European energy retailer rebuilding its business-customer platform, an offshore build at a European banking group's IT services subsidiary, and a data programme proposal written for a European food and consumer goods manufacturer. Different sectors, different decades of technology, different failure modes. The same small structural question decides whether the fallback was ever real.
The question is not whether somebody thought about what could go wrong. In every one of these, somebody had. It is whether the line carries a trigger: something that converts the fallback from a description into an action, on a day when nobody wants to take it.
The first form: name the substitute
The clearest instance I have sits inside a bracket. A phase-two proposal for a European travel and tourism group names the input its organisation design depends on, and in the same sentence names the worse input it will use instead if the good one is not ready in time. No escalation clause. Nothing left conditional on a conversation.
That bracket does something a risk line cannot. It removes the moment of choice from the moment of pressure. When the good input is late, nobody has to argue for the substitute, because the substitute was already agreed by people who had no reason to be defensive about it. The full account is in The Plan That Named Its Fallback Input and the Date It Would Switch.
The second form: put a date on the switch
The same bracket carries the second form, which is why that document is worth more than its length suggests. It does not say the substitute will be used if the good input is delayed. It names the month.
A condition written as "if it is not ready" is settled by whoever has the strongest opinion on the day. A condition written as a date is settled by the calendar, and the calendar does not have a stake in the answer. That difference is the whole mechanism.
A second plan is not a hedge until somebody has written the sentence that moves you onto it. Everything else is a document, and a document has never switched anything on.
The third form: a person who can refuse
The third form does not look like a contingency at all. A kick-off deck for the re-tender of an outsourced service desk at a large European public-sector organisation carries a page of assumptions, each of them a statement that somebody in the room can decline to accept.
That is a trigger in a different costume. An assumption with an owner is a line that can be broken by a named person on a knowable day, and the plan changes when it breaks. The mechanics of that page, and why it did more work than a colour-coded register would have, are set out in What a Page of Fifteen Assumptions Does That a Risk Register Cannot.
What happens when there is no trigger
Two of the five show the other side, and they fail differently.
In the first, the fallback existed. A review I led of a failed offshore build at a European banking group's IT services subsidiary found an adverse-case variant of the project plan sitting in the evidence register, one page from an independent assessment of the system. One of those two documents was operated. The other stayed in the folder, because nothing in it said who would move the project onto it or when. See The Project Plan Had an Adverse-Case Variant That Nobody Ever Switched To.
In the second, there was no fallback to trigger. An independent readiness check on a European energy retailer's business-customer platform rebuild recorded plainly that there was no back-up if the new system arrived late or not at all, and that the only thing capable of holding the line could not deliver the business model the programme existed to create. The numbers behind that, including what the date itself was resting on, are in When the Only Fallback for a New Platform Is the System You Are Replacing.
The fifth engagement sits between the two. A data programme proposal for a European food and consumer goods manufacturer printed six ways the engagement could fail, on the slide selling it. Naming them was honest and unusual. None of the six carried an owner or a date, which is why the list reads as a warning rather than a control. That piece is Six Ways a Data Programme Dies, Named on the Slide Selling It.
The counter-example, because it changes the advice
If the argument stopped there it would suggest that adding a trigger is free. It is not, and one engagement in this set says so directly.
The same banking group's IT services subsidiary did everything the delivery playbook asks. Documentation complete, governance present and evidenced, and early formal escalation through the route both parties had agreed. The independent post-project review praised all of it. It then recorded that escalating early, rightly so, may have discouraged the supplier and made it hesitant about admitting timeline problems, and a separate working page found that reaching for the contract had not helped the working relationship. Five of the review's eight recommendations asked the client to change rather than the supplier, including dropping penalty language on the reasoning that a supplier not measured for punishment gives more honest estimates.
That is a trigger which existed, was operated correctly, and had a cost that ran the wrong way. The full account is Why Early Escalation Can Make a Supplier Slower to Admit Timeline Problems.
It does not overturn the pattern. It qualifies it. A trigger buys you a decision that would otherwise be made by drift, and the price is that pulling it is a real act with real effects on the people watching. Designing one badly, so that it fires loudly and often, teaches everybody around it to route around you.
What to ask on a plan in front of you
Four questions, and they take about ten minutes.
Who moves us onto the fallback, by name. Not a forum, not a partnership, not a role the governance model never fills. If the answer is a committee, there is no trigger.
What day. If the condition is a judgement about lateness, the plan will be defended by whoever is most invested in it. If it is a date, it will not.
What exactly do we switch to. A named substitute, specified well enough that adopting it needs no design work at the moment it is adopted.
What does pulling it cost us in candour. This is the question the counter-example adds, and I did not used to ask it. A trigger changes the relationship with whoever is on the other side of it, and a plan that fires escalation as its only mechanism will get slower information over time, not faster.
The reason this matters more now than it did is that agentic systems are being handed exactly this class of decision. A model that continues on the primary path until a human intervenes has the same defect as a plan with an untriggered fallback: it runs on the good scenario by default. The graded-autonomy work we do starts from the switching condition rather than the capability, because the condition is the part that decides what actually happens on the bad day.
Drawn from five published engagement reviews and proposals, each linked above. The observation that these five share one structural device, and everything said here about what a trigger costs, is ours. No client outcome is claimed beyond what the individual pieces record, and several of the documents involved are proposals rather than delivered work, which their own pieces state.
“A second plan is not a hedge until somebody has written the sentence that moves you onto it. Everything else is a document, and a document has never switched anything on.”
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.