What is risk management in project management?

Risk management exists with one purpose — to maximize the chances of project success.

In project management, this is done by identifying risks, analyzing them, and creating response plans for each one.

If done correctly, you have the upper hand even when a risk materializes. And, if every risk is accounted for, then nothing can catch you unawares and hinder project completion.

So, despite the fact that 40% of project managers don’t regularly conduct risk management, this is a process that should be part of every project.

In this guide, we’ll walk you through a 5-step process that will help you implement risk management practices into your projects. After that, we’ll provide you with some tips on how to analyze your risk management plan upon project completion, so that all subsequent projects can benefit from it.

But before we can talk about managing risks, we first have to establish what exactly risk is in project management.

What is risk in project management?

According to PMI’s PMBOK (Project Management Body of Knowledge), a risk is a “situation or condition that, if it occurs, has a positive or negative impact on project objectives.”

Obviously, the difference between the everyday definition of risk and the project management definition of risk is that the latter pertains to projects specifically. 

However, this isn’t the only difference, as the latter definition also encompasses the so-called positive risks. 

For example, if the project is to create and furnish a company office, a crypto crash resulting in the normalization of hardware prices would still be defined as a risk, despite the fact that its impact — your ability to procure office computers at better prices — would be positive. 

To avoid ambiguity, the umbrella term risk encompasses opportunities and threats.

Opportunities are positive risks, whereas threats are negative risks. On top of this, a negative risk that occurred is referred to as an issue.

So that we can all remain on the same page, it’s imperative we follow the above-said definition of risk whenever we refer to it throughout this guide. This can be slightly confusing at first, but it doesn’t take long to adjust.

After all, if we can accept that the Force in Star Wars isn’t an equation denoting the mass of an object multiplied by its acceleration, but rather a mystical cosmic energy that gives Jedi superpowers, then we should be able to distinguish between the everyday definition of risk as “a situation involving exposure to danger” and the more nuanced definition of risk in project management outlined above.

Risk management process

The following risk management process is a tried and tested 5-step solution to keeping your projects on track. The steps to managing risks include:

• Identifying,
• Analyzing,
• Assigning,
• Monitoring, and
• Responding to risk.

Identifying the risks 🔍

The first step in any risk management plan is always to identify the risks. 

This can be done in many ways. 

Usually, you start by brainstorming possible risks. 

Feel free to include your team, stakeholders, and even outside experts in this process. 

Exercise openness and inclusivity — so that even newer or shyer team members feel comfortable sharing their thoughts and opinions.

Enter all the identified risks into a risk register — this is a list used for tracking all potential risks for an ongoing project. 

Many companies also run so-called risk repositories — compendiums of all the risks identified across all projects carried out by the company.

Keeping a risk repository helps out with risk identification tremendously, especially if the new project shares a lot of similarities with one of the older ones. 

This can give you a head start, as you’ll already know what to expect going into new but familiar projects.

While identifying risks, you should also know the difference between risks and impacts.

Risk vs impact

It is impossible to manage risk if you can’t pinpoint what risk is in practice. 

And it just so happens that mistaking the impact of risk for risk itself is a very common problem for inexperienced project managers.

To give an example, let’s say your project objective is to create and maintain a social network.

This entails dealing with confidential information. 

Potential leakage of said confidential information can cause great damage to the company and brand. 

But this PR nightmare isn’t the risk — it’s the impact the risk will have if it occurs. 

In this case, the risk is the leakage of confidential information. 

A risk response to this may be the implementation of tighter procedures and safety measures to prevent the risk from happening.

Risk response plans have to take the risk into account in order to prevent or minimize its impact.

Therefore, whether or not you can identify the risk correctly will directly affect your ability to plan for said risk.

Analyzing the risks 📊

Once the risks are identified, it’s time to analyze them. Risk analysis is divided into qualitative and quantitative analysis, both of which have their pros and cons. 

This step also includes prioritizing the risks and creating response plans for them.

Performing qualitative risk analysis

Qualitative analysis is done by evaluating the severity of the impact potential risks could have, along with the likelihood of these risks occurring. 

Given that you only need to account for these two axes (likelihood and severity), qualitative analysis is often represented in the form of a table known as the risk assessment matrix.

Risk assessment matrices are great for helping you decide how to prioritize risks — more on this later. 

It’s up to you to decide how many rows and columns you wish to divide these axes into.

Provided below is one example where both the likelihood and severity are divided into three parts:

Severity:

• Catastrophic
• Manageable
• Negligable

Likelihood:

• All but guaranteed
• Likely
• Not likely

The more potential risks for your project, the more benefit there is in creating a comprehensive risk assessment matrix.

