What Is Risk in Project Management?

In project management, everything that has the potential to affect the outcome of the project is categorized as a risk.

For example, running into a resource shortage is a risk — if it happens, bad things are going to follow. 

But in project management, the term risk isn’t exclusively negative. If a software that could significantly speed up the project development were to get released, it would still be categorized as a risk, albeit a positive risk — using that software could improve your timeline and allow you to finish the project sooner.

This isn’t just semantics either. 

Treating positive risks just like negative ones ensures that you’re ready and able to take advantage of them should they occur, just as it enables you to avoid or minimize the consequences of negative risks.

In this guide, we’ll teach you all you need to know about risks in project management so that you can analyze them more effectively and prepare a more thorough risk management plan. We’ll focus on the elements that comprise project risks, as well as various ways in which you can categorize risks.

Risk analysis in project management

Before you can fix a problem, you have to understand it. Diagnostics are crucial for understanding problems. Just as this is true for doctors and patients, developers and software, engineers and gadgets, it also holds true for project managers and project risks.

Risk analysis is the process by which you come to understand how, when, and to which extent the risks you’ve identified pose a threat to your project.

Elements of risk in project management

To help you understand a project risk, it helps to break it down into these six parts:

• Risk event
• Risk probability
• Risk impact
• Risk timeframe
• Risk indicator
• Risk trigger

Understanding these risk aspects will greatly aid you in preparing your risk management plan.

Risk event

To put it simply, a risk event can be described through the consequence of a risk. In other words, what (bad) things are going to happen if the risk occurs?

Examples of risk events include a hacker attack, a key employee resigning, or a lightning strike frying some electronics.

To put it another way, the thing that most people would have in mind when they say the word risk is called a risk event in project management.

Risk probability

Not all risks are as likely to happen. It’s safe to say that miscommunication or equipment malfunction happen much more frequently than lawsuits or earthquakes.

To ascertain the probability of a given risk, you just need to ask yourself how likely it is to happen. 

In most cases, risk probability boils down to guestimation. 

Some project managers prefer to use percentage values, while others use descriptors like highly likely or unlikely. 

Risk probability doesn’t have to rely on guesswork. By conducting a quantitative risk analysis, you can arrive at more data-driven conclusions.

Risk impact

Risk impact is the estimation of the severity of a risk’s consequences. Risk impacts can range from catastrophic to inconsequential. Much like risk probability, risk impact is most often derived through estimation — in either percentages or descriptors — but, the option for a more data-driven quantitative analysis or risk impact does exist.

Risk impact and risk probability are often paired together to create the risk assessment matrix.

Risk assessment matrices help you assign overall threat level scores to individual risks so that you can prioritize them accordingly.

Risk timeframe

Risk timeframe is a description of when a risk can be expected to happen. 

Risk management entails risk monitoring — but knowing the timeframe for any given risk is can help you focus your efforts. 

For example, a server crash due to massive online traffic is a real concern — but, it’s more likely to happen during large holiday sales than on a random Wednesday afternoon.

Also, there is no need to be jumpy and keep worrying about a certain risk if it’s not going to occur until the project enters its final phase.

Risk indicator

Risk indicators are portents of impending risk events. They’re the signals that indicate a risk event is looming on the horizon and that you should be prepared to react to it.

So, if the flu season rendering a large part of your workforce bedridden constitutes a schedule risk for your project, then news of cases outside the office could serve as early risk indicators.

That being said, risk indicators aren’t always followed by risk events. They only serve to forewarn you of risks potentially materializing in the near future. 

Let’s illustrate this.

Dark clouds are an indicator of rain. Sometimes, these dark clouds pass overhead without producing so much as a droplet. But to see dark clouds and ignore the chance of rain entirely would be tantamount to turning a blind eye to a risk indicator in project management.

Risk trigger

A risk trigger is a switch that, when flipped, turns a potential risk into a tangible issue.

If the risk event is getting shot — excuse the violent analogy — the risk trigger would be pressing the actual trigger. 

A single risk event can have multiple risk triggers. 

Also, while risk triggers are often designated during risk identification, this isn’t always the case.

