Managing Risk with Contingency Plans and Workarounds

Eleanor Roosevelt once said, "What you don't do can be a destructive force." This is especially true in terms of risks. Leaving risks to run their course without taking action can be very destructive to your project.

When a risk occurs, you must take corrective action to harness the risk and lead it down the least destructive path. In project risk monitoring and control, two of the most helpful forms of corrective action are contingency plans and workarounds.

Contingency plans
Contingency plans are management plans that identify alternative strategies project teams can use to ensure project success if specified risk events occur. They are developed before the risk occurs and are used if the original risk response is not effective. Contingency plans go beyond the original risk response to address "what if" scenarios that may further complicate risk control efforts. Risks that pose a significant threat to the project should have a contingency plan.

Contingency plans should contain information such as the plan's objective, criteria for implementation, roles and responsibilities, and the details for implementation.

Untouchable Tires is producing winter tires to stock its retail outlets. During this project, the company has encountered a major risk. The employees have gone on a strike that has lasted longer than the company had originally anticipated. The original response was to negotiate with the employees to get them back on the job as soon as possible.

To ensure that production deadlines are met and that retail orders can be filled, the company reassigned the work that would be done at this factory to other factories nearby. It will make production more expensive, but it will help meet the deadlines.

Workarounds
Another type of corrective action is a workaround. Workarounds are unplanned responses to emerging risks that weren't accepted or identified. Workarounds give you a way to "work around" the problem and as a result, reduce the effects that the risk has on the project. Workarounds should not be applied without documentation. Since using workarounds may have a positive or negative effect on the project, you need to incorporate them into the project plan and risk response plan.

Corrective action is any action taken to bring expected future project performance in line with the project plan. Implementing corrective actions such as contingency plans and workarounds will help your company keep its project performance in line with the project plan.

Primary Risk Response Planning Outputs

As a project manager, you will often face sudden or unexpected risks—risks that were not identified or prepared for during risk response planning. The best way to respond to these kinds of risks is to monitor and try to control them by examining the primary risk response planning outputs.

In addition to the risk response plan, there are four primary risk response planning outputs that you can use to ensure successful project completion: residual risks, secondary risks, contractual agreements, and contingency reserve amounts.

• residual risks
  The first output that will result from your project's risk response planning process is residual risks. These are the risks that remain after avoidance, transference, and mitigation responses have been implemented.
  
  Residual risks also include any minor risks that have been accepted and addressed during risk response planning through the addition of contingency amounts to the project budget or schedule.
  
  
• secondary risks
  The second output that will result from your project's risk response planning process is secondary risks. These are risks that arise as a direct result of implementing a risk response.
  
  Secondary types of risks should be identified as soon as possible so that appropriate and effective risk responses can be planned. For example, due to the complexity and detail involved in most projects, it is possible that adding personnel resources to address one identified risk may result in a risk of cost or schedule overruns in another project phase.
  
  
• contractual agreements
  Another risk response planning output that is useful in promoting project success is contractual agreements. These types of agreements help to ensure that all parties involved in a project's development are aware of their responsibilities and bound by law to fulfill all agreed-upon commitments.
  
  A contract is typically defined as a mutually binding agreement that obligates a seller to provide a specified product and requires a buyer to pay for it. As a result, contractual agreements are essential to risk management.
  
  Contractual agreements are also used to help specify each party's responsibility for specific risks. For example, a contract between an insurance provider and a company will detail the insurance provider's responsibility to pay out a certain amount of money to the company in the event that an insured risk occurs. Contractual agreements, as an output of risk response planning, will help you be confident that specific identified risks will be responded to in a timely and efficient manner.
  
  
• contingency reserve amounts
  The final output that results from your project's risk response planning process is contingency reserve amounts. These reserve amounts are over and above the estimated amount of time and resources allotted for a particular project. These additional resources are set aside to help reduce the risk of overruns to project objectives as a result of risk.
  
  Contingency reserve amounts will help you lower potential overruns to a level that is acceptable to your project stakeholders.
  
  Contingency reserve amounts are usually determined by the project manager with the aid of the project's established risk thresholds and probabilistic analyses. These analyses are used to forecast potential project schedule and cost results.
  

As a project manager, it is important to remember that almost every risk response will have a corresponding effect. Most risk responses involve expenditures of additional time, cost or resources and therefore require changes to the project plan. The results of the risk response planning process must be incorporated into the project plan to ensure that agreed actions are implemented and monitored as part of the ongoing project.

