The debate about keeping (or ditching) the Business Impact Analysis is missing the point

There has been a lot of hubbub in the Business Continuity (BC) arena lately over the relative value of the Business Impact Analysis (BIA). In my view, this is completely missing the point. The BIA is most simply defined as a tool for quantifying the potential, future impact to a business from disaster-related losses. It is just a small part of a larger problem: even after 20 years, Business Continuity still struggles to prove its worth. The practitioners of BC know its intrinsic worth. Emergency managers know its worth too, but generally speaking, BC has not permeated in the way it could, and we all know it. The BIA is just a tool that the average practitioner uses to get the job done, and there are many variations of the tool itself. In fact, much of the information collected in the BIA process is necessary for an in-depth understanding of organizational processes and dependencies. Instead of focusing on the “keep the BIA or ditch the BIA” debate — which is a sidebar anyway — we should be focusing on what can be done to pull the mission of business continuity into a more central strategy for companies, organization, or business.

First, let’s get some context. And up front, I’ll ask your forgiveness for all the acronyms. They come with the territory! Traditional Business Continuity largely emerged from IT Disaster Recovery (DR), which was focused on the restoration of IT functions, hardware, software, and apps following a disruption or “disaster”. A critical element of any continuity planning must necessarily involve the recovery of IT functions. Practitioners then correctly recognized that organizations, governments, and businesses had a lot more going on than the IT functions alone. For example, following Hurricane Katrina, 25% of businesses shut their doors forever, largely because they had not planned for the physical losses they would face in such an event. It was simply too costly to keep going after a disaster like that. BC, modeled after the IT DR processes, thus began to expand into other functional areas. For example, if a company relied on particular processes for payroll, shouldn’t those functions also be included into business continuity planning? As described elsewhere, the evolution of BC included the creation of business continuity standards (like ISO 22301) by which an organization, government agency, or business could evaluate the robustness of their BC program. If the goal was to make organizations more resilient to disaster, has BC succeeded after 20 years of effort? In some ways, yes, and in other ways, no.

I’m not really going to get into the overall success or failure of BC, because I can see the defensive postures that such a dichotomy will invoke. However, as I see it, one of the problems is that far from being integrated into the central functions and daily operations of an organization, BC has remained largely peripheral, a little esoteric, and certainly uneven in terms of application, training, practice, outcomes, and evaluation. It’s difficult to hire a continuity professional, and I would wager that nine times out of ten, continuity practitioners are on their own trying to grapple with the enormous scope of their entire organization. It’s usually not very tenable to do the job required. The exception might be in the financial services industry, where BC planning is required.

Given how little slack exists in the supply chains of today’s modern companies, the scant resources in government agencies, and the increasing vulnerability of data, shouldn’t BC now be an intrinsic part of any organization’s daily operations? It just makes sense that companies would want to be flexible, adaptable, and ready for any quick pivot or strategic shift necessary in the wake of a disruption — especially given the global risk environment. In fact, the more globalized we are, the more intimately networked, the more vulnerable we become to disruptions. Instead, BC remains effectively sidelined in most organizations — one, two, or a small group of practitioners is tasked with taking on the entire organization and creating plans that often consist of a high level of detail and little practical use. People engage with the process once a year, if that, and much of the time, they are merely documenting what their normal operations require rather than coming up with work-arounds and alternative paths to success should they lose critical systems or personnel. Perhaps they are entering their data in a software platform for ready retrieval, but they are not outlining and practicing the procedures needed for the regular barrage of disruptions that can and do happen at any time. Power outages, cyber breaches, internal building floods, fires — these are the normal events that can set a business unit back unless they incorporate regular practices to keep the continuity of their processes fluid. i often think that if we all adopted the mentality of a young start up, operating on synced devices from wherever we might be positioned, able to pivot on a dime, we would probably be a lot more lean and flexible in the first place. Not a bad aspiration to have, even for hard-to-move corporations.

Perhaps you, dear reader, might protest: “Well in my organization, BC holds an honored position!” Well, that’s great to hear! Though you may, in fact, be in the minority. For example, I spoke to one young practitioner several months ago, and he had been working in big tech companies in the silicon valley, each BC position held for little more than a year. He seemed to feel very offended by any critique of BC practices, but I wonder if he even knows how well BC practices have been adopted and integrated in the very organizations where he worked? One year is hardly long enough to set up a program that is married with real culture change, and deep culture change is what is obviously necessary in the BC environment. There very well may be (and likely are) organizations where TBC is taken seriously, incorporated fully and seamlessly into all administrative and business functions, where management provides adequate support and resources, and where the organization itself becomes steadfastly more robust, able to withstand and adapt to disruptions of any kind. However, I have been working in this arena for over 15 years, and that has never been my experience. In fact, that is not my experience today.

