Is this project one which your company is going to tackle itself, or do you want to contract it out? If you hire an outsider to do it, make sure that you stay involved in every phase of the operation. If you do, you will learn a tremendous amount about your organization.
For one BIA I participated in, our company hired a consultant, but we made it very clear that we wanted to be assigned to tasks just as if we were employed by the consultant. This worked very well throughout the project. We all participated in the kickoff meetings. The consultant performed one-third of the interviews, and we performed two-thirds (after several training sessions). We prepared the detail spreadsheets while the consultant wrote the final report, which we then edited before submitting it to management. It was a true partnership, and we learned some invaluable insights into our company that we would have missed had we farmed out the entire project. As a side benefit, we also saved our company about half the cost consultants normally charge for a BIA.
Whether to use software or not is another issue. I feel that software at best can be a good beginning, but it should not be relied upon as the sole determinant of your BIA findings. We owned BIA software at the time of one of our BIAs, but we chose not to use it, and instead developed our own questionnaire. This allowed us to capture quantitative and non-quantitative information. In my opinion, this worked very effectively, although it was also very time consuming.
The software issue leads into another quandary, whether to rely solely on a questionnaire, perform personal interviews, or use a combination of both. This will be determined in part by the amount of resources available to collect your data.
Questionnaires definitely have their place in data collection, but I don’t believe they should be used as the sole means to have a manager rate the criticality of their business functions. If resources are extremely limited, this may be a necessity, but I would try to avoid it if possible.
A good use of questionnaires is to gather data that involve lists of items (such as software applications, vendors, vital documents, or interdependencies among business units). Another purpose of the questionnaire is for items that may require research or some thought before answering. How many employees are required for a particular business function? How many during peak periods? How much revenue would be lost if the business function couldn’t be performed?
These types of questions take a lot of forethought to answer correctly. We also asked the managers to rate the criticality of each business function, but only because we were going to follow up with discussions about this during the interview. A number of ratings were changed during the give and take of the interview process.
If information did not fall into these two categories, then we did not put it into the questionnaire. We saved everything else for the interview. During the interview itself, having the questionnaire answers in advance allowed us to focus in on the key areas that needed to be addressed. It streamlined the interview, saving time during each of the 100 plus interviews that were held. Combining methods in this fashion gave us more information than either a questionnaire or interview by itself ever could have.
Determining what should go into the BIA report is also critical to its success. As stated above, it is critical to decide what information is going to go into the report, so you must make sure to ask the right questions during the information gathering process. If you would like several types of questionnaires, feel free to e-mail me at dolginh@bcbsmo.com, and I would be happy to send them to you. Every company should judge the effectiveness of these forms for your organization.
One main objective of the BIA is to capture the number of employees utilized under normal and peak operating periods, and then determine how many employees (or desks, in a multiple shift environment) are needed within the Recovery Time Objectives (RTO) outlined by your company.
If you aren’t familiar with the term, RTO means the timelines within which you need to recover your business functions. There are several ways to define the criticality of business units. There are usually three to five levels, broken into mission critical, near mission critical (sometimes called “necessary” or “essential”) and non-essential. To make it simple, you can even number them Tier 1, 2 and 3 or A, B, and C. These labels will mean different things to every organization. Mission Critical could mean minutes for some organizations or it could mean a week for other organizations, depending on your company’s tolerance for downtime.
It is also important to gather information on your company’s tolerance for data loss. While RTO measures your tolerance for downtime following a disaster, Recovery Point Objective (RPO) measures how much data can be lost prior to the disaster.
A simple example should illustrate this point. If you backup your data nightly during the week, and you have a disaster event at 4:00 p.m. on Monday, you have lost one full days worth of data plus any processing since Friday night’s backup. Add to those two days that it would take you to recover at your hot site, and you’ve potentially lost a total of five days. If your critical business units feel they can only be down for two days, then losing five days of productivity might be unacceptable to them. You can use the BIA process to make them understand that the true length of an outage due to a disaster is the amount of data lost (the RPO) plus the time it takes to bring your systems back to life following a disaster (RTO).
Following the BIA your business units will now have a more realistic expectation of how they will be affected during a disaster. The importance of this cannot be stressed enough. A good partnership with the business units is essential to a successful BIA, and to the health of the DR program altogether. The definitions for RTO and RPO should not be driven by the IT organization, but by the business units themselves. They are in the best position to gage the tolerance in your industry for an outage. Generally, the only time this is discussed in any formal way is the BIA process. Otherwise, it is usually dictated by IT, who are making some very large assumptions that they know what the business units want, or there may not be a concrete policy on the subject. Either way, don’t let it happen to YOUR organization. Keep your business units involved!
One of my objectives during a BIA is to understand how every piece of software relates to every business unit. If you have a large organization with hundreds of software programs, you may decide this is too tasking. If so, make sure you get at least the top five programs that impact each business unit. Applications should have a criticality rating separate from the business unit’s rating, because you should not assume that every business unit needs every application it uses within the same timeframe.
A business unit that has a recovery window of 24 hours may only need its two main programs up and running within that time frame. It may not need three other programs until the end of the first week, which might give you time to procure equipment and build it yourself, rather than including it in a hot site agreement.
Vendors, vital records and other equipment should be treated the same way. They all need to be rated based upon how quickly the information or relationship needs to be reestablished.
Once all of these lists are created for each business unit, it will become self-evident which applications, vendors, etc. are most critical. Your plans can virtually write themselves. Well, its not really that easy, but the plan writing stage does become much easier when the BIA is performed in such detail, and if all the business units have participated and taken it seriously.
Determining what constitutes a mission critical business unit will also impact your final product. There will certainly be monetary concerns of how each business unit affects the bottom line of your company, but you should also consider each business unit on other levels, including customer service, regulatory, legal and whether other departments are dependant on this unit, such as a printing department.
Imagine not being able to print out statements that generate revenue for a few weeks. Yet many companies may not consider their print shop worthy of having a mission critical rating. In banking, checks and deposits need to be processed within substantial time constraints. If they aren’t, there could be fines and a very big public relations mess, where it could lose business. Customers’ account balances would also be affected. Yet, the department does not generate measurable revenue. It is, however, mission critical.
In determining how many business units might be critical in your organization, there are no hard and fast rules. However, the 80/20 rule has seemed to prove itself out over several projects. Approximately twenty percent of your business units should fall into the highest criticality rating. It will be higher if you are in a highly time sensitive field. These twenty percent of business units will require eighty percent of your efforts, and deservedly so, since they are the heart of your organization.
If you haven’t tried a BIA in your organization for some time (or ever), this should give you enough food for thought to point you in the direction you want to go. There will be other issues and decisions to make, to be sure, but you should be able to develop your own technique, incorporating some ideas from this article, and your own experience on what will be successful in your company.
Harlan Dolgin, CBCP, is a Business Continuity Analyst with Blue Cross and Blue Shield of Missouri. He is a non-practicing attorney and has been involved in IT since 1994.
