What was the business impact analysis?

Adaptive BC, a website established to develop and promote a new approach to business continuity, has been calling for the elimination of the BIA. In this article David Lindstedt, one of the founders of Adaptive BC, explains why.

The business impact analysis (BIA) has been a staple of business continuity for decades. In that time, the BIA has grown, expanded, and become rather nebulous in its scope, objectives, and value. By exploring both its initial purpose and current implementation, we can conclude that early benefits gained from the BIA no longer outweigh the disadvantages, and that practitioners ought to eliminate the use of the BIA as much and as soon as feasible.

Part one: genesis

What was the BIA when it came into use? The original intent of the BIA was to estimate the impact that a significant incident would have on the business. More accurately, it was to estimate the different types of impact that a significant incident would have on different parts of the business.  As the BCI DRJ Glossary states, even today the BIA is defined simply as the, “Process of analyzing activities and the effect that a business disruption might have on them.” (1)

Why did practitioners want to know how incidents might impact an organization’s activities? Why did experts think this analysis was important? Likely, practitioners employed a BIA to try and obtain one or both of two types of outcomes:

Legitimacy and funding:

• Initial – If executives realize the potentially catastrophic effects that an incident could have on their organization, they will be willing to pay for preparedness. Because incidents could negatively impact brand, capital, life-safety, reputation, resources, revenue, and other essential aspects of the organization, executives would agree to spend time and money to prepare the organization to appropriately respond to such incidents.
• Ongoing – By learning how much money each service generates (or saves), and then quantifying potential impacts, we can use this information to obtain ongoing funding and support of the business continuity program. We can work with leadership to determine funding based on an explicit or implicit percentage of the amount of money the service generates (or saves).

Prioritization:

• Prioritize services – If we learn which services generate (or save) the most money or benefits and how badly each could be impacted, this information will lead to a prioritization of services. We can do a quick calculation between these two factors for each type of impact, average the results, and prioritize the importance of services based on the outcome.
• Prioritize effort – Based on a prioritization of services, we can properly prioritize the work of our business continuity program. The business continuity practitioner starts with the most important service and works down the list from there.

This approach must have worked well enough.  The growing reliance on information technology, mainframes, and desktop computing gave rise to business continuity. However, while this BIA technique was useful at the time, it has set practitioners down a path of problems and pitfalls.

Part two: problems and pitfalls

Stop and reflect for a moment – what has been your experience with the BIA? How valuable do you and others find it in practice? Here are common problems voiced by professionals:

• It takes too long: While there have been no official studies, the average time it takes to perform a BIA is about 3-9 months, and often longer. This is a very long time in an ‘Agile Age’ where software and other development sprints are expected to deliver value to the customer every 2-4 weeks.
• It takes too long for too little value: The duration of effort might be acceptable if stakeholders found the results valuable, but most do not. A common lament in blogs, articles, and presentations is the lack of receptivity for the process and its results.
• The results go stale: We work in complex organizations in a complex world. By the time the ink is dry on the BIA and it’s placed on the shelf, the results have gone out of date.
• The results are not used for action: Once the results are delivered to executives, one of two things usually happens. Either the rankings are in line with executives’ priorities, in which case you wasted 3-9 months to show them something they already knew –or– the rankings are not in line with executive’s priorities, in which case you wasted 3-9 months to tell them they have poor judgment.
• The results are not used for anything: What if the reputational impact from a significant incident changes this year from a “3” to a “2” for Accounting? What if customer dissatisfaction moves from a “1” to a “2” for Payroll? Prioritization of services remains the same, the business continuity program remains the same, participation remains the same, and funding remains the same. BIA results are not meaningful to executives, stakeholders, participants, or, most often, the practitioner.

There are also more ‘human’ problems with the BIA. Practically speaking, the drive to identify and document specific impacts often gets the planner off on the wrong foot with participants.  The planner spends a disproportionate amount of effort and relationship capital negotiating with participants to pinpoint these estimates.  Frequently the participants, including management, feel that this activity is arbitrary and artificial, searching after something that is unrealistic and unreflective of what would actually happen in the case of disaster.  As these conversations often take place at the very beginning of planning work with participants, it can set a negative, and sometimes adversarial, tone to the rest of the planning activities.

There are other, potentially more serious problems with the BIA. Many have argued that the BIA is fundamentally flawed and inherently problematic. Space precludes a detailed discussion of these arguments, but deep flaws exist because of:

• The inability to accurately predict what specific disaster will happen and what the actual effects of that disaster will be (2);
• The inability to fully encapsulate and accurately map out all functions and interdependencies for each service (3);
• The inability to translate relative business value to dollars or ‘scores’ on a spreadsheet (4);
• The inability of a department to properly estimate the criticality of their services within the larger context and mission of the entire organization (5);
• The time, effort, and difficulty in accurately determining actual monetary losses for unpredictable impacts within specific time-brackets over time;
• The tendency of a department to (consciously or unconsciously) inflate and over-estimate the criticality of their services (6).