The current state of BC is troubling for several reasons: 1) management often doesn’t know that BC is a thing, 2) when BC is recognized as a thing, it still remains peripheral and uneven in its application, and 3) when it is incorporated, it is measured against a standard that acts as a check-the-box mechanism, without any real effort to ensure readiness for any sudden disruption, regardless of the cause. BC has responded to this insecurity complex by increasingly adding new functions to its umbrella-like portfolio. Emergency management now falls under the scope of BC, as does crisis communication, crisis management, risk management, and enterprise risk management (I did see an amusing article at one point arguing about whether BC should be “over” enterprise risk or “under” it). Some practitioners even argue that their office should become the center of all data collection for the company — the “data hub”. That’s absurd! And wholly unnecessary. Why is this happening? Because BC is still a sidebar function, struggling to show real value in their organizations. BC has certainly been ripe for some new strategies. Recently, an alternative approach, called Adaptive Business Continuity (ABC) emerged on the scene. ABC has been seen as a provocative disruption to traditional Business Continuity (BC) practices, but at its core, it’s asking a good question: Is there another way?

First of all, the goal for Continuity Practitioners really should be to help their company’s staff devise ways of practically dealing with disruptions, regardless of cause. In Emergency Management, “All-Hazards” planning focuses on effects rather than cause, and that also seems apt for BC. Focusing on the effects, or the impacts, may mean considering the minimum viable alternative, even if that’s reverting to old paper forms and pencils for a brief period. It appears that one chief question is how BC practitioners obtain the data that they need to help devise these alternative strategies, for use when a disruption occurs.

So what’s up with this debate over the BIA? Let’s start with the fact that practitioners define, create, and use a BIA in a diversity of ways, and many don’t actually do what the BIA was intended to do: i.e., quantify the impact for a business, in financial terms, of a potential disruption or disaster. Continuity of Operations in government, for example, rarely wades into that territory, and perhaps this is because government agencies have to continue onward regardless of the financial impact. That, and they may be able to obtain the financial resources they need to continue forward, unlike a business.

Personally, I have found that there is real value in diving deep into the context of a critical function so that the practitioner fully understands the nature of that business or operational ecosystem, its dependencies, and how the most value can be brought to the organization. I see this as more of an ethnographic process than one of collecting measurable data, but more on that later. First, let’s examine the premise of ABC’s desire to ditch the BIA. The Adaptive Business Continuity manifesto lists “Omit Risk Assessments and Business Impact Analyses” as one of its ten principles. As the ABC website describes the BIA’s purpose as functioning to “identify an organization’s services along with the potential daily or hourly loss, usually in terms of money, that a disruption of the service would have on the organization.” If you do a quick search, you’ll find that there are many, many versions of the BIA that exist, but there is some consistency in items such as: financial costs presumed for a specific business function loss, Recovery Time Objectives (RTOs), Recovery Point Objectives (RPOs), upstream and downstream dependencies, interdependencies within the organization, and maybe seasonal vulnerabilities. This all sounds good, right? The ABC critique of the BIA includes some of the following points: 1) The goal of quantifying the impact of the disaster is likely a non-starter from the beginning (i.e., do we actually need know the dollar figure of an impact to do this work? and for how long is that number accurate? Wait, doesn’t risk management already do that for insurable losses anyway?, 2) executive leadership can be trusted to identify the most critical services, meaning that the business unit may not need to ‘rank’ their functions by RTOs and other factors, and 3) the “proper” sequence to restore services at a time of disaster will depend on the exact nature of the post-disaster situation, a situation that cannot be predicted ahead of time (in other words, maybe RTOs are a bit pointless if we don’t really know how functions will be restored and in what order).

Following presentations about the Adaptive approach, there is an immediate outcry on behalf of the beloved BIA. And why not? The BIA provides a data set that is full of numbers and looks so reliable and data-ish, and true. However, we have to address the fact, that much like a qualitative risk assessment dressed up to look quantitative, there may even be real data to back up those BIA numbers. The data! The numbers! The costs! The truth is that continuity practitioners seem neatly divided in to camps that more or less love the BIA process or more or less hate it. The more regulated an industry, say, financial services, the more likely it is that a company is going to try to put a dollar figure on its business functions. Continuity planners in the government, education, or the non-profit world may still collect much of the same information, though they may skip the whole effort of putting that financial cost on an operation. Why? They likely have no idea how to do it or whether it really even serves a purpose. And I think that is the real question here at the heart of this crisis for BC: What is the REAL GOAL of continuity planning? Is it to document data or is it to work towards flexibility, adaptability, recoverability, and resilience to rapid and unexpected change?

