DRJ's Spring 2019

Conference & Exhibit

Attend The #1 BC/DR Event!

Spring Journal

Volume 32, Issue 1

Full Contents Now Available!

What’s the Difference for the Business Continuity Planner?

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?

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 This email address is being protected from spambots. You need JavaScript enabled to view it..