top of page
Search

Project Risk Management: Monitoring and Controlling Project Risks

  • Writer: June Tucay
    June Tucay
  • Jan 17, 2017
  • 7 min read

Incorporating risk management into reporting

You can perform a lot of great work on your risk management and it can all go for naught if you don't communicate it well. However, communicating something as comprehensive as the risks on your project can be of far reaching and tedious task. Incorporating risk management into your regular reporting approach is a great way to both bring your risk management to life and keep a bit of balance in your own life.

Here’s how. First and foremost put a risks section into your regular status report. This is where you talk about what you've accomplished, deadlines you might have missed, and tasks you’re going be tackling within the next reporting period.

It’s natural that risks can affect all of these, so should be included in your status. As status reporting should be concise, consistent and frequent, so should your references to risk. By documenting risks in your status report you're doing several things, including:

  • Communicating the risks to your project team,

  • Keeping your sponsor up-to-date on the true position of their project,

  • Preparing stakeholders for any corrective action you may need to take and

  • Shows your planning ahead.

A second way to incorporate risk management in your reporting is to use your project schedule. It’s a good practice to associate risks with tasks. using dates from your project schedule, you can create sections in your schedule a risk response plan for risks that been by pass, risks that you have to be aware of in the moment and risks you will be looking at in future periods.

The third technique is to regularly distribute significant parts of your risk response plan. Highlight the risk you are currently focused on, and provide the details to stakeholders that can help you detect and manage them. This is particularly helpful if you need to provide more detail on your risks, or your organization has a particular sensitivity to a certain risk.

For example, if your organization is particularly sensitive to schedule risk, you might have a separate detailed report to say when your schedule has varied from the plan. You can include details as to why it's varied and any specific actions you're planning that will get you back on schedule. During times when there are lots of schedule risks, your risk response plan extract can go even further. You can detailed the risk triggers and the actions to take if they are noticed. It’s also useful to make known of any meetings or communications that happen around the risks, even like a phone call or email. This basically highlights how you’re managing the risks through the process.

With concise and focus risk reporting you can help your sponsor and key stakeholders make very clear and informed decisions. You can also help your project team help you with appropriate and timely risk management. Put the effort into your risk reporting and you'll likely be able to suggest the best way to enhance or avoid most any risk that may surface on your project.

Deciding when to execute a risk response

Determining the right response take some work but determining when to pull the trigger and spend time and money on a risk response can be a tricky venture given all the dynamics of today's projects. Project managers, who understand when to execute a risk response and when to hold off, are the ones who always appear in control of their projects. There are three ways to approach the execution of the common risk response actions of avoidance, transference, mitigation and acceptance

1. Execute proactively.

For example in a component design and assembly project you may believe there is a risk in making a telephony component out of a fibreglass, because you may need a solution that is going to be more rigid. So using steel to make the component has been proposed as a response action. You can address this risk proactively by spending the money and time to have sample fiberglass components manufactured ahead of time. From these samples, you can determine if the rigidity risk is viable. This gives you assurance and as proactive, but can be very expensive in some project instances. Still it could be money well spent

2. Execute a response action immediately after, and assess a respond approach.

You make an assessment based on testing the manufactured parts at the prescribed time in your schedule, and then you decide on the immediate actions to take based on the results. If the fiberglass works well you do not spend any money on a response action you don't need. If the risk is valid and the fiberglass is too flexible you have to spend the money to correct the situation by using steel and recover any delays in your schedule

3. Be reactive.

You change something after the impact of the risk has been felt. If the fiberglass proves not to be rigid enough once we deployed it, then we can correct it after installation. This will probably involve some other testing processes in coming up with a corrective action like reinforcing the fiberglass parts in some manner. It can also upset your client and your reputation. In this case we've let the risk pan out and then reacted to it. It is not usually a very good option but can be considered for very low probability or low-cost risks.

Basically, what you're trying to do is think about the right balance between your triple constraints: time scope and cost. Being proactive and doing something ahead of time typically gives you the best end result when it comes to risk management. But it can have drawbacks and costs and potentially time. going down the assess and respond route could cost you nothing if it works, but if the work is not the level of quality you need it could cost you scope and time when you least need those challenges. Being reactive could impact all three of your triple constraints. In our example by trying to reinforce the fiberglass it could mean you have to perform some redesign of the entire component and this probably would be expensive.

Whatever the case, it pays to analyze your risks before deciding which way to execute your response. Assess the impact of a risk and really look at how much control you need to put in place and when to get the optimal risk management result.

Adding and deleting risks from the plan

It is a very tempting and refreshing thing to do like striking items off of your to-do list at the end of your week. Striking risks of your risk plan that did not come up and bite you can be liberating. As liberating is that can be, I recommend you carefully consider how you manage the removal or addition of risks to your plan. Here are some of my thoughts on how best to make adjustments to your risk plan.

1. Clearly demonstrate when a risk has been bypass on your project. It’s good for your sponsors to know that something which was a concern is no longer a risk. If they can see that in black-and-white they'll have even more faith in your ability to competently manage the project.

Don’t delete them however, because when and how the status of each risk was communicated is useful information to refer to in future projects. In addition having carefully track your risks and was communicated about them is useful, if there is a change to your sponsor or key stakeholders. They can bring new or different perceptions about things that can impact your project.

2. I want you to ensure you capture close calls in your risk plan. Sometimes risks do not become issues because your project team performs extraordinary acts, or a last-minute decision by your sponsor or significant stakeholder saves the day, and circumvents the risk. These are close calls. You will want to ensure that information is captured completely, and in details for these close calls as they very important risks to remember. They are likely to occur again on the future project.

3. If you or another stakeholder perceive a new risk exists, capture it immediately. It’s important to document new or additional risks, even if they may be deleted in a short period of time. It will help you to pinpoint what happened and did not happen and which risks you should consider in future projects. It also helps you ensure you have all your bases covered and are perceived as listening to your stakeholders.

4. It is important to add risks that you didn't originally consider, either because of new news or you just overlooked things.

Adding risks that you had originally considered, even without the changes we've discussed here is the other project reality. Once you complete tasks and you have your task output, new risks can popup. You should always take the time to add these to your project documentation. this helps provide you with a master list of risks that you can referred to on any project you manage in the future, in any scenario.

5. Modify your plans and project task as appropriate to accommodate new or altered risks. New risks that are considered to help you and the team mindfully complete task or consider other approaches as appropriate. Being proactive with new risks can also lead to the reassignment of contingency money you haven't spent. Adding risks to your plan can help you attract these funds appropriately.

Your risk plan can be the most valuable permanent record of what transpired and did not transpire on your project. As such, it is a valuable document that could prevent you and your project management peers for having to relearn painful lessons. Capturing more detail versus less in my risk plan has always served me well and it can also save you pain and heartache.

For other articles in Project Risk Management, see also:

  • Project Risk Management: Creating a Risk Plan

  • Project Risk Management: Identifying Project Risks

  • Project Risk Management: Analyzing Project Risks

  • Project RiskManagement: Responding to Project Risks

  • Project RiskManagement: Monitoring and Controlling Project Risks

If you are looking for even more information on managing risk, I encourage you to check out some very insightful books:

Risk Management: Concepts and Guidance by Carl Pritchard is a great book that addresses risk concepts that can be applied to any project.

Here are good references for handling IT-based projects.

Waltzing with Bears: Managing Risk on Software Projects by Tom DeMarco and Timothy Lister

Managing Risk: Methods for Software Systems Development by Elaine M. Hal

 
 
 

Comments


bottom of page