The Project Disaster Recovery Plan

From my experience, it’s not often that you’ll put together a Disaster Recovery Plan that is project-specific. The exceptions are government projects – which sometimes require separate one-time documents for the project for which you charge dearly to put them together – and larger, very visible and mission critical projects that may involve highly sensitive data.

However, if you find yourself up against a wall and facing a deadling to put a DRP together, maybe this template will be just what you need. As with all the others I’ve posted over the past few days, if you want a Word doc version of this template, let me know and I’ll be happy to send it out to you. And, if you have your own version that you’d like to see posted and share with the readers here on PM Tips, send it along to me and I’ll see that it gets posted.

Disaster Recovery Plan

1.0 Preliminary Planning

This part of the plan describes the purpose, scope, assumptions, responsibilities, and overall strategy relative to the plan.

1.1 Purpose

Describe the reason and objectives for having a DRP.

1.2 Scope

Describe the extent of the coverage of the plan in concise terms.

1.3 Assumptions

A DRP is based on several categories of assumptions. Most can be established only after the completion of a risk assessment that includes the following information:

• Nature of the problem
• Priorities
• Commitments to or Assumptions of Support

1.4 Responsibilities

Document the specific responsibilities as assigned by management to all activities and personnel associated with the plan.

1.5 Strategy

The selection of appropriate strategies should follow the risk assessment. Until the risk assessment is completed, it is difficult to know the critical systems that must be maintained, and the demand for resources that will be made to support those critical systems.

1.5.1 Emergency Response

The strategies selected must provide a sufficient base upon which procedures can be devised which afford all personnel the immediate capability to effectively respond to emergency situations where life and property have been, or may be, threatened or harmed.

1.5.2 Backup Operations

Most backup sites will not have sufficient equipment, personnel, supplies, etc., to sustain the complete operational requirements or another facility. In this case, a more detailed backup strategy must be developed.

1.5.3 Post-Disaster Recovery Actions

The strategy for recovery must be linked closely with that of backup operations, as initiation of recovery actions may overlap.

1.6 Record of Changes

Each DRP should be preceded by a change audit record that lists all changes to this document, including the change number, change date, change detail, person making the change, and the date that the document is published.

1.7 Security of the Plan

This plan should be available to just those personnel affected by the plan.

2.0 Preparatory Actions

This part of the plan is key. Preparatory actions are critical to the emergency response, backup, and recovery from all but the most routine problems.

2.1 People

Provide names, addresses, and telephone numbers of all people, internal and external (vendors and/or contractors) who may be required in any backup or recovery scenario. Alternates should be designated.

2.2 Data

It is essential that all data on which backup and recovery are dependent be adequately recorded, stored offsite at a secure, environmentally safe facility, maintained in as current condition as is feasible, and occasionally tested to ensure validity.

2.3 Software

It is also essential that a current copy of the systems and application software programs be stored offsite at a secure, environmentally safe facility that will make that software available immediately.

2.4 Hardware

A DRP should minimize, to the greatest feasible extent, the dependence on rapid replacement of hardware. Define a list of the hardware and where replacements are available. Identify any contracts in place to ensure the availability of any hardware.

2.5 Communications

Define both the internal (LAN) and external (WAN) communications connectivity.

2.6 Supplies

Describe any special supplies that are needed.

2.7 Backup Site

Describe the location of the backup facility. When choosing a backup site, consideration should be given to accessibility, and the site should be free of whatever external problems are hampering the supported facility.

2.8 Space

Describe the physical location where the recovery operations will take place.

2.9 Power and Environmental Controls

Define the power and environmental controls that are required for the recovery.

2.10 Documentation

Describe all backup documentation that is kept in the offsite facility.

3.0 Action Plan

This part of the plan consists of the “what to” actions to be accomplished by those personnel or activities identified in section 1.4, and should only consist of concise, short instructions of the specific actions to take in response to each of the categories below:

3.1 Emergency Response

Include the immediate actions to be taken to protect life and property, and to minimize the impact of the emergency.

3.2 Backup Operations

Describe what must be done to initiate and effect backup operations.

3.3 Recovery Actions

These should be limited to describing what to do in effecting recovery from disasters, including any alternate manual scenarios until the systems have been restored at the backup site.

4.0 Post-Disaster Review

Immediately after the resumption of the IT function, IT management should assess the success and adequacy of the plan, and update the plan accordingly.

Approved:

__________________________________________

Business Sponsor

__________________________________________

IT Director

__________________________________________

Development Director

__________________________________________

Infrastructure Director

A Lessons Learned Template

Lessons Learned – often talked about, a discussion that is usually planned…but often forgotten.  You’re at the end of the project and the plan is to pull both teams together to go over lessons learned in great detail and for the benefit of all – but it often doesn’t happen.  Team members move on to other projects or post-deployment issues are taking up everyone’s time.

Lessons Learned sessions can be very helpful – and if you’re luck enough to keep yours on the project schedule, then this template may help you.  It looks a little rough pasted into this post and one of the tables turned into a bullet list, but I think you’ll get the idea.

As always, if you want the Word doc template, let me know…and please feel free to share your version as well.

PROJECT LESSONS-LEARNED DOCUMENT

The purpose of this template is to help the project team share knowledge gained from experience so that the entire organization may benefit. A successful Lessons-Learned program will help project teams:

• Repeat desirable outcomes
• Avoid undesirable outcomes.

A. Your project team should begin to use this document at its first project meeting. Continually recording Lessons-Learned throughout the project is the best way to ensure that they are accurately recorded. Topics to consider include all of the following (feel free to change the list). The Lessons Learned Checklist is also available as a guide to discussion.

B. At the end of your project, use this document to summarize your experience.

During your discussions:

• Be positive
• Do not place blame!
• Focus on successes as well as failures
• Indicate which strategies contributed to success
• Indicate which improvement strategies would have the greatest impact

The signatures above indicate an understanding of the purpose and content of this document by those signing it. By signing this document, they agree to this as the formal Project Lessons-Learned Document.

Strategies for Managing a Mobile Team

I ran across a great document put together by Terrence Gargiulo for Makingstories.net. Mr. Gargiulo discusses what he feels are the top ten strategies for managing mobile workers. His full document is a very good read because he also discusses things such as risks and issues to consider when managing mobile workers.  You can access his full document here.

I’m sharing this here because so many times as project managers we are overseeing the work of a very geographically dispersed team. In the past three years I’ve only managed one project with a team that I could see on a daily basis. Dozens of others involved remote workers all around the country.

Here are Mr. Gargiulo’s Top 10 Strategies for Managers of Mobile Workers as described in his document.

Top 10 Strategies for Managers of Mobile Workers

1.    Focus on building relationships

You are now in the business of managing relationships. Once a quarter audit your time. How much time are you spending engaged in activities meant to foster stronger relationships with your mobile employees? Rate each relationship on a scale of 1 to 10 where 1 is weak and 10 is very strong. Craft a strategy for continuing to develop your strong ones and triage the weak ones. Ask yourself why they are weak and what you can learn from them. Avoid finger pointing and hold up the mirror to reflect on your own opportunities for improvement. Extreme cases of under-performance do not warrant time or effort. These however are few and far between.

2.    Streamline communications

Consolidate and prioritize communications. Use email and IM (instant message), texting, blogging, threaded discussions, etc. for relationship-driven communications (i.e., staying in touch and being personal). Communications of an important nature should be cohesive and never delivered in fragmentary pieces that have to be cobbled together by the receiver. Mutually assess the communication preferences of yourself and your team members to develop a communication plan. Avoid assumptions and revisit your plan on a regularly basis especially when the nature of the work is about to change.

3.    Incorporate less didatic forms of communications