Finally, the nail in the coffin for the BIA may be the phrase, “It depends.” To what degree would a significant event impact each department’s brand, customer satisfaction, reputation, revenue, time to market, etc.? “It depends” is the most accurate answer. Impact will depend on a large and complex number of factors and variables, most of which cannot be known ahead of time. Consider this simple list of context-sensitive considerations at some unforeseeable time of disaster:

• Contracts and legal agreements;
• Current business models, strategic goals, culture, vision, and/or mission of individual departments and the organization overall;
• Estimated time to market or time to launch for in-flight projects and initiatives;
• Influences from the board of directors, stakeholders, shareholders, customers, competitors, and the market;
• Leadership and management priorities;
• Liquidity, capital, and revenue streams;
• Profit, perception, promotion, and bonuses;
• Regulations and compliance requirements from federal, state, local, and other regulator and accrediting bodies;
• The actual size, range, duration, and impact of the event;
• The post-disaster status of general market conditions, including affects on our customers and competitors;
• The post-disaster status of other organizations affected by the same disaster;
• The post-disaster status of other processes, functions, systems, and services;
• Or, how about simply: The time of year, week, or day (7)

Practitioners have inherited a tool that was once useful in a time of mainframe computing and Y2K. We may owe a debt of gratitude for the practitioners who worked so hard to establish business continuity as a legitimate practice. But in this complex time of Bitcoin and Blockchain, virtualization and cloud computing, mergers and acquisitions, the BIA is outdated and detrimental.

Part three: “We just call it a BIA”

While many practitioners still perform a traditional BIA as prescribed, most often because it is required of them, many practitioners are working around the prescribed practice in order to provide better value to their organizations. Such activities are beneficial in themselves, either because of advantages found in the process, the discussion, or the results (or all three). Practitioners will perform these activities, document the results as needed, and then “just call it a BIA” in order to meet external requirements.

Here are a few examples (at a departmental level):

• A simple list of services: This is a very handy thing to have. It forces folks to categorize the work they do. This is necessary for almost all subsequent steps in improving recovery capabilities.
• A brief interview with executives: A few minutes with those who founded or lead the company can provide a wealth of helpful information in a short amount of time. Executives know and set the direction for the business and are planning out for the next three years and beyond. As they will set the priorities in a post-disaster environment, it’s good to know what they are thinking and how they see the relative business value of each area.
• A simple SIPOC: SIPOC (suppliers, inputs, process, output, customers, requirements) is a Six Sigma tool to give you an idea of what a process does. Regardless of what you call it, in about 20 minutes, the practitioner can create a one- or two-page at-a-glance overview of a department’s services.
• A prioritized list of value: Why does this department exist? Why do they do what they do? In a post-disaster situation, what is of importance is not a relatively arbitrary ranking of services, but a prioritized set of values through which the team can self-organize, self-direct, and self-recover as much as possible and as soon as prudent.
• A dependency diagram: What do we need to function? Where does it come from? And to whom do we give our ‘products’ that they need? While the author does not personally find this useful, many practitioners use it to help participants understand where they fit within the organization as well as how they influence and are influenced by others.

The list goes on. Innovative and responsible practitioners are coming up with new ways to obtain information that is practical, informative, and meaningful. And they are doing it in increasingly effective and efficient ways. Executive management and stakeholders are right to reject a BIA that takes 3-9 months to complete and offers little to no value when business continuity professionals can provide actionable outcomes in a matter of hours.

The scope of the BIA has become more and more nebulous over time. Recall that the defined scope is simply an estimate of the different types of impact that a significant incident would have on different parts of the organization. Some practitioners have tried to expand this scope to include everything from asset tracking to reams of recovery strategies. The 2014 draft of ISO/DTS 22317, focusing exclusively on the BIA, even requires an “activity level prioritization to obtain a detailed understanding of day-to-day resource requirements… to help confirm impact-related conclusions developed at the process level” (p. 19, emphasis mine) and an “understanding of the dependencies on other activities, suppliers, outsource partners, and other interested parties” all of which “…serves as the justification for business continuity requirements…” (p. 7). This ever-increasing scope for the BIA will only present more problems for the practitioner and the business continuity industry as a whole. Requiring additional activities as a way to try and bolster an inherently problematic practice cannot be a wise response.

Part four: exodus

Eliminating the traditional BIA may seem counter-intuitive, but given the problems inherent within the BIA, it may be inevitable. The good news is that it is no longer needed. Let us quickly revisit the original purposes of the BIA, namely legitimacy and funding, and prioritization. With regard to the former, business continuity has obtained enough legitimacy to secure tens of millions of dollars in funding, establish support institutions, and provide jobs. With regard to the latter, we can and must shift our thinking (and the thinking of those with authority) away from arbitrary rankings of services to increasingly self-sufficient team members who can operate effectively in a post-disaster situation precisely because they understand the business and the value that their services provide within the context of that business.

