Risk Management

Projects are, by their nature, unique. In fact, A Guide to the Project Management Body of Knowledge (PMBOK® Guide) says that a project is "a temporary endeavor undertaken to create a unique product, service, or result."1 So in that uniqueness is uncertainty and with that uncertainty, risk. If you think about it, pretty much everything on a project is risky including availability of resources, estimates for both cost and time, procurement lead times and requirements. So if there is that much risk and uncertainty on a project, it behooves us to manage that risk, to anticipate the negative risks (threats) and look for positive risks (opportunities).

In the PMBOK® Guide, the Project Management Institute (PMI)® details six processes that must be performed in order to accomplish a viable risk analysis. This article will present a brief summary of those processes. For sake of brevity we will focus on threats. But know that it is very important to look for opportunities and try to make them happen.

Plan Risk Management

It is an axiom of the PMBOK® Guide that one should plan thoroughly for the project before executing. This is especially true in regards to risk, as the risk management plan establishes key information needed to perform the subsequent processes. A partial list of some of the items covered in this plan would be:

• Budget, including contingency and management reserves
• Risk categories
• Stakeholder risk tolerances
• Definitions of risk probability and impact

Of the preceding, arguably the most important is in establishment of risk probability and impact scales. You first establish these scales and then later use them to evaluate and prioritize each individual risk. Typically it's easy to establish probability. You might agree that a scale of, for instance, 30%, 50% 70% and 90% probability is sufficient. (If you go to 100%, it's no longer a probability, it's a fact).

More challenging is to establish an impact scale. You and your team have to decide which project objectives (or constraints) would be most impacted by risk. Typically, teams will use the triple constraint of cost, scope and time.

So for example, you might decide (keeping it simple) that an impact of .05 means no real impact, .20 means project delayed by 10%, .80 means project delayed by 40%. You'll also determine threshold scores for high, medium, and low risk. We'll see exactly how all these factors get considered later on.

Identify Risks

While the preceding process was intended to govern the creation of the risk management plan, the purpose of 'Identify Risks' is just that - to identify as many threats as the project team can articulate. In fact, it's not just the project team doing this. The identification may also be performed by sponsor, consultants and even in some cases, customers. In this process, no team is broad enough and no stone (or document) should be left unturned. Everything from schedule to work breakdown structure to estimates should be examined for possible risk.

The team can do this by using techniques from brainstorming, to Delphi, to SWOT analysis. In the Delphi technique, anonymous input is requested which helps to reduce bias. SWOT (strengths, weaknesses, opportunities, threats) analysis allows the team to look at risk in context of not only the specific project but also the organization. So if, for example, you needed three contractors and your organization had a hiring freeze, that organizational reality most assuredly impacts your project. Or the very fact that perhaps your organization does not have strong project management processes will have an impact.

As a result of these analyses, the beginnings of a risk register can be formed. The register - often in the form of a spreadsheet - is at this point only a list of possible threats that are not yet ranked. The exercise here is not to figure out what to do about them or which ones to react to. The goal here is just to create a list. If you stop to try to plan how to deal with each risk, it's possible not only that you will get sidetracked from your mission but even conceivably plan responses to risks that are not very impactful to your project.

Here's an example: Let's imagine we have a project to build a machine for a manufacturing plant, and so of course it requires parts. To keep it simple, imagine we've identified three risks thusly: 1) Delay in receiving parts; 2) Parts not correct and 3) Design defect. (You would find quite a few more in a real risk exercise but this should suffice for our purposes). At this point our job is just to create a catalogue of those risks with some possible initial actions (called response) that we might execute if they happen. But this is just a list. It is not until the next process that we prioritize those risks.

Perform Qualitative Risk Analysis

As mentioned, this is where we decide on which risks have the highest priority and rank them, in this case, from 1 to 3. Clearly we will deal quite differently with the highest ranked risks than we will with the lowest ones.

So how do we accomplish this ranking? Well, in what may seem to be (and is) a somewhat subjective exercise, the team decides what the probability is of each risk happening and its impact if it does. But what reduces the pure subjectivity of this exercise is that it is not performed by the man-on-the-street but by experts well-versed in the discipline. So if the risk involves design, the person or persons with expertise in that area should perform the assessment. The project manager owns the risks overall and can override the expert decision as he or she sees fit. Let's look at an example of how we might do this using the risks above.

Firstly we would establish a probability/impact (P/I) matrix. This is simply a grid with four quadrants which can easily be created on a flip chart. The top right quadrant is for the high probability/high impact risks; the bottom left quadrant is for the low probability/low impact risks. After you've gotten the assessments from the experts, you put each risk on a Post-It® note and place it in the appropriate quadrant on the P/I matrix. So let's say the experts do this and we ascertain the following results:

• Parts not correct; .50 probability of occurring, .80 impact. Score (P*I) - .40
• Delay in receiving parts; .30 probability, .40 impact. Score - .12
• Design Defect; .10 probability, .05 impact. Score - .01

So what have we accomplished? Well, we've prioritized the risks! Remember our thresholds from the risk management plan for high, medium and low ranges? Clearly that risk of 0.40 is of somewhat greater concern than that of .12 or for that matter, .01. How will we treat these risks? According to the PMBOK® Guide, the highest risks "may require priority action and aggressive response strategies."² In other words, these are the ones that have the highest potential negative impact and so are where we must focus our energies. But do we ignore the others? Of course not.

Threats in the low-risk area can be documented in the risk register and are considered part of the watch list. They can be accepted (more on that in Plan Responses) or have contingency reserves set aside for them. The PMBOK® Guide makes no statement about those risks in the mid-zone but one can imagine these can be dealt with either by contingency reserves or by close monitoring.

Quantitative Risk Analysis

Basically this is a numerical analysis of the prioritized risks that may most substantially impact the project's objectives. However, of the various risk processes, this one can be considered the most optional. Typically, there may not be enough data to make the calculations, and often specialized software is required to run these analyses.

There are four possible main techniques that can be used here:

• Expected Monetary Value - Multiplying the probability of each risk by its impact in dollars (or days). This can be used to create contingency reserves for the project.
• Decision Tree Analysis - A technique for decision making which incorporates probability.
• Sensitivity Analysis - A method of determining which risks have the most impact on a project as measured by some objective of interest (e.g. raising or lowering of project costs). It is manifested as a Tornado Diagram.
• Monte Carlo Simulation - Simulation of the project multiple times to ascertain the probability of achieving specific targets.

As a result of these analyses, the risks may be re-ranked.

Plan Risk Responses

So now that you've identified, prioritized, and (perhaps) numerically analyzed the risks, what's left to do? You need to decide what you would do if and when these risks occur. In the PMBOK® Guide, there are four possible responses to threats: avoid, transfer, mitigate and accept. Let's look at each of these in turn

• Avoid - In this case, the team seeks to eliminate the threat entirely or protect the project from its impact. If, for example, you knew that Rev 2.0 of your software was buggy, you might take it out of the project management plan and replace it with Rev 1.0. Perhaps not forever but maybe for the short term. So you've driven the threat to having a zero percent chance of affecting your project. PMI says that the most radical avoidance is to shut down the project entirely.
• Transfer = The risk and ownership of the response are shifted to a third party. Very often this is used for transferring cost risk. Insurance and warranties are common as are performance bonds. As an example of the latter, let's assume an agency sends a contractor on site to do some work. Under the terms of his performance bond, if he or she fails to deliver, the agency has to pay a penalty. Contracts are often used to transfer risk.
• Mitigate -Acting to reduce the probability of risk occurrence and/or impact if it does occur. For example, if there is a fairly high probability that a key resource might leave the team, we might incentivize him or her to stay. But since mitigation does not drive the probability to zero, there is still some probability - however reduced - that he or she might leave. So in order to reduce the impact should we lose him or her anyway, we might further reduce risk by having a more junior resource shadow him or her. So in this way we've reduced both the probability of it happening and the impact if it does.
• Accept - This strategy is usually employed for low-risk items. There are two kinds: passive and active. In passive acceptance, nothing is done other than to document the risk and monitor it. If it happens, it happens. Active acceptance means that we might set aside contingencies of time or money. We still have done nothing to prevent its occurrence. But now at least we are prepared should it occur.

Control Risks

At this point, we can utilize the fully populated risk register at our regular status meetings. By now, everyone on the team should be attuned to risk and as part of this process, be encouraged to identify new risks as and if they occur. Risk owners, acting on the project manager's behalf, will monitor specific risks and perform the response should the risk occur. During this process we should also evaluate how effective risk responses have been. If any risks occur that had not been previously identified or were accepted passively, then a workaround, a quick short-term solution, will need to be performed.

Conclusion

This concludes our discussion on risk management. Using the above tools and techniques will not make your project entirely risk-free. That is impossible. But it will allow you to account for the uncertainties that crop up in every project, increasing the likelihood of success and ultimately, customer satisfaction.

1. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) - Fifth Edition, Project Management Institute Inc., 2013, Page 4 ^

2. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) - Fifth Edition, Project Management Institute Inc., 2013, Page 332 ^