The Essentials of Effective Project Risk Assessments

Project leaders can use various tools and methodologies to help measure risks. One option is a failure mode and effects analysis. Other options include a finite element analysis or a factor analysis and information risk.

These are some common risk assessment tools:

• Failure Mode and Effects Analysis (FMEA):This analytical method helps project leaders evaluate a process and identify where the process might fail. The method helps teams identify the failures that could cause the largest impact. By performing this analysis, teams can determine parts of the process that need adjustment.
  
  When using the FMEA framework for risk assessment, identify each of the following components:
  • Process Steps:Identify all steps in a process.
  • Potential Problems:Identify what could go wrong with each step.
  • Problem Sources:Identify the causes of the problem.
  • Potential Consequences:Identify the consequences of the problem or failure.
  • Solutions:Identify ways to prevent the problem from happening.
• Finite Element Analysis (FEA):This is a computerized method for simulating and analyzing the forces on a structure and the ways that a structure could break. The method can account for many, sometimes thousands, of elements. Computer analysis then determines how each of those elements works and how often the elements won’t work. The analysis for each element is then added together to determine all possible failures and the rate of failure for the entire product.
• Factor Analysis of Information Risk (FAIR):This framework helps teams analyze risks to information data or cybersecurity risk.

Bring your team together to identify all potential risks to your project. Here are some common ways to help identify risks, with tips from experts:

• Review Documents:Review all documents associated with the project.
• Consider Industry-Specific Risks:Use riskprompt listsfor your industry. Risk prompt lists are broad categories of risks, such as environmental or legal, that can occur in a project.
• Revisit Previous Projects:Use checklists from similar projects your organization has done in the past.
  
  “What I like to do for specific types of projects is put together a checklist, a taxonomy of old risks that you've identified in other projects from lessons learned,” says Wendy Romeu, President and CEO ofAlluvionic. “Say you have a software development program. You would pull up your template that includes all the risks that you realized in other projects and go through that list of questions. Then you would ask: ‘Do these risks apply to our project?’ That's kind of a starting point.”
  
  “You do that with your core project team,” Romeu says, “and it gets their juices flowing.”
  
  Learn more about properly assessing lessons learned at the end of a project in thiscomprehensive guide to project management lessons learned.
• Consult Experts:Conduct interviews with experts within and, in some cases, outside your organization.
• Brainstorm:Brainstorm ideas with your team. “The best scenario, which doesn't usually happen, is the whole team comes together and identifies the risks,” says Romeu.
• Stick to Major Risks:Don’t try to identify an unrealistic or unwieldy number of risks. “You want to identify possible risks, but you want to keep the numbers manageable,” says Wills. “The more risks you identify, the longer you spend analyzing them. And the longer you’re in analysis, the fewer decisions you make.”
• Look for Positive Risks:Identify both positive risks and negative ones. It’s easy to forget that risks aren’t all negative. There can be unexpected positive events as well. Some people call theseopportunities, but in a risk assessment, experts call them positive risks.
  
  “A risk is a future event that has a likelihood of occurrence and an impact,” says Alan Zucker, founding principal ofProject Management Essentials, who has more than two decades of experience managing projects in Fortune 100 companies. “Risks can both be opportunities — good things — and threats. Most people, when they think about risk assessment, they always think about the negatives. I really try to stress on people to think about the opportunities as well.”
  
  Opportunities, or positive risks, might include your team doing great work on a project and a client wanting the team to do more work. Positive risks might include a project moving forward more quickly than planned or costing less money than planned. You’ll want to know how to respond in those situations, Zucker says.
  
  Learn more about project risk identification and find more tips from experts in this guide to project risk identification.

After your team has identified possible risks, you will want to determine the probability of each risk happening. Your team can make educated guesses using some of the same methods it used to identify those risks.

Determine the probability of each identified risk with these tactics:

• Brainstorm with your team.
• Interview experts.
• Review similar past projects.
• Review other projects in the same industry.

Your team will then determine the impact of each risk should it occur. Would the risk stop the project entirely or stop the development of a product? Or would the risk occurring have a relatively minor impact?