Determining the right amount of detail and when to provide detail is an ongoing responsibility of a manager with a mobile worker. As a general rule, less is more. This leaves bandwidth for the times when lengthy, explicit instructions and information are essential for the work at hand. Try working with more story-based forms of communications. Sharing tidbits from the field and office in the form of stories, anecdotes, case studies (use cases), jokes, innocent productive gossip, and even metaphors will relay context, encode key pieces of information, and give mobile workers a sense of inclusion.

4.    Spend more time listening

Obvious, but counterintuitive. When you are out of easy reach and you are tasked with managing the performance of others it’s easy to get sucked into the trap of needing to transmit lots of information. In most cases the opposite is what is most productive. Make listening a priority. This is the hardest and most tiring aspect of managing others. It is also the single most important thing you can do accelerate the development of strong relationships. Listening is not enough. Keep an open mind. Be present and try to enter the perspective of the speaker. This will help you ask effective questions and identify what direction to go with your own needs and agenda. You’ll be surprised at what emerges.

5.    Let mobile workers define communication and reporting practices they want to follow

Structure is critical. Adopt rules of engagement that place people at the center of their own decisions. Managers provide the boundaries and constraints but let employees define the working and communication styles, tools, and processes that will help them perform at the best. Set expectations on two fronts. First, treat these employees’ defined practices as privileges that can and will be modified if key performance metrics are not hit. Second, let employees know there will be times when a projects or work require less flexible, employee-driven communication and reporting practices.

6.    Manage deliverables, not activities

Lots of project-oriented work is well suited to mobile workers. Even roles that are more task driven can be effectively managed if they are broken into deliverables. For mobile workers this may mean collapsing some of the activities of a business process or workflow that had manual checkpoints and controls associated with them into deliverables. Automation where possible can be used or batching activities into larger groups can transform task oriented jobs into deliverables. Realize that there can be many facets of people’s jobs that need to be adjusted to accommodate a mobile work style.

7.    Engage in more frequent and informal performance management activities

When you manage mobile workers, relationships are at the heart of your job. Performance management does not need to be a loathsome, “administrivia” obligation. Designing some unstructured, informal ongoing dialogs with mobile employees about their performance goals and personal development plans is a great way to strengthen communications, and shows an active interest in employees and relationships. This might look and feel very different from one employee to the next. This is another tangible way managers can adapt their style to match the needs and preferences of employees. It works best when the performance management conversation flows in both directions.

8.    Give complete trust until given a concrete behavioral reason to do otherwise

According to a recent survey conduct by HR.com and ic4p, listening and trust are the two most important factors to virtual and remote teams. Without trust, relationships are bankrupt. Abuses of trust can always be found but these occur in spite of whatever systems we put in place. Mobile workers thrive when managers give them complete trust. In some respects managers of mobile workers have no other choice. Use trust to create strong relationships. When some concrete behavior and not just someone else’s word of mouth shows that trust has been violated, then take it away, but not until then.

9.    Use adaptive management styles tailored to individual workers

Every employee is different. Mobile workers make it easier for managers to take a more personalized approach in how they work and interact with members of their team. It takes more work and effort on a manager’s part but the results can be phenomenal. Understanding what enables each employee to perform at his or her best is the most important responsibility of a manager.

10. Leverage technology

Technology drives and supports managing mobile workers. Using technology well is not as simple as it appears. Standard models of communication and transaction should not always be mapped in a simple one-to-one way. Communication and collaboration technologies offer new and exciting models. These need to be purposely exploited in order for organizations to realize the full extent of benefits these wonderful new capabilities and features offer.

Beyond email, IM and phone, Web conferencing plays a key role in virtual team enablement. Take an inventory of “stuff” you need to collaborate on with your virtual team. If the list includes Word docs, spreadsheets, software applications, or anything else on your desktop, Web conferencing will be critical for collaborating in real time. You’re projects will lag if you can’t be on the same page with mobile workers.

