| Business continuity plan development explored
Just yesterday I said to a professional chef with 20+ years of high-level experience in his industry that I was beginning to feel like business continuity was becoming like cooking - everyone thinks that all they need is ‘secret recipe’ and they can turn out professional dishes, achieve their lifelong dream of opening a restaurant, etc. Somehow business people have become universal "do it yourselfers," failing to understand that the deep and broad knowledge and the painfully honed skills gained from experience are far more important than the business continuity recipe. Here are some important points to consider when developing a business continuity plan: 1. A business continuity plan is NOT a single unified plan. It is a set of specialised team plans documenting the backup and continuity strategies decided upon, based on the company's needs collected through a BIA or other method, and the actions required to implement that strategy to re-create/restore/relocate a business. There are several types of plans, each with some differences in content, but no team plan includes information about policy, history, etc. Each includes only that information necessary for that team to accomplish its functions. I am getting pretty discouraged with those who think that the plan IS the strategy. I have found that companies tend to do rather well on IT recovery plans, less well on business unit plans, and abysmally on logistics / communication plans and overall coordination. This makes sense since technical recovery is relatively simple, once you have got the bugs out through testing and your data is available; business unit recovery is more complex, but still not terribly difficult. Logistics and coordination processes are definitely not easy, particularly when you leave the military or emergency sectors. A very small percentage of private sector organizations do logistics well. 2. IDR - Individual Default Response. Within each plan, the individual default response of each team member during work hours and outside of work hours is listed by team member name. People pay attention to information associated with their names, not with roles, such as team member. The IDR can also be coded, along with other critical information, on individualised wallet cards that each person will carry at all times. 3. Use an automated notification system that allows for pre-programmed messages, ad-hoc messages, and voice-text translation. We all know that call trees are like passwords: they just don't work...and never have. Remember that you can use these systems to do regular notification tests painlessly - reports are automatically generated. Add up the time that you and everyone else spends on this and the product starts to look very good even as a testing tool. And obviously such a system will perform much better than any manual call tree during an emergency. So do not put the contact information of team members in the team plan....put it in an ASP-based high-performing automated notification system. Sell this kind of system to your management based on higher business continuity program productivity and ROI, not just on superior performance during the catastrophic emergency that they suspect will never happen. One caveat: make sure that the service that you subscribe to has fully redundant sites far from each other and that it can be accessed through phone or the Internet - make sure nothing goes on your site, because your emergency communication system will disappear when your site does! Sounds pretty obvious, but until the current generation of products, companies in fact put emergency communication boxes in their primary sites! 4. Keep your detailed reference information - electronic and non-electronic - offsite and out of your plan. A good place for technical recovery information -- past tests, command-level system re-creation scripts, etc., is the site where you plan to re-create your systems. Coordination information and contractual information can be in your command centre. If you have more than one command centre, replicate the information in each and store a copy offsite as well, just in case. Just DO NOT put it in the plans. Make your maintenance requirements minimal and you will have a chance to have current information. 5. Don't forget that the best recovery is one
that does not have to happen. Make sure that you identify all risks
in mission critical resources (not just 6. One more hint: more and more of us in the profession are understanding that recovery planning for the total catastrophic event (the so-called "worst-case scenario") is NOT the best way to go. If you plan to deal with the interruptions that have a high probability of occurrence, you will get more immediate payback from your business continuity efforts. Work up to worst case gradually - don't start with it. But again, this is a whole other subject. My advice to someone who is new to business continuity, but is nonetheless charged with doing a "business continuity plan" for regulatory or other purposes: Hire someone to advise you and take their advice. There is no reasonable justification for any enterprise to expect you to do something well that you have never done before and where you have no training or knowledge. Knowing the business and knowing IT does not equal to knowing business continuity. This is a complex professional skill that takes time and pain to acquire, and guess what, it is continually evolving. Sorry, there are no silver bullets here. If your organisation is too small to pay someone to advise you, at least get some training. Just remember that you need a whole lot more than a recipe! And that you will truly get nowhere if you are expecting to do this in your "spare time." Contact Kathleen Lucey at K.Lucey@montaguetm.com The above article is based on a presentation given by Kathleen at the Continuity Planning & Management 2004 West conference, May 2004.
•Date:
16th July 2004 •Region: US/World •Type:
Article •Topic: BC
plan development |
