Starting a Business Continuity/Disaster Recovery (BC/DR) Program

Starting a Business Continuity/Disaster Recovery (BC/DR) Program

This series is dedicated to providing direction for applying Project Management principles to starting a Business Continuity or Disaster Recovery (BC/DR) Program.  This is the first installment of a multi-part series.  In this installment we will focus on the Project Initiation phase.  Subsequent segments will be aimed at additional phases of starting a BC/DR Program, on improving an existing BC/DR Program, and on elevating a mature program to a new level of efficiency and effectiveness.

Starting a Business Continuity Program

Launching a BC/DRBC/DR Program requires its own plan.  This is not a plan as in a recovery or response plan, but a plan in the sense of a project plan.  Starting a BC/DR is no different than starting any project, and success essentially hinges on your project management skills.  You may want to reach out to the Project Management Office (PMO) if you are fortunate enough to be part of an organization that has one.  The PMO may be able to provide an experienced project manager who can assist by applying current project management theory and techniques to the initiative.  If your organization does not have a PMO, or a resource is not available, then gaining a basic understanding of project management is the starting point.

There are many available information sources for project management principles.  The Project Management Institute (PMI) is the leading authority in the field.  The PMI offers training and certification and most community colleges and universities offer courses in project management.

So let’s take a real-life approach to this and assume that you were invited into your supervisor’s office or your supervisor’s supervisor’s office on Friday afternoon, and, due to some outstanding work in a field that has nothing to do with business continuity or project management, you were “offered the opportunity” to start and lead the organization’s business continuity program.  You will do this, of course, while managing your non-business continuity, non-project management work responsibilities.  I feel your pain.  So, here’s where you are: you didn’t sleep much this weekend, you have a huge new project in your lap along with a bunch of other things on your already-full plate, and you’re probably not getting enough time, money, or people to make it happen.  Step 1 – keep reading.

This is still a project, and we still need to approach it as such despite the possibility that we are short on time and resources.  Here are the basics we need to know about project management and its application to starting a BC/DR.

Project Initiation

Project initiation is the first phase of project management.  Project Initiation is typically where a business case is created to provide the rationale for undertaking the project and proving that it is feasible.  Management will use the business case to ultimately determine if the project will be approved.  This may have already taken place and the project assigned to us after the fact.  If, however, we will be part of creating the business case, there are a ton of templates available online as well as recommendations for writing a good one.  Check internally first because there may be a standard template specifically for use by your organization.

The Business Case for a BC/DR
The business case needs to explain the why for performing the project.  Focus on describing the need for the project and how it solves an issue that the organization is facing.  Provide examples that are not exclusively IT focused as this can expand the scope of the case beyond traditional boundaries and allow areas like Supply Chain, HR, and other customer impacting areas to be included or considered. Without a BC/DR Program, the entire organization is at risk.  The organization could experience a disruption that causes injuries to associates and/or the inability to provide the products and/or services normally provided to clients.  Without a BC/DR Program there is a risk in regard to providing the safest possible working conditions for employees, and there are operational risks that could include regulatory and contractual breaches, diminished reputational status, financial loss and loss of financial opportunity, and a diminished competitive capability.

The goal of the project is the creation of a program that is focused on improving safety for all personnel and raising the state of readiness for the organization by understanding and mitigating risk and instilling an ever-improving culture of resilience.  The business case should demonstrate the value of performing the project.  For this part refer to the Business Continuity Institute (BCI).  The BCI is a leading authority in the field of business continuity.  The BCI offers a paper for download that details how business continuity delivers ROI.  This section can also leverage relevant industry requirements.  These are often the driver for the creation of a BC/DR Program.  Depending on the industry, the ability of an organization to continue operations can hinge upon proving it has an effective BC/DR Program.

