Risk Management Plans

Overview

Although project managers can prepare a well-thought-out and comprehensive project scope, schedule and cost management plans, they cannot ensure that all these plans are free of problems that may occur due to numerous reasons during the project. Even the most carefully planned projects can run into trouble. No matter how well we plan, our project can always encounter unexpected problems. Team members get sick or quit, resources that we depend on turn out to be unavailable, even the weather can throw us for a loop (e.g., a snowstorm). So, does that mean that we are helpless against unknown problems? No! We can use risk planning to identify potential problems that could cause trouble for the project, analyze how likely they are to occur, take action to prevent the risks we can avoid, and minimize the ones that we can’t. In this chapter, we will discuss both negative risks (i.e., threats) and positive risks (i.e., opportunities). A project manager must always keep in mind that risks mean uncertainties, not solely problems or threats all the time, since they are sometimes opportunities that we should consider exploiting. There are no risk-free projects because there is an infinite number of events that can have a negative or positive effect on projects. Project managers must be prepared to deal with uncertainties. Planning for events that can delay a project, decrease its quality, or increase its budget is a necessary part of project planning.

Source: Abdullah Oguz, https://pressbooks.ulib.csuohio.edu/project-management-navigating-the-complexity/chapter/10-0-learning-objectives-and-overview/
This work is licensed under a Creative Commons Attribution 4.0 License.

Project Risk

Project Risk

Risks are an aspect of uncertainty. Therefore, an uncertainty is not equal to a risk. Risks can be measured while uncertainties cannot be. That is, potential outcomes of a risk can be described whereas it wouldn't be possible to determine the outcomes for uncertainties. Risks can be controlled if response strategies can be defined and monitored during the project. Project team can respond to a risk if the risk triggers are identified and there is an owner of the risk who monitors the risk among other factors. Thus, when the project teams discuss all possible uncertainties in the initiation and planning stages, they determine the occurrence probability and the impact scale. For example, in our m-commerce project, testers may not determine some of the important code errors, which might lead to rework, schedule slippage and cost overruns. Considering the previous projects and lessons learned, we can predict the probability and how it may affect the project if the risk occurs. However, we can never be sure that this tester has malicious intentions to help a strong competitor. This would be an uncertainty, not a risk.

Project risk is an uncertain event or condition that, if occurs, has a positive or negative effect on one or more project objectives. Risks exist in all projects. It is of high importance to keep in mind that a risk does not always create negative outcomes, but can lead to positive outcomes. The subsections 10.1.1 and 10.1.2 below elaborate on both types of risk with examples.

Negative Project Risks

It is the reality that project teams mostly encounter negative risks. These risks might jeopardize the well-being of a project's progress and lead to failure if they occur. Some examples of a negative project risk are:

• Machines can fail in the middle of a critical activity.
• A vendor may not dispatch raw materials on time, or they may be damaged during a long journey from the vendor's or supplier's country to our project's location.
• A key human resource for an activity may become sick or may find a better job and leave the organization.
• Projects that depend on good weather, such as road construction projects, face risk of delays due to exceptionally wet or windy weather.
• Safety risks are also common on construction projects.
• Changes in the value of local currency during a project affect purchasing power and budgets on projects with large international components.

A short example for negative risks:

A construction company is building a 20-storey building in a Northeastern state, and they are expected to finish it by February. However, the project team is aware of the fact that winter is not a preferred season to carry out construction works, and the adverse weather conditions may disrupt activities leading to schedule delays and cost overruns. This is why the project team should evaluate all the possible risks that may result from inclement weather such as snowstorms. Project team can obtain the long-term historical data and seasonal forecasts from the National Weather Service, and can monitor the daily and weekly weather forecast.

Positive Project Risks

Some uncertainties that we are not 100% sure that they may be materialized can make it easier to achieve a project's objectives. When this type of uncertain happens, the risk is positive and is therefore referred to as an opportunity. Some examples for positive risks can be described below:

• The potential of finding an easier way to do a task
• Acquiring some materials in exchange for lower prices than estimated
• A potential change in organizational process that can accelerate the procurement of some materials
• A new technology that has been developed and can be introduced to the market while we carry out the project
• A grant our organization had applied, which can provide more funds to our project if accepted

As for the five positive risks above, a project manager's response strategy would be exploit or enhance (among five alternative strategies in total) when they occur.

Known-Unknowns and Unknown-Unknowns

As discussed in Chapter 9 for contingency and management reserves, risks can be categorized as known-unknowns or unknown-unknowns. As regards known-unknowns, we can identify these risks in the planning stage, and estimate costs, and additional schedule and resources needed, if they occur. The costs allocated to compensate for managing these risks are named "contingency reserve". However, it is not always possible for project teams to predict all the risks. Therefore, a management reserve is assigned besides the cost baseline (in which contingency reserves are accounted for). One obvious risk that emerged at the end of 2019 and has had a severe impact on all countries since March 2020 is the COVID-19 pandemic. This pandemic was an unknown-unknown for all the projects across the world. Some projects were able to overcome the issues by using their management reserves besides contingency reserves. However, numerous projects failed although they had contingency and management reserves since the impact of this pandemic exceeded the projects alone.

Individual and Overall Project Risks

Besides the categorization of risks as negative and positive, and as known-unknowns and unknown-unknowns, another categorization would be individual and overall project risks. Individual risks can affect the achievement of project objectives, and disrupt some activities, decisions, components, or deliverables. They can affect only one or some of the activities, but not always the whole project. If a risk has an impact on the project as a whole, this risk is considered an overall project risk. Let's consider the case study of "Grocery LLC's M-Commerce Project". One project objective can be formulated as "to complete the elicitation of mobile app requirements as well as budget, schedule and resource estimates on which all the key stakeholders agree". The activity 2.3 "Review specifications with team and stakeholders" is essential to identify the requirements that address all stakeholders' expectations and concerns. However, some of the stakeholders may not agree on some of the requirements. Priorities of the top management, project sponsor, and product owner might not always overlap with one another. When the project team and team members review risks, they need to consider all possible risks that may affect the activity 2.3 and the overall project. If the conflict among stakeholders affects this objective, and therefore the activity 2.3, this would be counted as an individual project risk. Project team should create a contingency budget and schedule for this activity. If there is a risk of obtaining fund to conduct project activities, this would have an impact on the whole project, and will affect the overall project objective that aims at creating a mobile app. Project team must also develop risk response strategies to tackle with this risk. Besides, project team can determine an acceptable range of negative and positive variations for overall risks.

Risk Management Plan

The risk management plan is a component of the project management plan that describes how risk management activities will be structured and performed. This plan tells us how we are going to handle individual and overall risks in our project. It documents how we will identify and analyze risks, who will be responsible for doing it, and how often we will review the risks (since we have to meet about risk planning with the project team throughout the project).

This plan allows the project team to reduce the likelihood of negative surprises (problems, weaknesses, and threats), proactively take advantage of positive risks (opportunities), and ensure risk management is considered when schedules, budgets, and other management plans are developed. Creating and maintaining a risk management plan significantly increases the likelihood of project success. The risk management plan identifies the processes and procedures to be used in managing risk throughout the life of the project. It includes a number of key sections such as risk sources, categories, assessment definitions (e.g., very high to very low), probability/impact assessment (matrix), roles and responsibilities, budget and schedule estimates for risk-related activities, and the risk register. Like the other knowledge area (e.g., scope, schedule, stakeholder) management plans, the risk management plan is integrated into the project management plan, and must be aligned with all the subplans and the project management plan.

The risk management plan can consist of some or all of the following items:

• Methodology
  • What kind of approaches, tools, and data sources will be utilized to perform risk management activities (e.g., risk identification, risk assessment, risk response strategies)?
  • g., checklists, risk indicator scales, probability-impact matrices, informal direct risk assessment, probabilistic modeling.
• Risk strategy
• Roles and responsibilities
  • The guidelines how identified risks will be assigned to team members, and how these risk owners will take care of risks, and monitor them.
• Risk categories
  • Risks can be grouped into high-level categories to facilitate the identification of individual risks. Some of the categories can be technical, cost, schedule, client, contractual, weather, financial, political, environmental, and people.
  • Similar to a WBS (Work Breakdown Structure), RBS (Risk Breakdown Structure) would be a very helpful tool (Table 10.1).
• Risk probability and impact
  • Level and percentage of probabilities and impact of negative and positive risks
  • Which project aspects will be included in the impact analysis (e.g., scope, quality, schedule, cost, safety, environment)?
• Risk register
  • How will the risk register be structured?
  • Components such as risk ID, description, risk owner, probability, and impact (see 10.3)
• Risk response plan
  • How will risk response plan be structured?
  • Strategies for negative and positive risks, and individual and overall project risks.
• Funding of reserves
  • How will contingency and management reserves be determined and released?
• Reporting formats
  • Reporting formats and frequency should be in alignment with other project plans.

Table 10.1: An Example of a Risk Breakdown Structure (RBS)

Adapted from Project Management Institute's Learning website

Identifying Risks

A more disciplined process involves using checklists of potential risks and evaluating the likelihood that those events might happen on the project. Some companies and industries develop risk checklists based on experience from past projects. These checklists can be helpful to the project manager and project team in identifying both specific risks on the checklist and expanding the thinking of the team. The past experience of the project team, project experience within the company, and experts in the industry can be valuable resources for identifying potential risk on a project.

When risks are identified, they are recorded in a risk register. It is a key tool that helps project teams keep track of the status of risks, ensure response plans are effectively implemented, and new risks are managed. The register is an output of the process of identifying project risks. The project charter can involve some of the risks, generally the overall risks. After the WBS and activity list are created, and the schedule, resources and cost are estimated for all the activities, the project team can identify the risks more easily. Project team must review this register periodically by assigning each risk to a team member.

Risk register can be composed of the items below:

• Risk ID
• Description
• Related WBS activity or activities
• Risk owner (Name of the team member who monitors the risk)
• Risk trigger (How do we know the risk is becoming an issue or has reached a point that requires action?)
• Risk category (based on RBS categories)
• Probability (How likely does the risk occur?)
• Impact (How will the risk affect the project if it occurs? E.g., schedule delay, budget overrun, quality issues)
• Probability-Impact Score (Multiplying probability percentage by impact percentage)
• Risk response strategy (see 10.5)
• Description of the response (see 10.5)
• Response owner (if different from the risk owner)
• Expected impact of the response (What result do we expect from the response?)

Table 10.2 illustrates a short version of a sample risk register for Grocery LLC's M-Commerce Project. Only six columns have been included in this risk register.

Table 10.2: An Example of a Risk Register

Risk Assessment

After the potential risks have been identified, the project team evaluates the risks based on the probability of occurrence and impact if they occur. This is a qualitative risk analysis method. In this textbook, we will not discuss quantitative risk analysis process. 

Not all risks are equal. Some risk events are more likely to happen than others, and the impact of a risk event can vary greatly. Therefore, project teams perform qualitative risk analysis in order to prioritize individual project risks by assessing their probability of occurrence and impact. This assessment technique is conducted by the project team. Team members indicate their opinions regarding each risk. Therefore, this kind of process introduces bias into the assessment. However, project manager assumes the role of a facilitator or a moderator to minimize the bias by implementing techniques such as Delphi. Besides, in order to minimize the bias and provide a consensus, the project manager should clarify the underlying mechanism of how each team member and expert justify their perceptions as regards the probability and impact.

For the qualitative risk analysis, let's use a five-scale measure: Very low, low, medium, high, and very high (Table 10.3). It is always possible to have more and fewer number of scales. Each level may correspond with different percentage values depending on the project, project manager, and organizational policies. Table 10.2 displays two different percentages of probability. Organizations may have an overarching policy to implement levels, percentages, and risk categories. In this case, project manager must comply with this policy.

