How priorities, dependencies, scenario planning and practical delivery decisions can help an organisation respond to change.
Resilience is often discussed as if it were a quality an organisation either has or lacks. In practice it is the result of a series of deliberate choices: what to protect, what to monitor, who can act and how quickly the organisation can adjust when something it relied on stops working. Those choices belong in the business strategy itself, not in a separate continuity document that is reviewed once a year and then filed away.
This article sets out a practical approach that leadership teams can use to build resilience into strategic planning, with attention to the operational and digital decisions that determine whether a plan holds up under pressure.
Understand what needs to remain dependable
Business resilience involves maintaining important services and adapting when conditions change. Start with the activities customers and teams rely on, and the dependencies that support them.
Review potential disruption, available capacity and the decisions that would need to be made. Different organisations will need different arrangements.
A useful first exercise is to list the handful of services or outcomes that would cause real harm if they were interrupted for a day, a week or a month. For a professional services firm this might be client delivery, invoicing and access to shared information. For a manufacturer it might be order processing, supplier communication and quality release. The list should be short. If everything is treated as critical, nothing is prioritised when it matters.
For each item, trace what it depends on: people with particular knowledge, specific systems, suppliers, data sources, approvals and physical locations. This is where hidden fragility tends to surface. A process may appear robust until it becomes clear that it relies on one person who maintains a complex spreadsheet, or on a supplier whose contract has no clear service commitments.
Consider an illustrative scenario. An operations team manages regional orders through a shared workbook maintained by two experienced colleagues. The process works well in normal conditions, but there is no documented logic, no audit trail and no cover when both colleagues are unavailable. Identifying that dependency does not automatically mean building a new system. It might mean documenting the rules, training a third person and agreeing a review point to decide whether a more structured tool is justified. Where it is, a workflow application can replace spreadsheet-based processes with clear steps, permissions and records, as in our process automation application for European operations.
Test assumptions and scenarios
Identify the assumptions behind the strategy, including demand, suppliers, systems and skills. Consider what would happen if one changed materially.
Scenario planning is useful when it produces decisions: which actions are available, who can authorise them and what evidence would trigger a response.
Most strategies rest on assumptions that are rarely written down. Demand will follow a predictable pattern. A key supplier will continue on similar terms. Existing systems will remain supported. The team will retain the skills it has today. Writing these assumptions out in plain language is a simple step, and it often prompts a more honest discussion about which ones the organisation is least sure of.
From there, select a small number of scenarios that would test the strategy in meaningful ways. Three or four well-developed scenarios are more valuable than a long catalogue of remote possibilities. For each, the leadership team should be able to answer a few direct questions:
- What would we notice first, and who would notice it?
- Which decisions would we need to make, and who has the authority to make them?
- What options do we already have available, and what would take time to prepare?
- What would we stop doing in order to protect the services that matter most?
A common pitfall is to treat scenario planning as a workshop output rather than an operating tool. If the scenarios do not lead to agreed triggers, owners and prepared options, they will not help when conditions change. Another is to focus entirely on dramatic events and overlook gradual shifts, such as a slow loss of specialist knowledge or rising costs from a supplier, which can be just as damaging over time.
Keep priorities and responsibilities clear
Adaptability depends on people knowing what matters and how to raise an issue. Agree responsibilities and communication, especially where work crosses functions or suppliers.
Diversification or new technology may help in some cases, but each brings costs and dependencies. Assess the fit rather than treat either as a universal route to resilience.
When disruption occurs, the organisations that respond well are usually those where people already understand the priorities and know who to contact. That clarity has to be built in advance. It includes named owners for critical services, agreed escalation routes, and a shared understanding of what can be decided locally and what needs senior approval.
Cross-functional work deserves particular attention. Consider a hypothetical situation in which a customer-facing team depends on information from finance, which in turn depends on an external payroll provider. Each party may have its own plans, yet no one owns the end-to-end outcome. Agreeing a single accountable owner for that outcome, and a simple way for issues to move between teams, often does more for resilience than any individual system upgrade.
Leaders should also be cautious about adding complexity in the name of resilience. A second supplier, a new platform or an additional location can reduce one risk while introducing others, including integration effort, management overhead and new information handling obligations. The right question is whether the change reduces the organisation’s most significant exposures at a cost it can sustain.
Make digital changes maintainable
A useful digital service needs support, information ownership and a plan for updates. Consider how changes affect the experience of customers and staff as well as technical availability.
Digital tools frequently become points of fragility because they are introduced quickly and then left without clear ownership. A resilient approach asks, before anything is built or bought, who will maintain it, who owns the information it holds, how access will be managed and what will happen when the people who set it up move on.
It also helps to think about resilience from the user’s perspective. A system can be technically available while still failing the people who rely on it, for example when a change to a form confuses staff or when a customer portal works but no longer answers the questions customers actually ask. Reviewing user experience alongside uptime gives a more complete picture.
Where automation or AI is part of the plan, resilience depends on clear oversight. Define what the tool does, what a person reviews and how the organisation would continue if the tool were unavailable. Automation that removes all human understanding of a process can make the organisation less adaptable, not more.
Where to start
A practical starting point is a short review with the leadership team: agree the services that must remain dependable, map their main dependencies, write down the assumptions behind the strategy and select a few scenarios to test. From that work, a prioritised set of actions usually becomes clear, some of which will be organisational and some digital.
Glyz supports the strategy, process, design and technology work involved in turning these priorities into a practical delivery plan. Our AI and digital strategy service helps organisations assess dependencies, prioritise improvements and plan changes that can be maintained over time.
