Better Risk Meetings

I have lost count of the hours of my life I have lost in risk meetings where someone has ground through the risk log line by line. Each risk having to be explained in detail, as the description was ambiguous, and then the ensuing discussion (ego fight) over what the probability and impact should actually be and who knows best. Ten minutes later, once everyone had agreed to leave everything as it was, the next risk would go through the same treatment. While all this went on, one thing wasn't happening - nobody was doing anything about them.

Years a go, I came across a useful expression:

Get the frogs off the log

Risk only disappear if you take action. Risk meetings need to be about taking action not grinding through a risk log.

A better approach.

Concentrate on creating action plans and getting these into your plan, sprint log or product back log (as executing any action will take effort).

  1. Before the meeting, get participants to privately identify or brainstorm any risks in their own words.
  2. Everyone presents their risks and these are put on a board or post-its or whatever.
  3. Risks that are the same or have same root cause can be combined.
  4. Triage the risks and decide if anything is going to be done about them. 1 It is important to agree if effort is going to be spent or not. If not, stick the risk in the bin and don't waste anymore time on it.2
  5. For the remaining risks, brainstorm and agree an action plan3. It is important that all stakeholders agree who is doing what and commits.

The action plans should then be fed into the project plan or product backlog 4 as they may have a material impact on the effort or project timeline. The project owner can then decide when or if they are going to spend that effort. Impact and probability can play a part in making that decision.

Where an action plan mitigates a risk, but doesn't completely prevent it, a contingency budget and project plan B should be developed for when or if the risk strikes.

Tackling risks has a cost that needs to be met and be clearly visible to all.


  1. They may already be being dealt with. ↩︎

  2. Participants can bring a risk again to a later meeting, either in a different disguise, or because the project environment has changed and it has become relevant. ↩︎

  3. This may be to remove the risk or to mitigate its impact. Not all risks can be neutralised totally ↩︎

  4. By tagging these you can easily generate a 'live' risk log without the need of a separate list ↩︎