Assessing impact is important because if it’s a positive risk, Romeu says, “You want to make sure you’re doing the things to make it happen. Whereas if it's a high risk and a negative situation, you want to do the things to make sure it doesn't happen.”

There are two ways to measure impact: qualitative and quantitative. “Are we going to do just a qualitative risk assessment, where we're talking about the likelihood and the probability or the urgency of that risk?” asks Zucker. “Or are we going to do a quantitative risk assessment, where we're putting a dollar figure or a time figure to those risks?”

Most often, a team will analyze and measure risk based on qualitative impact. The team will analyze risk based on a qualitative description of what could happen, such as a project being delayed or failing. The team may judge that impact as significant but won’t put a dollar figure on it.

A quantitative risk assessment, on the other hand, estimates the impact in numbers, often measured in dollars or profits lost, should a risk happen. “Typically, for most projects, we don’t do a quantitative risk assessment,” Zucker says. “It’s usually when we’re doing engineering projects or big, federal projects. That’s where we're doing the quantitative.”

Once your team assesses possible risks, along with the risk probability and impact, it’s time to determine a risk score for each potential event. This score allows your organization to understand the risks that need the most attention.

Often, teams will use asimple risk matrixto determine that risk score. Your team will assign a score based on the probability of each risk event. It will then assign a second score based on the impact that event would have on the organization. Those two figures multiplied will give you each event or risk a risk score.

Zucker says he prefers to assign the numbers 1, 5, and 10 — for low, medium, and high — to both the likelihood of an event happening and its impact. In that scenario, an event with a low likelihood of happening (level of 1) and low impact (level of 1) would have a total risk score of 1 (1 multiplied by 1). An event with a high likelihood of happening (level of 10) and a large impact (level of 10) would have a total risk score of 100.

Zucker says he prefers using those numbers because a scale as small as one to three doesn't convey the importance of high-probability and high-impact risks. “A nine doesn't feel that bad,” he says. “But if it's 100, it's like, ‘Whoa, I really need to worry about that thing.’”

While these risk matrices use numbers, they are not really quantitative. Your teams are making qualitative judgments on events and assigning a rough score. In some cases, however, teams can determine a quantitative risk score.

您的团队可能会决定,根据以往的项目or other information, that an event has a 10 percent chance of happening. For example, if that event will diminish your manufacturing plant’s production capacity by 50 percent for one month, your team might determine that it will cost your company $400,000. In that case, the risk would have a risk score of $40,000.

At the same time, another event might have a 40 percent chance of happening. Your team might determine the cost to the business would be $10,000. In that case, the risk score is $4,000.

“Just simple counts start to give you a quantifiable way of looking at risk,” says Wills. “A risk that is going to delay 10 percent of your production capacity is a different kind of risk than one that will delay 50 percent of it. Because you have a number, you can gather real operational data for a week or two and see how things support the argument. You can start to compare apples to apples, not apples to fish.”

遗嘱补充说,“人类,非常乐观和内涵rible at predicting the future, will say, ‘Oh, I don't think it'll happen very often.’ Quantitative techniques help to get you away from this gambler fallacy kind of approach. They can make or break your argument to a stakeholder that says, ‘I've looked at this, and I can explain mechanically, count by the numbers like an accountant, what's going on and what might go wrong.’”

As your team considers risks, it must understand the organization’s risk tolerance. Your team should know what kinds of risks that organizational leaders and stakeholders are willing to take to see a project through.

Understanding that tolerance will also help your team decide how and where to invest time and resources in order to prevent certain negative events.

Once your team has determined the risk score for each risk, it will see which potential risks need the most attention. These are risks that are high impact and that your organization will want to work hard to prevent.

“You want to attack the ones that are high impact and high likelihood first,” says Romeu.

“Some projects are just so vital to what you do and how you do it that you cannot tolerate the risk of derailment or major failure,” says Wills. “So you're willing to spend money, time, and effort to contain that risk. On other projects, you're taking a flier. You're willing to lose a little money, lose a little effort.”

“You have to decide, based on your project, based on your organization, the markets you're in, is that an ‘oh my gosh, it's gonna keep me up every night’ kind of strategic risk? Or is it one you can deal with?” he says.

Once your team has assessed all possible risks and ranked them by importance, you will want to dive deeper into risk response strategies. That plan should include ways to respond to both positive and negative risks.

These are the main strategies for responding to threats or negative risks:

• Mitigate:你会采取这些行动减少lihood of a risk event happening or that will reduce the impact if it does happen. “For example, if you’re building a datacenter, we might have backup power generators to mitigate the likelihood or the impact of a power loss,” says Zucker. You can learn more, including more tips from experts, about project risk mitigation.
• Avoid:If a certain action, new product, or new service carries an unacceptably high risk, you might want to avoid it entirely.
• Transfer:The most common way that organizations transfer risk is by buying insurance. A common example is fire insurance for a building. Another is cybersecurity insurance that would cover your company in the event of a data breach. An additional option is to transfer certain risks to other companies that can do the work and assume its risks for your company.
  
  “It could be if you didn't want to have the risk of running a datacenter anymore, you transfer that risk to Jeff Bezos (Amazon Web Services) or to Google or whoever,” Zucker says.

These are the main strategies for responding to opportunities or positive risks:

• Share:Your company might partner with another company to work together on achieving an opportunity, and then share in the benefits.
• Exploit:Your company and team work hard to make sure an event happens because it will benefit your company.
• Enhance:Your company works to improve the likelihood of something happening, with the understanding that it might not happen.

These are the main strategies for responding to both threats and opportunities, or negative and positive risks:

• Accept:Your company simply accepts that a risk might happen but continues on because the benefits of the action are significant.
  
  “You're not ignoring the risks, but you're saying, ‘I can't do anything practical about them,’” says Wills. “So they're there. But I'm not going to spend gray matter driving myself crazy thinking about them.”
• Escalate:This is when a project manager sees a risk as exceptionally high, impactful, and beyond their purview. The project manager should then escalate information about the risk to company leaders. They can then help decide what needs to happen.
  
  “Some project managers seem almost fearful about communicating risks to organization leaders,” Romeu says. “It drives me nuts. It's about communicating at the right level to the right people. At the executive level, it’s about communicating what risks are happening and what the impact of those risks are. If they happen, everybody knows what the plan is. And people aren't taken by surprise.”

Your team will want to understand how viable your organization’s risk plans are. That means you might want to monitor how they might work or how to test them.

A common example might be all-hands desktop exercises on a disaster plan. For example, how will a hospital respond to a power failure or earthquake? It’s like a fire drill, Zucker says. “Did we have a plan? Do people know what to do when the risk event occurs?”

Your team will want to continually assess risks to the project. This step should happen throughout your project, from project planning to execution to closeout.

Zucker explains that the biggest mistake teams tend to make with project risk assessment: “People think it's a one-and-done event. They say, ‘I’ve put together my risk register, we’ve filed it into the documents that we needed to file, and I'm not worrying about it.’ I think that is probably the most common issue: that people don't keep it up. They don't think about it.”

Not thinking about how risks change and evolve throughout a project means project leaders won’t be ready for something when it happens. That’s why doing continual risk assessment as a primary part of risk management is vital, says Wills.

“Risk management is a process that should start before you start doing that activity. As you have that second dream about doing that project, start thinking about risk management,” he says. “And when you have completely retired that thing — you've shut down the business, you've pensioned everybody off, you’re clipping your coupons and working on your backstroke — that's when you're done with risk management. It's just a living, breathing, ongoing thing.”

专家说,项目经理必须学会发展a sense for always assessing and monitoring risk. “As a PM, you should, in every single meeting you have, listen for risks,” Romeu says. “A technical person might say, ‘Well, this is going to be difficult because of X or Y or Z.’ That's a risk. They don't understand that's a risk, but as a PM, you should be aware of that.”

After your project is finished, your team should come together to identify the lessons learned during the project. Create a lessons learned document for future use. Include information about project risks in the discussion and the final document.

By keeping track of risks in a lessons learned document, you allow future leaders of similar projects to learn from your successes and failures. As a result, they can better understand the risks that could affect their project.

“Those lessons learned should feed back into the system — back into that original risk checklist,” Romeu says. “So the next software development project knows to look at these risks that you found.”