Other risk response planning outputs contribute to project success. You will want to use them to ensure that your project is protected from threatening project risks and prepared for the risk monitoring and control process.

Accepting Risks with a Contingency Plan

In addition to avoidance, transference, and mitigation, acceptance is also an important strategy for effective risk response planning. Acceptance is a strategy that indicates that a project manager and a project team have decided not to change the established project plan in order to deal with an identified risk. Acceptance may also be performed if a project manager is unable to identify any other suitable risk response strategy to effectively handle the identified risk.

If you choose to accept a project risk, you need to develop a contingency plan that can be implemented should the risk occur. Developing a contingency plan in advance can greatly reduce the cost of future risk responses.

Every contingency plan contains specific details that are only relevant to the identified risk and the project at hand. However, all contingency plans should contain the following components: the plan objective, implementation criteria, roles and responsibilities, resource requirements, operation procedures, and discontinuation criteria.

• The plan objective
  For a contingency plan to be effective, a project manager must first ensure that there is an established plan objective. This objective should clearly detail the risk of failure that prompted the creation of the contingency plan.
  
  A project manager must also decide what the desired outcome of implementing the plan will be: to continue normal operations, to continue operations in a degraded mode or to abort a project area as quickly and as safely as possible. The plan objective should also outline the potential impact, in terms of financial costs, on the organization.
  
  
• Implementation criteria
  In addition to establishing a plan objective, a project manager must ensure that an effective contingency plan contains well-defined implementation criteria.
  
  You and your project team must understand when your contingency plan should be implemented. In addition, this criteria outlines the specific failure, or risk trigger, that necessitates the start up of your project's contingency plan. For example, the contingency plan will be implemented in the event of a network failure.
  
  
• Roles and responsibilities
  The third essential component of an effective contingency plan is the designation of roles and responsibilities. A project manager must decide who will be responsible for making implementation decisions, such as implementing the contingency plan or informing the team that the project is operating in contingency mode.
  
  The roles and responsibilities component clearly outlines who is responsible for plan implementation. For example, the technical engineer on duty will be in charge of activating the contingency plan in case of a network failure.
  
  
• Resource requirements
  The resource requirements component details the equipment, supplies, funding, and overtime estimates needed to activate the planned response. To create a list of required resources, you need to ask yourself the following questions.
  
  • What equipment will be needed to implement the contingency plan? What equipment will be required once the plan is activated and in full operation?
  
  
  • What types of materials or supplies will be needed to implement and operate the contingency plan? What quantity of materials and supplies will be required?
    
    
  • How much should your contingency plan budget be in order to effectively fund the contingency mode operations?
    
    
  • How much overtime will employees be expected to undertake in order to keep the project on track during contingency mode?
  
  Having a list of resource requirements available before an emergency arises allows you to move quickly and easily into contingency mode to meet the plan objective.
  

• Operation procedures
  Operation procedures outline plan implementation instructions so that everyone will know what to do in an emergency. For example, in case of a network failure, Sarah will switch the network to backup mode in order to save important data.
  
  The procedures must also describe how project personnel will be informed that the plan is being implemented. Operation procedures should also define how records will be managed and data security ensured.
  

• Discontinuation criteria
  Discontinuation criteria describe how to determine when a project should move from contingency mode back to normal operating mode. This criteria will outline the conditions or events and the timing that make it possible to discontinue the contingency plan. For example, the network has to be fully tested and be 100 percent operational before returning to normal mode.
  

The development of an effective contingency plan, as part of acceptance, will help you create options and potential actions that will serve to reduce threats to critical project objectives and to promote project success.

Attributes of Effective Cost Estimates

Cost estimates, which are outputs of the project cost estimating process, are quantitative assessments that you, as a member of a project management team, make. You assess the likely costs of the resources required to complete project activities and then present them in summary or in detail.

Once you've estimated a total project cost, how can you determine if the estimate is good? You'll know its good if it includes the three attributes of an effective cost estimate. Good cost estimates should have the following three attributes.

1. They should include all the resources for a project.
To be accurate, an overall estimate must include all the resources that will be charged to a project. Study the project's work breakdown structure (WBS). The more resources you overlook, the less accurate your estimate will be.

To ensure you include all the resources for a project in your cost estimates, you may want to develop a checklist. This can help you ensure that all costs related to labor, materials, supplies, and special categories, such as inflation, are included in your estimates.

If you are unsure whether your finalized cost estimates truly reflect every resource that can and should be charged to your project, go back to the WBS and verify that the estimate is complete. As long as each work package for your project has been fully decomposed, you should be able to tell from the WBS if any resource has been omitted from the estimates.

