Please rank the following three items from one to three, with No. 1 being the item you wish to do most:
- Listen to your Uber driver’s thesis on everything;
- Talk politics over Thanksgiving dinner; or
- Conduct a business impact analysis (BIA).
This article is for those who would rather get back in that Uber and continue the riveting weather conversation or sit through Uncle David’s regurgitation of the latest facts he heard on his favorite cable news outlet than conduct a BIA.
Now, we should begin by asking ourselves, why is that?
Why is something which can create so much value for your program looked upon with such exasperation? As with most things in life, it’s all about perspective. Let’s take a few minutes to re-evaluate our current perspectives.
I know many of you feel like the BIA takes too much time and doesn’t add much value.
I know you have executives asking for a plan and see the BIA as a distraction or a delay tactic.
I even know some of you do extensive BIAs, but you quietly aren’t sure if you’re overdoing it.
The BIA process I’m sharing below doesn’t take too long, will absolutely be used, and will in fact make your planning easier and better!
When you use this process, I know you’ll find:
- clarity and confidence in the fact that the plans you are developing address what truly matters most to the organization
- the ability to confidently report on key organizational risks and provide leadership with sound strategy recommendations for consideration in addressing these risks
- significant amounts of time that you have saved yourself and others during the plan development phase
A Case Study
I was recently working with a newly installed business continuity program manager who was tasked with building their organization’s business continuity program from the ground up. This program manager, like so many others, was resource-constrained and under pressure to show significant progress within a short period of time. When discussing the design of the program, the program manager had reservations about conducting the BIA, as their program sponsor had stated they just needed to hurry up and get plans in place to meet a customer requirement which dictated the organization must provide evidence of business continuity planning. This program manager felt they were being forced to decide between delivering it quick or delivering it right. Delivering it right required taking the time to conduct a BIA to truly understand the unique requirements of the business.
It was at this point that the program manager, program sponsor, and I engaged in a discussion about the differences between taking a plan-centric or program-centric view. This organization had other drivers for implementing a business continuity program beyond just the initial customer requirement, yet this customer request was seen as the most urgent. So, the organization adopted a very plan-centric view. The entire effort became focused on developing “the plan.” We discussed how rushing to develop a plan may help satisfy this one program driver, but it was a rather reactive approach which would eventually cause the organization to have to re-do much of the work later to satisfy other drivers. By taking the time to understand the unique requirements of the business the first time and building the program in alignment with industry standards (e.g., ISO 22301), we would be building a program which is truly operational and more efficient to manage and maintain in the long run.
With the program sponsor on board, the program manager worked with their commercial team’s account executive on resetting expectations with the customer as to when they would be able to provide evidence of the plan. They explained to the customer the program implementation was in process and shared with the customer one of the organizations business continuity program governance documents (their standard operating procedures), which detailed the program design principles as well as how the program would be managed and maintained once implemented. In response to reviewing the standard operating procedures, the customer agreed to extend their timelines for requesting evidence of plans, allowing the organization the time it needed to implement the program properly.
Keys to Ensuring That Your BIA Doesn’t Suck
Program managers who want to be able to derive the most value from the BIA process should consider the following advice:
Start with Products and Services to Engage Your Executives
The first thing all program managers should do is ensure every department, business function, or group included in the program scope can be traced back to supporting the delivery of your organization’s key products and services, inclusive of internally facing products and services (e.g., employee payroll). Do you have a plan for internal audit? If so, you may want to reconsider this! While internal audit certainly performs an important function, in most organizations they are not on the critical path to ensuring that the organization can continue to deliver its products and services during an actual disruption.
Additionally, not all products and services are created equal in the eyes of leadership. In organizations which provide more than one product or service, there may be an appetite to suspend delivery of some products or services in favor of others, thereby reducing the need to plan for these less profitable or potentially nearly obsolete products or services. Once you have confirmed the list of key product and services with leadership, the next step is to ensure that all departments considered to be “in scope” can be directly tied back to this list of key products and services.
Interview In-Scope Departments for the Five Dependencies
Once you finalize the department scope based on the organization’s prioritized products and services, the next step is to conduct the BIA interviews. I always recommend conducting the BIAs using an interview-based approach over other methods, such as a survey or questionnaire (more to come on this topic in just a moment).
When conducting the BIA interviews, focus on identifying the key activities the department performs as well as when the inability to perform these activities would result in impacts the broader organization. These impacts could arise in the form of financial, reputational, operational, legal/contractual, or even regulatory impacts. Next, identify what the department relies on to perform these activities. It is imperative to understand what these dependencies are, as you will be addressing the loss of these resources during subsequent planning efforts. Consistent with best practices, I seek to identify dependencies in the following five categories:
- technology
- suppliers
- personnel
- facilities
- departments (departmental dependencies within the organization)
Leverage the Data to Accelerate Planning
Once you have gathered all the relevant BIA data from the various in-scope departments, it is time to summarize the findings with leadership. Summarize is the key word here. Leadership does not want you to bog them down with every minor detail, but instead would prefer you provide them with the information necessary to enable decision-making that will impact the organizations ability to recover. This information typically falls into two categories:
- Information which falls out of line with leadership’s expectations. For example, during initial program implementation discussions with leadership, the executives identify a specific downtime tolerance for the delivery of in-scope products and services. During the BIA, a department which directly enables the delivery of a product or service in question provides a downtime tolerance in excess of what leadership expected. Leadership would want to understand the department lead’s logic in providing this downtime tolerance to ensure they have the full picture as to why there is a variance and to see if they need to recalibrate their expectations based on this new information.
- Information that points to gaps in recovery capabilities. For example, during the BIA you identify that your organization’s ERP is not recoverable in less than 12 hours. However, numerous departments on the critical path have identified a downtime tolerance for the ERP of no more than two hours before significant financial and reputational impacts are realized. Providing this information to leadership in conjunction with high-level strategy options for closing this gap will enable swift decision-making.
Once this information has been summarized for leadership and any subsequent strategy discussions have taken place, cascade the selected strategies into the plans and move forward confidently into the planning phase.
But an Interview-Based Approach Is Too Labor Intensive!
I hear this sentiment fairly often. Some program managers feel they don’t have the time to conduct the interviews and can save a great deal of time and effort by taking another approach to BIA data gathering such as a survey or questionnaire. They may also feel conflicted about taking up too much time from the participants, and a survey may help save the participants some time. In almost every instance, conducting the BIA through an interview-based approach saves the program manager as well as the BIA participants’ time.
When I conduct a BIA interview, I schedule one hour with the department/function lead and any subject matter experts they choose to bring with them. During that hour we provide context for the program and the BIA itself, gather BIA data through a series of questions, and ask any clarifying questions which may be necessary. I can also challenge recovery time objectives (RTOs) that may seem too aggressive or not aggressive enough based on our knowledge of leadership’s stated downtime tolerance for the delivery of products and services. I then take a few hours to write up the summary and ask the BIA participant to spend a few minutes reviewing and providing any comments or additional thoughts to ensure accuracy.
Contrast this with sending out a BIA survey, which takes very little time up front. However, the survey typically does not allow you to provide context, ask clarifying questions, dig deeper in certain areas, or challenge RTOs, if necessary. In my experience, people tend to provide the bare minimum when it comes to explanations on surveys, as they are usually pressed for time and eager to move onto their next task. The amount of time you spend going back and forth with the department/function owner and/or SMEs for clarification and additional information, will quickly add up and likely result in having less than optimal data as things tend to get lost in translation.
Bottom line, taking a little extra time up front to conduct the interview will save you and everyone else a lot of time on the back end and provide you with better data.
Conclusion
While I can certainly appreciate some practitioners’ apprehension or initial aversion to conducting a BIA, we should challenge those initial reactions and instead focus on the benefits of taking the time to perform a BIA correctly. Sure, BIAs take some time and effort to conduct, but the pros certainly outweigh the cons when we take the time to do them correctly. As a reminder, the benefits which can be realized include the following:
- clarity and confidence in the fact that the plans you are developing address what matters most to the organization
- the ability to provide your leadership team with sound strategy recommendations designed to address your organizations key risks
- saving yourself as well as other participants significant amounts of time during the subsequent plan development phase.
We have also covered a few suggestions on how to make performing a BIA “suck” less and ultimately make the program manager’s life – as well as everyone else’s life who is involved in the process – a little easier. Those suggestions include the following steps:
- starting with key products and services to engage your executives (don’t boil the ocean)
- interviewing in-scope departments to understand the five dependencies
- leveraging the data to support effective and efficient planning
