Author

Saul Midler FBCI

A Business Continuity (BC) Plan provides the guidance and instructions required to respond to a disrupting event and recover business operations. But does your BC Plan take into consideration the reality of on-the-spot decision-making required to recover business operations efficiently and effectively?

Most BC Plans are set in concrete and don’t allow any flexibility to make decisions during Business Recovery (BR). They create roadblocks by limiting people’s expectation of what will be done. This article highlights how concrete BC Plans hinder your BR and why your BC Plans must be elastic.

The Business Impact Analysis (BIA) is the foundation on which the whole BCM process is built. It seeks to identify Business Functions (in terms of output, location and organisational structure), the impact on the organisation if the Business Function is disrupted and an attribute of time which reflects when the Business Function needs to be resurrected (Maximum Tolerable Period of Disruption (MTPD)). When setting the MTPD, the following must be considered:

• The magnitude of impact over a variety of categories – reputation, financial, environmental
• Seasonality; to consider the impact at the most disruptive time – EOFY, periodic functions, one-off projects

While MTPD defines worst-case timing, the Recovery Time Objective (RTO) represents a cost-effective, pragmatic target. The RTO must come before MTPD – creating a natural contingency buffer. The result is a list of business functions in time sensitivity order (a recovery sequence).

The BIA leads to strategy development followed by plan construction. The BC Plan is a documented collection of procedures and information that has been developed, compiled and maintained in readiness for use in an incident. They can be modular in design so that separate sections can be supplied only to those teams that require them. The BC Plan is then tested and rehearsed and, for many, committed to memory ready for activation. It then becomes the default BC Plan which is set until the next review period and will be relied upon to recover business operations in the case of any business disruption.

Let’s consider the reality of operational disruption to assess whether it is possible that on the day of the disruption:

• Every business function will be impacted at its own worst-case timing
• Every business function across the organisation will be disrupted
• Your contingency site will always be available and suit all requirements
• The defined team structure will suit every situation and team membership will suit requirements

Is it possible that every business imperative will be known and catered for? Absolutely NOT

Concrete BC Plans can’t support any of these situations because they are not flexible. Concrete BC Plans prohibit the Crisis Management Team from making on-the-spot decisions in response to the unforeseen dynamics of the disruption event and its impact on the organisation. This may place the organisation at risk. BC Plans need to be elastic, so they can stretch or shrink to fit the event and then return to their original form – the default BC Plan –ready for post-incident review.

Core BC information must change as, and when, needed to allow the Recovery Program (BC Plan) to be produced in concert with the needs of the Crisis (Executive) Management Team. The default BC Plan must be used as a basis from which changes can be made for business priority reasons. These changes should then automatically cascade through all BC documentation.

Here are the top four reasons why you need elastic BC Plans:

The Business Recovery process is all about following procedures to recover functions and resources in a priority sequence. The recovery sequence is derived from the RTO allocated to each function and resource, running from most to least time-critical. But what if the default RTO doesn’t meet the requirements for the event at hand? For example:

• The Monthly Payroll function has been allocated an RTO of 1 day to ensure that staff are paid within a timeframe that balances impact with implementation cost. What if the event occurs the day after payday? Or two weeks after? Valuable time and resources will be wasted restoring a function which is no longer required in 1 day.
• The Manage Litigation function has an RTO of 2 days, however, the legal team are not always in the heat of litigation. If the disruption happens when the organisation is not pursuing a case, the RTO should be pushed out.

In both of these examples, the resulting changed plan may be materially different to the default BC plan. Functions and Resources, including IT DR, Teams, Supplier participation and so on, must be re-sequenced to reflect the new recovery needs of the organisation based on the actual disruption event.

There are various ways to slice and dice BC information to create the default BC Plan. Some create a BC Plan for:

• The whole organisation
• Part of the organisation operating at a specific site
• Part of the organisation structure e.g. group finance

Disasters don’t always, and may not naturally, align snugly with the plan. Consider a disruption event resulting in the loss of:

• One building at a campus due to loss of power
• The computer room due to a flood on the floor above
• Half of Level 20 due to a well-contained fire
• A team of staff due to food poisoning after lunch

The ability of the decision-makers to easily and quickly assess the situation and utilise the plan has a profound impact on the effectiveness of the response and recovery process.

Searching through reams of paper (the default BC Plan), extracting the right components and re-ordering them prior to actually responding and recovering will slow down the process. It will be a difficult task to find out which functions have been affected and cross-match them with resources (including IT Systems), teams and other components of the plan. It is time-consuming, risk and error-prone and could be almost impossible depending on the nature and structure of the default BC Plan.

The default BC Plan allocates Teams to perform certain parts of the response and recovery process. For example, there may be a Crisis Management Team, a Recovery Management Team, a Site Recovery Team, Damage Assessment Team, Business Function Recovery Teams, Resource Recovery Teams or IT Recovery Teams. However, at the time of the disruption event, it may be necessary to establish a new team (e.g. Regulator Liaison Team, Supply Chain Management Team, Emergency Travel Management Team) – not because it wasn’t considered during planning, but because recovery will be more effective if this team is put in place. The challenge then becomes how to quickly and accurately:

• Define new teams in the hierarchy with a membership that does not conflict with the objectives of other Teams or Team members
• Assign new procedures to those teams
• Re-assign existing procedures ensuring they are transferred from the old team

Have you ever considered a contingency location for a contingency location? Many organisations will plan a contingency location so that their business functions can be relocated when needed. This is a risk mitigation activity to support business functions with short RTOs. Strategies and plans are then created with various assumptions associated with the designated contingency location.

What if, at the time of the disruption event, the targeted contingency location is unavailable? For example, at the contingency site, there is a local demonstration/street march, flooding, storm damage, local power outage, unavailable comms link due to routine maintenance etc. What if it becomes apparent when trying to recover business operations that the contingency location does not support the required seating capacity, IT or other requirements, so some functions need to be relocated to a new contingency location defined then and there? This will have real consequences to your ability to recover in a timely and efficient manner, including transport logistics and extra travel time. Changed contingency locations require reassignment of teams, procedures and other BC information.

In summary, the default BC Plan may need to be changed for contingency locations, RTOs, recovery sequence and alternative or new team members. Plus, it must be done live in battle, accurately and quickly. For some organisations, it must feel like brain surgery! Flexibility combined with clarity is the key to a successful response and recovery process. Our BC plans and underpinning capabilities are premised on the idea that the unknown will strike – yet, many plan constructors still write plans that don’t allow for unknowns. By developing Elastic Plans to deal with unknown unknowns, you are actually taking that next evolutionary step toward Organisational Resilience – a state that requires an organisation to be, amongst other attributes, adaptive, agile, responsive and inventive.