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.

Thank you for your input.