Project risk management--another success-boosting tool in a PM's toolkit

Abstract

Project risk management is perhaps the least understood—and most effective—tool project managers can employ to increase the odds of project success. When implemented correctly, project risk management not only boosts the probability of success, but it also alleviates anxiety and offers a higher degree of predictability. Over the last decade, project risk management has become the backbone of organizations, which successfully deliver projects, and in the current period it is absolutely essential to the success of a project.

This paper covers the theoretical as well as practical aspects of risk management methodologies. The readers will learn how to (a) develop a risk management plan; (b) identify risks; (c) prioritize risks; (d) develop risk responses; and (e) monitor and control risks on an on-going basis. Readers will also learn how to develop a communication strategy to clearly and quickly articulate the project risk picture at various points in time to gain upper management support. Examples from real projects clarify concepts and illustrate the best practices.

The Concept of Project Risk

What Is a Risk?

According to A Guide to the Project Management Body of Knowledge (PMBOK@ Guide) (Project Management Institute [PMI], 2008), a risk is an uncertain event that, if it occurred, has an effect on at least one project objective. The first and foremost thing to note is that risk is an event that has not happened yet but could happen in the future. Therefore, when we talk about risk we are talking about the future, not the present or the past. Therefore, if an event has already occurred or is already occurring it cannot be called a risk, this kind of event would be classified as an “issue” or “problem.” The difference between risks and issues is discussed in details in the following section. Secondly, a risk event may affect one or more project outcomes. If a future event were not expected to affect any of the project outcomes then it would not be called a risk. Last but not the least, risk impact could be favorable or unfavorable to the project.

Usually a risk is seen as a bad thing, something that will always have a negative impact. However, the PMBOK@ Guide treats risk as an uncertainty that may have a positive or negative impact. The risks that produce negative outcomes are called “threats,” and risks that produce positive outcomes are called “opportunities.” Identifying the two types of risks allows project managers and teams to not let opportunities pass by while managing threats.

The Difference between an Issue and a Risk

Risk is an event that has not happened yet but there is a likelihood that it may happen in future, where as an issue is an event that has already happened. The main differences are related to timing and probability. Because of these differences, the language used to describe risks is in the future tense: “If this happens, then this will be impacted,” the language used for issues is in the present tense: “We have this problem. How should we deal with it?”

The names of the documents that store information about risks and issues are also different. The risk document is called “risk register” whereas the issues document is called “issue log.” The risk register will normally include columns like “likely risk event date,” “probability,” “impact,” and “person responsible for risk response plan” in addition to other columns. The issue log will not contain such columns, rather it will generally contain columns like “date issue reported,” “action items to resolve the issue,” and “person responsible to resolve the issue.” Since probability and impact are associated with risks, the mitigation strategy would involve reducing one or the other or both, whereas there is no probability associated with an issue (since the event has already occurred), the issues are not “mitigated” but rather “resolved.”

Is it Necessary to Manage Project Risks?

There is no doubt that it is essential to manage project risks. For example, the space shuttle Columbia disaster might have been prevented or its impact substantially reduced if an appropriate level of risk management was exercised. The space shuttle Columbia disintegrated into several pieces on its re-entry into the earth's atmosphere on 1 February 2003. In August 2003, an investigation board issued a report revealing that it would have been possible either for the Columbia crew to repair the damage to the wing or for the crew to be rescued from the shuttle. The Columbia could have stayed in orbit until 15 February and the already planned launch of the shuttle Atlantis could have been moved up as early as 10 February, leaving a short window for repairing the wing or getting the crew off of the Columbia (Columbia disaster, 2012).

The appropriate level of risk management helps improve probability for project success and keeps the schedule and cost variance close to zero and the SPI (schedule performance index) and CPI (cost performance index) close to one. It also helps manage stress for the team and improve its credibility about project management.

Taking project risks lightly could ruin your projects…and your career too. Therefore, it is very crucial to pay attention to project risks—identify them, analyze them, prioritize them, develop response plans for them, and keep monitoring them throughout the life of the project.

Project Risk Management—The Process

The Six-Step Process of Project Risk Management

Practice Standard for Project Risk Management (Project Management Institute, 2009) describes a six-step process to effectively manage project risks. Exhibit 1 shows the entire process along with relationships and dependencies among the six steps. The process starts with developing the risk management plan, followed by identifying risks, performing qualitative analysis, performing quantitative analysis if required, and planning risk responses. That completes all planning activities related to risk management. Risks should be monitored and controlled throughout the duration of the project. During the plan risk responses, secondary risks may be identified for which qualitative and quantitative analysis may be needed, which is shown by arrows going back from plan risk responses. Similarly, monitor and control risks may result in identifying new risks and/or altering the risk response for one or more risks, which is shown by the arrows going back from monitor and control risks box.

Project Risk Management Process

Exhibit 1: Project Risk Management Process

The entire risk management process is iterative and the entire process is executed several times during the life of the project. Let's discuss each step in more detail.

Develop Risk Management Plan

The first step in project risk management is to develop a tailored risk management plan, which is used as a guide to manage the project risks. Here is where the tailored process is created that will be followed throughout the project. The risk register template is finalized and included in the plan. The probability-impact Matrix (P-I matrix) (Exhibit 2) is created and risk thresholds are decided, which will be used in the later steps to prioritize risks. The risk management-related roles and responsibilities are also decided and documented in the risk management plan. The risk management plan is an important document because it is used as a guide to carry out risk management activities throughout the life of the project.

Probability/Impact Matrix

Exhibit 2: Probability/Impact Matrix

Identify Risks

Risk identification is the most crucial activity in the entire risk management process. Identifying all/most project risks is not a trivial task. The project manager must have knowledge about all aspects of the project such as requirements, scope, customer/stakeholders/sponsors, team members, rules and regulations, contracts etc., since risk can originate from anywhere. The most effective way to identify all/most project risks is to collaborate with customers/stakeholders/sponsors and team members. Brainstorming is an excellent technique; document all possible scenarios and then consolidate to develop the list of potential risks.

The major output of this step is the “risk register,” which should contain a list of risks, a description, timeframe, and risk manager for each risk. If a potential risk response is available it can also be put against the respective risks though it is not necessary that every risk should have a potential response.

Perform Qualitative Analysis

After risks have been identified and listed in the risk register, the next step is to start analyzing them. There are two types of analysis that can be performed on risks identified for the project. Qualitative risk analysis is the first type of analysis; it is mandatory and need to be performed on every risk listed in the risk register.

The qualitative risk analysis involves but is not limited to these:

  • Performing root-cause analysis, which will help figure out the source of the risk and other the attributes (such as impact and response strategy) of the risk.
  • Determining probability of occurrence for the risk event. The probability should range between 0 and 1. If the probability is zero then this event is not likely to happen. If the probability is one, then this event has already occurred and there may be a need for an issue resolution plan rather than a risk response plan.
  • Estimating the impact, if the event did occur. The impact can be in terms of time or money or both. The time impact may most likely result in altering the schedule whereas cost impact may most likely increase/decrease the project's bottom line (and hence the profitability or the top line).

The last step in qualitative analysis is to prioritize risks using the P-I matrix, which was developed as part of the risk management plan, as shown in Exhibit 2. Risks that have high probability and high impact appear at the top of the risk register, which is prioritized now, and the ones with low probability and low impact appear at the bottom, and rest are in between. The prioritization of risks is very important since it allows project teams to focus on serious risks first.

Perform Quantitative Analysis

The second type of analysis is called quantitative analysis. The quantitative analysis provides a better handle on probability and impact of the risk since it quantifies the two. Since such analysis is costly, time consuming, and may require a large amount of data, only a few selected risks may be subjected to this kind of analysis based on the prioritized risk register that resulted from perform qualitative analysis. There are three primary types of quantitative analysis that can be performed for the selected risks:

  1. Sensitivity analysis—determines which risks have the most potential impact on the project. A what-if analysis is performed and a tornado diagram is created to represent most potential risks on the top.
  2. Expected monetary value (EMV) analysis—used to calculate the average outcome of uncertain scenarios by multiplying probability with impact for each risk and summing them up (EMV = Σ(probability*impact)). Opportunities produce positive values and threats produce negative values. This method is the easiest and the least time-consuming quantitative analysis method.
  3. Modeling and simulation—translates uncertainties into potential impact on project outcomes such as cost and/or schedule. Typically performed using Monte Carlo techniques to predict probabilities for completing project on different dates and/or at different costs.