For effective risk management, you should review risk triggers from time to time and update them if necessary.

–

Now that we have understood the elements of risk in project management, let’s see how we can categorize risks. For the purpose of this guide, we have categorized risks in project management as inherent and thematic risks.

Types of risks  — The inherent categorization

Not all risks are made equal.

Just to name some of the more prominent types of inherent risks, we have:

• Positive and negative risks
• Known and unknown risks
• Primary risks, secondary risks, and residual risks

Understanding these risk categorizations will help improve the execution and effectiveness of your risk management plan.

On top of this, we can also divide risks into any number of thematic categories, like cost risks, technology risks, strategic risks, and so on. Further below we’ve provided 15 examples of thematic risk categories that are aimed to help you identify more risks. 

These thematic risk types are different from inherent risk types in that they aren’t as well defined and often feature overlap. With inherent risks, a risk is either known or unknown, positive or negative, primary or secondary — there is no middle ground.

We should also note that the inherent and thematic risk categories aren’t mutually exclusive. Namely, you can attribute descriptors from each category to a risk. 

For example, it’s possible to have a negative, known, secondary technological risk.

Positive and negative risks

The first category divides all risks into positive and negative ones.

Positive risks are those risks that, if they happen, will have a positive impact on the project. They help you finish the project quicker, make it cost less, or have any other positive effect.

Negative risks are those risks that, if they happen, will have a negative impact on the project. They make you miss the deadline, incur extra costs, lower the quality of the product, and so on.

Known risks and unknown risks

The main advantage of risk management is the ability to take a proactive approach to managing risks. 

However, you can only proactively manage the risks that you’ve identified. Even with extensive risk management and the best PM helming the project, an unknown risk will force the team to respond to it reactively.

These two risk response types — proactive and reactive — constitute the first paradigm for categorizing risks. 

Known risks are those you can manage proactively. They are the risks you’ve predicted and accounted for by, among other things, defining their risk event, probability, impact, etc.

Unknown risks are those that demand a reactive response because you’ve failed to predict them. They spring out of nowhere and leave you scratching your head, wondering what happened. Sadly, the only way to learn what unknown risks are is to fall victim to them.

Some project managers choose to call risks unknowns, leading to the existence of confusing terminologies such as known and unknown unknowns. The reasoning behind this is that, while you may predict that a product will encounter bugs during testing, you don’t know how these bugs will manifest — they are known unknowns. And if you get hit by a lawsuit that you didn’t see coming, well that’s an unknown unknown. It’s confusing, and we don’t recommend using this terminology — but you can encounter it so it’s good to be equipped with this knowledge.

Each project starts with a few known risks and plenty of unknown ones, but as you progress with risk management planning, the known risks should greatly outnumber the unknown ones. In an ideal case, you’d identify all potential risks, leaving the percentage of unknown risk at 0%.

Primary risks, residual risks, and secondary risks

In a category of their own, we have primary risks, secondary risks, and residual risks.

Primary risks are the risks you’ve identified and designated with a risk event, probability, impact, and so on. Unless stated otherwise, assume that the term risk implies primary risks, just as it usually implies negative risks.

Secondary risks are those risks that stem as a consequence of risk management implementation. In other words, risks that occur as a consequence of responding to a primary risk are called secondary risks. 

Let’s say you switch to using a new team communication tool to reduce costs only to have it be plagued with crashes and downtime. The issue — crashes and downtime — are something that would have never occurred if not for your risk management efforts, making them the impact of a secondary risk.

Residual risks are the threat that remains even after you’ve implemented your risk response plan. Mathematically, they could be expressed as:

Residual risk = risk – risk response

To give a concrete example, let’s say you impose contractual penalties upon the shipping company responsible for delivering your product to retailers. These penalties reduce risk probability, but not risk impact. Therefore, this risk response plan leaves you with some residual risk.

Now if the risk you’re combatting is equipment malfunction, and your risk response includes having redundant equipment on standby, then the residual risk is low or non-existent.

Residual risks and secondary risks are often mixed together, but they are fundamentally different. 

Types of risks — The thematic categorization

