The Risk Management SIG (RiskSIG) provides forums for the professional exchange of ideas on a myriad of topics related to the management of risk in projects. Experts and practitioners from Public and Private sectors share their knowledge and experience.

The Risk Management SIG is in the forefront of developing concepts and ideas. Members share their "Lessons Learned," practical ideas and real life solutions that you can take back to your organization.

The Risk Management SIG will help you gain valuable new perspectives for implementing risk management in your projects. Professional interchange with experts from various industries will broaden your view of risk management and serve to improve your management of projects. 


Announcements:  Please forward any announcements to


Q - What are good alternatives to a heat map?

First, what is a “heat map,” and what is wrong with them?  A heat map is a matrix of cells often colored to indicate risk severity using red for the highest priority risks.  The size of the matrix can vary from 3 by 3 to larger sizes, arranging the cells using rows to indicate probability categories and columns to indicate impact categories from highest to lowest (or vice versa), with the least important risks clustered in the lower left cells and the most severe risks gathered in the upper right.  A five-by-five cell example:










The first issue with heat maps is with defining the categories.  Probabilities are percentages, so the most obvious way to define the rows is to use “quintiles:” Under 20%, 20% or more but less than 40%, etc. While this works, estimating percentages is difficult, especially for events that occur infrequently. Also, people tend to underestimate probabilities for events (often significantly) that have unpleasant potential outcomes.

Categories for impact are even more problematic, because project risk consequences can involve time, money, effort, or any of a large number of other parameters that may be both hard to estimate (things such as loss of reputation or future business, or creation of conflict) and very difficult to compare.

Added to this, heat maps also carry an implication of symmetry, with the “high impact, low probability” events in one corner of the map equated to the “low impact, high probability” events in the opposite corner.  In fact, this is never true; high impact potential events—regardless of perceived probability—always warrant more attention than risks having trivial impact.

So, what is an alternative to a heat map? 

Many prudent project leaders instead rely on a prioritized risk register using a table, spreadsheet, or database.  This method still requires assessment of probability and impact for each risk event, but it allows comparison of adjacent risks on the list once they have been sorted using some variation on “Loss times Likelihood.”  If the rank-ordered list of risks appears inappropriate because a risk that deserves attention falls below a risk that does not seem quite so dire, it will encourage discussion and adjustment of the estimates for probability and/or impact, possible redefinition of the risks, or other actions that will result in a deeper understanding of project exposures and better guidance for risk responses.

Other alternatives, particularly for risks that carry high potential consequences, include detailed worst-case assessments, root cause “fishbone” analyses, bow-tie diagrams, and Monte-Carlo simulations.  All of these techniques will expand understanding of project risks and avoid the “single point,” deterministic-looking assessments implied when placing each risk into one specific cell in a “heat map.”

 - Tom Kendrick, RiskSIG Director, Region 2 (Western Americas)


Q - How do you choose your risk categories to enable reporting?  Do you use a formal Risk Breakdown Structure?


In my opinion, the final answer to this question largely depends upon the organization’s project and risk management maturity level.  It’s which journey is taken that varies.  In either case, an RBS or checklist is always the best.

For the more mature organization, project history files should exist. Knowledgeable business experts can be readily identified and interviewed.  The files should also contain information about what went right and wrong, lessons learned, etc. These sources help establish the baseline RBS and/or checklist that captures recurring events within your particular business environment that should be considered. It is then just a matter of diligence to keep these products up to date/expanded to incorporate new experiences.

For the less mature organization (the mature one can consider this as well), generic industry based checklists can be an effective starting point to build the initial RBS, as well as discussions with experienced PMs within the organization.  Like before, keeping these work products updated with new experiences is critical.

In both cases, a formal RBS is advantageous, as it ensures the project team routinely focuses on a given set of potential areas for examination.  It relieves them of the need to expend critical time to “re-think” the routine ones, and thereby provide more time to creatively examine the effort for project unique conditions.

     - Craig Peterson, RiskSIG President

I would also add that it is always a good idea to review recent projects to diagnose any significant problems that were encountered.  For any cases of schedule slippage, cost overrun, overtime required, or other issues, use root cause analysis and other techniques to ascertain why the problems occurred.  For any situations that could recur on current or future projects (which will be most of them), ensure that the identified root causes are listed in your risk register and RBS templates.

   - Tom Kendrick, RiskSIG Director, Region 2 (Western Americas)


The articles or comments published in the RiskSIG newsletter or on the RiskSIG web site do not necessarily reflect the views of the Risk Management SIG.