Adaptive Business Continuity: A New Approach

David Lindstedt, Mark Armout, Kristen Noakes-Fry

• Publisher: Rothstein Publishing
• Year: 2017
• eBook ISBN: 9781944480400
• Topic: Business
• Subtopic: Insurance
• Index: Business

Have you begun to question traditional best practices in business continuity (BC)? Do you seem to be concentrating on documentation rather than preparedness? Compliance rather than recoverability? Do your efforts provide true business value? If you have these concerns, David Lindstedt and Mark Armour offer a solution in Adaptive Business Continuity: A New Approach. This ground-breaking new book provides a streamlined, realistic methodology to change BC dramatically.

After years of working with the traditional practices of business continuity (BC) – in project management, higher education, contingency planning, and disaster recovery – David Lindstedt and Mark Armour identified unworkable areas in many core practices of traditional BC. To address these issues, they created nine Adaptive BC principles, the foundation of this book:

• Deliver continuous value.
• Document only for mnemonics.
• Engage at many levels within the organization.
• Exercise for improvement, not for testing.
• Learn the business.
• Measure and benchmark.
• Obtain incremental direction from leadership.
• Omit the risk assessment and business impact analysis.
• Prepare for effects, not causes.

Adaptive Business Continuity: A New Approach uses the analogy of rebuilding a house. After the initial design, the first step is to identify and remove all the things not needed in the new house. Thus, the first chapter is "Demolition" – not to get rid of the entire BC enterprise, but to remove certain BC activities and products to provide the space to install something new. The stages continue through foundation, framework, and finishing. Finally, the last chapter is "Dwelling," permitting you a glimpse of what it might be like to live in this new home that has been created.

Through a wealth of examples, diagrams, and real-world case studies, Lindstedt and Armour show you how you can execute the Adaptive BC framework in your own organization. You will:

• Recognize specific practices in traditional BC that may be problematic, outdated, or ineffective.
• Identify specific activities that you may wish to eliminate from your practice.
• Learn the capability and constraint model of recoverability.
• Understand how Adaptive BC can be effective in organizations with vastly different cultures and program maturity levels.
• See how to take the steps to implement Adaptive BC in your own organization.
• Think through some typical challenges and opportunities that may arise as you implement an Adaptive BC approach.

Chapter 1

Demolition

Many stakeholders involved in business continuity (BC) have expressed frustration with the existing state of affairs. Many practitioners feel unrecognized and underappreciated. Executives are confused by our methods and unclear about the value BC professionals provide. Some participants are skeptical of the outcomes and uninterested or frustrated by the activities. And, the discipline as a whole is often unknown to communities at large, despite the fact that costly disasters of every sort increasingly fill our newsfeeds. If you’ve been involved with this profession for any length of time, then you’ve likely experienced difficulties yourself or have heard the frequent laments of others.

How did we reach the point where BC is often misunderstood and undervalued? We believe several specific practices in traditional BC are ineffective and should be dismissed. The good news is that a collection of new practices has emerged that has not yet been fully synthesized and adopted. This book is an attempt to bring these practices together within a single framework built on a practical, unifying theory.

This chapter will help you to:

• Recognize specific practices in traditional BC that may be problematic, outdated, or ineffective.
• Identify specific activities that you may wish to eliminate from your practice.
• Approach the BC field with a critical eye and an open mind.
• Consider the need for an alternative approach to continuity planning.

1.1 Demolition: Traditional Practices to Eliminate

This chapter assesses the specific practices in traditional BC that contribute to the frustrations of practitioners, executives, and participants. We have called this chapter “Demolition” because we propose clearing out a space before we can build something new. While the title might seem a bit provocative, we believe this chapter will get you to think about your BC program and the specific practices that might be holding it back.

Take a moment and consider this possibility: Perhaps a main cause of frustrations with BC outcomes is not the way we have gone about executing individual BC activities, but the activities themselves. Perhaps we are expending enormous effort to perform the wrong activities in the right way. We believe this is exactly the case.

Here we provide an analysis of accepted practices within our discipline that we argue no longer meet the needs of today’s organizations. These practices are requirements within nearly all BC standards and guides. The details and guidance for each one vary slightly from one institute or association to another but they largely exist with similarly defined objectives and deliverables. Let us look at these practices in-depth to determine if, indeed, they provide value to the overall BC venture. We believe that the following seven traditional practices should be reevaluated or even eliminated in favor of a new, value-driven paradigm:

1. Produce a business impact analysis (BIA).
2. Set recovery time targets.
3. Conduct a risk assessment (RA).
4. Obtain explicit executive support.
5. Document the plan.
6. Test the process.
7. Deliver training and awareness.

1.1.1 Eliminate the Business Impact Analysis

At its core, the BIA is exactly what its name implies: An analysis of the impact to business from a future disastrous event, a process that often proves far easier to state than to actually do. Today’s standards go through great pains to explain the steps a practitioner should take to perform just such an analysis. And while standards can vary, they are largely in agreement over some very basic activities that contribute to the final product:

• Identify and define all processes performed within an organization.
• Determine the impact to the organization, in terms of financial loss and inability to meet regulatory and contractual obligations, should each process fail.
• Identify the minimal resources needed to perform each process.
• Prioritize processes across the organization and assign recovery time obj ectives.
• Identify process dependencies for the purpose of determining downstream impact from the failure of a single process.

Many practitioners add an activity: creation of recovery strategies. As if the BIA was not difficult enough, practitioners create continuity and recovery strategies for each process as part of the BIA itself. This is not the original intent of the BIA, nor is it a recommended practice in any guide or standard; we assert recovery strategies should always be a separate undertaking apart from the BIA. Therefore, we limit the scope of the BIA, for the purposes of our demolition, to its traditional role.

It does not take an exhaustive reading of BC articles and blog posts to see that there are a range of opinions and even doubts about the usefulness and validity of the BIA. The BIA can be said to form the bedrock of traditional BC practices, but it is arguably the most problematic activity. Because others have already gone into detail regarding the many issues associated with the BIA, we briefly outline these arguments in what follows.

1.1.1.1 The BIA Requires Too Much Effort for Too Little Value

A common critique asserts that the BIA requires significant effort with little value to show for it. Jim Mitchell, in his blog for eBRP Solutions, states, “Repeating the pattern of BIA surveying - with its inherent flaws - produces results of little or no value” (Mitchell 2011). The CEO and President of Lootok says the same in his series of articles debunking common myths of BC. Myth #2 in this series is dedicated to the BIA and asks the question “Honestly, what’s the point?” leading off with the claim of having “witnessed tons of BIA projects - all exhaustive, but useless from a business perspective.” Many commentators and practitioners bemoan the limited return on investment from the often-lengthy effort to produce a BIA.

1.1.1.2 The BIA Becomes Outdated Quickly

Another common concern is that the BIA is a snapshot in time that is so quickly outdated that it is rendered useless (Mitchell, 2011). Given the effort needed to execute a BIA, particularly following the time-consuming requirements in the newest ISO standards (ISO/TS 22317:2015), it stands to reason that information gathered at the start of the process could become stale by its conclusion. Since the results of the BIA form the basis of subsequent activities in traditional BC planning, results could become even further out-of-date as more steps are taken. This creates a potential cycle of misinformation and poor planning. As Mitchell summarizes, “By the time the ink is dry on the Senior Management presentation, the organization has certainly changed. Basing BC and DR [disaster recovery] plans on outdated results compounds the problem” (Mitchell, 2011).

1.1.1.3 The BIA Contains Significant Flaws

In a piece from August 2015, “Lessons Learned from 15 Years of Conducting BIAs,” Samuel Shanthan lists twelve individual problems with the BIA. This list summarizes many common complaints, such as overestimating the degree of impact, overstating the importance of individual departments, overlooking critical interdependencies, and the overall subjectivity of the process.

Finally, Rainer Hubert introduces several vital critiques. In his thorough article, “Why the Business Impact Analysis Does Not Work,” Hubert (2012) details four major problems with performing a BIA. These are:

Problem 1. The BIA is generally used to confirm assumptions about criticalities, not to identify criticalities. If it would actually be used to correctly identify criticalities, the time and costs needed to apply a BIA would be prohibitive.

Problem 2. The BIA requires an organization with established processes and activity-based costing as part of the day-to-day business to be able to deliver valid, reliable and reproducible information. In reality, only very few organizations can provide that.

Problem 3. The BIA is inaccurate or incomplete in its statement about impacts, since it needs information which is not available at the moment the BIA is created, and consequently either includes assumptions or leaves necessary parts of information out.

Problem 4. The information out of the BIA needs to be aligned against information, which is, in most cases, either not available, or reluctantly provided, or based on quick and dirty problem solving.

Hubert argues that the BIA is ultimately a nonstarter. He sees significant flaws in its approach that render it unreliable and ill advised. Hubert argues, and we agree, that the BIA suffers from both theoretical and practical defects that cannot be overcome. The time and money it would take to accurately identify all processes, their upstream and downstream dependencies, along with a forecasted impact from an unpredictable disaster are likely to be substantial. What specific disaster may befall an organization and the exact scope of its impact is unknowable. Specifying the revenue, liability, regulatory, and even reputational consequences for every function following an unpredictable event and its aftermath is all but impossible. Trying to quantify such an impact is unreasonable. As stated in the second problem of Hubert’s paper, “You need an established and consistently implemented system of activity based costing for that.... How many companies actually do have something like that?” (Hubert, 2012). In the end, the BIA has theoretical and practical failings.

1.1.1.4 The BIA Fails When Streamlined

The number of authors and the volume of material written about the BIA and its inherent flaws point to irresolvable problems with the BIA. In response, many practitioners have attempted to “fix” the BIA process. Many advocate for a more concise, streamlined approach, focusing on specific deliverables of the BIA such as prioritizing business functions, defining recovery times, or identifying process dependencies. Some professionals are now trying to save the BIA by eliminating large parts of its scope, picking the activities that are best received in their organization, or trying to keep with its spirit while cutting out many of the recommended activities. We contend that further discussion is fruitless and the entire endeavor should simply be eliminated. We suggest the profession accept the inevitable conclusion that the BIA is defective and must be jettisoned.

Recommendation #1: Omit the BIA

Actually, eliminating the BIA is very good news for the practitioner and our practice. Performing a BIA is unnecessary. You can eliminate it from your BC program and save huge amounts of time, effort, reputational capital, and emotional investment. While we will explain in greater detail throughout the rest of the book, we can summarize our perspective in three points. First, we no longer need a BIA to tell us which parts of the organization are important for planning and recovery. In most cases, senior leadership knows very well what parts of their organization are important. A brief conversation with executives and leadership is likely all you will need to get to work. Second, we no longer need a BIA to prioritize our services. We ought not to prioritize our services at all prior to a disaster, because, as we will discuss in detail later, the order in which leadership decides to recover services following a disaster rightly depends on the post-disaster environment, an evolving situation that cannot be anticipated. And, third, we do not need to set targets for recovery time. This third point leads us into our very next section.

1.1.2 Eliminate Recovery Time Targets

Time is often at the very heart of any discussion of BC and information technology disaster recovery. While planning, practitioners quickly ask, “How soon does it need to be available?” Following a disaster, everyone wants to know, “How soon will it be back up?” Maximum tolerable downtime (MTD), recovery point objective (RPO), recovery time objective (RTO), recovery time capability (RTC), and other time-centric considerations are intertwined within the very nature of current preparedness planning.

But there are deep flaws with the continued attempts to incorporate time into preparedness planning in this manner. These flaws lead to frustrated participants, disengaged managers, wasted effort, and dubious outcomes. Fortunately, these flaws are easily avoidable and correctable.

1.1.2.1 Time Targets Require Inaccessible Information

When the planner asks the participant, “How soon do you need X up and running?” the participant often answers, “It depends.” This answer is almost always the most accurate one. How long an organization can do without a particular service or system will depend on factors such as, but not limited to:

• Contracts and legal considerations.
• 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 proj ects and initiatives.
• Influences from the board of directors, shareholders, customers, competitors, and the market.
• Leadership and management priorities.
• Liquidity, capital, and revenue streams.
• Regulations and compliance requirements from federal, state, local, and other regulatory and accrediting bodies.
• The post-disaster status of other organizations affected by the same disaster.
• The post-disaster status of other processes, functions, systems, and services.
• The post-disaster effect on customers, consumers, and end-users of the organization’s products and services.
• The time of year, week, or day.
• Simply who happens to be in charge of recovery operations and who is in the war room at any given hour.

Forcing a single answer for recovery time targets may be impossible, inaccurate, and ill advised, because “it depends” is almost always really the best answer.

But, “it depends” is a challenging answer to accept. We want to drive to one specific answer about time, particularly because documenting this answer is required by current practice. Faced with this challenge, we can take a best guess, pick the worst-case scenario, or try to capture all the branching “if/then” conditions that lead to different time requirements. None of these responses seem particularly useful to the organization when planning for or responding to the chaos of an actual disaster.

1.1.2.2 Time Targets Set the Wrong Tone

Practically speaking, the drive to identify and document specific time objectives often gets us off on the wrong foot. We spend a disproportionate amount of effort and reputational capital negotiating with participants to pinpoint these time-related objectives. 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, they can set a negative, and sometimes adversarial, tone to the rest of the planning process.

Since “it depends” is indeed the right answer, there is a related problem with our determination to define a single time within which to recover a given service: It is inflexible. Once designated, such times rarely, if ever, change. The designated time then becomes the default measure by which all other activities are validated. It drives the recovery procedures and the objectives of all subsequent testing. It is often the first factor to be considered when events occur that do disrupt service, the consequence of which is that recovery time objectives become some of the first casualties.

1.1.2.3 Time Targets Create Risk Through Faulty Estimates

Recovery times are arguably the single most dominant values in an organization’s entire continuity program. Likely only a small number of mature BC programs do not capture recovery time targets. Consequently, establishing a recovery time for services is perhaps the most central activity of the practitioner in traditional continuity planning, usually in conjunction with the BIA. This is a particularly troubling situation if, as we have argued, recovery time targets and recovery time estimates are flawed from the outset.

Certainty can be a good thing. But certainty arrived at through spurious means is a serious risk. As has been demonstrated previously, the BIA is far from perfect. Using such a subjective and ill-suited tool to arrive at something so fixed is asking for trouble. Inaccurate time targets can forever set a practitioner’s program down the wrong path. Focusing on time targets can misguide planning participants, and shift resources from more important effort...

Table of contents

• Cover
• Title page
• Copyright
• Dedication
• Acknowledgments
• Preface
• Foreword
• Introduction
• Chapter 1
• Chapter 2
• Chapter 3
• Chapter 4
• Chapter 5
• Appendix A
• Appendix B
• About the Authors
• Credits
• More from Rothstein Publishing