World Headquarters or Mom Pop Operation - 1702-03 - Disaster Recovery Journal

Return to the
Spring 2004 Issue

DISASTER RECOVERY
JOURNAL

P. O. Box 510110
St. Louis, MO 63151
(314) 894-0276
Fax: (314) 894-7474
Internet www.drj.com
E-mail drj@drj.com

PUBLISHER &
EDITOR-IN-CHIEF
Richard L. Arnold, CBCP
richard@drj.com

SENIOR EDITOR
Janette Ballman
janette@drj.com

MANAGING EDITOR
Jon Seals
jon@drj.com

COPY EDITORS
Richard Sandhofer
richards@drj.com
Pamela Clifton
pamelaclifton@hotmail.com

ADVERTISING
Robert Arnold
bob@drj.com

_____________

Corporate

President/CEO
Richard L. Arnold, CBCP
richard@drj.com

Vice President
Robert Arnold
bob@drj.com

CONFERENCE COORDINATOR
Patti Fitzgerald, CBCP
patti@drj.com

CONFERENCE REGISTRAR
Merce Knese
mercedes@drj.com

CIRCULATION
Laura Baugh
laurab@drj.com

EXECUTIVE COUNCIL
Jeff Dato, MBCP, KPMG
John Jackson, IBM
Edward S. Devlin, E.S. Devlin & Associates
James Hammill, CBCP, JMH Consulting Inc.
Pat McAnally, SunGard Availability Services
Brian Turley, Strohl Systems
Belinda Wilson, Hewlett-Packard

INTERNATIONAL
CONTACTS
England: Thom Hetherington
Business Continuity
Phone: 0161-237-1007
thomh@tempus.demon.co.uk

Australia: Anthony J. Harvey
Journal of Business Continuity
Phone: 0011-613-953-0055-8
fax: 0011-613-953-0528
sector@notability.com.au

Japan: Shinji Hosotsubo
Quake Japan Co., Ltd.
Phone: 03-3215-2880
fax: 03-3215-2881

Brazil: Jose Carlos Ferreira
Disaster Recovery Mercosul
Phone: 55 11 3666-9506
conc2000@uol.com.br
www.drms.com.br

Click Here for a Printable Version

World Headquarters
or Mom and Pop Operation:
What’s the Difference for the Business Continuity Planner?

By JOHN GLENN, CRP, CBCP

What are the basic differences between creating a business continuity plan for a multi-billion dollar corporation and creating a business continuity plan for a mom and pop grocery?
How about differences between a business function and IT?
By this planner, all plans basically are the same; they have the same basic requirements. The operative word is basic.

Each plan has the following segments in common:

• Determine why the entity (or process or procedure or ...) exists.
• Identify risks to the “thing.”
• Rate the risks: what is the probability of the risk occurring versus the impact on the “thing” if the risk occurs.
• Identify ways to avoid or mitigate the risks.
• Document what must be done if the risk occurs.
• Create a training methodology to assure that if the risk occurs, it will be dealt with within the defined time constraints by people who are confident in their skills.
• Maintain the plan by watching for trigger events and by watching the calendar.

Pretty simple. Certainly straight forward. Of course the “devil is in the details.”
Business continuity planning, at least the basic functions of a plan, are the same no matter what or who the plan covers.
Does that mean anyone can be a business continuity planner?
Yes.
And no.
There is a difference between a business continuity plan and a successful business continuity plan, and that “difference” very often is the planner.

For Example
The second or third thing on a planner’s agenda – following the proposal and statement of work/project plan – is to find out why the entity exists.
I was talking with an IT senior director recently and she used a customer relations management (CRM) system – hardware and software – as the at-risk entity. (Now it should be clear why I fudged the wording above? The entity can be anything from the “total corporation” to the smallest critical process.)
Once we established the entity to be protected, we could start playing the “what if” game to identify risks.
What if the hardware hiccupped? Can it be fixed within the allowable time frame? Are parts on hand? Are tools available? Is someone trained to do the repair work?
If the software sneezes, where is the application located? Is there a mirror image of the software, with all the localization – known technically as “tweaks” – in place? Where is this version? (There ought to be two copies, incidentally – one on site and the other elsewhere.) What about all the outside-the-application routines that either reference the application or are referenced by the application? Do they need to be reinstalled? Are they compatible with the restore application?
(The number of “real” and “off-the-wall” questions I can raise is limited only by time and space.)