EMV analysis is recommended for beginners because it is very simple to implement and does not require a lot of data gathering and analysis, and can be performed using simple mathematics.

Developing Risk Response Plans

Now that risks have been identified, analyzed and prioritized, it's time to start thinking about developing response plans for risks that have a higher value than the thresholds defined in the risk management plan. The risks below the threshold values are kept on a “watch list”; there is no need to develop a response plan for them until they cross the threshold values.

There are seven different strategies that can be used to develop risk response plans. Three for negative risks (or threats), three for positive risks (or opportunities), and one that is applicable to both. Exhibit 3 describes the seven risk response strategies.

Risk Response Strategies

Exhibit 3: Risk Response Strategies

A risk response is developed for each risk in the risk register by utilizing one more out of the seven strategies mentioned in Exhibit 3. The risk register is updated with the response plans.

Monitor and Control Risks

Monitor and control risks is the last risk management process and the only one that is not part of the planning process group of the PMBOK® Guide. This process is exercised during the project execution. On regular intervals (weekly, monthly, etc.), the project situation is reviewed and new risks are identified. For new risks, the entire risk management process is carried through the development of risk response plans. The updated risk register and the watch list are reviewed. Each risk's timeframe, probability, and impact are re-evaluated. The risk register is updated with re-prioritized risks, including the watch list. Some risks may move between the risk register and the watch list.

See Appendix A for a partial snapshot of a risk register at regular intervals. In this example, the impact is the number of days the project will be delayed if the risk event occurred. Expected monetary value (EMV) for each risk is calculated by multiplying probability with impact. Total EMV at a point in time is the sum of individual EMVs for each risk. Observe how total EMV first increases and then drops. This is not unusual since it is not possible to identify all risks at the beginning of the project. As the project progresses, new risks are identified and older risks are managed, which results in a constant decline in total project EMV.

Risk Contingency Reserve

Developing Risk Reserve

It is important to develop risk reserve and apply it carefully to a refined schedule and cost to achieve greater predictability in meeting project deadlines and/or staying within the budgeted cost. At the same time, it is very difficult to accurately determine the probability and impact for each of the risks. This exercise requires an enormous amount of time to be executed properly. Some form of quantitative analysis is required before an estimate of risk reserve can be determined.

For most business/commercial projects where the impact is mainly monetary, an 80/20 rule-based approach can be implemented. This approach may need about 20 percent of the effort to achieve about 80 percent of the result or about 80 percent accuracy, which may be good enough for a commercial project. Much more sophisticated and costly techniques may be needed for better accuracy for other types of projects where a lot more could be at stake (such as environment, culture, animals, or human life).

For most commercial projects, the EMV technique is the most cost effective and easy to implement to determine an estimate for risk reserve that is almost 80 percent accurate. The first step would be to estimate the probability and impact for each of the risks using “expert judgment” or the Delphi technique. This should be done after taking into account the risk response plan, which may have a significant impact on these numbers. The total project EMV is simply the sum of the individual EMVs. The total project EMV is then used as the estimate for the risk reserve needed for the project.

Using Risk Reserve

Like other contingency reserves, risk reserve can be used when a risk event occurs. Normally once the risk reserve has been approved, a project manager is authorized to use the risk reserve. In case of a schedule reserve, the project manager will update the schedule and re-baseline it. Since a part of the total risk reserve has been used to deal with the impact caused by a particular risk event, the total risk reserve is reduced by that amount. This process is followed every time a risk event occurred. It is interesting to note that total risk reserve was based on impact multiplied by probability, but when risk occurs, it may use 100 percent of the impact amount, not what was calculated by multiplying it by probability. For example if a risk event has a probability of 30 percent and an impact of 10 days schedule delay, the EMV for this risk event will be 3 days, which goes as part of developing the total risk reserve (not 10 days). If this risk event occurred, the schedule may have to be delayed by 10 days (not 3 days), and total risk reserve reduced by 10 days to arrive at remaining risk reserve for the rest of the risks. At the surface level, it seems like a problem, but in the real world, it is not. If there were 10 risks that were used to create the total risk reserve, it is highly unlikely that all 10 will occur. The portion of risk reserve for non-occurring risks will generally cover the impact for the risks that occur.