Risk Management Planning

I’ve offered – and provided already to many requestors – my template for a Risk Management Plan. It’s not groundbreaking or even earth-shattering, but there are just some key concepts to include and critical areas to ensure are covered. It’s not absolutely necessary to even have a formalized plan, unless you’re working on a critical government project and it’s required or you’re working with a project staff or customer that is missing the point of managing risk…then it may be necessary to formalize it for them.

I recently ran across another outline for a risk management plan and I am sharing it below. If you want my copy/template as well, just send me a note and I’ll email it to you – mine comes as a prepared document and you can just insert your info.

Risk Management Plan

Purpose

The risk management plan lays down the groundwork for how risk management will be carried out in a project. It serves as guidance for the risk process, its thresholds, and its formats, defining the roles and responsibilities of stakeholders in risk management. It is notable that the risk management plan is not a listing of specific risks and is not used to establish the particular strategies for risks, once they are identified.

Application

The risk management plan is shared with project stakeholders to clarify their roles and responsibilities in the risk management process and to identify when specific potential risks are truly of concern to the organization. It also outlines the risk budgeting process, detailing how and when risk contingency funds may be allocated and applied.

Content

The risk management plan consists of basic information about how risk management will be conducted during the project. It does not address specific behaviors associated with specific risks, but instead forms a framework for the rest of the risk management process.

1.0 Risk Process

Risk process may be as simple as two steps (e.g., assessment and response) or as complex as six or seven steps (e.g., planning, identification, qualification, quantification, response development, and response control). The process steps should include clarification on how each of the processes will be carried out and the level of depth of information to be provided for each.

2.0 Risk Responsibilities

Just as the buyer and seller in project environments have different responsibilities for deliverables, so do they have different responsibilities for risks. Those responsibilities should be outlined here. Responsibilities may include information on who will identify risks, as well as who should evaluate them and develop strategies for those that are of the greatest significance.

3.0 Risk Thresholds

Thresholds represent personal and organizational tolerance for risk. They are the definitions of tolerance in terms of budget, schedule, requirements, and other sensitive cultural issues (e.g., politics, media exposure). They are normally expressed as ceilings beyond which the project should not proceed, or as notification points for upper echelons of management.

4.0 Risk Finances

This element of the risk management plan may address both funds set aside for risks within the project (contingency reserve) and funds set aside within management control for risks outside the project’s purview (management reserve). In both cases, this component of the plan details how and when the project team may draw down funds from those reserve accounts. Risk finances may also provide detail on how the amounts for the reserve accounts will be established.

5.0 Risk Evaluation

Because evaluation protocols vary from project to project, the risk management plan should include some detail on how risks will be scored and termed. Particularly for risk qualification, there should be some definition of terms for both the probability of a risk’s occurrence and for the impact should it come to pass. Many projects employ the high–medium—low (H-M-L) scheme for both impact and probability. The risk management plan should define each of those terms.

6.0 Process Timing

High-risk projects may require frequent risk reevaluation. Projects with lower risk may not require such frequency. The risk management plan should include detail on the frequency of risk identification, assessment, and response development, as well as the appropriate application of any tracking processes or documentation.

Defining Risk Management – Part 9: Risk Control

This is the ninth and final installment in the Defining Risk Management series. In this final segment, we look at what risk control is and how we monitor and track the risks that are identified and new ones that are encountered on our projects. This information is again, for the most part, derived from the book “The Project Management Question and Answer Book.”

What is Risk Control?

The process of monitoring and controlling and keeping track of the identified and the unidentified risks is risk control. In this process we hope to identify risks that are no longer possible and risks that are coming due, as well as any new risks that may become evident. We will also monitor risk activity to make sure the risk plans have been carried out successfully. Problems that have been found out in the risk plan can help us adjust the plans for future risk activities.

