No, we didn't say "7 easy steps", because we don't want to insult your intelligence. Planning to continue critical operations isn't easy, and it can't be boiled down to a simple graphic, but it is important to understand the framework of an effective program. And that's the purpose of this business continuity info graphic. We hope you find this valuable, particularly if you are new to business continuity.
We doubt Jillian or Tony knows what a BIA or RTO are, but we do think they represent a terrific example of how buyers think about business continuity software.
We've said this before: we think software is awesome...if used correctly. But if not used correctly, its hard to think of a bigger time suck or distraction. So now we're going to hack off every business continuity software salesperson by exposing a far too common business continuity software experience (specifically, for those that jump into using software too quickly). But we don't care because we're only concerned about you, the person who actually has to implement the program.
You Can't Afford Not to Have These Results!
Here's the software sales pitch: "It's easy to use, it'll save you time, and your results will be spectacular!! Here are some sample results...aren't they sexy?!" Sounds sort of like a physical fitness pitch, right? It's a great analogy-- lets go with it.
Or, Can You Afford to Have These Results?
You love Tony's biceps, but what you might not realize is the number of pushups, pull ups, curls, and sweat went into getting to that point. You love Jillian's ripped bod, but do you have any clue as to how many thousands of crunches and planks she's probably done? Every month? But that's not the focus of the sale. The focus of the sale is on the results. For business continuity software, your push-ups, sit-ups, and 10Ks are measured in program design, system integration, user training, user retraining, more user retraining, system adjustments, de-bugging, user documentation, and on and on. Not so sexy anymore, is it? None of what we just listed is actually business continuity planning or solving real life business problems.) For a new program that hasn't established a high level of support, point-and-click planning is about as realistic as scoring that beach body in 5 minutes a day on a diet of Cheetos and PBR. Just ain't gonna happen. And you'll look pretty silly trying to sell your organization on the idea that it will.
Just Be Real
So, like P90X and The Biggest Loser, take a realistic look what you're getting into. The results are great if you commit to doing what it takes to get there. But don't rely on the software salespeople to tell you what it takes to get results, that not their job. Their job is to convince you to buy.
The First Law of business continuity?Sorry to drag you back to high school physics, but does anyone remember Newton's first law of physics? If not, here's a refresher: "An object in motion tends to stay in motion, and an object at rest tends to stay at rest."
Sir Isaac Newton should have been a business continuity professional. He clearly understood the importance of BC program momentum, or the lack of it. Your business continuity program might as well be an object-- maybe the apple that fell on Newton's head-- because the same law applies. But here's a corollary: "A business continuity program that is at rest is actually getting worse." That's because business continuity is a perishable program. To be stagnant is to collect dust, to lose importance, to become forgotten, to lose support, to become obsolete.
Ideas that Isaac would get behind
You want your business continuity program to have momentum: consistent, positive forward movement. It helps to realize that, for business continuity, forward movement comes in small steps. Trying to do too much can bog your program down and prevent momentum. Here are some tips to keep your program moving forward:
Lets start by acknowledging that there is a sizeable group of BC types that are firmly opposed to the Business Impact Analysis. One line of reasoning is that today’s enterprises are just too complex for a BIA to cope with. The organization drowns in data that is ever-changing due to business dynamics. So it becomes an exercise in futility and frustration. It’s hard to argue, having seen how several BIAs have been conducted.
But there are differences between well-done BIAs, and poorly done BIAs. This piece will focus on just one area: setting reasonable objectives. You really have to get that right if the overall process is to be of value.
Remember, the primary purpose of the BIA is to understand which business functions will cause the most pain if disrupted. That way you can focus your planning and mitigation efforts where they will do the most good. Once those functions are adequately addressed, you can move on to the next priority tier.
A secondary goal can be to understand some essential details about the critical functions: recovery time objectives, recovery point objectives, interdependencies, IT requirements, employee skills, essential third parties/records/equipment, etc.
Some BIA’s try to catalog detailed information for every function that occurs within an organization. Its unnecessary, and it’s a distraction. In fact you’ll be digging a hole because you’ll be asking people for a lot of information that won’t ever be used. People don’t like that, and you wouldn’t either. It’ll damage your credibility.
One Step at a Time
So, if the objective of step one was to fill your priority “buckets” (High, Moderate and Low criticality), you can now set an objective for the next step. In this step you’ll gather essential details for just the high criticality functions. Your stakeholders will understand why that’s appropriate. It makes sense and they can support it. And its far less taxing on the organization.
Regardless of how meticulous you prepare for the BIA, your results won’t be 100% spot on, and that’s actually OK. So keep the BIA as simple as you think you can…build support and understanding, and realize that some adjustment will be necessary. As people become more aware of the business continuity program, they’re thinking will evolve, as will their thoughts on what is most critical. That evolution in thinking is a terrific sign; it means that people are engaged and improving what’s been put in place. And you'll be on your way to an effective business continuity program.
Wouldn’t it be great if the media showed up only when invited? That way your company could be fully prepared: you’ve reviewed your speaking points, anticipated likely questions, and trained your spokespersons. If only that were true in the real world. When a crisis occurs-- as far as the press is concerned-- it’s “Ladies and Gentlemen, Start Your Engines” because the race for the story is on. Whether you are prepared for crisis communications or not.
So, if your organization is subject to media attention, you need to be ready to respond to questions at a moment’s notice. Of course you may decide not to interact with the media, but if you do, that first step can be a doozy. Your first order of business is to not make any mistakes; you want to put your company on a solid footing to deal with continuing media attention. What you don't need to do at this point is answer every question that is asked, speculate, or just say anything in the hopes that the media will go away. Remember, an ill-considered statement will become the story. If your spokespersons remember nothing else when first engaging with the media, they should remember these 4 points:
1. Acknowledge the issue. Don’t go into denial mode. Remember, you’re not accepting blame, you're just confirming that you understand. Your company shouldn't be oblivious to an obvious issue.
If you spend time with planners, at some point you’ll likely hear the following statement: “A bad plan is better than no plan”. My answer to that is…WRONG! (First, let me characterize what I think of as a “bad plan”. To me, a bad plan is one that won’t offer any value. It’s woefully out of date, it has gaping holes, it has significant errors, or it calls for actions that are unreasonable.) Here’s why those bad plans are worse than having no plans.
First and foremost, the development of plans creates expectations within the organization: “Oh, we have a plan, we must be ready to deal with so-and-so situation.” Obviously that’s an erroneous assumption if the plan actually won’t work. That false sense of security will leave your organization on the tightrope without a net. When crisis strikes, it would be better to have the organization think, “Hey, we need to figure this out…quickly!” That’ll at least give you the opportunity to come up with solutions that actually work.
And plans that don’t work will cause confusion (“We said we would take this action…why aren’t we doing this?”) and lost time (“We tried this and it didn’t work, so lets try something else.”)
Of course it’s best to have a good, solid plan that’s been trained and exercised. But in the absence of that, realize that a “bad plan” could be worse than none at all. -C
ICS is an absolutely terrific response structure that allows various agencies to work together using a common approach and terminology. But it’s usually a mistake to adopt it in the private sector, and here’s why--
1. It takes enormous practice (training and exercises) to maintain competency in ICS. Commercial enterprises are rarely able to dedicate the resources needed to maintain even a minimal competency level. If you’re a firefighter, police officer, or other responder, ICS is an integral part of your job. That’s not true for most companies.
2. ICS’ organizational structure and roles are different than a company’s day-to-day organizational structure and roles. That causes confusion. In the heat of a crisis, you want to minimize confusion, not create it. Example: why should the Director of Corporate Communications have to become the PIO (Public Information Officer) during an emergency? Who benefits from that? (If you think it’s the first responders, see the next point)
3. If your organization adopts ICS and you tell first responders “We use ICS”, they’ll have certain expectations. What’s the operational period? Where is your EOC? When was the last IC briefing? Who is the Planning Section Chief? If you’re not honest-to-goodness ICS competent, better not to even pretend; it’ll just be another source of confusion to them and to you.
Here’s the good news. Most companies don’t have to worry about the complexities of ICS. A crisis management team should be able to do the following:
How many times during the course of a project have you gotten the advice “if in doubt, over-communicate”? It’s easy to justify that approach by convincing ourselves that more information is better. But is it? Providing too much information can be just as harmful as providing too little… and even more so in some situations.
It’s Really Just a Tactic, Right?
Lets start by admitting that-- at its core-- over-communicating is just a Cover-Your-Ass tactic to mask our deficiencies. Here are a few reasons why:
Whether developing business continuity plans, or reacting to a crisis, you want people to know that when you send a message, it means something. When we hammer people incessantly with email and information, they tune us out. You’ve conditioned your audience to assume that what you have to say isn’t important. That’s not where you want to be.
Getting it Right
On too many occasions, the lucky soul who’s been assigned the responsibility to lead business continuity feels like she just won a contest where the prize is a big sack of cow manure: you think it stinks, it has no form, and you don’t know what to do with it. I’ll stop with that metaphor before this gets out of hand, but you get the point.
This will sound cliché, but there are very few other responsibilities that provide as much opportunity as leading a business continuity effort. Seriously…just think about it. What other responsibility gives you insights into all areas of the enterprise: how they work, how they fit together, and what their challenges are? What other responsibility allows you to build connections in all departments, at all levels? What other responsibility lets you interact with senior executives on strategic matters? BC provides all that.
I won’t say that business continuity is a simple program to take on, but if you’re interested in becoming more valuable to your organization, the rewards are significant. It’s all in your mindset. Viewing BC as a professional opportunity will yield personal benefits to you. Viewing BC as a monumental administrative task is a lost opportunity (and the program will probably reflect that).
I’ll be up front about this topic— it’s a hot button with me. Not because I don’t like BC software providers, I do..I’ve designed BC software myself. It’s because we use BC software for all the wrong reasons; we mis-use it. Its not the software providers, it us, the users. BC software can be a great thing if applied correctly. Unfortunately that’s way too rare. There are many reasons for this, but in this blog I’ll focus on two areas. Let me explain.
We want to simplify our planning by using technology. Our intentions are good, but here’s what happens…
The reality is that in most organizations, people are engaged in BC planning infrequently. So, they don’t ever become intimately familiar with a system that is unique to business continuity (regardless of how simple you think it is to use). So, someone has to train and re-train people, re-set passwords, undo inadvertent mistakes, etc. That is not simplifying planning. Simplifying planning might just be giving people the tools they already know how to use. Yes, I’m talking MS Word files. Think about saving the software system for work that requires analysis.
Maybe our goal in introducing BC software is to improve planning by integrating other data sources (e.g, Peoplesoft, etc.). I won’t even go into a discussion about how much time and effort integrating systems can require, but will focus on another point. The whole purpose of planning is to familiarize people with the things they need to do in various situations. Makes sense, right? By automating all of the data, we essential engineer out that familiarity. There are new people named in the plan? Peoplesoft took care of that change. We use new IT applications in a critical process? The IT configuration management tool addressed that change. We have new equipment in the factory? ERM covered that. In other words, you are eliminating the need for key people to review and update the plan…one key activity to reinforce familiarity.
So what to do? If you’re implementing a relatively new program, give yourself a bit of time to let thing shake out a bit. Develop your program with the tools that you already have, and after some time you’ll be able to see where technology will help. At that point you're ready to make a good decision about business continuity software.