For example, Harvard University experienced a power failure that resulted in the loss of a third of the world’s autism brains. I am unsure if it even serves a point to put a dollar figure on that, apart from recouping insurance premiums for research asset loss (again, which is the job of risk management). Still, for the purpose of creating continuity plans for research, the value here is likely much better served in ensuring redundant, switch-over power supplies and alarms on -80 freezers that will also automatically call Principal Investigators. Those PIs also really need to know who to contact, how to respond, and what to do for those research assets if there is no hope of restoring a power supply to that freezer. How about a decision tree that illustrates what options the PI may have. Relocation? Dry Ice? A secondary, back-up generator? The utility supply is one thing, but sometimes we need additional measures when no further power is possible for a period of time. This kind of planning takes time and effort, but the actions are well worth it. In this case the value of the operation (autisim research) doesn’t need to be quantified to be worth the effort in creating back-ups and alternatives.

The value of the BIA is that it provides rich context for a critical functions. The trouble lies when practitioners want to apply the BIA to absolutely all business functions. The process can take forever, it may be mostly guesswork, and it is extremely boring. The second problem lies when this context-seeking is completed up-front, at the beginning of the planning process, before any actual value or engagement is really felt. You may think that people enjoy that initial conversation, and if you are very skilled, they probably do! But at the end of the day, you need to question two things: 1) What is the quality of that data, 2) is it biased in any direction, and 3) will it continue to deliver value beyond today? By continuing to deliver value, I am referring to the problem that many a continuity practitioner experience wherein they collect the data, everyone agrees on the data, and then the data is stored away and forgotten for another year. Are action items identified and completed? Are real steps made towards making the company more flexible and adaptable to change? I honestly bristle at the comment “if you can’t measure it, isn’t real”. I work in preparedness. Preparedness is notoriously difficult to measure, and counting the things done does not mean that an organization is more prepared. In fact, most of the real preparedness lies in the redundancies built into infrastructure and personnel, including the wherewithal to carry out a task under crisis conditions. And if the bad thing doesn’t happen? Well, maybe my prevention strategies proved themselves. If so, we may never really know. As Taleb writes in his book The Black Swan, if we could have predicted the events of September 11, 2001, then before September 10th we would have imposed continuously locked, bulletproof cockpit doors in every aircraft, just in case. If we had, however, I’m sure no one would have measured our preparedness against terrorist attacks like that one.

Now let’s talk about the client, or the user experience of BC. Despite my most energetic efforts, I’ve found that people tire of the continuity planning process very quickly. My suspicion is that this happens for three reasons: 1) People don’t like to think about risk on a sunny day, 2) Starting the conversation with a bunch of opaque and often esoteric terminology makes it even harder for them to digest, and 3) a lengthy initial emphasis on data gathering (and frankly, guesswork about financial impacts and RTOs) bores people to tears. After the BIA conversation, they’re not that excited about keeping the process going by moving onto actionable steps. To be fair, in some ways the current practices are logical. But they aren’t pragmatic and engaging, and the practice of BC hasn’t found its way into the culture of the organization, which is where it needs to be to have a real impact. There is a lot in the ABC “textbook” that I don’t use and don’t intend to use. In fact, I’ve been taking an approach that is my own sort of hybrid. First, I don’t work to identify all business functions, but focus on only the most critical functions. I prepare people to think about continuity as a messy middle zone between the moment of disruption and the return to normal operations. You might not have power, you might not have access to your server, you might have lost company email. But if you do a deep dive into each essential function and ascertain all the most important systems, personnel, and components that support that function, you can develop short-hand procedures so that you can continue with operations no matter what happens. In this approach, much of the information that is usually collected up front with the BIA is still collected, but it looks much more like a Design Thinking “discovery” process; it’s more engaging and it feels more practical and relevant to the client. The real work then lies is in developing written Standard Operating Procedures and tools like checklists and decision trees, all of which are developed only for those most critical functions. The rest of it can wait until normal operations resume again.

BC practitioners have been recently protesting that this sort of approach is going to cheapen Continuity Planning for everyone. I am not convinced by that argument. In fact, my guess is that BC desperately needs some innovative approaches so that management executives are reading about the wonder of BC and thinking about creating “Continuity organizations”, much like the are thinking about Agile methodologies today. It’s definitely going to take a novel strategy to make that happen! So forget the debate about the BIA. It doesn’t really matter anyway. The real need here is for us to re-examine what it means to provide value — in all sectors — by this work. Having collected data does not mean you have a more resilient organization, especially if those numbers are, at best, a good guess. We are in danger of fetishizing data over qualitative understandings of the operation itself and by providing real value with actionable goals that can be regularly practiced. Now, go out and do some good work! How have you applied more novel and innovative approaches to BC? I’d love to hear about your experiences.