Risk control and monitoring are part of the risk management process and must be started early in the project and continued until the end. As the project progresses, we will find that many of the risks will change, some will no longer be possible, others will happen and be disposed of, and new risks will be identified. In addition we will learn about the project and the risks associated with it and adjust our vision of individual risks.

The level of risk tolerance should be monitored as well. The attitude of the stakeholders will change during the course of the project. Communication with all stakeholders is important since it gives us a means of assessing changes in their risk tolerance.

Risk control may involve changing the way we look at risk. There are several reasons why this might take place. The risk tolerance of the stakeholders may change; the risk tolerance of the project team may change. As the project progresses toward its completion, certain risks that were thought to be very important to the success of the project may become risks that are no longer thought of as being so important.

In the beginning of the space shuttle project, the heat-resistant ceramic tiles were originally thought of as being one of the major risks in the program. If the tiles were lost or their integrity was compromised, the heat of reentry, some 3,000 degrees Fahrenheit, could reach the airframe’s aluminum structure and cause breakup of the ship. As time went by and NASA flew over one hundred missions with the space shuttle vehicles and the whole take-off and landing process became routine, the perceived severity of the risk diminished. During this time there were minor failures of the reentry tiles, but these failures proved to be minor repairs, and the shuttle vehicles suffered only minor damage. A program to develop a method of repairing risks in space was discontinued because it was deemed impractical. Part of the impracticality was probably because of the perceived reduction in the probability and impact of heat shield failures.

On February 1, 2003, just three days after the anniversary of the crash of the space shuttle Challenger, Columbia, the oldest space shuttle in the fleet, disintegrated on approach to landing. At this writing the investigations have hardly begun, but the heat shielding tiles are once again suspect because there is little that can go wrong on reentry except for a heat shield failure.

We see that during the project, the evaluation of the risk of heat shield failure began as a high risk. As time went on, the risk was revalued lower and lower. After the crash, the valuation of the risk has no doubt been raised higher than its former level.

In all projects, as we gain knowledge and experience about the project and its risks, we will change our attitude toward the risks in the project. This is natural and important. As we learn, we must change the level of effort we spend in certain areas or we will never have the resources, time, or money to complete any project.

A control system for risk is influenced by the organization the project is being managed under as well. In a project that is high in risk, we might have a person who is at a high level and is exclusively responsible for managing risks. On projects that are relatively routine by comparison, the risk manager may be the person responsible for the tasks that are most affected by the occurrence of a risk. These persons are responsible for communicating risk progress to the project manager and other affected stakeholders.

Risk audits can be used to document the effectiveness of the risk plans and the strategies that were used to mitigate, avoid, or transfer risks. A judgment can be made as to whether it was cost-effective to ignore the risks that were ignored.

Deviations in the project performance may indicate the effect of risks on the project. The earned value reporting system is helpful in identifying trends in performance on the project. Generally, schedule slippage and cost overruns are the result of some problems that have occurred. Trends in certain areas may indicate that risks are more severe than was anticipated or that new risks have taken place. One important product of the earned value reporting system is the indication of the cost and completion date at the end of the project. The sooner these slips in schedule or budget overruns can be communicated to the stakeholders, the better it will be for the project. Schedule slides and budget overruns that are severe enough can result in project termination.

A workaround is an unplanned response to a risk that was previously unidentified. These are the unknown risks that were discussed at the beginning of this chapter. They are also the risks that were passively accepted since these were deemed to be risks that would be ignored. Workarounds are paid for from funds from the contingency reserve or the management reserve, depending on whether the risk was identified and accepted or whether it was unknown until it occurred. In any case, the funding for the workaround comes out of these accounts and is put into the operating budget of the project, and a new baseline is created.

Since contingency plans and workarounds are not part of the project baselines until they occur, they should be initiated and approved by the execution of an official change notification. Remember that changes to the baselines should require an official change notification as the vehicle for showing the change in funding, schedules, and scope resulting in a new and current baseline.