Use Sophia to knock out your gen-ed requirements quickly and affordably. Learn more
×

Identifying Project Risks

Author: Sophia

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

Table of Contents

1. Project Risks

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.

EXAMPLE

In software development projects, if programmers are not available to work when expected in the schedule, that is considered a risk.

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 throughout the project. Whenever risks are added or removed, the key stakeholder should be notified of the change.

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

2. Risk Matrix

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:

Risk Matrix

Depending on the type of risk, project contingencies may be put into place. These are actions that will mitigate the risk if it does occur.

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

2a. Risk Probability

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.

EXAMPLE

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

Medium risks may happen but are still not expected to occur. The project manager might create project contingencies for these risks.

EXAMPLE

A medium risk on our tablet watch project would be manufacturing delays in the prototype watches causing slippage in the schedule. 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.

EXAMPLE

A high risk on the tablet watch project could occur when we are nearly sure that the tablet development software will not be available in time to build the user interface for the tablet watch. The project manager might suggest a contingency that tasks people to find ways to use existing software in preparation for the event.

2b. Risk Impact

In addition, each risk is also given one of three impact ratings.

"Not a problem" risks are risks 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 happen, then it should still be noted since the impact might be more significant than predicted.

EXAMPLE

A "not a problem" risk could be upper management missing an update on the project. Although this can often occur in a project, it has a low impact because the project manager can easily update the management with a quick phone call or email.

"Bad, but survivable" risks are closely tracked by the project manager and contingencies must be developed.

EXAMPLE

A "bad, but survivable" risk would be delays in the design process for our tablet watch.

"Project killer" risks involve using project contingencies being developed by the project manager to protect the organization and possibly save the project. Project actions are often taken to avoid these risks instead of merely mitigating them.

EXAMPLE

A "project killer" would be the failure to gain approval from customers on the prototype tablet watch. This could end the project, so a contingency plan would involve testing multiple simple prototypes earlier with customers for this to be avoided.

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.

summary
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.

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.