Tag Archive for business continuity plans

Having Plans vs Being Prepared – Avoid the Oops

I have recently posted a couple of blogs discussing the difference between Planning and having Plans.  In this blog, I want to explore the difference between Having a Plan and Being Prepared.

I have been in a number of environments where I thought the organization had great business continuity or disaster recovery plans – but, I did not believe that they were prepared to recover from a business interruption event.

Most plans rely on a number of “enablers” that have to be in place in order for the plan to be successfully executed.

First and foremost, the physical environment that the plan relies on has to be in place.  I have gone into a number of situations where the Executive Teams were convinced that their planning team had put great plans in place and I had to be the one to tell them that the plans were based on infrastructure not yet put into place.  “Yes, your plan is to recover applications in an alternate recovery site, which is a terrific plan … but you have not invested in or built out that site yet.”  Oops.

Secondly, the plan must be socialized and known by those who must manage to the plan.  I have seen some great plans sitting on shelves, known by only those few who wrote the plan – but all the people that would have to oversee and manage the execution of the plan had never read or been educated on the plan.  Oops.

And, third, in order to really be prepared, you must test, exercise and drill the plan.  It is through tests that you validate the correctness of the plan; through exercises that you discover ways to improve the plan; and through drills that you condition people on how to respond when executing the plan.  I have been in many environments where the plan may be understood by everyone, but never physically put into action to see if it will actually achieve the intended results.  Oops.

So there is much more to being prepared than to simply having a good plan.

Having just passed the anniversary of the D-Day invasion, perhaps that will serve as an example of what I am talking about.  There were relatively few people that actually “planned” the invasion.  And only a few more that were educated on the plan.  But, 10’s of thousands of others that had to “prepare” for it, in order for the plan to work.

It only takes a few people to create a good plan … but, it takes an entire organization to be prepared.

Don’t let your good plans fail because of an oops.

Removing the Fluff from the Stuff

I understand and appreciate the need to document your Business Continuity, mission, objectives, process, justification and analytical results.  I think all of this information is valuable in advancing and promoting your programs; educating management and participants on your program; and, providing a foundation for internal and external audits.  And, I think it is important to mandate that certain, key players in your program read and understand all of this information.

But …  Oh, come on, you knew there was a “but” coming.  But, I don’t think that stuff belongs in the same document that includes your “at-time-of-interruption” action plans.

Too often, I see organizations create one tomb of everything Business Continuity and call that their Business Continuity Plan.  In my opinion, you should have the book that explains everything business continuity related and then a stand-alone “Action Plan” that is you instruction manual of what to do when the lights go out.  In fact, you should probably create a whole bunch of “Action Plan”s – one for each unique function in your continuity, recovery and emergency response program.

I think reading and understanding “the book” prior to an emergency is important and should be mandated.  However, much of the stuff in “the book” just gets in the way at time of event.

“The book” should: set the premise for your program; identify objectives, assumptions and givens; explain, holistically how teams work together; provide background on how and why strategies and solutions were selected; explain the entire planning and implementation process – all stuff that is important to know, prior to an interruption, but just becomes a burden to flip through when trying to figure out just what to do now that an event is occurring.

The “Action Plan”s should be concise and detailed, step-by-step, vetted through testing, tactical tasks to be undertaken once a disaster is declared.  These plans need to be easy to follow (relatively) easy to reference and to enough detail that a backup team member, with less experience in the process, can follow and successfully implement.

I have seen organizations get very creative in producing wallet sized plans, tri-folds and/or thin plans that get right to the point and, in some cases, provide a way to record which steps were executed along the way.

There are a number of software products that also help maintain these action plans and allow you to track the implementation process at time of disaster.  These can be very powerful emergency management tools if properly implemented and monitored.  (They can also become just as cumbersome and useless as the War and Peace-like plan if implemented incorrectly.)

So look at your documentation and ask yourself if you have successfully separated the wheat from the chaff?  Do your team members have a useful tool to help them execute their recovery responsibility at time of disaster without having to flip through pages of “fluff” to find out exactly what they are supposed to do?  And, when you test your program, do you make sure these plans are being referenced and updated to ensure the documentation matches the reality?

More on this topic to come in future blogs, but – I use that “but” word a lot, don’t I – I think that is enough for today.  Thanks for visiting our blog.

Why I Hate the Word ‘Plan’

I have already discussed, and most of us already understand, that business continuity, disaster recovery and crisis management professionals are challenged by use of an inexact and often confusing jargon.  We use terms such as business continuity, disaster recovery, resiliency, hot site, warm site, cold site, recovery time objective, recovery point objective, business impact analysis, contingency plans, etc., that are often used to mean very different things to experienced and practiced professionals – not to mention what they mean to the uninitiated.  It can be confusing and often lead to misunderstandings and gaps between expectations and deliveries.

But, the one word I hate the most.  The word that makes me cringe when I hear it.  The word I try to eliminate from the vocabulary of consultants who work for me is … “plan”.  Such a little, simple word – how can I possibly have such distaste for this common word amongst all those other confusing terms?  Well, I’ll tell you.

What exactly do people mean when they say the word “plan”?  And what exactly do people assume when they hear the word “plan”?

There have been more than one occasion where a consultant went into an organization and had this conversation:

CONSUTLANT:  “Do you have business continuity (or disaster recovery) plans?”

CLIENT:  “Yes.”

CONSULTANT:  “Can I see them?”

CLIENT:  “See what?”

CONSULTANT:  “Your plans.”

CLIENT:  “Oh, there is nothing to see, our plan is to …”

What the consultant was meaning to ask was, “Do you have a manual of documented business continuity policies and procedures?”  What the client heard was, “Do you have a business continuity solution in place?”

Then there was this rather uncomfortable moment I had in a corporate board meeting where I was reporting on the company’s business continuity posture:

CEO:  “Okay, Joe, cut to the chase.  You have been here a while, what is your greatest fear that could impact our ability to operate our business?”

JOE:  “A data center disaster.  This is the one disaster that will impact your operations world-wide and bring everything to a halt.”

CEO:  “But, we have taken care of that.  Our IT Director just gave us a presentation last month on his Disaster Recovery Plan in case of a data center disaster.”

JOE:  “Yes, I saw that presentation.  His plan is a plan to build out a recovery capability – but you have no recovery capability today.  His presentation showed a backup site that he recommends be established but isn’t there today.  If your data center goes down today … you are out of business.”

CEO:  (Turning to the IT Director)  “Is that true?  We don’t have a recovery plan today?”

IT DIRECTOR:  “No, we have a plan.  It is just going to take us 15 months to get it up and running if the budget gets approved.”

CEO:  “Oh, that’s not good!  I was under the impression we had a plan in place and not just a plan to build a plan.”


I have seen it time and time again.  The board of director does what it is told to do; ask if we have a plan in place.  The responsible party gives a nice terse, “Yes” answer and everybody is happy.  Then I come in later and explain, “Well, you might have a recovery ‘plan’ but you don’t have a recovery capability.”

I instruct my consultants:  If you want to know if they have a recovery capability, ask them what their recovery capability is; If you want to know if their capabilities are supported by documented policies and procedures, ask them to see their documented policies and procedures.

My consulting plan is – avoid the word “plan” – and, be more precise by stating what you want that word to mean.