By Mark Armour, cABCF:
A fundamental problem with our traditional approach to business continuity is that it is predicated on the belief that BC is something that can be delivered. This forms the foundation of our lifecycle and methodology-driven approach as it believed that, by properly executing a series of steps, a required level of preparedness will be the natural outcome.
In truth, preparedness and recoverability is something we –as business continuity practitioners –can only influence and facilitate. So, what are some tips or tricks we can employ that take us out of this mindset that BC is provided by us rather than something we enable through facilitation?
1. Defining recovery objectives
Traditional time-bound objectives are designed to provide a single means of validating that business continuity has been “delivered”. Satisfying such objectives becomes the driver and incentive within the business continuity space. Changing our mindset around business continuity starts with eliminating such focus. Instead of striving to satisfy an objective, look at business continuity as improving upon existing capabilities.
2. Separate Technology Recovery
Business continuity is about the delivery of services absent a resource –like Technology, Workspace and Staff. For this reason, time-bound parameters may make sense. When we understand this, we can separate our approaches. This is particularly important for business continuity practitioners who may have responsibility for both areas.
3. Realize that capability already exists
The Adaptive BC practitioner understands that recovery capability exists, regardless of whether formal programs and plans are in place. Through measurement, we can help the organizations we support to understand their level of recoverability, make informed decisions, and identify concrete steps that can be taken to improve.
4. Stop focusing on compliance
Compliance-driven programs reinforce the notion that business continuity is achieved by satisfying the requirements around execution of specific actions or delivery of materials. When we understand that such approaches only satisfy compliance mandates then we can start to think of business continuity as something that exists within a wide range of possibilities. Our goal should be to understand where, in that spectrum, our organizations sit and how we can improve.
5. Skip the gap analysis
Adaptive business continuity is about continuous improvement, not about satisfying an arbitrary objective. A gap creates the impression that there is a pre-defined recovery level that must be achieved, and the purpose of the program is to reach it. This can cause two problems. First, once levels are met, there is little or no incentive to improve even though improvement is always possible. Second, if objectives cannot be reached, then we put processes in place to accept the risk or shortcoming. This reduces or eliminates the opportunities to improve as such approvals are designed only to satisfy compliance requirements and disincentivize further progress.
6. Eliminate the focus on risk
The sooner we eliminate our focus on risk, the sooner we can get to our primary responsibility: preparing for the materialization of risk. Risk management teams do not take responsibility for preparedness so we should not be doing their jobs.
7. No more plans
This may be the most controversial but may also make the most sense. Eliminating our reliance on detailed documented instructions clears the path for a better approach to preparedness overall. If we remove plan documentation from our deliverables, the participants will not expect that their recovery can be scripted beforehand and, instead, consider the importance of flexibility and adaptability in response. In addition, if participants in our efforts do not expect that all their ideas and contributions will be written down for future reference they maybe more apt to commit the important aspects of their work to memory through focus and practice. By doing this, we foster an environment of learning and a culture that is more focused on practice than on documentation.