You’ll often hear that the three types of project risks are cost risks, schedule risks, and performance risks.

This division is perfectly valid, as it closely ties to the triple constraint theory which states that the project budget, timeline, and scope are linked to project quality and that a change to any one of them will affect the others.

But, limiting yourself to only these three risk categories doesn’t really help you identify risks any easier. Therefore, we like to place them into a category of thematic risks. This isn’t an official PM term, but we call them thematic as this name evokes the sense of direction from which risks can emerge. 

So, to facilitate your risk identification process, we’ve provided 15 different thematic categories that risks could fall under:

• Cost risks
• Schedule risks
• Performance risks
• Scope creep risks
• Communication risks
• Security risks
• Health and safety risks
• Technology risks
• Resource risks
• Strategic risks
• Operational risks
• Legal/regulatory risks
• Market risks
• External hazard risks
• Project deferral risks

One of the best ways to improve your risk identification skills is by going through this list and finding as many risks for each category. This allows you to comb through a wider range of risks than you could without using such a structured approach.

You’ll frequently find that some examples of risks given to portray risk categories could fall under several categories. 

For example, a product name dispute lawsuit could be a cost risk (regardless of whether you win or lose the lawsuit), a schedule risk (if you are forced to push back the product release due to the lawsuit), or even performance risks (in cases where the attention of the general public gets drawn to it), in addition to being a legal risk. 

So, there can be overlap.

Provided below are some of the more common risk categories that will help guide your risk identification efforts in the right direction, starting with the three most common ones.

Cost risks

Cost risks are all risks that have the potential to make you go over budget (or under budget, if we’re also taking positive risks into consideration).

From the very outset, poor budget planning, and sloppy execution are bound to leave their mark on a project. Let’s take the infamous FiReControl project as an example. The goal of the project was to develop control hubs for the fire brigade in England. The original cost estimate of the project was £120 million, but at one point threatened to cost £635 million.

How did this happen?

Apparently, the department in charge of the project thought IT development would be smooth sailing and began the endeavor with quite unrealistic expectations — which quickly built costs.  

And that’s just one example. Plus, poor budgeting isn’t always the root cause of the problem. Scheduling issues often also constitute a cost risk, as the people working on the project need to be compensated for their prolonged work.

Schedule risks

Likewise, schedule risks are all risks that affect the project timeline. Implementing a new piece of software or equipment that can help in reaching the project deliverables sooner is one example of a positive schedule risk. 

In most cases, though, you’ll be dealing with negative schedule risks:

• Flu season leaving your workforce temporarily halved, 
• Questionably competent shipping companies failing to get the product to retail shelves in time, or 
• Equipment malfunctions mandating a halt in production.

Performance risks

Performance risks don’t have to do with the performance of the team working on the project — this falls under schedule risks. 

Instead, performance risks are all about the quality of the project deliverables. 

Anything that can impact the desired quality level of the project deliverables is a performance risk: 

• High employee turnover, 
• High costs, or
• Stretched resources. 

Sometimes, schedule risks bleed over into performance risks, which is often the case with a time crunch.

Scope creep risks

Let’s say you’re trying to make an ultra-durable smartphone. Outside of making it waterproof, dustproof, and otherwise resistant to the elements, the smartphone isn’t supposed to have any fancy features. Everything is agreed upon and the project gets underway.

Then, a call gets made to add support for a smart assistant or to add a gyroscope — something that wasn’t part of the agreed-upon project scope. This is a classic case of scope creep — the requirements increase after the plan has already been made.

The addition of new features is one of the more common causes of scope creep, but it can also come about as a result of poor communication with stakeholders, having a poorly defined project scope in the first place, or any other reason.

Communication risks

You could have the most skilled workers in the world, but that wouldn’t matter one bit if the work they’re doing is based on miscommunication. Theoretical frameworks of communication break this process down into at least 8 elements:

• Sender
• Message
• Encoding
• Noise
• Channel
• Receiver
• Decoding
• Feedback

As you can see, there are plenty of stops along the way where the intended meaning can get distorted. Perhaps you won’t phrase it properly (encoding), you’ll opt for verbal communication for complex ideas where a message would have been more apt (channel), or maybe the message recipient will simply interpret the message incorrectly (decoding).

