4 Tutorials that teach Identifying Project Risks
Take your pick:
Identifying Project Risks

Identifying Project Risks


This lesson discusses how to identify project risks.

See More
Try a College Course Free

Sophia’s self-paced online courses are a great way to save time and money as you earn credits eligible for transfer to over 2,000 colleges and universities.*

Begin Free Trial
No credit card required

27 Sophia partners guarantee credit transfer.

245 Institutions have accepted or given pre-approval for credit transfer.

* The American Council on Education's College Credit Recommendation Service (ACE Credit®) has evaluated and recommended college credit for 21 of Sophia’s online courses. More than 2,000 colleges and universities consider ACE CREDIT recommendations in determining the applicability to their course and degree programs.


What's Covered

In this lesson, you will learn how to identify project risks and create contingencies to manage those risks. Specific topics include:

  1. Project Risks
  2. Project Contingencies


A project manager identifies project risks in order to outline the uncertainty that exists in their project. Uncertainty can come in many forms, but the project manager is primarily concerned with those that are dangers to the successful completion of any component of the project scope. For example, in software development projects, if programmers are not available to work when expected in the schedule, that is considered a risk.

    • Project Risks
    • Events that if they occur will impact the successful project completion and require project change.

It's the project manager's responsibility to document any occurrence that might jeopardize the project's completion. The risk document is created during the development of project scope, but since risks can be added at any point during a project's lifetime, the risk document could also be modified over the course of the project. Whenever risks are added or removed, the key stakeholder should be notified of the change.

Risks are categorized based on the probability that they will occur and the impact if they do occur. This is called a risk matrix, and here's how it looks:

The probability that a risk will occur is given a rating of low, medium, or high. Low risks likely won't occur but will still impact the project if they do. These should still be documented, but they don't need monitoring closely.

ExampleIn the case of a project that's been tasked to build a wearable watch with tablet computer-like functionality, a low risk might be that tablet operations change so dramatically that the watch must be completely redesigned.

ExampleMedium risks may happen, but are still not expected to occur. A medium risk on our tablet watch project would be manufacturing delays in the prototype watches causing slippage in the schedule. The project manager might create project contingencies for these risks.

Example An example of a bad, but survivable risk would be delays in the design process for our tablet watch.

Each risk is given one of three impact ratings. "Not a problem" is a risk that won't be a significant issue if it occurs. If a low probability/"not a problem" risk does occur, a project manager might not need to document it. But if there is a likely chance it will occur, then it should still be noted since the impact might be more significant than predicted.

Let's move on to the high impact risks that may require contingencies.


Contingencies are actions that will mitigate the risk if it does occur. In the case of "bad, but survivable", risks are closely tracked by the project manager and contingencies must be developed.

In the case of "project killers", project contingencies are developed by the project manager. These contingency plans will be used to protect the organization and possibly save the project. Project actions are often taken to avoid these risks instead of merely mitigating them.

    • Project Contingencies
    • Actions that can be implemented to reduce project risks.

In the example above, a contingency would be identifying alternate manufacturing methods that could be used. High risks will likely occur and are the ones that must be watched most closely by the project manager. Project contingencies must always be identified for high risks and, in some cases, begin addressing the risk before it even occurs.

Let’s say we are pretty sure the tablet development software will not be available in time to build the user interface for our tablet watch. If you were the project manager, what contingency might you suggest?

Perhaps, you might task people to find ways to use existing software in preparation for that event.

An example of a tablet watch project killer would be the failure to gain approval from customers on the prototype watches. This could end the project, so a plan contingency might involve testing multiple simple prototypes earlier with customers to avoid this situation.

Each identified risk will fall somewhere on this matrix. And the project manager should document each risk based on its location and then include any contingencies that will mitigate the risk.


Now, you understand project risks. You've learned how to categorize risks using the risk matrix and why the project manager needs to document and closely monitor risks over the project's lifetime. Once risks are categorized, it's the project manager's responsibility to establish project contingencies. In the case of project killers, contingencies might be put in place before such a high level risk occurs.

Good luck!

Source: This work is adapted from Sophia author jeff carroll.

Terms to Know
  • Project Contingencies

    Actions that can be implemented to reduce project risks.

  • Project Risks

    Events that if they occur will impact the successful project completion and require project change.