Get Real
Granted, there is an almost limitless number of risks to consider. Unfortunately, there usually is a limited number of coins to throw at the risks to avoid or mitigate them.
Now is the time to get real, to seriously look at each risk from two angles: probability and impact.
What is the probability the risk will occur?
My IT senior director is located in Florida. Given that location, we pretty much can rule out snow as a risk. Not 100 percent, of course, since snow might be manufactured down there for a party or something. A truck carrying the artificial stuff could tip and ... .
But it’s not a likely event and I won’t ask anyone to spend big bucks to buy snow plows, shovels, and similar equipment.
On the other hand, hurricanes do visit the director’s area and she might want to spend some money making certain her machines are protected from wind and water and that the troops can get to the work. Then again, if her machines are safe and her troops are on the job but the business functions are unstaffed . . . (Enterprise planning will save the day – if it is in place and tested and maintained.)
Having rated the risks, I need to come up with recommendations to avoid or mitigate the risks. To be honest, some risks are absorbable; either they are too far down the probability/impact scale for concern, or they are to a process, procedure, product, or other which is slated for replacement.
Being a good planner, I present all reasonable options and the impact of implementing each option: cost, training, impact on existing policies, procedures, product, image, whatever.
Now it is up to management – the senior director and her bosses – to decide what to implement, if anything.
Once management makes its decisions, and while we are waiting for all the pieces to fall into place, we can start the documentation process.

Who’s On First
Knowing the audience is crucial for this phase. Knowing the pressure the audience will be under when they need the documentation is crucial too.
Knowing the audience means knowing the readers’ comprehension level for the material. Education level is not a useful criteria and can cause serious problems if it is slavishly followed.
There are basic writing techniques used in the U.S. and Canada that writers in those countries should follow. Active voice is the first rule. (In many places other than North America, the passive voice is common and understood and the writer should write accordingly.)
The documentation created at this stage tells responders what to do right now. This is not the time for in-depth presentations of why something should be done. It is the time to state, as concisely and unambiguously as possible, what must be done to restore functionality ... by the numbers.
Tables lend themselves well to this approach:

Column 1: Do this
Column 2: This happens
Column 3: Remarks (tools, location of spare, etc.)

Do it one task at a time. Preferably one task on one sheet of paper. In big print.

Guaranteed Readership
There is only one way to guarantee people will read the documentation – exercise the plan.
That means creating a training methodology appropriate to the need. If the plan covers a 24/7/365 operation and requires “pulling the switch,” the training must work up to that exercise. On the other hand, if not, spare the budget and scale back the effort.
Throwing the switch is both expensive and dangerous.
Never, never, never expect a training exercise to be error free. One of the reasons the exercise is exercised is to find the “gotcha’s” that are bound to crop up. The purpose of the training is two-fold – to isolate and eliminate as many “gotcha’s” as possible, and to help the people who will be under the gun develop confidence in their abilities.
Many training methodologies start small and work up – simple desktop walk-throughs where everyone talks about what needs to be done and what is expected. This level exercise forces everyone to read the plan and comment.
A good idea, borrowed from the Sanhedrin, is to ask for comments from the most junior person first. Starting at the top may stifle valuable input from the junior members present.
As people gain confidence, the training becomes more realistic. If you think the CEO would be down screaming for results, have someone play the CEO role and scream for results. Better, involve the CEO so he or she can understand that “screaming for results” is counter-productive. My philosophy is to involve everyone at some point in the business continuation/disaster recovery process. What better time to bring the CEO on board?

Keeping Watch
Plans must be kept up to date.
There are a number of “triggers” which initiate plan maintenance. The triggers are determined by the entity the plan covers.
Back to the senior director’s CRM. If any hardware changes, the plan must be updated.
If the software changes and any procedures change, the plan must be updated.
If the senior director is promoted to very senior director and someone else is promoted to senior director, the plan must be updated.
If the vendor – any vendor – changes, update the plan.
Then, once something – depending on how dynamic the entity, this can be quarter, half, or year – give the plan a global review, a “gap analysis” to assure all hands that it really is up to date with reality.
Planners have to worry about more than just what is presented here. They should worry about personnel safety. They have to worry about a myriad of interdependencies.
The bottom line is that a plan is a plan is a plan.
If it is good or bad depends on a number of variables beginning with a planner’s curiosity, his or her ability to play the “what if” game.
But no matter what the plan covers, it needs to include all the basics.

John Glenn, CRP, has been helping organizations of all types avoid or mitigate risks to their operations since 1994. Comments about this article, or others at http://johnglenncrp.0catch.com/ may be sent to JGlennCRP@yahoo.com.

To comment on this article, go to 1702-03 at www.drj.com/feedback.