Miscommunication can occur between the PM and stakeholders, the project team, or any other party. 

The important thing to remember is that communication risks can easily happen in any project and that their impact can range from negligible to quite problematic.

To avoid communication risks, you could establish communication protocols, like asking the message recipient to reiterate what they’ve heard. It will feel a bit unnatural at first, but you’ll quickly get used to it. 

Security risks

Anything that can lead the project deliverables to suffer from prying eyes (and hands) is a security risk. 

Information leaks, hacks, or even theft, are all security risks that can negatively impact projects.

As an example of a security risk, let’s look back to the spring of 2020, when the hotly anticipated sequel to PlayStation’s hit video game The Last of Us was gearing up for release.

Months ahead of the game’s release, the plot of the game was leaked, causing a large controversy over the death of a fan-favorite character.

The game went on to be a critical and commercial success despite this setback — but needless to say, the road to get there was less than ideal, due to breached security.

Health and safety risks

Safety and health risks constitute all risks that could endanger the safety of workers and/or consumers. 

For example, a risk with mercury-in-glass thermometers was that, should they break, the consumers would be exposed to mercury. This is why everyone avoids that risk and makes electronic thermometers nowadays. 

Nowadays, a  common safety risk is the presence of toxic elements used in most QLED displays. Although Samsung has made QLED TVs without these elements — making them 100% safe for consumers — the sales are still low due to the negative public perception of the technology as a whole. 

In this case, we can see that health and safety risks can cause a problem for projects even when there aren’t actually any health and safety risks involved.

Failing to account for such risks will negatively reflect on the project, either by:

• Incurring extra costs to pay for medical treatment of employees, 
• Muddying the company’s brand, or 
• Affecting your bottom line if you associate your product with “the wrong crowd”.

Technology risks

Technology risks include a plethora of different risks intended to help guide your risk identification efforts in the right direction.

This is because anything relating to technology can be seen as a technology risk. Some of these risks could even be labeled under multiple categories.

For example, data security issues can be seen as both technology risks and legal/regulatory risks. 

Technology risks also include service outages, like your cloud storage provider losing your data or your server provider failing to maintain uptime on your website.

New software implementation is often perceived as a risk due to the costs associated with it, as well as the need to train employees to use said software.

All of the previously mentioned examples refer to forces outside your influence, so to speak, but technology risks aren’t always someone else’s fault. 

If you roll out a software product that suffers from frequent crashes, it can take months to repair the PR damage after fixing the crashes.

Resource risk

Resource risks are exactly what they sound like — risks that threaten to prevent you from completing a project (or keeping it on track) due to a shortage or unavailability of essential resources. 

Imagine if you needed to make and ship out 50 million gaming consoles but a shortage of microprocessors bottlenecked your production. 

This is a resource risk, and you can tackle in the following ways:

• Prolong the development — which would affect your timeline
• Use a different type of microprocessor — which would affect the quality of your product and your projected ROI
• Proceed as planned and ship our fewer units — which would reduce your overall profits.

In any case, categorizing this (and all similar cases) as a resource risk is much more conducive to risk identification and risk response planning than if you were to limit yourself only to cost, schedule, and performance risks.

Strategic risks

Most companies have a clear strategic vision when they commence work on a project — and if they don’t, they should. The project deliverable and the strategic vision of the project can be two separate things. 

For example, a project deliverable could be to develop and maintain a cloud storage service. 

And, here are three very different strategic goals for this project:

1. To develop an in-house cloud infrastructure that the company can use for their other projects and services.
2. To leverage affordable plans to amass popularity, attracting other companies to it who would like to use your cloud storage for their products.
3. To increase your sales by 15% over the next year.

The product being developed could be exactly the same in all cases, but you would have to react to external stimuli differently depending on your strategic goal. 

For example, if a new competitor were to blast onto the market with an amazing cloud infrastructure, you’d feel much worse about it with number 2 and 3 strategic goals than with the number 1 goal.

Operational risk

Operational risks include any issue that stems from the company’s business as usual. 

