I have analysed the possible risks of my project, and I do intend to get back to them from time to time and make sure that the project is safe.

I am trying to figure out how often I should check them, trying to avoid risks as much as possible, while spending not more then the necessary time.

How often should risk management be analysed and tracked?

  • Do you have any methods where you quantify risk and determine when processes are out of control? If so, it may translate to a six sigma type problem and more information would be needed. Commented Mar 28, 2011 at 18:54

4 Answers 4


Risk management is an ongoing process. Both Ashes and David have pointed that out clearly. Some of my own practices are:

  • My top 5 risks are always on my radar (as are my top three issues, but that's another matter)
  • During weekly status or sprint planning or other team meeting I encourage team members to express whatever concerns they may have, justified or not, in order to capture new risks early.
  • The whole risk register is reviewed weekly; I check up with risk-owners how their mitigation or other actions concerning their risk(s) is going forward as planned. When we come close to the specified time-range of a risk (if it has one) I notify the risk-owner, etc.
  • Risks and their reduction are discussed during each SteerCo meeting as well.

Your total risk exposure should decline over the course of the project. That means it has to be actively planned and managed that way.


It depends on your project. At a minimum, I would recommend reviewing them once a week. Your goal in a review is to:

  • Identify risks that actualized into incidents
  • Identify new risks that may occur
  • Drop old risks that can no longer occur

If your project can tolerate it, and will benefit from it, track risk more frequently. In Agile software development projects with two-week release cycles (small, frequent releases) we used to track risks daily. The best risk updates were "nothing new here."

Also, it's something of a best-practice to have the whole team help in identifying and monitoring risks, not just the PMs.


The identification and its subsequent risk analysis and COA decisions are ongoing. Your risk capability should have a vehicle in which each and every project team member and other stakeholders can escalate a potential threat on a daily basis. This part of the process should not be "scheduled", but rather simply a fluid trigger.

Each discrete risk captured on your risk database has its own schedule for progress updates, briefings, and oversight. Some will require daily updates sequel to the threat and overall exposure while others may only need monitoring on a monthly, quarterly, or other basis. The team assigned to mitigate can recommend the schedule and PM can put a requirement out there, too. The points here is to let the threat dictate reporting and update requirements.

Formal update briefings to leadership and client can be scheduled on a set frequency. No right answer here; it will depend on many factors and, of course, overall agreement to all the parties involved.

  • Capturing risks is something team-members usually need training on and scheduled time for -- especially if you do it right, and you end up with hundreds of risks. Expecting it to be fluid is great, but it rarely works out that way in practice.
    – ashes999
    Commented Mar 28, 2011 at 13:42
  • The project's risk manager controls that. The fluid escalation is absolutely necessary. The risk manager will help newer resources define the threat, weed it out, or do whatever to control what ends up in the queue. Without it, you will close the door and inhibit risk identification. It works if you have a good risk manager. Commented Mar 28, 2011 at 18:49

The other answers are correct; I don't disagree with them. I would like to add a couple of supplementary notes.

First, the frequency of updates depends on the size, complexity and velocity of the project, and on the priority your stakeholders give to risk management. Yes, risk management should be continuous, but if the project is not staffed for a full time risk manager, you're going to have to fit the updates in as time permits. Remember that the critical thing you want to do is to warn your stakeholders in time to productively intervene. If your work packages average a week long and you've got a dozen or more in progress at any time, then monthly updates will not permit timely intervention. If your work packages extend over multiple quarters and you've got only a few in progress, monthly may work.

Second, although I update my risk registry monthly, that's somewhat deceptive. The driver is that each risk has an urgency; I mark each risk with the date of next review. Some high level risks (high probability, high impact) don't vary by much. Some risks are dependent on political events that have very fixed deadlines and won't change till then. If you capture the urgency of the risk as the next date on which it could potentially change, then you can review the risk registry very quickly/economically.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.