While the benefits and ROI of implementing a BC/DR Program can be difficult to express numerically, one way to do so is to establish the cost of downtime.  The factors involved in determining the cost of downtime will vary greatly from industry to industry and organization to organization, but if we can have a few minutes with the CFO, we may be able to derive a dollar amount that can adequately highlight the value a BC/DR Program will bring.  (The CFO would make a great Executive Sponsor – keep this in mind for later.) Ask for an estimate of the losses expected for a day where no work activity could be performed.  If you are part of an organization where the products and services provided are extremely time-sensitive, the cost of downtime may be measured in hours, rather than days.  In either case, the value of a BC/DR Program is in improving safety for employees and mitigating against the cost of downtime.  Be careful not to infer that a BC/DR Program will ensure safety or that downtime can be completely avoided.  A BC/DR Program can only promise to improve safety and minimize downtime.

The business case will also need to detail the requirements for the project.  In this section we need to provide information on what will be done, who will do it, how it will be done, and the timeline (when) for completion.  Who will depend on how many people we can involve.  If it’s just going to be you, you may want to include estimates for contracting with outside consultants.  If it is just you, be savvy with the timeline estimate because the revision process for the business case will most certainly include shortening the project time frame.  These project requirements will set you and the organization up for success.  Understanding your current team’s high-level bandwidth, level of effort, and deadlines will help you determine the resources required to meet your project goal.  We see too often organizations asking employees to “Just Do it!” and these eager employees struggle with trying to do more with limited resources.  Planning will provide a logical progression to achieve success and meet your organization’s goals.

We can be more certain regarding what will be done and how it will be done.   Here are some traditional deliverables (what will be done) for the project:

  1. Business Continuity Policy

  2. Business Impact Analysis

  3. Threat Evaluation

Understand that there is a debate within the Business Continuity industry over whether to perform the Threat Assessment or the Business Impact Analysis (BIA) first.  We will not wade out into that discussion in this installment; although you can see we’ve placed the BIA before the Threat Evaluation.  Our position is that the BIA should come first; however, there is enough flexibility in the sequence that they can be performed concurrently if desired.

The Business Continuity Policy will establish the requirements and responsibilities for the BC/DR Program.   The Threat Assessment will examine the likelihood, impact, and state of readiness for threats to the organization, and the BIA will establish the Recovery Time Objective (RTO) for the processes engaged by the organization.  (The RTO is the measurement of time in which a business process or service must be recovered following a disruption.)  Note that we are referring to our deliverable as a Threat Assessment, rather than a Risk Assessment.  These are two different things.  A threat assessment is identifiable with standard business continuity procedures while a Risk Assessment is wider in scope.  The Threat Assessment and BIA will provide the background and organizational understanding for establishing the program.

Prior to writing the Business Continuity Policy, it will be helpful to review a few resources:

The documents above will give you the essential steps for completing the tasks required to starting a program, and, more importantly, will provide you with an overall understanding of what is necessary for establishing a successful BC/DR Program.

As you formulate the Business Continuity Policy, cite the need for a Steering Committee.  The Steering Committee should include an executive sponsor – someone from upper management who agrees to serve as the chair of the committee.  (Recall the reference made earlier to the CFO.) The executive sponsor provides a valuable top-level presence to the program, functions as the voice of the program to other members of executive management, and assists in avoiding and ending impasses that could occur between equals.  Include a suggested structure for the Steering Committee.  In addition to the Executive Sponsor/Chairperson and the BC/DR Manager, propose that leadership from the business areas of the organization also serve as committee members.  Their support for the program will be essential to long term success.  We will eventually request each business area participate in the BIA and in building and maintaining recovery plans.

 Designing and delivering an effective BIA is a major endeavor.  The Business Case should include the BIA scope, design, and delivery method(s).  There is some cross over here between Project Initiation and Project Planning.  We will need to plan the project at least at a high level in order to provide an idea of the scope of the BIA.  Determining the scope of the BIA is the first task.  The size and structure of the organization as well as the staff that can be allocated to the task will be considerations.  If the staff is not considerable, but the size of the organization is, it may be necessary to implement the BIA in carefully planned phases or to narrow the scope to a limited portion of the organization.  Part of that determination should include the implementation method(s).  Face-to-face meeting are preferred, but they may not be feasible given resource restrictions.  The use of a business continuity software tool may  help as well.  Distribution of electronic files developed in Word or Excel can be effective, but compiling the data for analysis and reporting can be time consuming.  A blended approach to implementation is often required given restrictions on travel and staffing.  If company culture allows consider engaging an external consulting firm to collaborate on the design and provide the delivery of the BIA.  This may be the best possible use of any financial resources the project may include as the results of the assessment will be delivered along with external endorsement.