Perhaps the workflow is just not efficient enough to accommodate the needs of the project. This may require some changes, but changes bring with them their own operational risks.

This can include changes in:

• Management
• Software used
• Communication guidelines
• Business strategy
• Team roles
• Leadership

The result of any of these changes will likely be confusion and adjustment periods, during which the project will not get its timeline paused.

Legal/regulatory risks

We’ve mentioned legal/regulatory risks as part of other categories, but they really are deserving of their own category. They are also a broad category — legal trouble can come from the state, from competitors, unrelated third parties who aren’t even competitors, or even the organization’s employees.

Similar to legal risks are regulatory risks are — but they’re more focused on the product than the company. 

This is especially the case with many innovative IT projects that depend on data security and privacy protection. When developing something new, there is always a chance that the project deliverable is going to be at odds with some regulations. 

For example, if you’re selling your product in different countries, you need to account for their varied laws.

In other words, the trouble with legal and regulatory risks is that they can stop the project dead in its tracks, which is why it’s crucial to consider how any project fits into the legal and regulatory constraints in their markets.

Market risks

Every project product can be made to look great in a vacuum. In all likelihood, it will be competing against other, sometimes more popular and well-established, competition.

Unfortunately, it’s often not enough to simply make a good product or offer a good service and expect the rest to work itself out. A project geared for success will take the volatility of market changes into consideration.

Remember that a risk isn’t necessarily a bad thing in project management. You should be ready to respond to positive market risks that can undermine your competition.

External hazard risks

External hazard risks are a perfect example of risks you cannot prevent. 

All you can do in the face of storms, floods, and earthquakes is have a solid response plan in action. 

Not having your office on the ground floor helps mitigate the negative effects of floods, for example. 

Setting up shop in an aseismic building can greatly reduce the impact of earthquakes on your project. 

And having a server room power generator can help projects stay on track even through power outages that frequently accompany storms.

These are just a few ideas of what constitutes an external hazard risk and how one might go about dealing with them. 

Do keep in mind that external hazard risks aren’t limited to natural disasters — armed robberies or terrorist attacks could also be categorized here. 

Not every project needs a response plan for all external hazards — but it’s best to stay aware of these things.

Project deferral risks

Project deferral risks are all risks that can stem from a project being put on hold.

Leadership greenlights projects, but it also has the power to put them on hold for whatever reason. 

But not all projects handle being put on hold equally. 

Some projects get exponentially more expensive as they get prolonged. 

Others may suffer from a limited window of opportunity to achieve their maximum effectiveness.

For these reasons, understanding how big of a risk deferral poses to your project is crucial and can offset some of the drawbacks associated with said deferral.

Conclusion: Understanding project risk is simple, but identifying risks is difficult

It only takes one sentence to define risk in project management:

Risk is anything that can affect the project, either positively or negatively.

But knowing what risk is and how to identify it and mitigate it are as different as knowing what a computer is and knowing how to fix one.

Keeping the 7 types of inherent risks and 15 thematic risk categories listed in this guide with the examples we’ve provided will help you identify a larger pool of risk for your projects. 

📖 Risk is just one of the terms that doesn’t have an identical meaning in project management from its standard dictionary definition. You can learn more about similar terms, and many others, from our Project Management Glossary of Terms.

References

• Monnappa, A. (2021, October 8). Residual Risk Vs Secondary Risk. Simplilearn. https://www.simplilearn.com/residual-risk-vs-secondary-risk-article
• Padgett, C. M. (2021, June 21). Managing Known and Unknown Unknowns. Forbes. https://www.forbes.com/sites/forbesbooksauthors/2021/06/21/managing-known-and-unknown-unknowns/?sh=34d1941cd02e
• Pumble. (n.d.). What is good team communication and why is it important. Retrieved February 24, 2022, from https://pumble.com/learn/communication/communication-importance/
• PwC. (n.d.). Regulatory Risk Management. Retrieved February 21, 2022, from https://pwc.to/2X9nR5z
• Spacey, J. (2021, March 19). What is Secondary Risk? Simplicable. https://simplicable.com/new/secondary-risk