Regardless of the size of the matrix, once you have it, you can determine where each risk slots into. 

It’s not uncommon for a project to come under fire from several risks at once — so knowing which risks to prioritize can be a great asset.

Performing quantitative risk analysis

The quantitative analysis takes a much more scientific approach to risk analysis by using empirical data to arrive at accurate predictions. 

With qualitative analysis, you rely on guesswork, more than anything else, to derive the likelihood and severity metrics for each potential risk. 

These may be educated guesses — but they’re guesses nonetheless.

The quantitative analysis takes actual data to predict the severity of the impact of certain risks and their chances of happening. 

With quantitative analysis, you can get tangible, numerical answers to questions such as: 

• How much will this risk affect the budget, timeline, scope, or resources of a given project? 

Getting these tangible numbers in terms of risk impacts, instead of vague descriptors like highly probable, catastrophic, inconsequential, and so on, is the biggest advantage of quantitative risk analysis.

The downside to quantitative analysis is twofold: data requirement and complexity.

The data requirement for quantitative analysis

Before you can do your thorough analysis of data on a project, you first need to acquire said data. 

This is easily done when your current project shares a lot of similarities with previous projects.

After all, the relevant data is all contained in old documentation and the risk repository. 

But if you’re embarking on a project that is unlike anything the company has ever done before, then you won’t have enough data to do proper quantitative analysis.

➕ The complexity of quantitative analysis

The concept of diminishing returns is integral to understanding why many project managers still opt for qualitative analysis — even when they have sufficient data for quantitative analysis. 

If something requires twice the effort but only yields a 10% improvement, then it’s simply not worth the effort in most cases. This decision is made on a risk-by-risk basis. Sometimes, the extra effort is worth it, but not always.

This is because quantitative data analysis is complex to the point where it often demands the use of specific software to compute. 

If the ballpark approximations of qualitative risk analysis are good enough, then quantitative analysis requires more time, effort, and/or money than it’s worth.

Prioritizing risks

The risk assessment matrix should already make it clear that not all risks are “born” equal.

Taking the likelihood and the severity of risks into the equation, you have to decide on the priority level for each. 

In addition to the risk assessment matrix, you should also keep risk appetite, risk tolerance, and risk threshold in mind when prioritizing.

➕ Risk appetite

Risk appetite refers to the amount of risk the organization is willing to expose itself to in pursuit of its goals. 

An organization that is unwilling to take any risks is unable to grow, whereas one that takes any and all risks with reckless abandon is doomed to fail. 

Project managers need to weigh the organization’s risk appetite against their project objectives and resources to determine whether to move forward or not. 

➕ Risk tolerance

Risk tolerance is often used interchangeably with risk appetite, and for good reason — they are confusingly similar. 

So to dispel the confusion, we’ll use a simple stretching analogy to highlight the difference. 

If you’re stretching for flexibility and other health reasons, you are required to expose your muscles and joints to some pain and discomfort — otherwise, you may as well not be doing anything. 

This is your risk appetite — you’re exposing yourself to some risk (pain) that’s necessary to the pursuit of your goal (flexibility). 

But expose yourself to too much pain and you may cause unwanted damage to your muscles and/or joints. 

Your risk tolerance is the level above which you refuse to expose yourself to any further risk. 

You can think of it as the uppermost limit of your risk appetite. 

We called it a limit and not a threshold — because risk threshold is yet another potentially confusing but completely separate term.

➕ Risk threshold

Risk threshold refers to the level of risk exposure that spurs the organization into action. 

Risks below the threshold are, in most cases, simply accepted. 

When a risk crosses the threshold, it must be addressed. 

In other words, the difference between risk tolerance and risk threshold is that the former represents a limit beyond which you are unwilling to take risks whereas the latter represents a limit beyond which you have to address risks.

Establishing a risk appetite, risk tolerance, and risk threshold can help you meet your project objectives by informing you whether: 

• Your goals are worth pursuing (risk appetite), 
• When you have to stop pursuing your goals (risk tolerance), and 
• When you should respond to risks arising from this pursuit (risk threshold). 

All of this information can help you prioritize risks and strengthen your risk management plan.

Preparing to respond to risks

Regardless of whether you use qualitative or quantitative analysis to determine the threat level of risks and prioritize them, you need to create a response plan to account for each risk.

How detailed or general you want to be with this comes down to the risks and projects in question.

For example, it’s taken for granted that unwanted bugs will constitute a risk that is both highly likely to occur and bears great severity on the overall quality of software-related products. 

One risk response plan for dealing with bugs might be to tighten quality assurance and introduce new procedures — whereas another might be to expand the QA team.

