Manage the Recovery Planning Project Part 1 & 2
David A. Johnson, CBCP, FBCI
All too often, Recovery Planning projects begin with great expectations but end in disillusionment. Cost overruns, missed deadlines, staffing problems, and a plan that is outdated even before the ink is dry, are just a few of the pitfalls that can plague the unwary Recovery Planner. For the benefit of those responsible for managing Recovery Planning projects, this article will first review the various obstacles that may be encountered during a typical project, and then review how the Recovery Planner can overcome these obstacles, and ensure that the project meets expectations.
It should be emphasized, however, that this article is not about Recovery Planning; it is about project management. While the information will be presented within a Recovery Planning context, the problems and solutions to be discussed are not unique to Recovery Planners. Anyone responsible for managing a complex, multidisciplinary project, regardless of its purpose, may face the same problems, and can employ the same solutions.
The fundamental goal of project management is to ensure that the expectations of management and the projectís sponsors are met. These expectations are usually quite straightforward. In the case of a Recovery Planning project, management and sponsors will undoubtedly expect three things: they will expect the plan to be completed; they will expect it to be completed on time and within budget; and they will expect it to be workable.
Consequences of Failure
These expectations are perfectly reasonable, and should come as no surprise to the Recovery Planner. It should also be no surprise that failing to meet these expectations can have adverse consequences. First, if a workable plan is not completed, the exposure that was to have been addressed by the plan will remain. Second, if a workable plan is not completed on time and within budget, the Recovery Planner may find it considerably more difficult to gain support for subsequent projects. Last, failing to meet expectations may result in a significant setback, if not an abrupt end, to the Recovery Plannerís career.
Why, then, do so many Recovery Planning projects fail to meet expectations? If the Recovery Planners know what is expected of them, and the possible consequences of failure, why do they allow their projects to fall short of expectations? The pat answer is "circumstances beyond their control".
Obstacles to Success
There are indeed many obstacles to a successful project which may seem to be beyond the control of the Recovery Planner. If the Planner simply accepts that he or she is powerless to overcome these obstacles, failure is inevitable. For the benefit of those who choose to take this fatalistic view, the ten most common obstacles to a successful Recovery Planning project are listed below, along with the corresponding excuses that can be used for failing to meet expectations.
1. Too Broad a Scope: "The scope of the project was simply too broad. There was no way it could be kept under control."
2. Ambiguous Objectives: "The objectives of the project were too vague. Nobody could agree on exactly what we were supposed to accomplish."
3. No Real Commitment: "Management wasnít really committed to the project. They were just paying it lip service."
4. Budgetary Constraints: "The budget was too tight. We couldnít get adequate funding or resources to achieve our objectives."
5. Unrealistic Target Dates: "The target dates for the project were completely unrealistic. There was no way the schedule could be met."
6. Lack of Accountability: "No one involved in the project was accountable for meeting target dates. Falling behind schedule was inevitable."
7. Poor Communication: "Communication between project members was terrible. Everyone seemed to be working at cross purposes."
8. Lack of Technical Expertise: "The project required technical expertise in so many different disciplines. The project members were simply out of their depth."
9. Inadequate Testing: "We werenít able to do enough testing to prove the plan would actually work. We just had to keep our fingers crossed."
10. Poor Maintenance: "It was impossible to keep the plan up to date. The environment kept on changing too quickly."
The Fatalistic Approach
It is unlikely that a given Recovery Planning project will encounter all of the above obstacles. However, it is equally unlikely that a given project will encounter none of them. The fatalistic Recovery Planner, therefore, should be prepared to offer the appropriate excuse or excuses to management and the project sponsors when it becomes evident that expectations have not been met. If the Recovery Planner is convincing enough, he or she may get a second chance. However, the Recovery Planner that is prepared to accept failure once is a Recovery Planner that is destined to fail again.
There is no substitute for success. Failing to meet expectations, no matter how well rationalized, is not an acceptable course of action for anyone wishing to pursue a career in Recovery Planning. The fatalistic approach is, indeed, fatal. The Recovery Planner, therefore, must not accept any of the above obstacles as being beyond his or her control.
Five Key Principles
Barring acts of God or deliberate sabotage, no obstacles to a successful project are insurmountable. By following five key principles of project management, the Recovery Planner can, in fact, avoid all of the obstacles listed below, and never have to resort to making excuses.
The five principles are:
1. Manage Scope and Objectives: Never allow a project to become unmanageable due to a scope that is too broad, or objectives that are ambiguous.
2. Manage Commitment and Budgets: Never allow a projectís objectives to be compromised by lack of commitment or inadequate funding.
3. Manage Target Dates and Accountability: Never allow a project to fall behind schedule due to unrealistic target dates, or lack of accountability for meeting target dates.
4. Manage Communication and Technical Expertise: Never allow a project to get off course due to poor communication among project members, or lack of well rounded technical expertise.
5. Manage Testing and Maintenance: Never allow a project to produce a plan that may not work due to inadequate testing or poor maintenance.
The key word in each of the above principles is "manage". This is an active verb, and effective project management requires action: action initiated by the project manager to avoid pitfalls and overcome obstacles. The specific actions that can, and should, be taken to ensure a successful Recovery Planning project are described in the following sections.
Principle #1: Manage Scope & Objectives
A project with too broad a scope, or ambiguous objectives, will be out of control even before it begins. The Recovery Planner can prevent this from happening by taking the following actions.
a) Limit Initial Scope: Donít take on a project to develop recovery plans for the entire corporation at once. Start with one area of the company, and make that project a success before moving on to the next area.
b) Document Limitations and Assumptions: Ensure that there is no confusion or disagreement about what will, or will not, be included within the projectís scope. If, for example, the project will be addressing recovery of data communications, but not voice communications, document this as a limitation which will be addressed in a subsequent project.
c) Break the Project into Phases: Even with a limited scope, a Recovery Planning project can be a large undertaking. To keep it manageable, the project should be broken down into discrete phases, such as risk assessment, impact analysis, strategy selection, plan development, implementation and testing, etc.
d) Define Explicit Deliverables: Before beginning each phase of the project, be sure that the anticipated deliverables of that phase are defined explicitly. In other works, make it absolutely clear to management, sponsors, and participants what the end product of each phase will be, to avoid any misunderstandings during the course of the project.
e) Donít Allow Unapproved Deviations: Once the project has started, there may be pressure to modify the scope or objectives. This should be resisted if at all possible. If not possible, ensure that the deviations are explicitly approved by management, and that any implications to the project schedule or resourcing requirements are understood and accepted.
Manage Commitment & Budgets
A project with no real management commitment, or an inadequate budget, will be compromised from the start. If the project ever gets off the ground, it is unlikely to be completed, or to produce a viable recovery plan. The following actions can ensure this doesnít happen.
a) Request a Policy Statement: Before starting the project, ask senior management to issue, or endorse, a policy directive, stating their commitment to recovery planning in general, and this project in particular. If they agree to this request, the project will have gained a great deal of credibility. If they wonít agree, you will at least have been forewarned that senior managementís support for the project is lukewarm at best, and that you should proceed cautiously.
b) Present the Business Case to Sponsors: As important as senior managementís commitment is, it is even more important to have the full support of the projectís sponsors. These are the individuals in middle management or front line supervision whose support, or lack thereof, can make or break the project. Identify these sponsors and get them on board early by presenting a solid business case for the project, in terms they can relate to.
c) Obtain Formal Project Approval: Insist upon formal approval for the project. Prepare a written project proposal, including estimated costs and staffing requirements, and request that it be signed by management of all affected areas. Do not rely upon verbal approval alone (as the saying goes, "a verbal contract ainít worth the paper itís written on").
d) Issue Recommendations After Each Phase: Breaking a project into phases, in addition to helping keep the project manageable, provides an opportunity to gain management commitment incrementally. After completing one phase, recommendations can be issued on how to proceed with the next phase. Since the ability to produce results will already have been demonstrated, management should be predisposed to endorse the recommendations. As each phase builds upon another, managementís comfort level in making project commitments will increase.
e) Work Within the Budget Cycle: Budgetary constraints can stop a project dead in its tracks. No matter how convincing the business case, the required expenditures may not be approved if there is no allocation of funds for the project in the relevant department budgets. It is paramount, therefore, that the Recovery Planner lobby the various departments, during the annual budgeting process, to include appropriate funding for Recovery Planning in the upcoming yearís budget.
Manage Target Dates & Accountability
Recovery Planning projects are often viewed as having a relatively low priority. In competing with other projects for scarce resources, it is all too easy for target dates to be missed, and for participants to resist accountability for completing their activities on time. This can doom a Recovery Planning project to failure, and must be avoided at all costs. Following are some of the tactics which can be employed to ensure that the project remains on schedule.
a) Develop a Critical Path: Each phase of the project will consist of many key activities, all requiring varying amounts of time to complete. Some activities can be scheduled concurrently; others can only be scheduled consecutively. By mapping out the interdependencies of these activities, a Ďcritical pathí can be developed which identifies those activities which must be completed on time in order to remain on schedule. While all activities are ultimately critical, those on the critical path are the ones which will require the closest attention by the Recovery Planner.
b) Break Activities into Measurable Tasks: To complete each key activity, specific tasks will need to be assigned to individual members of the project team. These tasks should be explicit, unambiguous, and measurable. In other words, it must be possible for the project leader to Ďmeasureí successful completion through some verifiable end product of the task. Never assume a task has been completed successfully simply because it is reported as complete.
c) Get Agreement on Target Dates: When assigning tasks to team members, it is unwise to simply state "I need this task completed by such-and-such a date." Without any input to the scheduling process, the team member may not accept accountability for meeting the target. Instead, ask "How soon can you complete this task?" Negotiate if necessary, but be sure to get agreement, and to hold the team member accountable for meeting the agreed-upon date.
d) Conduct Regular Status Meetings: Frequent meetings of the entire project team may seem counterproductive. However, holding team meetings every two to three weeks to review the status of the various tasks and activities is the most effective way of ensuring that the project remains on schedule. Firstly, the meetings will provide an opportunity to identify and resolve problems, and, secondly, they will help keep the pressure on team members to meet target dates. This pressure can be reinforced by issuing minutes of the status meetings to team membersí management or supervision.
e) Resolve Delays Immediately: Typically, projects fall behind schedule in small increments: a week here, a week there. Suddenly, the project is months behind schedule. Always make every effort to resolve delays as soon as possible. This is particularly important during the early stages of the project, when the perceived urgency is less. It is important to remember, however, that a week lost at the beginning of a project is the same length as a week lost at the end of a project.
Manage Communication & Technical Expertise
On a typical Recovery Planning project, team members will come from a variety of different disciplines, and will have their own areas of specialized expertise. This diversity of backgrounds can cause communication problems within the team, and present difficulties in channelling everyoneís efforts in the same direction. If communication and technical expertise are not managed effectively, team members may begin working at cross purposes, and the project can get dangerously off track. To avoid this happening, the following strategies can be employed.
a) Do Your Homework: A project manager does not need to be an expert in any particular discipline (other than project management, of course). However, he or she must have a working knowledge in all the disciplines involved in the project, in order to communicate effectively with each of the team members, and to direct their individual efforts. There is no magic solution to this requirement: it is simply a matter of doing your homework. Each of the disciplines must be researched and studied in sufficient detail to attain a level of comfort in your dealings with each of the team members.
b) Facilitate "Structured Brainstorming": During the project, there will likely be the need to hold frequent brainstorming sessions with team members, to work out strategies, solutions to technical problems, etc. Given the diversity of expertise on the project, it is essential that the Recovery Planner facilitate these sessions in a structured fashion to ensure everyoneís participation, and their understanding of the relevant technical concepts. Donít allow individual members to take off on abstruse technical tangents that no one else can follow. Make them slow down and express their ideas in laymenís terms so that everyone can participate in the discussions.
c) Translate "Technobabble" into English: It may seem, at times, as if everyone on the team is speaking a different language. Each discipline has its own peculiar idiom, and uses jargon which may be meaningless to the uninitiated. The Recovery Planner must be able to recognize when a team member is spouting "technobabble", and ensure that it is translated into the common language of the team (presumably English). This translation process can serve, not only to improve understanding, but to help ensure the validity of the suggestions or arguments being presented.
d) Issue Work Orders for Technical Tasks: Some technical people, when presented with a specific task, become absorbed in the fine details and lose sight of the original goal. As a result, a considerable amount of time may be spent on irrelevant, or even counterproductive, activities. It may be advisable, therefore, to issue written "work orders" for technical assignments, explicitly stating the objectives and parameters of the assignment. This approach is analogous to issuing a work order to a car mechanic, rather than giving him or her licence to tinker under the hood indiscriminately.
e) Insist Upon Written Documentation: No technical assignment should be considered complete until the results of that assignment have been documented in writing. While many technical people seem to abhor documentation, this requirement must be insisted upon for several reasons. Firstly, it enables the Recovery Planner to verify successful completion of the task. Secondly, it makes it easier to communicate the results to the other team members. Thirdly, and perhaps most importantly, it ensures that the assignment has been thought through in sufficient detail to withstand scrutiny.
MANAGE TESTING AND
Effective project management can ensure that a Recovery Plan is completed on time and within budget. But will it work if and when it is needed? This can only be assured if it is tested and exercised on a regular basis, and if it is kept up to date. Unfortunately, many Recovery Planners find that ensuring their plans are tested and maintained adequately is like fighting a losing battle. To avoid losing this battle, the following actions should be taken.
a) Identify Infrastructure Requirements Up Front: On-going testing and maintenance typically requires changes and additions to the organizational infrastructure. Staff may have to assume new duties, departmental procedures may have to be modified, support systems may have to be developed, and so on. None of these can be expected to happen on their own after the project is complete. The infrastructure requirements must be clearly identified, and explicitly approved, during the early stages of the project, and must be implemented before the project is considered complete, not after.
b) Publish a Formal Testing Plan Annually: Testing of a Recovery Plan does not end with the first successful test. The plan must continue to be tested, or exercised, on a regular basis to validate any changes or enhancements to the plan, and to ensure that recovery personnel remain proficient in their assigned roles. The Recovery Planner should develop a detailed testing plan on an annual basis, outlining the testing schedule, the types of tests to be conducted, the testing objectives, and the areas of the organization that will need to participate in the testing. The Recovery Planner must then obtain formal approval for the testing plan from all of the affected areas.
c) Present Test Results in a Real Life Context: The results of every test should be documented and distributed, not only to the participants, but to each area of the organization that would be impacted in a real disaster. The primary goal of distributing the results is to maintain awareness, particularly awareness of the need for continued testing. This can be facilitated by presenting the results within the context of specific disaster scenarios. The closer that testing approximates real life, the greater the likelihood that the significance of the testing process will be fully appreciated.
d) Institute Regular Plan Audits: Each component of the recovery plan should be audited regularly to ensure it remains current. These audits should be scheduled semi-annually, or whenever there are significant organizational or technological changes. While guidance may be provided by the Recovery Planner or the Internal Audit department, the audits should be performed by those departments that would be directly involved in an actual recovery effort. In addition to identifying any updates that must be made to the plan, regular audits will ensure that the various areas of the organization maintain their familiarity with the detailed recovery procedures.
e) Integrate Recovery Planning into the Change Management Process: While regular plan audits are essential, a plan that is only updated every six months may be six months out of date when a disaster strikes. Every effort must be made to ensure the plan is updated immediately when organizational or technological changes occur, even minor ones. Given the rate of change in most organizations, this can be a challenging proposition to say the least. It can only be accomplished by ensuring that Recovery Planning is fully integrated into the various processes used to manage changes within the organization. The Recovery Planner must continually insist that no change be initiated without assessing the possible implications to the recovery plan, and that no change be considered complete until the plan has been updated accordingly.
Successful management of a Recovery Planning project, like any other complex, multidisciplinary project, is not an easy undertaking. Unexpected complications are inevitable, and the Recovery Planner must react quickly and decisively. However, the critical success factor is the Plannerís ability to be proactive, in anticipating potential obstacles and taking appropriate preventive or corrective actions. By following the five key principles of project management described in this article, the Recovery Planner may not manage to avoid the unexpected, but should always be able to manage to meet expectations.
David A. Johnson, CBCP, FBCI, is a director of the Canadian Centre for Emergency Preparedness, an executive member of the Disaster Recovery Information Exchange, and a member of the Journalís Editorial Advisory Board.
DR World Main Index | Return to DRJ's Homepage
Disaster Recovery World© 1999, and Disaster Recovery Journal©
1999, are copyrighted by Systems Support, Inc. All rights reserved. Reproduction in whole or
part is prohibited without the express written permission form Systems Support, Inc.