Determining the Most Appropriate Risk Response

As a project manager, you can use a risk response plan to ensure that you meet your project objectives. A risk response plan is a document that details an identified risk, its cause, probability of occurrence, potential impact, and proposed responses. An effective risk response plan will help you enhance risk opportunities and reduce risk threats.

A risk response plan, which is sometimes called a risk register, is comprised of a number of different components. A typical project's risk response plan includes the following components:

• a detailed list of all identified project risks
• the risk owners responsible for formulating and implementing one or more risk responses
• the results from the project's qualitative and quantitative risk analyses
• the established responses for each identified risk
• the expected level of residual risk
• the specific actions required to implement the chosen response
• the budget and timing for all risk responses
• a description of any contingency or fallback plans.

One of the most important components of a risk response plan is "the established responses for each identified risk." As a project manager, it is your job to select the most appropriate and effective response for managing that risk. Once this selection is made, the agreed-upon risk response is entered into the project's risk response plan.

How do you determine which risk response will be the most appropriate and effective for an identified project risk? There are three important questions that you should ask yourself when making this critical decision.

1. What are the potential risk responses?
   The first question that you should ask yourself when determining the most appropriate risk response for one of your identified project risks is: What are the potential risk responses? You should apply the four risk response strategies to your risk, discard those strategies that are either impossible or impractical to use, and formulate potential responses from the strategies that remain.
   
   
   • Avoidance - should be used when the level of risk is unacceptable, when the means for controlling the risk are not feasible or when there is a potential for harm. This risk response strategy involves changing the project plan to eliminate the risk or the condition causing the risk.
     
     
   • Transference - should be used when there is a potential for significant financial exposure. Risks can be transferred through insurance, performance bonds, warranties, and contracts. This strategy shifts the consequences of a risk to a third party, such as an insurance company.
     
     
   • Mitigation - should be used when there is an opportunity to significantly reduce the probability or consequences of an identified risk. Throughout a project's life cycle, it may be possible to perform risk mitigation by reducing both the risk probability and the risk consequences.
     
     
   • Acceptance - should be used when the probability and consequences of an identified risk are low. This strategy results in no changes to the project plan. It involves leaving a project team to deal with a risk when it occurs or forming a contingency plan to deal with the risk if it occurs.
     
     
2. What are the project constraints?
   The second question that you should ask yourself when determining an appropriate and effective risk response for an identified risk is: What are the project constraints? The PMBOK Guide defines a constraint as an "applicable restriction that will affect the performance of a project." No project is completely free of constraints. As a result, you will need to keep this in mind when selecting an appropriate risk response. Constraints will limit the choices available to you during risk response planning.
   
   For example, you may initially decide that avoiding a risk by changing the project scope is an appropriate response for a given risk. However, a careful examination of the constraints facing your project may indicate that avoidance is not possible or that it is unwise given your circumstances.
   
   During the life cycles of your projects, you may encounter many different types of constraints. However, there are some constraints that you will face more frequently than others. A few of these constraints are listed below.
   
   
   • An established project budget - An established project budget is one constraint that can affect your selection of risk responses. For example, if your project is restricted by a tight budget, any responses that require a vast amount of funding to implement will be deemed unwise and detrimental to project success.
     
     
   • A defined project schedule - A defined project schedule can also act as a constraint when determining the most appropriate response for an identified risk. For example, if your project's sponsors have established an inflexible schedule, the responses that will add time or cause delays to the project schedule will have to be rejected.
     
     
   • Contractual obligations - Another constraint is contractual obligations. Risk responses may need to be discarded if they have the potential to deviate from a signed contract. For example, you cannot reduce the risk of cost overruns by paying your contractor less than the amount agreed upon in the project contract.
     
     
   • Product specifications - The final constraint that can affect your selection of risk responses is product specifications. If project sponsors are expecting a particular product, they may be unwilling to approve any changes to the project scope. This decision can limit your options when responding to risk.
     
     
3. Which risk response will be the most appropriate for managing the risk?
   The final question that you need to ask yourself when determining an appropriate risk response for an identified project risk is: Which risk response will be the most appropriate for managing the risk? Once you have decided what the potential risk responses are and what constraints are facing your project, you can then determine the most appropriate and effective risk responses for your project risks.
   
   By eliminating those responses that are not feasible for your project or those that cannot be achieved due to certain constraints, you will be left with only the responses that are appropriate for the chosen risk. These responses will serve to protect the project from the risk's potential impact.
   

As a project manager, you can determine the most appropriate risk response for a given project risk by answering the following questions: what are the potential risk responses, what are the project constraints, and which risk response will be the most appropriate for managing the risk?

Once this determination is made, you can include your chosen risk response into your risk response plan. This plan will help you enhance risk opportunities and reduce risk threats to project objectives and overall project outcomes.

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.

What is the Final Output of Project Scope Verification?

Someone once said that "Happiness can exist only in acceptance." Although the statement wasn't referring to project management, project managers are certainly happy when the client accepts the project work results.

The final result or output from the scope verification process is formal acceptance. Formal acceptance happens when the client or sponsor of a project accepts and acknowledges the project phase or major deliverable of the project. Formal acceptance is usually in the form of written documentation.

Formal acceptance may be conditional or complete.

• Conditional acceptance is usually offered when minor adjustments are necessary. Conditional acceptance is dependent on correcting the work results that don't match the project scope.

