Source: Image of bullseye, person thinking, Creative Commons, Kelly Eddington; Image of risk register, Creative Commons, Jeff Carroll; Image of exclamation point sign, tablet computer, calendar, dollar sign, silhouettes of people, silhouettes of people holding up hands, images by Video Scribe, License held by Jeff Carroll.
Hi, I'm Jeff, and in this lesson we'll discuss how to manage project risks. A project manager will need to continually make the effort to identify and classify events that threaten a project's success. Unexpected challenges always occur on projects, but it's the project manager's responsibility to use their expertise to find these risks and uncertainties early in a project and implement mitigations that will reduce their impact.
Risks are often found and triggered in this phase of a project. No matter how diligently a project is documented during the scope and planning phases, there's just no way to define every deliverable perfectly. So risks will occur, and it's up to the project manager to find and investigate them.
A risk can relate to any of the following. Scope creep. Deliverables or additional requirements might be added to a project. For example, if a new stakeholder is added to a project after the planning phase, they might have additional requirements that affect the project. Deliverable risks. The quality or the performance of deliverables may not be meeting the standards set in the project scope. If a mobile email application is expected to be delivered with fewer than five errors, but testing is currently seeing 100 bugs, then that's a risk.
Schedule risks. Tasks might take more time or more effort than expected. Dependency issues might lead to slippage in a critical path. If a senior programmer is taking longer to code their work because they are adding features that are unnecessary for a product, that is a risk. Risk with budget. If the schedule or quality is an issue, then budget will be impacted also. Any additional resources will increase the budget, such as the need to add an additional programmer when a task slips due to inexperience with the development team.
Risks with people and non-people resources. There might be issues with personnel, including work performance issues. Or there might be issues with materials. For example, if the mobile email application is being developed for an unreleased smartphone, and the development versions of those phones are not available for testing, that's a risk that must be managed carefully. Risk can occur anywhere on a project, but this list should provide guidance about the most common places where risk appears.
When thinking about risk, it helps to remember the triple constraint from an earlier lesson. Any impact to scope, time, or cost will impact the other two variables. If the project manager identifies risk in the schedule, then the risk to scope and cost must also be identified. Then the risk and the mitigations should be documented in the risk register. The risk register should be reviewed and updated periodically over the course of the project. When new risks are found, they should be discussed in team meetings. But risk, especially those with fast impacts, can be brought up with the team any time.
As we just noted, the risk register is used to monitor and track risks. And it's the project manager's responsibility to keep the risk register updated. But every member of the team should be encouraged to identify risks and notify the project manager when they're discovered. Risks in the risk register should be reviewed at every team meeting, and the project manager should also take that opportunity to remind the team of the importance of risk identification and mitigation.
Using the risk register, current risks should be evaluated to determine the current status of the risk and the current effectiveness of any mitigation. A good question to ask is, has the probability of the risk occurring and the impact of the risk changed since the risk was first identified? To better ensure all risk types are monitored and reviewed, the risk register can be organized by the categories of risks that we discussed earlier.
Note this example, where the deliverable risk was identified early in the process. It has a high impact, so the mitigations need to be aggressive. The earlier a risk is identified, the easier it will be to mitigate that risk. More options will be available to a project manager if a risk is identified in the planning phase, for example, when resources might be easily added to tasks to help mitigate the risk.
A project manager should constantly search for new risks that might impact the project. It's their role to take the big picture view of the project, and that often involves identifying dangers that might affect a project in the future. Again, the project manager should also encourage and involve the team in this process.
Whenever an identified risk either occurs or is considered too dangerous to allow to happen, the project manager should plan one or more contingencies to mitigate the risk. Contingencies are actions taken to address the risk. The project manager and any team members who can assist should devote the time necessary to develop these contingencies.
Project managers should encourage open, what-if thinking when discussing these contingencies. Any ideas that manage the risk effectively should be considered. Risks that are high impact and high probability must have contingencies, and perhaps more than one. These contingencies should be discussed and recorded in the risk register.
No matter how prepared a project is, risks will happen. And when they do, the project manager must be ready to take action. The following steps should occur.
Number one, risk happens. The triggering of the risk starts the process. Recognize the risk has happened. The project manager documents the occurrence and communicates the status to the team and stakeholders.
Reference contingency plans. If mitigations have already been identified, those should be considered if they are still appropriate. New mitigations might be developed also.
Select the contingencies to use. Consult with the team and the stakeholders. The project manager meets with team members who have expertise with the elements of the risk to determine how the mitigations might impact the project. The project manager then meets with the project sponsor and/or the stakeholders to review the contingency plan and determine if it is still the right course of action.
Finalize selected contingency plan. Implementing a contingency plan often involves changes to the schedule, cost, and scope of a project. So change requests might need to be created for the stakeholders also. Once the plan and any necessary change requests are approved, the project manager can then move forward.
Implement the plan. If the contingency plan is approved, the project manager will then make the appropriate changes to the project documents, such as the scope, schedule, budget, and requirements. And they will need to shift or reassign resources and tasks to implement the contingency plan. Finally, update the risk register. Once the plan is executed, the risk register should be updated to reflect the actions that were taken.
All right. That was excellent work. Managing and avoiding risk is one of the primary responsibilities a project manager has. In this lesson, we learned about project risk management and the varying categories of risk. We discussed how the triple constraint relates to risk. We learned about the elements of risk management and how the entire team should be encouraged to identify risks. And we talked about contingencies and why they're important to risk management. And finally, we learned the steps to use when risks become reality. Thanks for listening and have a great day.
