To kick off my presentation at a recent conference on business continuity, I called for a volunteer from the audience. A man at the back of the room stood and moved into the center aisle. I beckoned for him to come closer and then stopped him when he was about halfway to the front of the room. All around him, his fellow audience members sat and watched, curious and expectant.
Are you, Sir, a continuity or recovery planner? I asked.
Yes, he said.
As your new boss, I have some job responsibilities for you.
I began handing him a number of small rubber balls, five in total, each one marked with a different topic such as systems, applications, documentation, etc. When he was holding all five, I directed him to get all five balls in the air and keep them there. With scarcely a moments hesitation, the man proceeded to efficiently distribute the balls to various audience members seated nearby.
Had my volunteer attempted literally to juggle the balls, I suspect he would have nicely illustrated the futility of one person attempting to manage every aspect of the business continuity planning process. Instead, he demonstrated an antidote to such futility: delegation. I was not disappointed by my volunteers initiative since any response (short of a Ringling Bros.-style performance) would have served to illustrate either of two propositions central to my presentation: first, that the job of the continuity planner encompasses far more (tasks to perform and information to manage) than any one person can possibly hope to handle alone, and second, that delegation is one of the many skills critical to the continuity planners success.
The ability to juggle remains a critical skill as well because, ultimately, we can only delegate so much. Having delegated all that we reasonably and comfortably can, we are still left with an enormous amount of information and many critical tasks to manage. Use of a project plan, with some specific project planning software, is one of the more common ways of organizing information; ensuring task completion; and allocating time, resources and budget. Another common repository for storing and structuring information related to continuity planning is a software package created specifically for continuity planning. And yet, despite the availability of such resources, there are still planners who do not rely upon such tools and documents that, for whatever reason, are not easily tied to or integrated into these programs.
As a continuity planner, I have found that all of the responsibilities and expectations of my job and all the information I must manage can be classified under one (or more) of the following three headings: people, paraphernalia and paper.
People
These are the human factors with whom you must build rapport and develop relationships, the ones you depend on to perform specified tasks and who depend on you to coordinate and recognize their efforts. These can include system technicians, application developers, network specialists, end users, vendors, auditors and executive management. The importance of building good relationships cannot be overstated; of the three headers mentioned, the one of people is by far the most critical.
Time spent developing and enhancing relationships is almost always time well spent. It is, after all, people who make things happen and mutually supportive people that make great things happen. Oddly enough, a person will not always give immediate support to your vision, goals or requests, despite your winning good looks, forceful personality or even a corporate mandate requiring their support. In the workplace, as elsewhere, the cooperation and support of others must usually be earned by developing relationships marked by mutual respect, particularly if those others are not your direct reports.
As a continuity planner, you must have immediate access to the people who support your work. You should keep all contact information in a single location: a document, a spreadsheet, a database, etc. When you make initial contact with someone who you even suspect may have continued relevance to your work, get her name, office phone, cell phone and e-mail address, and store the info in your file under the people header. I guarantee that, when you need that info, it will be much easier to locate in that one place than having to search through a hundred Post-it notes.
Paraphernalia
This word is interchangeable with the word technology. It refers to all the concrete building blocks needed to ensure the continuity or recovery of your business, primarily computers and computer equipment. Paraphernalia also pertains to network equipment such as modems, routers, T1 phone lines, MUX devices or even a recovery facility. Once again, documents strictly relating to these building blocks should be kept together in a single location: network diagrams, system configuration specs, recovery site equipment lists, system or application recovery procedures, etc. If an auditor or senior manager suddenly requests such information, you dont want to find yourself chasing technicians and hoping they have properly maintained the documentation.
Paper
As you have no doubt observed, everything that falls under these three headings can be described as documentation. It all consists of information recorded on hard or soft copy (preferably both), yet people and paraphernalia pertain to specific kinds of information. The paper category would include everything that doesnt fit under the other two; for example, things like project plans, recovery test objectives and timelines, project scope statements, impact analyses, etc.
Simplify, Simplify, Simplify
The preceding has been a suggestion on how to organize information according to some fairly specific criteria, and its application will vary according to individual circumstances. Nonetheless, in light of the overwhelming volume of information that the continuity planner is expected to obtain, maintain and utilize, it is easier to juggle three balls than it is to juggle five, 10 or 100. And that is why I say, with Henry David Thoreau, that it behooves us, wherever possible, to simplify, simplify, simplify.
Prior to juggling (and delegating), the continuity planner must develop the skills of the ace reporter who knows which questions to ask and when. This is the phase that provides the continuity planner with something to juggle! Using a couple of the Ws of the ace reporter, allow me to unveil a mere tip of the business continuity iceberg, as it pertains to the planning of both technical and business recovery.
Why?
For many people, the first and most important question is why additional work has been heaped upon their plates, specifically, the work of business continuity planning and testing. People tend to be more accommodating if they know there are good reasons for what they have been asked to do. Being told by the boss that you must do something because its your job is not always the most inspiring motivator. If continuity planning is required by the shareholders of a publicly held entity or by the regulations of a Federal agency (as with financial institutions), this information should be shared with members of the planning and recovery team. Dont neglect to point out that continuity planning is in everybodys best interest since the stability and continuation of the business depends upon recoverability, which can only be measured and ensured through planning and regular testing. Point out, too, that a successful test is one that accurately measures the recoverability of the business. Failure to achieve specific objectives of a test does not indicate an unsuccessful test unless the reasons for non-achievement have not been identified and effectively addressed. Share all of the whys with your planning teams, then document them and file them under the paper category.
What?
In planning for recoverability, the first real what is typically identified by performing a business impact analysis (BIA). This is an in-depth study that qualifies and quantifies the impacts both tangible and intangible that any interruption to normal operations would have upon your business. The BIA identifies the companys most critical departments, systems and resources and provides essential data for determining the most cost-effective recovery strategies. The BIA also determines recovery time objectives for each critical system or function by showing the magnitude of impacts over time and delineating the maximum number of hours or days the company can tolerate without those systems or functions. With strong and ongoing management support, the BIA can serve as a solid foundation for all subsequent recovery objectives and activities. Without a BIA, efforts to differentiate what is critical from what is not can result in a lack of focus, a lack of commitment, departmental fighting or recovery plans based on erroneous assumptions.
Once you have identified the high-level what of recovery criticality, the next step is identifying the specific building blocks to be reassembled in the event of a disaster (yes, an interruption to normal operations is a disaster). This is where the path to recovery might be said to diverge along two parallel continuums: system recovery on one side and business continuity on the other. However, the two paths must be in constant communication with one another and must ultimately converge in a successful unity of common goals and activities.
In the recovery planning industry, the term disaster recovery signifies technical recovery or recovery of computing resources, while the term business continuity refers to business units and the specific processes and procedures upon which they depend. While technical personnel must create plans and procedures for recovering critical computing resources, business personnel must create continuity plans that ensure the continuation of business processes. Since these two groups are interdependent, they must work together to share information that ensures their plans are effectively integrated to the extent that their mutual needs and dependencies which constitute the companys life-support system as determined by the BIA are assured.
The building blocks for system recovery consist of all the technical components needed for restoration of the critical systems named in the BIA. In addition, an alternate site (for recovery) must be determined, recovery procedures written and appropriate data back-up strategies implemented. And this is merely the tip of a very large and detailed iceberg. For business recovery, the building blocks might include workstations, computer programs, fax machines, telephones, calculators, desks, an alternate work area, manual business procedures and cross-training strategies. This, too, hints at an imposing iceberg, and ignoring it can cause the business to sink.
Ideally, the efforts of technical personnel are led and coordinated by a disaster recovery planner, while on the business side, the work is driven by a business continuity planner. If your company is shrewd enough to employ two such individuals, they will necessarily work closely together to coordinate the efforts of technical and business personnel, to establish effective recovery plans and regular testing schedules and, thereby, to ensure the companys survivability in the event of an interruption to business as usual. In managing the building blocks relating to technical components, planners may find it convenient to organize this information under the heading of paraphernalia.
How?
The final ace reporter question Ill address, though not a W, represents the daunting prospect of how to go about the recovery and continuity planning process. Obviously, the planning process will entail a myriad of meetings. This will require documents such as meeting agendas and minutes, project scope statements and plans, objectives, milestones, timelines and more. It can be difficult to manage a project without a project plan. Likewise, a statement of the project scope brings focus and manages expectations related to the project. A list of detailed and carefully worded objectives provides a target to shoot for, and a schedule of milestones with deadline dates clarifies key tasks and events needed to achieve the objectives. A timeline used in performing tests and exercises is a critical tool for estimating and evaluating task durations and interdependencies. Planners can reach valid conclusions and provide accurate reports to management by measuring how closely testing efforts have met the stated objectives and timeline estimates. Whether planning technical recovery or business continuity, such tools and techniques can bring order to a dauntingly complex process. This collection of critical planning documents can be filed under the heading of paper.
Continuity planners and the teams and individuals with whom they work have an awesome responsibility to the company. It is their job to expect the unexpected and to plan accordingly. An interruption to business may be a calamity, but the failure to plan for business continuity is a true disaster.
Doug Sievers is the contingency planning manager for The Pillsbury Co., a division of General Mills, Inc. For more infor-mation, he can be reached by phone at 612-330-8524 or by e-mail at dsievers@pillsbury.com or mewmew2@msn.com.
