Risk monitoring and control during project execution is crucial to ensure a that project risks are accounted for and properly dealt with. Many things change during the course of the project which render parts of the risk register obsolete.
Controlling risks is the only risk management process in the monitoring and controlling process group within the Project Management Body of Knowledge.
There are three primary objectives to risk monitoring and control:
- Tracking risks
- Identifying new and residual risks
- Ensuring the response plans are executed as planned
Tracking Risk
Throughout a project the risk register is always changing. If nothing else, one by one the risks become obsolete and need to categorized as “did not occur.” Of course, risks that occur need the appropriate response plans to be initiated. In addition, risks that change due to project circumstances should be updated so that project stakeholders do not view the risk register as a planning document that did not receive proper attention during project execution.
Thus, the risk register needs to be revisited continually to ensure an effective risk management system. Risk should be an agenda item at regular status meetings and project members should give input to the status of various risks.
Calculation of variance and earned value should be done regularly throughout the project. This determines how far off schedule or cost the project is, and can be used to assess those (usually very important) risks to the schedule and/or project budget.
Although not a mandatory part of the risk register, risk triggers represent an excellent way to track risk. When in place they simplify the monitoring process. They allow you to quickly identify whether a risk has occurred, and thus allow for fast and decisive action.
Identifying New Risks
Throughout the project new risks will occur. Since many of the risks in the register tend not be completely independent of each other, the occurrence of a risk will change the risk profile (probability, impact) of others. Also, new risks are often identified during project execution which were not envisioned during the planning stage.
The project management team should designate regularly scheduled risk management discussions, and new project risk should be on the agenda. I recommend weekly project status meetings with the project team, because it tends to be the project team that identifies new project risks. They won’t use that terminology, but if you are constantly listening to their updates with the view of discerning possible risks, they will reveal themselves.
Execute Response Plans
When a risk occurs, you have one of two options:
- Invoke a contingency
- Make a change to the project (scope, cost, schedule, etc.)
If the project has contingencies (time, budget, etc.) allocated to the task that has been affected by a risk event, the contingencies can be invoked. The project manager needs to assess the contingency level and make a judgment call regarding the adequacy of contingencies for the rest of the project. This is certainly the preferred alternative, but if the project does not have the luxury of contingencies, project changes are required.
Response plans should be in place only for the most important risks. When a risk is deemed to have occurred, and a response plan is in place, it needs to be implemented swiftly.
When a risk event occurs, generally communication is paramount. Stakeholders need to be informed that a risk has occurred and what the response will be. If necessary, the project sponsor(s) also need to be informed. I believe that the status of current risk management practices will ensure that alot of credit will be given to project managers that have a response plan in place when things happen.
Project Closure
Once the project is complete, each risk will fall into one of the following three status categories:
- Did not occur
- Occurred with a project change (scope, cost, schedule, etc.)
- Occurred and contingency utilized
If all of the risks that did not occur were removed from the risk register, it could be renamed into a “lessons learned” database, together with any relevant information about how the risks were handled, and referenced for future projects. In fact, a lessons learned database is an essential component of the Project Management Body of Knowledge.
A strong lessons learned database is crucial in effective program management within a project management office, and the project manager is the front line person in this effort. Most projects have many parts that will be repeated in some form at some point in the future, and the final results of the risk register are an amazing organizational tool that can and should be utilized to the benefit of all projects.
