Risk Monitoring and Control

Part of project planning was the identification of potential risks to the project and the development of a risk response plan. Risk monitoring and control is the process of implementing the risk response plan. This process includes not only tracking the risks identified during planning, but evaluating the effectiveness of the actions you identified. Have the steps you identified to prevent the risk or mitigate the impact been implemented? Is the result what was expected? For those risks you could not control, you must track the status of the risk to determine whether to implement the contingency plan that was developed to deal with the risk.

Risk monitoring and control also includes identifying any new risks throughout the life of the project. Regardless of the level of detail in your original risk identification, as the project progresses conditions change, the business changes, and other components of the project plan change, all of which can produce new risks that must be dealt with.

Closely linked to risk control is the control of project issues. You must monitor and update the progress of current issues, evaluate the progress of resolution, and identify new issues.

Let's start with the risk response plan results.

Monitoring Risk Response Results

During risk planning, you identified risks to the project and prioritized those risks based on the probability of occurrence and the impact to the project if the risk occurred. The risk response plan includes a planned response for each of your high priority risks-action that will either avoid the risk or lessen its impact or a contingency plan to deal with the results of the risk.

Preventative Action Risks that can be avoided or mitigated should have specific actions associated with preventing the risk, often involving the addition of new tasks to the schedule.

In these cases, you should be tracking the implementation of the planned action and evaluating the impact of the action(s) on removing or mitigating the risk. If the action is not mitigating the risk, you will need to review the risk response and either choose to accept the risk or develop a new response.

When you review an action that is not having the desired result, you need to determine if other factors involved have changed the nature of the risk. If what you really have is a different risk, it may require a completely different approach.

Real-World Scenario: Keeping Your Eye on the Trigger

One of us was on a project a few years ago that involved extensive user training in multiple locations as part of the deployment of a new user interface. The training had to take place before the new application was deployed at each location, which drove the development of a very complex dependency between the training and deployment schedules.

Just when we thought we had this schedule planned out to perfection , we were advised that the end users were represented by a labor union in the midst of negotiating a new contract. Talks were not going well, and a labor strike could start in the middle of our deployment. No one associated with the project could do anything to impact the outcome of the labor negotiations, so we had to develop a contingency plan.

We discussed several options, one being to tighten up the deployment schedule to complete all locations prior to the end of the current contract. That plan would have required additional resources to both train the end users and deploy the system, which we did not have. We opted to keep the existing training plan and develop an alternate plan for those offices that would not be trained before the strike date. The contingency plan called for the training to start 2 weeks after the end of the strike and to keep the same sequence and time between training as existed in the current schedule. All deployments scheduled prior to the strike date would continue as planned. No training or deployments would be canceled until after a strike was declared.

The client approved this plan, a team member was assigned to monitor the progress of negotiations, and we established two triggers. The first was a vote by the union members to authorize a strike. When this occurred, a conference call was established with the managers of all offices impacted by the contingency plan. We reviewed the plan and made sure everyone understood the formula for calculating the new training date. It was agreed that a project team member would contact each office manager to confirm the training dates if we had to implement the contingency plan.

Our second trigger was the official start of the strike, which came at 12:01 A.M. on a Sunday morning. When the strike was declared, a message was sent to all training and deployment managers to cancel travel plans for that coming week.

Although the work stoppage delayed the overall deployment schedule by 6 weeks, the contingency was implemented smoothly and the remaining offices were deployed in an orderly fashion with no disruption to customer service.

The key to a successfully implementing a contingency plan is identifying your triggers and good communication.

 

Contingency Action The other type of action that you identified in your risk response plan was a contingency action to deal with a risk you could not avoid or mitigate. This requires a different approach to risk monitoring. A contingency plan is implemented only if a risk actually occurs, so you need to be monitoring for a risk trigger , which is an event that tells you that the risk is imminent.

As the project moves forward, you need to be alert to any signals that either the risk or the trigger is changing. The key to a successful contingency plan is knowledge that the risk is forthcoming.

Identifying New Risks

The risk response plan evolves throughout the project life cycle. Some risks identified during planning may not materialize, and new risks may arise that were not previously included in the response plan. As the project work completes, you need to be aware of any new unplanned risks.

Warning  

Any change to the project scope has a potential to add risk to the project, because it changes or adds to the major deliverables of a project. Because the new activities associated with the scope change frequently lengthen the project schedule, they may be on the critical path as well. A scope change should always include a risk analysis and review of the risk response plan.

New risks may also impact the risk priority listing. A new risk may have a greater probability and a more severe impact than previously identified risks. Changes to the project plan may also change the relative ranking of existing risks. For example, as actual work progress is reported , the schedule critical path may change, impacting the urgency of dealing with risks that were previously a low priority.

As you modify a response to an existing risk or identify a new risk, the action proposed to deal with the risk may itself result in a change to the project plan. The response may involve a change to the project scope, a change to the schedule, or money. In this case, your risk response should go through the appropriate change control procedures, like any other change.

Your issues log is another important document that requires ongoing monitoring and updates.

Monitoring Issue Resolution

Monitoring the progress of issues resolution is very similar to monitoring risk; you need to make sure appropriate action is taken to close the issue. An issues log that is not carefully managed can turn into an unwieldy monster, with new issues added weekly, and nothing getting resolved.

As you review your issues log in a project team meeting, you want to be sure the person who has been assigned to resolve the issue is working toward closure. Sometimes project issues will remain open for weeks or even months, especially if you consider 'we are still working on this one' an acceptable progress report. The status you request should always include both a plan for resolution and a target date to resolve the issue. If no progress is made, perhaps the responsible party needs assistance or does not really understand the issue. It may require escalation to the sponsor to overcome roadblocks .

Although the goal is to assign all issues and resolve them as quickly as possible, in some instances you need to prioritize issues and have them worked in sequence. You can use some of the tools from risk planning to complete this prioritization. If multiple issues require the same team member or group , review the impact of each issue on the outcome of the project and establish a priority list.

A Project in Jeopardy

What starts out as a risk or issue to be resolved by project team member action can sometimes escalate into a situation that can jeopardize project completion. If the actions you have taken are not having the desired impact or if you are identifying new risks that you cannot control, it is time to get with the project sponsor to determine the appropriate course of action.

Escalation to the project sponsor is a delicate balancing act. You do not want to get the reputation that you panic every time something goes off course or that you cannot handle tough decisions. On the other hand, if you have done everything you can, do not delay involving the sponsor on the faint hope that things will change. If you do not raise a red flag until the project is in serious trouble, it may be too late for the sponsor to do anything.

When you come to the project sponsor, be prepared to communicate clearly the issue or risk, the actions you have taken so far, and the impact to the project if nothing changes. Your briefing with the sponsor should be at a high level; he or she does not need to know every step taken along the way.

You should request specific action from the sponsor. You will not come off well if you go into your sponsor wringing your hands and saying you don't know what to do. If you are having issues with another department that requires a decision at the executive level, let the sponsor know who is involved and what you need done to get the project on track.

Sometimes nothing can be done to change the situation. Perhaps a new regulation has invalidated key project assumptions or new corporate leadership has implemented a strategy that nullifies the justification for your project. If this is the case, your request to the sponsor may be a recommendation that the project be canceled.

Project control results need to be reported to the stakeholders, and in some cases stakeholder decisions must be made regarding the future of the project.