Source: Image of cube, hand moving cube, Creative Commons, Kelly Eddington; Image of document, plus sign, minus sign, Public Domain, Sparkol VideoScribe Internal Image.
Hi, I'm Jeff, and in this lesson, we'll learn how to identify project risks and then create contingencies to manage those risks. So let's get started.
A project manager identifies 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.
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 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. In the case of a project that's been tasked to build a wearable watch with tablet computer-like functionality, for example, a low risk 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. 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.
Contingencies are actions that will mitigate the risk if it does occur. In our example, 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.
For example, if we're nearly sure the tablet development software will not be available in time to build the user interface for our tablet watch, a project manager might task people to find ways to use existing software in preparation for that event.
In addition, each risk is also given one of three impact ratings. Not a problem is a risk that won't be a significant issue if it occurs. If a risk has a low probability and is also not a problem, if it 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.
Bad, but survivable risks are closely tracked by the project manager and contingencies must be developed. An example of a bad, but survivable risk would be delays in the design process for our tablet watch.
Finally, there are project killer risks. In the case of these risks, the contingencies developed by the project manager will be used to protect the organization in addition to attempting to save the project. And project actions are often taken to avoid these risks instead of merely mitigating them. 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 would involve testing multiple simple prototypes earlier with customers so this might be avoided.
Each risk identified 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. Nicely done! 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.
Thanks, and have a great day.
