I'd be interested to discuss Project Risk Management with the M-T community. I find that it is a difficult thing to manage well. 

[For anyone wondering what is meant by Risk Management - the idea is to think about what the project is assuming will happen, and to make decisions about how likely that is to prove wrong, and how bad that would be. Then there's usually a review process to check whether the bad thing is looking more likely than before, and to record who is doing something about this,  if there is action to take]

There are plenty of tools and procedures to collect risks from the project team and record and manage them, but I've been dissatisfied with a lot of these. It seems to be easy to end up with a lot of documentation to maintain and discuss regularly at meetings, without anything very useful coming from it. Manager-Tools seems a likely place to find someone with a lightweight, effective tool for this!

What seems to go wrong (surprise, surprise) is the people side:

  • Things go on the risk list that are risks to any project and would be dealt with by standard management  in the first instance (all those items that boils down to "what if X does not get their tasks done on time?") Tracking these through a risk management process may be a waste of time, if other aspects of management are being done well
  • Things go on the risk list that no-one has any power to do anything about
  • Group-think rears its head & prevents the team from seeing some of the more interesting risks
  • It is difficult to get the team to engage  - they see risk management as a Meaningless Management Ritual, and it can use up a lot of capital and energy to get them to participate.Probably that's to do with people's earlier experiences of long rambling risk meetings and risk logs, which didn't lead to anything useful or actionable....


miketickle's picture

 My focus is always on - what can we do about it. E.g. Shipping might be delayed over Christmas- ok we'll order early for pre Christmas delivery. I find little value in a long list of things that might happen that we have no controll over. Except when an uncontrollable event might warrant some thinking on what to do should it happen.

I will type more when not on the phone 

gearhead86's picture
Licensee BadgeTraining Badge


We've done this successfully in our group.

1.  Hold a quick brainstorming session to identify risks.  Recommend that you write each one on a sticky.  

You can even have everyone grab their own stack of stickies, write them down  and stick it up on the wall.  It avoid group think and gets everyone in the game.  Remember, the peanut butter rule applies.  Of course, there's a pod cast about that (actually, at least two):

2.  Take each note/risk and rate the impact  High-Medium-Low.  Do it quick -- not a lot of analysis.

3.  Repeat process and rate the probability High-Medium-Low.

4.  Focus on the High-High risks and come up with mitigation strategies.  You can probably come up with a few on the spot.

M&M describe a similar technique in the Hot Wash podcast.

It worked for us -- we were able to complete the risk identification in less than an hour.   Everyone came out of the meeting energized and I felt we captured most of the relevant risks.

Good luck!



ChrisBakerPM's picture

 Thanks  MIKETICKLE and  GEARHEAD86 ! The theme emerging seems to be - <i>Make it a task if possible</i>. If it becomes "Who does what by when" then standard project management systems ought to get it done. 

Can I try writing up how I see it now, for your further comments? I now think it should come to one of:


We've decided to do [task] about this: here it is in the plan [with date, responsibility]

We've decided it's more appropriate to assess this later when we will have more info: here's the review task in the plan [with date, responsibility]

[for some risks and projects ] We've decided to do nothing about this risk ( the counter-measures are so unreasonably expensive or impractical compared with the risk  that we'd rather have the bad thing happen if it is going to & then react as best we can). That means the project could fail if this risk happens, check that is OK with the organization?

We've decided to review for new risks or anything substantially changes at these times [here they are in the plan....]


I think that was what I was groping towards earlier - the thing that doesn't work about risk management for me is a long list of rather academic-seeming risks, with no realistic action plan. That gets exacerbated by having a risk management process that requires you to review all this stuff repeatedly and decide whether the probability or impact have gone from 5 to 8, or from 9 to 7. Some people love that kind of thing (like thinking about the project abstractly as a relief from doing tasks; like stuff on the risk list for potential "told-you-so" later; like making complex tables and spreadsheets). But it can become an academic exercise that adds little value.


Here are examples of 1,2,and 3 above (in case that's helpful):

Agree an action now: : "Shipping might be delayed over Christmas- ok we'll order early for pre Christmas delivery." Get that into the plan and no further action ought to be necessary (unless a new risk pops up - e.g. supply disruptions in early winter exacerbating the usual Christmas problems)

Make a task to review the risk at a certain "red flag" date -  e.g. we decide to try an experimental new approach. We think it will work out, but can't be sure. We set a review date to decide whether this is working out for us. The date needs to be early enough for other options to be feasible.

Do nothing - There's a further class of risk for many projects (those that could in the last resort be allowed to fail without significantly damaging the business, causing  an environmental disaster etc.). Risks that no-one should run when handling, say, explosives, pathogens or credit card data might be OK for a project to publish a new textbook. So in many projects, the organization might choose to run the risk, because doing so brings very significant benefits. For example,  you decide to have work done in California and Japan, and take the earthquake risk: there are no suitable facilities in other areas. Or you decide to contract to an excellent  small supplier, running the risk that  the entire staff of 3 is tragically wiped out in a car accident on the way to your next risk meeting. Yes there are things you COULD do (find other suppliers, take out insurance, buy the small supplier's company...). But for some projects, it could be entirely rational to do nothing about the risk, because the precautions add more cost, work or delay than the value of the project. So we need some way to decide this, note it and move on. That does mean that the organization is willing to see the project fail if the risk comes to pass (it might be impossible to complete it at all, or only with significant delay or extra cost). 