Another potential risk might be uncertainty surrounding vendors and their ability to procure parts, materials, and other resources needed for project completion. 

Any delay, shortage, or price inflation on their end can influence the budget, timeline, scope, and/or quality of the project.

In this case, the risk response plan may include:

• Additional budget allocation, 
• Redundancy, 
• Guarantee or punishment clauses in the contract with the vendor, or 
• Having different vendors on stand-by.

It’s also helpful to determine what constitutes the risk trigger for each risk. 

Risk triggers are indicators that potential risks have either turned into issues or are about to.

Risks that score higher on the risk assessment matrix naturally warrant more detailed response plans — but this ultimately comes down to the project manager in charge.

We’ll go more in-depth on risk response plans in the final step of this risk management process.

Assigning the risks 📋

At the end of the day, the project manager is the one bearing accountability for the project as a whole. 

However, more often than not, the project manager is not the one actively monitoring all potential risks. 

Instead, what they do is assign risks to different team members to monitor.

In most cases, team members have risks assigned to them based on their roles and responsibilities.

If shipment delays are a potential risk, then the person who maintains contact with the shipping company is assigned to that risk. They will monitor the situation for risk triggers and report any changes to the project manager. 

The same goes with the team members who do maintenance or operate equipment getting assigned to the potential risk of equipment malfunction.

By assigning risks to team members, project managers can focus on more pressing matters while at the same time keeping a fresh pair of eyes on the status of each risk. 

This ensures that the team can assume a more proactive approach towards project completion.

Assigning risks isn’t necessarily an integral step of the risk management process — you can erase it and call this a 4-step risk management process. 

That being said, it’s still a step that’s highly advised.

Monitoring the risks 👁️

You’d think that once the project is underway and the risks have already been identified, analyzed, and assigned to different team members, the only thing left would be to monitor them for risk triggers and respond accordingly. 

This is the truth — but it’s not the whole truth.

It goes without saying that monitoring and responding to risks is an ongoing process that spans the entire project timelin. However, now is the best time to note that the first three steps in the risk management process should also be continuous. 

In other words, risk identification and subsequent risk analysis is something that the project team should revisit periodically.

Responding to the risks ☎️

If everything else has been done correctly, then the last step — responding to risks that have occurred, i.e. issues — should be smooth sailing.

The whole point of having a risk management plan is to allow the team to assume a proactive approach towards both preventing negative risks, dealing with issues that could not be prevented, and capitalizing on positive risks.

According to PMBOK, there are four responses you can have to both negative and positive risks.

Negative risk responses 📉

When creating a response plan for each negative risk during the analyzing step of the risk management process, it helps to know which category to place each risk into. 

We’ve elected to keep referring to threats as negative risks to keep this guide beginner-friendly.

Negative risk responses include:

• Avoiding, 
• Transferring, 
• Mitigating, or 
• Accepting the risk.

➕ Avoiding the negative risks

Avoiding the risk isn’t as elegant a response plan as it may sound. 

In many cases, avoiding the risk means shutting the project down because it exceeds your risk tolerance. 

For example, while this information was never publicly disclosed, many speculate that Google Glass — the glasses-shaped android device that used the lens as a display — was discontinued shortly after its release to avoid risk. 

Why might this be such a popular theory? 

Well, as it turns out, Google Glass proved incredibly contentious with regards to privacy laws and regulations. Even before the product was discontinued, its use had been banned in many places, including theaters, concerts, schools, vehicles, banks, ATMs, and casinos, just to name a few. 

In other words, the risk posed by potential legal repercussions was not worth bearing. Having exceeded the company’s risk tolerance, Google elected to avoid any further risks entirely by shutting the project down.

➕ Transfering the negative risks

Transferring the risk is a response plan that seeks to mitigate risks that stem from third parties by means of:

• Contractual obligations, 
• Insurances, 
• Guarantees, and/or 
• Penalties. 

For example, shipping delays that can lead to your product not hitting the shelves on its release date constitute a risk that most would rank highly on the risk assessment matrix. 

To prevent this, organizations will often impose contractual penalties on shipping companies in case of delays.

Transferring may not be the most appropriate name, as your project will still suffer if things go awry. 

But, the penalties serve as a response plan intended to minimize the chance of threats becoming issues.

➕ Mitigating the negative risks

Mitigating the risk means taking precautions to minimize the probability of risk occurrence for risks that cannot be transferred. 

For example, if workflow bottlenecking caused by equipment malfunction is a risk, one way to mitigate it would be by increasing the frequency of equipment maintenance. 

The equipment may still malfunction — but you’ve taken precautions to minimize the chance of this happening.

