Project Management

How to Monitor Risks

From the The Money Files Blog
A blog that looks at all aspects of project and program finances from budgets, estimating and accounting to getting a pay rise and managing contracts. Written by Elizabeth Harrin from

About this Blog


Recent Posts

Establishing the Performance Measurement Baseline in Earned Value Management

How to Create a Project Budget Step-by-Step [Infographic]

Books for Building Power Skills

3 Challenges That Risk Management Helps With [Video]

Components of Earned Value [Infographic]

Categories: risk

So you’ve created a great risk log, worked out what your risk responses are going to be and made a plan to get those actions done. But how do you check whether your risk response plans are having the desired effect?

The thing I see a lot of project managers doing – especially early on in their careers – is setting up the action plans for risk management and then not going back to check that the risk is actually being addressed. It’s one thing to ask people to take action. It’s another thing entirely to check they’ve done it, and to make sure that the actions you planned have actually addressed the risk in the way you want.

The thing with risk is that even if you do address it with an action plan, you might still end up with residual risk – potential problems left over after you’ve done your ‘main’ actions. And you need to understand what those residual risks are and what (if anything) you are going to do about them.

Last time in this occasional series on project risk management, we looked at how you implement risk responses. Today we’re looking at the monitoring part: the step in the risk management process where you double-check to make sure that your action plans are effective.

What to look for

The point of doing this process (the Monitor Risks process) is to make sure that the current level of risk exposure, taking into consideration any actions you are doing, is still OK overall. You’re looking for new risks, changes in risk status (because some might be getting more serious or less impactful for your project).

Also look out for:

  • What assumptions did you make about project risks that need a review? You might have more information now or you may need to include new assumptions.
  • What risk management policies do you have and are they being followed? Would it help to update or revise procedures in some way?
  • Are stakeholders still happy with the level of risk? The overall level of risk might change (and often does) as the project progresses because more risks are uncovered and that shifts the balance. Check in to make sure you are still in line with stakeholders’ expectations.
  • How much contingency or risk management budget is left? Is it being used in the way that you expected? Do you need to ask for more and if so, how are you going to justify that?


The inputs to this process are:

  • The project management plan, and in particular, the risk management plan section
  • Project documents including the issue log, the lessons learned register, the risk register (because this is where you will have written down what you are supposed to be doing) and risk reports (if you create them – I typically don’t, I just write down the details in a column on the risk log)
  • Work performance data and work performance reports – in other words, have the action plans been implemented?

Tools and Techniques

The tools and techniques for assessing whether the action plans have had the impact you expected are going to depend on how you can judge success.

However, there are some common things you can do to review and the kinds of tools and techniques you can use include:

  • Data analysis techniques like technical performance analysis (to compare what you have done against what was planned in a tangible way) and reserve analysis (to see how much money you’ve got left).
  • Audits - my recommendation is that you get an impartial person to run this for you instead of trying to review your risk processes yourself. Ask the PMO or a trusted colleague.
  • Meetings (because who doesn’t love a good meeting to discuss all the things that might go wrong on the project?)

Pick and choose the tools that will let you assess the impact of the risk (again) to see if it’s all squared away or if there is more you can do.


The outputs of this process are:

  • Work performance info
  • Change requests (because your new plans might involve adding or removing tasks to your project schedule, for example, to do a few more risk response actions)
  • Project document updates, especially to the project plan, assumption log, issue log, lessons learned register, the risk register and risk reports
  • Organizational process assets that might need updating e.g. risk template or your IT system, workflows etc.

Another output is doing the tasks to address the residual risks or any other actions you’ve uncovered to make sure that the risk responses are getting implemented as planned.

This process is something you can do on a regular basis. I put time aside in my diary to do a review of risk, normally once a week as I’m updating my project documentation. Then once a month I’ll try to work a risk conversation into our project team meeting – sometimes we only talk about one or two risks, the ones that are the most important at the time or that are likely to happen soon.

Use your judgement – this process is only there to prompt you to constantly keep your risks and management activities under review. If you keep risks front of mind, you’ll be fine.

Pin for later reading

Posted on: May 18, 2021 08:00 AM | Permalink

Comments (11)