Thanks again everyone - interested to hear further ideas, but this has already been very helpful.

miketickle's picture

Sounds like you have a good grip on it.  Taking it to the next level you can start to include your risk management techniques for specific risks in to the way you do things. 

There is a risk Bob will be called in for an op some time in March and when he does it will be a next day appointment and then a few weeks off.  If this risk occurs his work will stall. 
Treatment plan: Bob to keep a short daily log of where things are up to. Bob to keep his calendar up to date and shared with the team so the project admin can arrange for meetings to be cancelled / rearranged / attended by someone else. Bob to meet with his boos and direct to see what work goes up, what work goes down and what stops when he is out.

Then in the end of stage lessons learned session you might notice that having shared calendars is really useful as everyone knows were folks are and if someone calls in sick meetings can be rearranged/deputised.

I had great fun on an ESI Project Management Course where oner 4 days you run through a scenario.  We did some risk brainstorming in the first session and that flagged up snow as a risk to good being delivered by trucks, and an indecisive customer as a change control risk.  So we agreed change control process in the proposal back to the customer/course tutor and we got the heavy kit on early order.  The change control stood us well but the trucking was lucky.  In the scenario there was a trucking strike - but by the time it happened we had out stuff.  Those two things hit the other groups hard.

That's the challenging hing about projects - you never get to see what would have happened if you had done things differently.



6 3 4 2

ChrisBakerPM's picture

 I'm finding that hammering out risk reduction steps into a "who does what, by when?" task has further advantages. Risk reduction is almost always work for someone. Getting to  "who does what, by when?" concentrates the mind on whether the work of the proposed risk reduction is actually a good investment, as opposed to an idea that sounds good.  It's not cost-free of course: beyond a certain point you start risking the activities you are already doing, because people are distracted by the additional risk-reduction work , or the work you brought forward to reduce risk. 

Alex_W's picture

I came by this thread, which is a bit stale now but it is a worthy topic to pick back up.

For those of us PMP-certified, or PRINCE2 even, I wonder about the usefulness of a PMP-Risk certification, not the academic knowledge which goes along with it, which is of course good, but the need for this cert in the job world.

While there are some good certs out there, like the PMP-Agile and PMP-PgmP, and I'd like to get all from a professional and a personal interest perspective, I can't afford them and in case of Agile, don't have the time in work to qualify.



ChrisBakerPM's picture

 Hi Alex_W! I can't answer your question specifically. I don't recall ever having met anyone with the qualifications you describe, but I don't know whether that is significant.

The only potentially helpful thing I can offer is a general thought about certification. I think that one can reach a point of diminishing returns about getting more certificates. This point can be hard to find. One reason for that is that for some people  the opportunity to do more courses and learn more academic stuff is always palatable. Similarly, for others the palatable thing would be to grow their network, or further improve their presentation skills or grooming etc. It can be fun to pursue further something you are pretty good at already. If you can afford the time and money for it and are in the position to think of it as an interest which might pay off one day that is all very well. But usually if you do one thing, you don't do another. If your motive is career ambition, or if you MUST do something effective (e.g. you've been laid off & must find another job before the savings run out) then I think you are right to ask whether you are certificated enough and doing something else would be a better investment. 


pburns's picture

I know this is an old blog but my advice is at the start of any risk assessment emphasise that at the end of a risk assessment session we should be identifying the risks that keep you awake at night and if we fail to do this, then the session has not worked. Depending on the area you work in you should also consider emphasising that may risks are based on perceptions as opposed facts and figures. Finally tell them that we usually base are assumption on the past and that is always wrong. if you go back to 2007 no one thought we would be in a global meltdown.

sheryl22's picture

As I can summarize

1. Identify risks by brainstorming - Peer Reviews, Expert Reviews

2. Mitigation action - Who and When

3. Follow Up regularly - Personal and others.

4. Update the risk tracker along with the project milestone progress and Report status.

(1)We have a Severity and Impact matrix for risk tracking for project. I would create one and forget it later amidst the urgencies ( Reactive vs proactive).

(2)We even have a tool to record timelines and responsibility for Risk mitigation actions. Now imagine, the same tool is used and Abused to 1000s of other action items from meetings ( I am a Sustaining Engineer with multiple Stakeholders). I missed acting on one of the identified risks with a medium impact and regretting the same.

I am thinking loud on how to mitigate the most important actions pertaining to risks. Team meetups help, but once a portion of work is delegated ( Electrical for me), no one cares until it is done ( I am entrusted at a project management level and not task level). The mitigation actions are left to me. I hear some of you saying 'It s discipline'.

Thoughts ?