2. They are expressed in the appropriate units.
Cost estimates are most typically expressed in a unit of currency, such as dollars, pounds, or yen. Use the currency that most simplifies estimating, measurement, and reporting. For example, use the currency of the country where costs are incurred or the home currency of the parent organization.

Expressing costs in a consistent unit of measure makes it easier to compare costs both within, and across, projects. Multinational corporations will find comparative analysis much easier if they convert costs into one currency.

Some types of estimates are commonly indicated in units of time. Labor costs, for example, are usually expressed in hours, days, or weeks. Your cost estimates may include two columns: one for total "work effort," or duration, and one for total costs in dollars. Reporting labor costs in units of time provides the following benefits.

• You still can produce estimates even if you do not yet know who will be making up the project team. All you need to know is how long tasks should take to perform.
• Using work effort to report cost estimates allows you to tie into the automated scheduling tool that has been used to estimate and report activity durations.

3. They should include an appropriate contingency.
Cost estimates should include contingencies, or allowances, to cover specific risks and expected inefficiencies or problems. They reduce the necessity of revising cost estimates later on when one or more of your figures are causing unacceptable cost variances.
You should make every effort to produce accurate cost estimates, but don't forget that a good project manager will plan for the risk of change occurring during a project. Adding contingencies to cost estimates is one way you can do this.

Most project management software applications contain cost estimating and budgeting functions that select appropriate contingencies for you. They are based on risk factors and statistical analysis of data from previous projects.

In summary, examine your cost estimates closely for accuracy before relying on them. They will form the basis of the budget, the cost baseline, procurement planning, and the entire cost control system for your project.

The Most Common Reasons for Change Requests

Change is inevitable. As a project manager, you will probably encounter many changes as you plan and execute your project. At least some of these changes will affect the project's scope, either increasing it or decreasing it. To better manage and control these kinds of changes, you should know what changes are most often requested.

A change request may be initiated internally or externally. It may be written or verbal, legally mandated or optional.

There are five common reasons for changing the scope of your project.

1. an external event - The first reason for a scope change request is an external event. These are factors outside of your control that impact the scope of the project. External events can be general or project-specific.
   
   A general event, such as a state-wide power failure due to a violent hurricane, does not directly relate to the project, but could force a change request.
   
   A project-specific event could be a change in local zoning regulations that require immediate changes to the project. While this is out of your control, it affects the project.
   
   
2. a "product" scope error - The second reason for a scope change request is a product scope error. This includes any omissions, inaccuracies, or miscalculations relating to the product of the project. Any of these errors could prompt a change request.
   
   Think about a software development project. An example of a product scope error would be the failure to include a required feature in the original design. Without a change request, the final product would be missing a desired feature.
   
   
3. a "project" scope error - A project scope error is the third reason for change requests. A project scope error usually results from an error in estimating or planning the work in the initial phases of the project. This could include anything from underestimating the time it takes to complete each task to not properly defining the work in each phase. Although most project scope errors cause the project to run behind schedule, they can also result in phases or deliverables being completed ahead of schedule.
   
   Using an incomplete WBS for a telecommunications project would prompt a change request due to a project scope error. Since the project manager did not properly define some activities, activities were duplicated, causing schedule and budget problems.
   
   
4. a value-adding change - The fourth reason for changing the scope of your project is a value-adding change. Value-adding changes are caused by factors that cannot be considered when the original scope is defined, but if implemented into the project scope, will improve the project or make it more cost effective. In a software game development project, a value-adding change could be new technology that enables players to play against other competitors online. This situation would require a change request due to a value-adding change.
   
   
5. a contingency plan implementation - The final reason for a change request might occur if you implement a contingency plan to handle a risk on your project. A contingency plan is applied to the identified risks on a project to reduce the cost and impact if the risk does occur. If the risk has a higher impact than anticipated, a change in project scope may be required. Tom, a software engineer, is working on a software development project that will allow a home entertainment system to be activated by both remote control and a human speaking a command. Tom needed to implement a contingency plan—human voice recognition—because the project manager learned a competitor was developing a similar product with voice recognition capabilities. Without this change request, the company risked losing sales to the competitor once the project went to market.

Change requests act as a record of the project's evolution and progressive elaboration. Since change requests explain the reason for change, they help ensure that all stakeholders understand and agree to the proposed change.

Whether changes to your project come in the form of federal laws or an error in judgment, one thing is certain—change will happen. Familiarizing yourself with the most common reasons for changing the project scope will allow you to manage and control these kinds of change requests.