➕ Accepting the negative risks

Accepting the risk is a viable strategy. For risks that rank lowly on the risk assessment matrix, accepting the risk is sometimes the only response. 

It entails doing nothing to minimize the chances of the risk happening. 

That being said, we still differentiate between active and passive risk acceptance. 

Active risk acceptance means taking actions to minimize the impact of risks.

Passive risk acceptance means taking no actions aside from documentation. 

The simplest example of risk acceptance is in relation to natural disasters. 

Unless you’ve got the power to control the weather, you can’t hope to prevent a storm or a flood.

Nevertheless, you can still prepare to minimize the consequences of these or any other events on your project outcomes. 

And in the equipment malfunction example, actively accepting the risk may mean having redundant equipment on stand-by.

Positive risk responses 📈

We’ve placed a much higher emphasis on negative risks than positive ones throughout this guide — but it bears noting that responses to positive risks can also be divided into four categories :

• Exploit, 
• Enhance, 
• Share, and 
• Accept.

➕ Exploiting the positive risks

Exploiting the risk means making active efforts to bring the likelihood of the risk occurring as close to 100% as you can. 

If the positive risk is a substantial bonus for completing the project early, exploiting the risk may mean diverting other resources into this project to guarantee this happens.

➕ Enhancing the positive risks

Enhancing the risk is a less aggressive approach to exploiting it. 

You make some efforts to increase the likelihood of the risk occurring — but you don’t pursue it to an exploitative extent. 

For example, motivating the team to put in some extra work with a bonus increases your chances of positive risk occurrence, but it’s far from a guarantee.

➕ Sharing the positive risks

Sharing the risk entails getting a third party in on the action — usually because you are unable to seize the opportunity without them. A common example includes companies partnering together to bid for a project they would otherwise be unable to land on their own.

➕ Accepting the positive risks

Accepting the positive risk simply means acknowledging it — but not taking any effort to increase its chances of happening. 

If it happens, that’s great; if it doesn’t, no harm done.

Risk management analysis

Not to be confused with qualitative or quantitative risk analysis, risk management analysis is a process we advise you to do upon finishing each project — either successfully or unsuccessfully.

This entails taking a critical look at the risk register of the newly concluded project and scoring the accuracy of your risk management predictions. 

You do this by noting how many risks you’ve successfully managed to identify, along with the risks that managed to slip by. 

You should also compare to which extent you’ve managed to predict the severity of the impact the issues that have occurred had on the project. 

If you can count the number of times certain repeatable risks occurred — such as equipment malfunction — that’s also something you should note down.

Filling the company’s risk repository with this information will not only bring you that much closer to being able to conduct or improve quantitative analysis, but it will also give you guidance on improving the accuracy of your qualitative analysis with similar future projects. 

Conclusion: Risk management is paramount to increasing project success rates

Risk management is one of the most important hard skills for project managers to master. This is because risks are all but a certainty in project management. The projects that effectively account for everything that can go wrong are the ones most likely to succeed.

With this guide in hand, you have all the knowledge needed to create a risk management plan and avoid some common pitfalls. 

But, much like a surgeon is unable to perform surgery without the proper equipment, risk management also cannot operate off of knowledge alone. 

To this end, we highly suggest using dedicated project management tools like Plaky which have built-in risk registers that make it easy to manage and maintain the project’s risk registry.

References

• Bisson, C. (2014). Risks aren’t always negative. PM Network, 28(8), 24–25.
• Hillson, D. (2001). Effective strategies for exploiting opportunities. Paper presented at Project Management Institute Annual Seminars & Symposium, Nashville, TN. Newtown Square, PA: Project Management Institute.
• Hillson, D. (2012). How much risk is too much risk? Understanding risk appetite. Paper presented at PMI® Global Congress 2012—North America, Vancouver, British Columbia, Canada. Newtown Square, PA: Project Management Institute.
• Lavanya, N. & Malarvizhi T. (2008). Risk analysis and management: a vital key to effective project management. Paper presented at PMI® Global Congress 2008—Asia Pacific, Sydney, New South Wales, Australia. Newtown Square, PA: Project Management Institute.
• Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.). Project Management Institute.
• Shrivastava, N. K. (2012). Project risk management—another success-boosting tool in a PM’s toolkit. Paper presented at PMI® Global Congress 2012—North America, Vancouver, British Columbia, Canada. Newtown Square, PA: Project Management Institute.
• Virine, L. (2010). Project risk analysis: how ignoring it will lead to project failures. Paper presented at PMI® Global Congress 2010—North America, Washington, DC. Newtown Square, PA: Project Management Institute.