The probability, alone, wouldn't make sense if we disregard the impact of the risk. Just think that our project is in an area where a large earthquake hits every thirty years. Since the frequency doesn't look high, we can give a very low probability level (5%). However, we should consider the impact of an earthquake if it occurs. Although the probability may be 5%, the impact of an earthquake to disrupt project activities would be high. Even in our m-commerce project, an earthquake would have a number of negative effects such as power outages, water supply problems, transportation issues, supply chain problems, and in a worse scenario, destroyed buildings and infrastructure, and fatalities. This is also the case for an epidemic or pandemic. Therefore, we can decide on a very high impact value (0.9) while the probability is 0.05.

Table 10.4 displays the impact levels and values for the impact of risks on schedule. Project managers can use criteria for different areas such as schedule, cost, safety, environment and quality to determine the impact of level. For each area, description for each impact level should be described to eliminate ambiguities. According to Table 10.4, if an activity takes 10 days to finish, and we found that a risk may add an additional 1 day, it means that we have a delay by 10%. Therefore, the impact is low, and its value is 0.3.

When we use several areas besides schedule, we should formulate how to generate an overall impact level. We can use a non-weighted or a weighted model to combine all areas' values. Table 10.5 shows the impact levels regarding cost.

Table 10.6 displays the risk severity score which is found by multiplying probability by impact percentages. In Table 10.6, there are three severity levels: (1) Green indicates low-level severity, which is between 0% and 15%, inclusive, (2) Orange indicates medium-level severity, which is between 16% and 40%, inclusive, and (3) Red indicates high-level severity, which is at 41% and above.

Not all project managers conduct a formal risk assessment on projects. There may be barriers to identifying risks. David Parker and Alison Mobey found in a phenomenological study of project managers that there was a low understanding of the tools and benefits of a structured analysis of project risks. The lack of formal risk management tools was seen as a barrier to implementing a risk management program. The level of investment in formal risk management was also associated with managerial psychological dimensions.

Some project managers are more proactive and will develop elaborate risk management programs for their projects. Other managers are reactive and are more confident in their ability to handle unexpected events without prior planning, while some managers are risk averse and prefer to be optimistic and not consider risks or to avoid taking risks whenever possible.

In projects with low complexity, the project manager may informally track items that may be considered risk items. On more complex projects, the project management team may develop a list of items perceived to be higher risk and track them during project reviews. On projects with greater complexity, the process for evaluating risk is more formal with a risk assessment meeting or series of meetings during the life of the project to assess risks at different phases of the project. On highly complex projects, an outside expert may be included in the risk assessment process, and the risk assessment plan may take a more prominent place in the project execution plan.

On complex projects, statistical models are sometimes used to evaluate risk because there are too many different possible combinations of risks to calculate them one at a time. These are considered as quantitative risk analysis. One example of the statistical model used on projects is the Monte Carlo simulation, which simulates a possible range of outcomes by trying many different combinations of risks based on their likelihood. The output from a Monte Carlo simulation provides the project team with the probability of an event occurring within a range and for combinations of events. For example, the typical output from a Monte Carol simulation may reflect that there is a 10 percent chance that one of the three important pieces of equipment will be late and that the weather will also be unusually bad after the equipment arrives.

Developing and Implementing Risk Responses

After the risks are identified, described, and assigned to a team member to keep track, and their probability and impact scores are produced, hence risks are prioritized, the project team can continue with planning the risk responses. Which strategy and the action does the team have in order to respond to the risk's negative or positive impact? These strategies depend on factors such as whether the risk is negative or positive, and its severity or significance. Project managers can utilize mathematical optimization models or real options analysis as a basis for a more robust economic analysis of alternative risk response strategies in projects with a greater complexity.

Strategies Developed for Negative Risks (Threats)

The project team responds to negative risks in various ways:

1. Escalation
2. Avoidance
3. Transfer
4. Mitigation
5. Acceptance

Each of these responses can be an effective tool in reducing individual risks as well as the overall risk profile of the project. The risk response plan captures the risk management approach for each identified risk event and actions the project management team will take to manage the risk.

Escalation is implemented when the threat is outside of the scope of the project, and it is beyond the project manager's control, that is the project manager isn't capable of developing and implementing a response to this threat. Therefore, project manager should escalate the risk to a higher authority such as project sponsor, project steering committee, or the client. If there is a resource conflict with another project in our organization, it would be a wise move to escalate this issue to the sponsor or top management so that it can be solved at the program or portfolio level, or at the organizational level. Risks or issues related to project objectives, resource and inter-group conflicts, ambiguous roles and responsibilities, scope disagreements, third party dependencies are some known situations calling for escalations. Such issues require higher level intervention because many times the authority, decision making, resources or effort required to resolve them are beyond a project manager's horizon. At times, the project manager may want to involve higher authorities for information-only escalations to keep them abreast of potential issues in the project. Escalation should be treated as a professional act and should be done in an effective way. Project managers should escalate timely if something is blocking the project and is beyond the project manager's control. One should not hesitate to escalate within the performing organization and in the client's organization as well. A proactive escalation and risk communication is far better than unpleasant surprises requiring costly fixes to the project.

Risk avoidance usually involves developing an alternative strategy with a higher probability of success, but, usually, the associated cost of task completion also becomes higher. A common risk avoidance technique is using proven and existing technologies rather than adopting new techniques, even though the new techniques may show promise of better performance and/or lower costs. A project team may choose a vendor with a proven track record over a new vendor that is providing significant price incentives to avoid the risk of working with a new vendor. Alternatively, a project team that requires drug testing for team members is practicing risk avoidance by attempting to evade damage done by someone under the influence.

Risk mitigation is a response to a risk that cannot be avoided or if it is unwise to avoid it (due to risk avoidance strategies being too expensive, too time-consuming, etc.). In this case, the project team is attempting to reduce the likelihood and impact of a risk. For instance, assigning highly skilled resources to an activity or performing more tests to detect irregularities and problems reduces the likelihood and impact of errors occurring. In product development projects, teams can develop prototypes to mitigate the risks by obtaining early feedback on requirements by providing a model of the expected product before actually building it. These prototypes can be small-scale products, computer generated 2D and 3D models, mock-ups, or simulations.

Risk transfer is a risk reduction method that shifts the ownership of a threat from the project to another party. The purchase of insurance on certain items is a risk-transfer method. The risk is transferred from the project to the insurance company by paying a risk premium to another party that takes on the risk. A construction project in the Caribbean may purchase hurricane insurance that would cover the cost of a hurricane damaging the construction site. The purchase of insurance is usually connected to risks that can significantly impact the project while being out of the project team's control, such as weather, accidents, sharp fluctuations in currency, political unrest, and labor strikes. Using performance bonds, warranties and guarantee, and establishing agreements are also considered as responses to transfer the risks.

The fifth strategy, risk acceptance, involves doing nothing in response to the risk. The acceptance response is a good one when the likelihood and impact of a risk are low. In some cases, little else can be done about the risk, leading to acceptance being the only feasible option. When this response is chosen, an active strategy to deal with the risk would be to establish a contingency reserve that includes funds, time and/or resources to handle the threat.

Strategies Developed for Positive Risks (Opportunities)

As previously mentioned, positive risks (opportunities) are uncertainties that, if materialized, will have a positive impact on the project. The strategies to deal with positive risks can be listed as follows:

1. Escalation
2. Exploitation
3. Sharing
4. Enhancing
5. Acceptance

Escalation of positive risks has the same process as is for negative risks. When the client tells the project manager that they are considering adapting the product for a different market and asks if we are interested in bidding for the work, we can escalate this opportunity to the project sponsor. Another escalation strategy can be implemented when a team member identifies an opportunity to create a new value stream for the business. This opportunity is escalated for senior management attention.

Risk exploitation can be considered analogous to risk avoidance strategy in negative risks. Risk exploitation strategy attempts to eliminate the uncertainty and ensure the occurrence of the opportunity. An example of this could be pursuing a bonus that is available only if an activity is completed early. In this case, the project team will reallocate resources in order to ensure the activity finishes early and the bonus is obtained. Project managers can use new technologies or technology upgrades to reduce cost and duration by means of this strategy.

Risk-sharing can be considered analogous to risk transfer strategy in negative risks. It involves partnering with others to share responsibility for the risk. Partnering with another company via risk-sharing partnerships or joint ventures to share the risk is advantageous when the other company has the expertise and experience that the project team lacks. This increases the likelihood of the opportunity materializing and, if it does, both organizations share the gains.

Risk enhancement can be considered analogous to risk mitigation strategy in negative risks. This strategy attempts to increase the probability and/or impact of an opportunity. However, it does not seek to ensure its occurrence. Project teams need to focus on the causes of an opportunity to take the advantage of it. For one component of our project, we were aware of that an investor is interested in the deliverables of this component since their non-profit organization can benefit from them. We can communicate with this investor and their non-profit organization to learn more about their objectives.

The fifth strategy is the risk acceptance which is also used for negative risks. This risk strategy involves doing nothing in response to the positive risk (opportunity). This acceptance response is a good one when the likelihood and impact of a risk is low, or taking action is too costly or it needs a disproportionate amount of effort compared to the size of the work in the project and the benefit we can have. For example, for an activity, we want to have two highly-skilled engineers who work at another project. If we can convince them, we believe that we can have a better quality in our new product development, and we can finish this activity earlier. However, their project manager isn't willing to release them since they are key people in that project. Thus, we just accept this risk, and decide to do nothing.

Contingency Plan

The project risk plan balances the investment of the risk response implementations against the benefit for the project. The project team often develops an alternative method for accomplishing a project goal when a risk event has been identified that may frustrate the accomplishment of that goal. These plans are called contingency plans. The risk of a truck drivers' strike may be mitigated with a contingency plan that uses a train to transport the needed equipment for the project. If a critical piece of equipment is late, the impact on the schedule can be mitigated by making changes to the schedule to accommodate a late equipment delivery.

Contingency funds are funds set aside by the project team to address unforeseen events that cause the project costs to increase. Projects with a high-risk profile will typically have a large contingency budget. Although the amount of contingency allocated in the project budget is a function of the risks identified in the risk analysis process, contingency is typically managed as one line item in the project budget.

Some project managers allocate the contingency budget to the items in the budget that have high risk rather than developing one line item in the budget for contingencies. This approach allows the project team to track the use of contingency against the risk plan. This approach also allocates the responsibility to manage the risk budget to the managers responsible for those line items. The availability of contingency funds in the line item budget may also increase the use of contingency funds to solve problems rather than finding alternative, less costly solutions. Most project managers, especially on more complex projects, manage contingency funds at the project level, with approval of the project manager required before contingency funds can be used.

Key Takeaways

• Project risk is an uncertain event or condition that, if occurs, has a positive or negative effect on one or more project objectives.
• Contingency reserve is allocated for known-unknowns whereas management reserve is allocated for unknown-unknowns.
• The risk management plan is a component of the project management plan that describes how risk management activities will be structured and performed.
• When risks are identified, they are recorded in a risk register. It is a key tool that helps project teams keep track of the status of risks, ensure response plans are effectively implemented, and new risks are managed.
• Project teams perform qualitative risk analysis in order to prioritize individual project risks by assessing their probability of occurrence and impact.
• The strategies to respond negative risks are escalation, avoidance, transfer, mitigation, and acceptance.
• The strategies to respond positive risks are escalation, exploitation, sharing, enhancing, and acceptance.
• The project team develops contingency plans as an alternative method for accomplishing a project goal when a risk event has been identified.