Disaster Recovery Journal

I recently came across an article that got me thinking about the never ending struggle for visibility and acceptance our industry seems to have.  And it made me ask if we are approaching the problem correctly or for that matter addressing the right problem.

As Business Continuity professionals we are trained to be analytical and approach problems in a logical, fact based way.  You would think that after this much time someone would have come up with the definitive rational for business continuity. Yet, despite years of developing business cases, performing risk assessments and documenting a multitude of object lessons and justifications it seems that management disinterest and overall lack of attention are still the main complaints I hear. 

 

One of the ongoing problems in business continuity is articulating the business case in a way that resonates with executives and others in our organizations and doesn't require a twenty slide PowerPoint presentation.  In an attempt to help, I will periodically post items as I find them in the news or wherever they turn up.  The idea is to give business continuity professionals ideas for informal conversations that highlight both the need for business continuity activities and some potential pitfalls of ignoring them.

On Wednesday, August 25^th, a hardware failure in Virginia's main data center brought the services of multiple state agencies to a halt.  The failure impacted twenty-six of eighty state agencies including the Department of Motor Vehicles and the Department of Social Services, two of the most visible, public facing agencies.  Details can be found in an article from the Richmond Times Dispatch at http://www2.timesdispatch.com/news/2010/aug/27/8/vita27-ar-475161/.  As of Monday morning, August 30^th, three of those agencies still reported outages, including the inability of the DMV to issue driver's licenses.  

I have been resisting the urge to write about the myriad of continuity related issues and mistakes coming out of the gulf oil spill. However, recent articles and interviews about BP's contingency plan for an event at Deepwater Horizon raise an interesting question.

 Taking a quick step back, it seems that on an almost daily basis there is yet another communication blunder or operational disconnect that overshadows any progress BP may be making.  The accumulation of false starts, failed attempts, and changes to communication strategies only reinforce the idea that, to a large extent, BP is making things up as they go along - both technically and from a PR perspective.  The interesting part is that they have a plan - spanning hundreds of pages (I'll tackle the issue of quantity vs quality another time) - that was supposedly designed to address this type of worst case scenario.

The question is, is it better to have an imperfect (and in this case a woefully imperfect) plan rather than none at all? And if so, how do you set the bar for "close enough"? This has implications from both an operational perspective - time, manpower, cost etc. - and, more importantly, from an ethical perspective - for BC professionals.

 

One of the ongoing problems in business continuity is articulating the business case in a way that resonates with executives and others in our organizations and doesn't require a twenty slide PowerPoint presentation.  In an attempt to help, I will periodically post items under the title "BC Stories - Elevator Pitches and Object Lessons" as I find them in the news or wherever they turn up.  The idea is to give business continuity professionals ideas for informal conversations that highlight both the need for business continuity activities and some potential pitfalls of ignoring them.

An article posted March 24^th on cnn.com provides an object lesson on the need for regular testing of critical infrastructure  in order to effectively respond in an emergency, as well as an opportunity to engage people in your organization on the need for a formal exercise plan.  Basically, even if an organization has invested significant resources in its technology, things can still go wrong. Often, changes to support systems or network infrastructure can have unintended consequences that prevent access to even the most redundant and resilient systems.  The article, Wikipedia back up after server meltdown, highlights this issue.

 

One of the ongoing problems in business continuity is articulating the business case in a way that resonates with executives and others in our organizations and doesn't require a twenty slide PowerPoint presentation.  In an attempt to help, I will periodically post items under the title "BC Stories - Elevator Pitches and Object Lessons" as I find them in the news or wherever they turn up.  The idea is to give business continuity professionals ideas for informal conversations that highlight both the need for planning and some potential pitfalls.

A recent article posted on msnbc.com provides an object lesson on the need for proper planning and training in order to effectively respond in an emergency and another story to engage people in your organization on the need for formal continuity planning.  While the earthquake in Haiti may seem far removed from our daily activities and even the boundaries of most business continuity planning, the problems encountered in the relief effort mirror the difficulties encountered by organizations that fail to prepare. The article, which can be found at http://www.msnbc.msn.com/id/34958965/ns/world_news-haiti_earthquake/, highlights the problem of individuals and organizations with the best of intentions trying to help without understanding either the realities of the situation or the need to act in a coordinated manner.

It seems like everywhere I turn lately I see another article or advertisement touting the benefits of creating a culture around whatever it is they are involved with. Whether it's a "culture of security" or a "culture of continuity" it seems that everything is being sold as needing a culture.   My questions on this are twofold, what exactly is establishing a culture and is it something new and different or just an admission that there has been a lack of project management discipline in these areas.

A culture can be defined as "the attitudes and behaviors that are characteristic of a particular social group or organization".  In a business context, establishing a culture involves incorporating whatever is being added or changed within the environment into the basic way the organization does business, making performance of the necessary activities a basic part of the job and not as something seen as an extra task.  While I agree that this level of commitment is necessary for any change, and especially any new program, to be successful in the long run, viewing culture change as a separate effort makes the task much more difficult.

A recent question posted through the DRJ LinkedIn site looking for advice on business continuity metrics caught my attention and started me thinking.  At first I was tempted to fire off a quick response talking about the cyclical activities - BIA data refresh, plan updates, exercises etc. - that could be tracked, scored and summarized, but then I realized that without a larger context the answer would have little or no value.

Someone once said something to the effect of “if you don’t measure it, it doesn’t exist’”. To that I would like to add the idea that if you fail to present what you measure in the right format and don’t get it in front of the right people, it may as well not exist. Also, you must keep in mind that too much information can be as bad as too little. The key is to present what has business value and what will further the goals of the organization and the business continuity program. Therefore, the first step in designing a scorecard or other metrics is to understand the audience and present information that is relevant at their level.

Have you been feeling that your business continuity efforts aren't achieving the results you had hoped for?  Or is your program stuck in neutral and you have no idea exactly where the problem is or how to solve it?  Diagnosing the problems and getting things moving in the right direction might be as simple as documenting a business continuity program charter.  Which elements are clearly defined, and more importantly, which are missing or unclear, will speak volumes about the state of your program.

The first step in thinking about your business continuity activities as one connected program is aligning your business continuity activities with the larger organizational context. What are the key organizational objectives and how are they addressed by the program? Who are the key stakeholders and how are their needs and sensitivities addressed? By understanding business priorities and designing business continuity in direct support of them you will be able to clearly articulate the program’s value in a business context that will resonate with senior management.

I recently came across a new product called Vine from Microsoft.  It caught my attention because it seems to address some troublesome areas that regularly come up as we build business continuity programs.  Since Vine is still a beta product, it's difficult to assess the full range of capabilities or its viability for critical business use; however, several features are interesting, including:

1. The use of a map “dashboard” that allows the user to define an area of interest and receive news and other relevant updates. The dashboard also contains a social networking feature that allows the user to form groups and mark locations of group members;
2. The ability to send alerts to selected individuals or groups via the dashboard, text messaging, or email; and
3. The ability of any member to create what Vine calls reports and send them to any individual or group

There are two uses for this technology that might solve problems I regularly encounter:

Over the last number of years, many public and private sector organizations developed pandemic plans in response to potential public health threats that rarely materialize and have yet to reach a pandemic level. Consequently we have an abundance of plans at all levels that have never been implemented and tested against real world conditions (and some of these plans were developed based on flawed assumptions). With the recent and ongoing H1N1 outbreak causing many organizations to implement their pandemic plans for the first time, I wanted to begin discussing what we can collectively learn from the experience.

Some issues and potential solutions that I have noticed include: