Garbage in-Garbage out-Garbage Plans

Michael R. Galin, Director-Risk Management, TELUS [NYSE:TU]
472
757
150
Michael R. Galin, Director-Risk Management, TELUS [NYSE:TU]

Michael R. Galin, Director-Risk Management, TELUS [NYSE:TU]

Your IT disaster recovery plans are only as good as the information you collect about users’ needs. If you use inaccurate information you will produce ineffective plans.

The best way to gather important information about business recovery needs is to conduct a Business Impact Analysis (BIA) for each distinct business process. The BIA will identify how each business process uses your IT services and telephony. You will know who uses what, how they use it, when they use it, and what their recovery time objectives are. From that, you can determine your base service levels, IT recovery time objectives and recovery point objectives. Not only determine them, but justify them with data.

But, this isn’t about the necessity for a BIA. I hope you already buy into that. This is about how the BIA should be conducted and some considerations from an IT provider’s perspective. Let’s start with the methodology.

Survey Says …

Have you ever sent out a survey and received back a meaningful, comprehensive, succinct expression of the information you were seeking? Probably not.

  If you want to receive the most meaningful, accurate and detailed information, do not send out a survey. Conduct an interview 

If you want to receive the most meaningful, accurate and detailed information, do not send out a survey. Conduct an interview. It should only take 30-90 minutes and it is worth the effort. If you can do it in person, that is ideal. You can easily tell from the expression on a person’s face whether or not they fully understand the question you are asking. A telephone or tele-presence meeting will do as well if you cannot get together.

You don’t have to interview every person in the organization. Conduct one interview for each distinct business process and you will capture what you need. You can interview more than one person at a time, as long as you are interviewing them for the same business process. They may even help prompt each other and provide better results.

The key is to make it a dialogue. Don’t just recite questions and record answers. Listen attentively to the answers and engage in follow-up questions until you get the information you need. Be prepared to ask any question at least 3 different ways.

While you ask the questions and engage the interviewee, another person should record the information. You simply cannot listen attentively, think about the answers, ask follow-up questions and “read” the interviewee’s face if you are busy writing or typing. No, you can’t. Even if you could, your interviewee will not be fully engaged if you are not making eye contact and paying full attention to their answers. An additional benefit to working in pairs is that the person recording the information will catch inconsistencies that you will not even notice.

What Are You Looking for?

As an IT provider, what information do you want to capture in the BIA interview? You really want to know who uses which services and devices, to what extent they use them, what are their recovery time objectives, and how dependent are they upon them.

The BIA should start with demographic questions so you understand from where within the organization the requirements originate. At some point after you have completed the interviews you will want to slice and dice the data such that you can perform meaningful analysis.

From an IT perspective, you will want to know what hardware, software and services they use. Also, if they lose the use of their PCs, laptops, or mobile devices, can you replace them with machines containing the standard corporate image or are there special requirements? For example, if they require a particular item to satisfy a two-day recovery time objective, but that item has a three-day lead time, that represents a risk to be managed. You can only do four things with any risk; accept it, eliminate it, mitigate it, or transfer it. Time to get creative and resourceful.

Don’t Just Record, Understand

Anyone can record an interviewee’s answers, but you need to really understand what the interviewee is telling you. For instance, people will tell you that they use, and need “email.” What you actually need to know is how they use email and what it is used for. During an incident that shuts down or compromises the corporate email platform, do the users simply need the ability to send and receive messages, or do they need access to their archives and folders as well? Do they need to send or receive confidential or sensitive information? If they just need to communicate about who is where and what they are doing, maybe they could use Gmail as a backup strategy, while the regular email platform is restored. A cheap and easy interim solution that buys you time for a longer (more affordable) recovery capability. If, on the other hand, they need to send and receive confidential or protected data, the pressure is on to accelerate your email platform recovery. Of course that comes with a cost, so it is important to truly understand all the specifics of this need for “email.”

The “Doohickey” Effect

When you collect IT requirements information from users you get the information from their perspective—of course. They will refer to the systems and tools by the names with which they are most familiar. Sometimes they don’t even know what the things they use every day are called. I can’t tell you how many times someone has described a dongle along the lines of “the doohickey that plugs into the thing to make the computer work.” This is why it is essential that the interviewer understands the IT environment.

The users will likely not know the proper names for applications either. While conducting over 800 BIA interviews for one particular organization, we had several hundred people tell us, “I use SAP.” Very few people knew which modules they actually used. Rather than asking an open question such as, “What do you use?” use a pre-determined list of services and tools for the interview.

It is alright to ask a user about IT services using non-technical terms. Just be prepared to translate their “doohickey” to the proper name before recording it for analysis. You will need to develop a sort of IT Rosetta Stone with common user names for your services, devices and applications.

Good Data, Good Analysis, Good Plans

The key to effective DR plans is to truly understand what your users need in terms of recovery. The BIA is the most effective tool to collect that information, but you need to collect the right information, from the right people, in the right manner. Remember, Garbage in–garbage out–garbage plans.

Read Also

Using

Using "The Box" for Disaster Recovery Planning

Eric J. Satterly, Vice Provost for Information Technology
Disaster Recovery: A Continuous Journey

Disaster Recovery: A Continuous Journey

Mathew Beall, VP of Infrastructure, First American Financial Corporation
Crisis and Incident Management for the 21st Century

Crisis and Incident Management for the 21st Century

Louis Grosskopf, General Manager, Business Continuity Software, Sungard Availability Services