Communicating Project Risks

Who Should Be Informed About Project Risks?

It is important that everyone be informed about project risks on a regular basis. The frequency and level of detail may depend on the nature of the risk, its impact, and the role that a person or group is playing on the project. The communication plan developed during the planning process should clearly identify all stakeholders who should receive risk communication, and the content and frequency of communication. Normally, project managers have the primary responsibility of communicating risks and all information related to risks to all the stakeholders.

What Should Be Communicated About Project Risks, and When?

At minimum, the status of all risks should be communicated to all stakeholders. For every risk, the current status should include (a) timeframe of occurrence; (b) probability of occurrence; (c) the impact if the risk does occur; and (d) the response plan to manage the risk if it does occur. In addition, the remaining risk reserve, need for additional risk reserve (if any) and current baselines for schedule and cost may be very valuable information for the sponsors or stakeholders who approve the budget. The status and additional risk information should be communicated on a regular basis. The frequency of communication will depend on the nature and size of the project. For projects that are small but critical, a weekly risk update may be needed. For projects extending beyond six months, a monthly risk update may be sufficient. The project manager and stakeholders should make this decision and the project manager should document it in the communication plan.

How Should the Project Risk Information Be Communicated?

Graphs and charts are the best ways to communicate project risk information. In addition, the risk register maintained in a spreadsheet and the current version of schedule in MS Project format may be more than sufficient for the purpose. A graph that shows the total EMV and # of risks at different points of time may prove very valuable, and an example of such a graph is provided in Exhibit 4.

Risk Behavior Over Time

Exhibit 4: Risk Behavior Over Time

This type of graph is very helpful for sponsors and senior executives to understand the risk impact and its behavior over time. As the project progresses if the two lines show a downward trend that would be an indication the project risks are being managed effectively and project is likely to meet milestones of time and cost. If the two lines, especially the blue total EMV line, show unstable trends with several ups and downs or an upward trend, it would indicate ineffective risk management, which may lead to the project getting off the rails at some point of time. The power of the graph lies in the advance warnings that it provides about possible delays, overruns, and failures.

Conclusion

Project risk management is yet another tool in a project manager's toolkit. A project manager can employ this tool to improve the predictability of completing his/her project on time and within budget. This predictability will help project managers develop stronger relationships with sponsors, stakeholders, and team members as he or she regularly communicates risks information using graphs and charts—a language well understood by senior management/ executives in a company.

Research of failed software projects shows that their problems could have been avoided or significantly reduced if there had been an explicit early concern with identifying and resolving their high-risk elements. Effective risk management is the most important management tool a project manager can employ to increase the likelihood of project success. Since risk management is not widely used and understood, this could be a significant competitive advantage to those that implement the risk management processes in their projects (Kwak & Stoddard, 2004).

Project managers and organizations can get substantial benefits by utilizing the correct level of risk management for their projects. If practiced correctly, risk management can ensure predictability and save projects from failing.

Appendix A: Risk Register during Monitoring and Control Process

img

References

Columbia disaster. (2012). The History Channel website. Retrieved from http://www.history.com/topics/columbia-disaster

Kwak, Y. H., & Stoddard, J. (2004). Project risk management: Lessons learned from software development environment. Technovation, 24(11), 915–920.

Project Management Institute. (2008). A guide to the project management body of knowledge (PMBOK@ Guide) (4th ed.). Newtown Square, PA: Project Management Institute.

Project Management Institute. (2009). Practice standard for project risk management. Newtown Square, PA:

Project Management Institute.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2012, Narendra K Shrivastava, PMP, RMP, ACP
Originally published as a part of 2012 PMI Global Congress Proceedings – Vancouver, BC, Canada

Advertisement

Advertisement

Related Content

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.