See this discussion on LinkedIn under the Project Management in-depth study sub-group.

Risk Management is complex enough and in reviewing a link to a MindMap that had just a concept and then a little content, a longer risk discussion has started to evolve.

Mitigants .v. Management

Well, this should be pretty simple as a discussion, shouldn't it?!

After all, mitigants are one of the methods used to manage risk. They're part of the armoury at the project manager's fingertips.

Both of the above are correct but they're not the whole picture.

1. Project Managers are (should be) subject matter experts (SMEs) in the management of projects. This doesn't automatically make them  SMEs in the whole content of the project. Therefore it is likely that a PM will not be able to identify all of the possible mitigants to risks. Equally, they are unlikely to be able to identify all the risks on their own.
2. The PM has the arsenal of weapons that the Project Board gives them -I've been in too many projects where the project board really only gave me a lettuce leaf (and a floppy one at that) to try to mitigate some major risks - there was nothing substantial that they would allow me to do to help mentor the SMEs in the identification, analysis, evaluation, mitigation and management of risks. Too many was actually one or two projects in the same environment. I was expected to run the project without any risks, to time and budget but without any changes to scope or schedule as risks (that were not to be acknowledged) became issues that in turn impacted the time, cost and quality of the project.

Poor habits that I've encountered through my own mistakes and the approaches of others

• For some, management of risks is carried out based on the initial analysis and evaluations - they don't look at the residual risk once one or more mitigants have been applied. So a risk can be really high at initial identification but with effective mitigants becomes lower...
  What can occur is that the risks that have started off high remain the focus and those that can't be mitigated so well, that may have been lesser at identification but now have a higher residual risk are ignored or aren't escalated.
• Failure to inform the board of the overall number of risks in play - I've had times when I almost kept the numbers hidden (mostly as above where they were not to be admitted by the project board). If the culture isn't right then it isn't possible to manage risks. A classic case of the "Emporer with no clothes".
• For years, I have tended to present only critical risks to the Project Board.... Happily, I've recognised a weakness in this strategy....

Methods for successfully highlighting risk constellations to project boards

• I now present the most critical (highest score, closest proximity) and also provide a mapping of categories and criticality so that I can see where my projects' greatest number of risks are.... So it will show Critical, High, Medium and Low priority against the main categories (e.g. Strategic, People, Technical, Financial, Legal, etc). This now allows me to show where the greatest numerical risk applies - it's not just about severity of individual risks; it's also about overall exposure. 
• Simple visuals, 'cubing' the risk data through pivot tables so that the extent of the risks within categories and priority becomes really clear to the project board and team - "where's the overall risk concentrated?" is a question that can expose the program or strategic risk that a project is subject to.... The number of risks in a certain vector can be a risk in itself.
  
  
• This gives a very clear picture that the technical risks for the project are the ones to be managed and with four "lows" that could combine with the three "medium" and one "high" some serious work needs to be done in this particular vector. Traditionally, the project board may only have been presented with the two "highs" with the project manager and team needing to try and manage the rest. Armed with this constellation map, the PM can assist the project board in resourcing activity in the best vector for optimum result - the strategic high risk item is still important but the technical components need more action.

Ensuring that those who govern remain accountable for risk

This should be common sense - but all too often it becomes the preserve (or in fact demise) of the PM whereby the project board gives accountability and responsibility for risk to the PM. Day to day responsibility for risk management is rightly the PMs - it's part of what we are paid to do. However, bottom line is that the project board (or other aptly named governing body) has the final accountability to the project and to the organisation. Good communication of roles (preferably with role descriptions) should help to minimise the risk of poorly governed risk.