Every plan is built on a set of assumptions, and every plan eventually meets a moment where one of those assumptions turns out to be wrong. A key supplier suddenly can’t deliver. A critical team member leaves without warning. A major client’s circumstances change overnight. None of this is a sign of poor planning \u2014 it’s simply what happens when plans meet a world that doesn’t hold still. What separates teams that recover quickly from teams that scramble for weeks isn’t luck. It’s whether anyone spent a little time, in advance, imagining what a disruption might look like.<\/p>\n
Planning for a hypothetical disruption competes, in any given week, against planning for the work that’s actually in front of you \u2014 and the actual work almost always wins that competition, because it’s concrete and immediate while the hypothetical disruption is neither. This is a reasonable, if ultimately costly, way for attention to get allocated. The cost of contingency planning is small and immediate; the benefit is uncertain and in the future. Human judgement is notoriously bad at prioritising exactly this kind of trade-off correctly.<\/p>\n
The result is that most contingency planning only happens after a disruption has already occurred once \u2014 a genuinely inefficient way to learn a lesson that could have been anticipated, at far lower cost, in advance.<\/p>\n
It doesn’t require predicting the specific disruption.<\/strong> The value of contingency planning isn’t in correctly guessing exactly what will go wrong \u2014 that’s largely impossible. It’s in building enough general readiness and flexibility that a range of disruptions, most of which were never specifically anticipated, become considerably easier to absorb.<\/p>\n It focuses on genuine points of fragility, not every conceivable risk.<\/strong> Trying to plan for every possible disruption is its own kind of waste. The more useful exercise identifies the specific places where a single point of failure \u2014 one supplier, one person, one system \u2014 could cause disproportionate damage, and concentrates planning attention there.<\/p>\n It asks a specific, useful question: what would we actually do?<\/strong> Rather than a vague sense that “we’d figure it out,” genuinely useful contingency planning works through, at least roughly, what the first few concrete steps would actually be if a specific disruption occurred \u2014 who would need to be informed, what alternative options exist, and who’s responsible for making the call.<\/p>\n It’s revisited periodically, not created once and filed away.<\/strong> Circumstances change \u2014 a supplier relationship that was genuinely a single point of failure two years ago may not be today, and new dependencies emerge that didn’t exist when the original planning happened. Treating contingency planning as a living exercise, not a one-time document, keeps it actually useful.<\/p>\n Identify your team’s genuine single points of failure.<\/strong> Ask directly: if this specific person, supplier, system, or client relationship disappeared tomorrow, how disruptive would that actually be? The answers that come back as “quite disruptive” are where planning attention belongs.<\/p>\n For each significant point of fragility, sketch a rough response, not a detailed plan.<\/strong> A rough, directionally useful outline \u2014 who gets contacted first, what the immediate stopgap looks like, who owns the decision \u2014 is worth considerably more than no plan at all, and it doesn’t require the exhaustive detail that makes formal contingency planning feel like a large undertaking.<\/p>\n Build in some genuine slack, deliberately.<\/strong> A team or system running at absolute full capacity, with zero margin, has no room to absorb a disruption without everything else suffering. Some deliberate slack \u2014 in budget, in time, in redundancy \u2014 is what actually makes a contingency plan executable rather than theoretical.<\/p>\n Communicate the plan to the people who’d need to execute it.<\/strong> A contingency plan that exists only in one person’s head, or in a document nobody else has read, provides much less real protection than the same plan actually understood by the people who’d need to act on it during a genuine disruption.<\/p>\n Treat a near-miss as a valuable, low-cost lesson.<\/strong> When something almost goes wrong but doesn’t, that’s a rare opportunity to improve contingency planning at a fraction of the cost of learning the same lesson from an actual failure. Reviewing near-misses deliberately, rather than simply feeling relieved and moving on, captures value that would otherwise be lost.<\/p>\n A team relies heavily on a single external vendor for a critical piece of their workflow \u2014 a dependency that’s worked well for years and has never caused a problem, which is exactly why nobody’s given it much thought. A brief contingency exercise, prompted by nothing more dramatic than a routine planning session, surfaces the fact that a disruption to this vendor would be genuinely serious, with no real backup plan in place.<\/p>\n Rather than switching vendors unnecessarily, the team spends a modest amount of time identifying a viable, if less ideal, alternative and documenting the rough steps that would be needed to switch quickly if the primary vendor became unavailable. Months later, when the vendor does in fact experience a serious disruption of their own, the team activates the plan within days rather than scrambling from scratch \u2014 a direct, measurable payoff from a small amount of foresight that had felt, at the time, almost unnecessary.<\/p>\n Waiting until after a disruption to build a contingency plan.<\/strong> This is the most common pattern, and it means the lesson is learned in the most expensive, disruptive way possible, rather than the cheapest.<\/p>\n Trying to plan for every conceivable risk.<\/strong> This produces an exhausting, low-value exercise that discourages the more focused, genuinely useful version \u2014 concentrating on real points of fragility rather than everything imaginable.<\/p>\n Building a plan and never communicating it.<\/strong> A contingency plan that only exists in one person’s head provides much less real protection than one that’s actually understood by the people who’d need to execute it.<\/p>\n Running with zero margin or slack.<\/strong> Even a well-designed contingency plan is harder to execute inside a system that has no capacity to absorb any disruption at all.<\/p>\n No plan survives contact with reality perfectly, and that’s not a failure of planning \u2014 it’s the nature of operating in a world that doesn’t hold still. The teams that recover quickly from genuine disruption aren’t the ones that predicted the specific problem in advance. They’re the ones that took a modest amount of time to imagine that something, eventually, would go wrong, and built just enough readiness to respond quickly when it did.<\/p>\n How much time should contingency planning actually take?<\/strong> Is it possible to over-invest in contingency planning?<\/strong> How can I identify my team’s genuine single points of failure?<\/strong> Should contingency plans be formally documented?<\/strong> How often should contingency plans be revisited?<\/strong> What should be done after a near-miss that didn’t actually cause a disruption?<\/strong> The best-run teams aren’t the ones that never face surprises. They’re the ones that spent a little time, in advance, imagining what a surprise might look like.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[7,19],"tags":[9,20,34],"class_list":["post-2201","post","type-post","status-publish","format-standard","hentry","category-leadership","category-management-skills","tag-leadership","tag-management-skills","tag-risk-management"],"yoast_head":"\nA Practical Way to Build This Habit<\/h2>\n
A Practical Scenario<\/h2>\n
Common Mistakes<\/h2>\n
Action Steps<\/h2>\n
\n
Key Takeaways<\/h2>\n
\n
Conclusion<\/h2>\n
Frequently Asked Questions<\/h2>\n
\nFar less than it’s often assumed to require \u2014 a rough, directionally useful plan for a genuine point of fragility can often be sketched in under an hour, and that’s considerably more valuable than no plan at all.<\/p>\n
\nYes \u2014 trying to plan in detail for every conceivable risk produces diminishing returns and can itself become a significant time cost. Focusing on genuine, high-impact points of fragility is more efficient.<\/p>\n
\nAsk directly what would happen if a specific person, supplier, system, or relationship suddenly became unavailable \u2014 the answers that come back as seriously disruptive are where planning attention belongs.<\/p>\n
\nFor genuinely significant risks, yes, even briefly \u2014 a documented plan that’s been communicated to relevant people provides considerably more real protection than an informal understanding that exists in only one person’s head.<\/p>\n
\nPeriodically, since dependencies and points of fragility change over time \u2014 a plan built two years ago may no longer reflect current reality.<\/p>\n
\nTreat it as a valuable, low-cost lesson \u2014 reviewing what almost went wrong and updating contingency plans accordingly captures real value that would otherwise be lost once the immediate relief fades.<\/p>\n","protected":false},"excerpt":{"rendered":"