Please login or join to subscribe to this item
Dear Elizabeth,
You said this "The thing I see a lot of project managers doing – especially early on in their careers – is setting up the action plans for risk management and then not going back to check that the risk is actually being addressed"

I am wondering if this is not coming from the discouragement of planning for risks and having just few occur?

Hi Elizabeth, great article! One of the things I have observed a number of times when working with certain groups is the tendency to copy and paste the risks from project to project without any changes. Sometimes this is due to a lack of training, and other times due to being time poor.

Hallo Elizabeth, wonderful article indeed! The observation made in the Tools and Techniques portion about Audits is what I completely agree with. I also find it extremely important to keep a constant tab through established systems of reviewing the tasks of addressing the residual risks and adequacy of those tasks at regular intervals.

Risk management is all about planning ahead. At the same time as risk responses are planned, it is important also to define a) the expected effect of these actions as well as b) ways of measuring their effectiveness (tools, metrics and targets), and c) contingency actions to be envisaged if the response actions are not sufficiently effective.

Dear Elizabeth, quite correct, putting actions to risks is key. What works for me, especially with larger projects, is to have a weekly risk meeting with a coalition of key stakeholders. Although, I run it like a scrum stand-up, where discussions are short and measured. This does not lead to long-drawn meandering discussions. We look at the high, highest ones first and callout the actions. Those actions important enough to be shared with the larger scrum meetings, I transfer to the project action log and address at the scrum. I then take the key risks and table it at the weekly scrum of scrums and steering committee for executive awareness and steer.

Thanks, Nishka Harase

Making risk management a priority in each project meeting actually helps quite a lot while developing the right culture and attitude from each project stakeholder around this critical project knowledge area. Introducing the routine of reviewing the risk profile (graphical representation instead of only the tabular and/or PowerPoint version) is a great and an easy mechanism for having every project contributor understanding that a proper risk management cannot be ignored as it is critical for the project success.

Dear Elizabeth, projects on new technologies are fraught with many risks. The guidelines given by you should be useful for all concerned with project success.

Dear Luis,

For risk management on a project, it is particularly important for contributing stakeholders to be guided by a strong culture that shapes the mind on how to treat risks. For far too many projects, the lack of proper governance lends itself to filling in a risk log because it is a requirement of the PMO for example. Not that there is anything wrong with that, but treating a risk must yield the required results.

I agree to the observation that filling up the risk log more as a process of fulfilling the requirement of PMO without proper governance will lead risk management to more of a ritualistic affair and will not serve the ultimate purpose of risk mitigation.

Thank you for sharing, it is a good article.

In the article you mention "residual risk". I would like to add a mention of "secondary risk" as well.

Below I copy text (with permission) explaining the difference from the book "Bullet Dodging - A Risk Management Handbook for ICT Projects"

"At the initial qualitative risk analysis stage, we are only looking at the inherent risk. But we should be clear at the outset on the different types of risk scores. To take a simplistic approach, for most projects, there are three important risk scores to consider. The first is the inherent risk score, the second is the residual risk score, and the third is the secondary risk score.

Inherent risk is the risk that exists before any controls or other mitigating factors are implemented (the gross risk or risk before risk response plans are implemented). This is the risk score calculated from the probability and impact before you’ve done anything to affect them.

Residual risk is the risk that remains after you’ve implemented a risk response plan. It’s the risk remaining after you’ve taken action to remove the source of the risk, change the consequences, alter the probabilities, transfer the risk, or accept the risk. For example, if your risk response plan for a risk was to mitigate the risk, your residual risk will be the risk that is left over after you have reduced the probability and/or reduced the impact.

Secondary risk is a risk that arises as a result of the risk response plan that you enact for the inherent risk. It is the new risk that has been introduced by enacting your risk response plan. For example, if your risk response plan for a risk is transfer by engaging a third-party vendor to do a portion of work, you are introducing a secondary risk that the third-party vendor may fail to meet their contractual obligations."

The idea of secondary risk is quite applicable not only for the ICT projects but I think for any other project where an agency gets involved for risk treatment action.

Please Login/Register to leave a comment.


"A good composer is slowly discovered. A bad composer is slowly found out."

- Sir Ernest Newman