• Complete acceptance occurs when the work results of the project match the scope plan and client expectations. The project requires no changes.

Whether formal acceptance is conditional or complete, you should gather the documentation that reflects the formal acceptance of each phase or deliverable. This documentation includes:

• The scope statement
  The first component of the formal acceptance documentation is the scope statement. The scope statement is an output from the scope planning process. It is important to include this document because it outlines what the project was supposed to do.
  
  The scope statement typically has four sections: project justification, a description of the project's product, project deliverables, and project objectives.
  
  Project justification describes the business need that the project was undertaken to address. It provides the basis for evaluating future trade-offs within the project.
  
  The description of the project's product is a brief summary of the final outcome of the project. It should present all major aspects of the final product.
  
  Project deliverables are usually presented in a list of phases whose satisfactory delivery mark the project completion. For example, major deliverables for a computer software project may include a working computer code, a user manual, and a tutorial.
  
  Project objectives are the quantifiable criteria that determine if the project is successful. They must include at least cost, schedule, and quality measures. Unquantifiable objectives, such as customer satisfaction, involve a great deal of risk.
  

• A description of the work results
  The second component of the formal acceptance documentation is a description of the work results. This section outlines exactly what was presented for formal acceptance. It describes what the project produced. The description of the work results will most likely be the largest part of the documentation. This section should include both tangible and intangible items.
  
  Tangible work results include deliverables such as buildings, roads, computer software programs, or new products. Intangible items are deliverables such as people who are effectively able to apply new training.
  

• The details of inspection procedures
  The third component of the formal acceptance documentation includes the details of the inspection procedures. The documentation should explain what you have done to ensure that the project's product meets the original scope. As a PM, you need to provide verification that the project has been properly assessed. In this section of the formal acceptance documentation, include information from the inspection meeting, such as who attended the meeting, what areas were inspected, and the outcome of the meeting.
  

• The product acceptance form
  The final component of the formal acceptance documentation is the product acceptance form. This is usually a one-page document that acknowledges the client has signed off the phase or deliverable and accepted the work results. This form should bear the signatures of the project manager and the client.
  

After gathering the inputs to scope verification, completing the scope verification inspection meeting, and gaining formal acceptance by the client, you need only gather the necessary formal acceptance documentation to complete the process of project scope verification and work results acceptance.

A 4-step Approach to Scope Verification

As a project manager, you will need to prepare for a critical inspection of the project work. The inspection of the work results usually occurs at a meeting with project team members and key stakeholders. When conducted properly, this critical inspection verifies that all deliverables and work results are completed according to the project plan.

The project manager is frequently asked to facilitate the inspection meeting. There are four steps for facilitating a scope verification inspection meeting.

1. First, you need to choose the appropriate reviewers who will attend the inspection meeting.
2. Next, revisit project goals so that all of the reviewers are aware of the direction of the project.
3. Then you should review the work results to compare the project's product to the expected deliverables as outlined in the WBS.
4. Finally, you need to decide on appropriate action as a result of the scope verification.
   

Even before the actual inspection meeting begins, the project manager needs to choose appropriate reviewers. In addition to the project manager and at least one project team member, you may want to ask the following people to attend the meeting:

• Subject Matter Expert (SME) - An SME acts as an adviser to the project team when the team needs external expertise. SMEs should attend the inspection meetings to provide the team with the necessary advice and to verify the results of the work.

• Project Sponsor - The project sponsor is the individual or group that provides the financial resources for the project. The project sponsor should attend the inspection when the project is a new or risky venture. It is not necessary to include the project sponsor for projects that are repetitive or recurring.

• Customers - The customer is any individual or organization that will use the project's product. It could be the client or outside consumers. Customers should attend the inspection meeting when their cooperation is essential for the project.

The next step in facilitating a scope verification inspection meeting is to revisit the project goals. The meeting facilitator needs to ensure that all reviewers are aware of the original purpose of the project and of the goal of the inspection meeting.
As the meeting facilitator, you need to explain to the inspection team members that they will compare the actual work results to the planned scope of the project to ensure that project results are acceptable.

Once all of the reviewers are aware of the purpose of the project and the inspection meeting, the inspection team should review the work results and do the following:

• Identify any omissions in the product that were in the original plan.

• Verify whether the omissions, if any, were approved through a scope change.

• Note any oversights in the work results.

• Ensure that all documentation is available.

• Note any exceptions or deviations from the project baseline.

• Note any discrepancies (variances) between the work results and the scope baseline.

• Note any violations of industry or client standards.

After reviewing the work results, the inspection team needs to decide on appropriate action. In a scope verification inspection, there are three actions that you may choose from, depending on the outcome of the meeting.

1. The inspection team can accept the work results if the planned scope and the work results match. There should be no unapproved deviations from the plan when you accept the work results.
   
   
2. The reviewers at the inspection meeting should request minor changes if it won't affect the project budget or schedule. Minor changes could include asking for slight product modifications or for more detailed documentation.
   
   
3. The inspection team should reject the work results if there are obvious and substantial deviations from the planned scope. If the changes required to fix the deviations cause cost overruns or put the project behind schedule, the reviewers should reject the work results.

Before presenting your project to the client for final acceptance, you can use the tools and techniques for scope verification to ensure that the work results are acceptable. Remember to perform a careful and thorough inspection.