As for BIA design requirements, capture the need to measure impact using a qualitative and quantitative method.  Many organizations allow BIA participants to provide their opinion on how serious the impact of the outage would be within their area of specialization.  This is not recommended as most people are passionate about their work and find it difficult to provide an estimate of impact without allowing that passion to bias their assessment.  If specific criteria are provided for determining impact, the BIA results are more likely to represent an accurate depiction of how an interruption would affect normal activities.   This will be vital for selecting appropriate recovery strategies later.  Include the time frames in which RTOs will be expressed.  Provide a Tier structure that defines how processes will be categorized.

The policy should also state that the BIA will capture dependencies on IT assets and vendors.  Speaking with IT leadership is advised as IT may already have RTOs and classifications for applications and assets.  Sharing the same measurements, if possible, will simplify the mapping of IT dependencies and the identification of gaps between business needs and IT capabilities.  Detail the need for IT to provide current application Recovery Time Actual (RTA) and Recovery Point Actual (RPA) information.  The RTA is a measure of time in which it has been demonstrated that an application or other IT asset can be recovered.  The RPA is a measure of time indicating the true age of the data associated with an application that can be recovered by IT.   In some cases a disruption may mean that data entered into an application will be lost if it was entered within a certain time period prior to the disruption.  These measurements will ideally come from the results of IT recovery exercises, rather than estimates of what is currently possible.

Include the minimum requirement for refreshing the BIA in the policy.  Many organizations will perform the BIA on an annual or bi-annual basis.  The available methods of delivery and staffing will factor into how often the BIA can be repeated.  If a software tool to support the BC/DR Program is available, indicate that the BIA should be updated whenever there is a change in how a process is performed, where it is performed, or if the technology utilized or the role of a supporting vendor is amended.  Maintaining BIA data continually allows the organization to be more confident in the selection of strategies for recovery and more efficient in managing the resources allocated to enabling those strategies.

The Threat Evaluation should provide a score for potential threats to the organization that considers the likelihood of the threat and the expected impact if the threat were realized.  The Good Practice Guidelines provides a useful scoring model for threat assessments.  Enhance the model by accounting for any mitigation measures in place to reduce each threat.  This will ensure that the most likely and most impactful threats come to the forefront.  In order to determine the likelihood of each threat, examine historical disaster frequency data.  Here are a few websites that may be helpful:

Understand that accounting for every conceivable threat is not possible.  Try to keep the analysis simple.  The assumption should be that both the BIA and the Threat Assessment will evolve and improve over time and as the organization changes.

The policy should include specifics for program assessment and reporting.  Include information on the standards that should apply to the program based on your review of IS22301 and other relevant industry-specific requirements.  Your location in terms of state/province and nation may require additional compliance standards for the program.  The standards ultimately adopted by the organization, as well as those applied by your industry and government entities, will drive much of the design of the status reporting that is necessary for the program.

Internal and external audit findings should be part of the program reporting requirements.  Reach out to the Internal Audit Department if possible to request a collaborative effort on areas of compliance and to introduce them to the relevant standards.  For BIAs, include reporting on completion rates, updates, reviews, and overall approval statuses.  Outline reporting on the RTO and Tier results from the BIA.  Reports detailing dependencies and any gaps between business needs and IT and vendor capabilities should be outlined.  Sample Threat Assessment reports are available online.  The threat assessment is not something that will need to be refreshed often.  It will rather be repeated for all locations for the organization and for newly acquired locations should the organization experience growth.

Following the advice provided here, a very persuasive business case can be developed to support the need for a BC/DR Program.  With the steps provided herein completed, we are through Phase 1 of the project.  Watch this space for the next installment covering Phase 2 – Project Planning.

Schedule a demo