Business continuity practices must become more adaptive to adjust to the current business environment. Related disciplines such as Agile, Growth Mindset, Lean, Motivation 3.0, PM 2.0, Scrum, and Six Sigma can help show us the way. In a traditional (‘legacy’?) business continuity framework, eliminating the prescribed BIA may be perplexing. But within an Adaptive BC approach, omitting the BIA frees the practitioner to quickly and efficiently obtain meaningful information for the continuous improvement of recovery capabilities. As Agile project management provides a robust alternative to traditional project management, Adaptive BC provides a robust alternative to traditional business continuity.

What ‘takes the place’ of the BIA going forward? Nothing. Everything. Only those things that provide value to the organization within the context of its vision, mission, and culture while continuously improving each department’s capabilities to recover. Legitimacy for business continuity can now come from measured improvements to capabilities. Funding can be allocated in proportion to identified gaps in capabilities cross-referenced with the relative business value provided by each service. Strict prioritization can be replaced by progressively self-sufficient departmental teams informed by the business and empowered to flexibly adjust to a post-disaster situation as it unfolds unpredictably in real time. Scattershot business continuity efforts can be replaced by a more surgical approach informed by meaningful metrics and KPIs. The sequential list of required business continuity products can be replaced by a non-linear and iterative approach to take advantage of immediate opportunities and the nuances of each workgroup, recognizing that one size never fits all. And the work of the business continuity practitioner can more properly align with the realities and expectations of our increasingly complex world.

Addendum: audits, regulations, and compliance

We have spent the better part of two decades convincing auditors that the BIA is important and that its completion is a matter of compliance. Perhaps we have made our case too well.  A growing number of professionals would like to eliminate the BIA from their practice, but are now constrained by regulatory and other requirements.

Most auditors are not business continuity experts. They are responsible for auditing a wide variety of programs and processes. In order to audit a business continuity program, they must rely on some very specific criteria. Without a way to measure the effectiveness of a business continuity program, the auditor is forced to measure the implementation of the business continuity program instead. In other words, because there has been no way to determine to what degree a business continuity program is improving an organization’s recoverability, auditors have been constrained to focus on the make-up and products of the program itself.

We would like to suggest that there is a better way, and one that is fully in line with the spirit of ISO22301: Measure capabilities. How do you satisfy the “evaluation of business continuity procedures” requirement found in section 9.1.2? Evaluate the resources, procedures, and competencies required for recovery. How do you fulfill the purpose, set out in the very first sentence of ISO22301, to help “protect against, reduce the likelihood of occurrence, prepare for, respond to, and recover from disruptive incidents when they arise”? Measure preparedness, not program deliverables.

While it will certainly take time, and may be counter-cultural for a while, we urge business continuity practitioners to partner with auditors to reframe their thinking about how to meet requirements like section 9.1.2 of ISO22301 by employing measurements of recovery capabilities. Auditors will likely have to consider both the program’s structure and its effectiveness for the time being, but the hope is that the emphasis can begin to shift from the former to the latter in due time, and we can eliminate wasteful legacy artifacts like the BIA.

The author

David Lindstedt, PhD, PMP, CBCP, is the founder of Readiness Analytics, an organization focused on metrics, measures, and KPIs for recovery capabilities.  Dr. Lindstedt has published in international journals and presented at numerous international conferences. He taught for Norwich University's Master of Science in Business Continuity Management. He serves on the Editorial Board and is a frequent contributor to the Journal of Business Continuity & Emergency Planning. He is currently ‘shepherding the future’ of Adaptive Business Continuity with a co-authored book, AdaptiveBCP.org, and Jeomby.com. Contact: david@readinessanalytics.com

References

1. https://www.drj.com/resources/tools/glossary-2.html, viewed 6/10/17
2. Hübert R. Why the Business Impact Analysis Does Not Work. The Business Continuity and Resiliency Journal, Q2 2012, pp. 31-39.
3. Ibid.
4. Ibid.
5. Hutton R, Rupert J. The Top Five Ways to Fail at Business Continuity. Disaster Resource Guide. Available from: http://www.disaster-resource.com/index.php?option=com_content&view=article&id=820:the-top-five-ways-to-fail-at-business-continuity [Accessed: 30th June 2016].
6. Ibid. 
7. For more on this topic see: Lindstedt, D., Our Deep Misunderstanding of Time in Preparedness Planning. Business Continuity Institute’s Working Paper Series. Available from: http://www.mynewsdesk.com/uk/the-business-continuity-institute/news/our-deep-misunderstanding-of-time-in-preparedness-planning-233347
   

Read as a PDF.