Efficient Project Risk Management

Risk management is a commonly known practice within project management. In the specific context of IT, it can be either neglected (just omitted), seen as a burden, misunderstood or falling under criticism for having no concrete means to measure its benefits. PMIs gurus / addicts will fall from their chairs but I guess many people will tend to agree with this: IT projects fail… a lot, and risk management has more frequently been an epic fail than reached its promises. As an obvious reminder, risk management does relate to the strategies to manage risks. It does typically include identification, assessment, and prioritization of risks followed by coordinated actions to control them.

I’m not saying to abandon risk management, it is a mandatory component of every project manager’s toolbox and does represent a very sane and useful exercise when conducted properly. Uncertainty factors are very common and I cannot insist enough on the fact that all actors involved in IT projects should not fear the change but welcome it. Some initiatives have been launched to adapt or extend the risk management discipline to IT projects (Risk IT of course but even SWOT is an interesting alternative). They generally are in their early stages or focusing on IT Security too much (threats on assets and IT systems for instance).

One willing to perform efficient project risk management should consider the following criteria:

  • The process used should be lightweight. It’s a common practice to say that “the gain should exceed the pain“. Common sense tells that you don’t want to be spending 30% of your time in the activity of maintaining risks management plan
  • The reporting should be efficient, straight forward and an executive summary should be accessible. Overall, it should be very visual, the granularity of details should be adapted to the audience. Transparency is key. Whoever wants to access them should be able to do that anytime, you might want to store it as part of your online project documentation
  • Risks management procedures should be detailed and explained. Users, contributors (the PM is not the only one responsible for this) should be educated. Why are we doing this? What are the outcomes? What are people responsibilities?
  • Strict monitoring and efficient action plans to avoid, mitigate, share, or transfer the risks should be project manager’s obsession. Tracking risks for the sake of tracking them is a pure loss of time
  • The process should be iterative and done on a frequent and regular basis: all stages (identification, assessment, handling, monitoring) should be repeated and reevaluated
  • The risks management plan should be capable of handling the changes and continual improvements. A risk is not static!

Once we said that, a risk is defined by seven attributes: a description, a likelihood, an impact, an advancement, a category, an action plan and a rank. An Excel Spreadsheet will do the job!

An efficient risk management matrix will be like the one below and meets the above criteria. It is linked with a list of referentials that PMs will update according to their needs.

Risk Matrix Sample

  1. Description: provides a comprehensive and accurate description of the risk
  2. Likelihood: estimated probability of the risk to occur
  3. Impact: impact on the project. Consequences (financial, technical, planning, etc.) if the risk becomes a certainty
  4. Advancement: tracks the lifecycle of the risk (from its identification to its resolution)
  5. Category: allows segmentation of risks by categories. Useful to present an aggregated version to executives who do not need to dig in all risks details. Categories should ideally be discussed and validated with the steering committee
  6. Action plan: description of all actions to handle and mitigate the risk
  7. Rank: Computed field. Rank = Likelihood * Impact * Advancement: The higher the rank, the bigger the problem!“. You might want to sort risks by descending ranks to put appropriate means and communications on the top ones. The advancement is added to the equation as one way to remove risks that do not longer remain. When summed for all risks, ranks allow monitoring at project level

Some people recommend a unique identifier for a risk, up to you, it could be an additional attribute. In my experience, the above file is sufficient.

Risk Referential Values Sample

The referential above should be tailored according to your needs, enterprise vocabulary and expectations. I usually encourage keeping things simple (not too many values) and putting smart weights (a blocking risk should clearly be differentiated from a medium one, i.e. with a much higher weight).

Next to this raw matrix and to make it more visual I finally recommend two representations: a dashboard spider chart and a risk burndown chart. The first one gives a visual understanding of risks by categories (for instance biggest risks concern architecture: it will appear very clearly). The second one displays overall project risks throughout time (remember the risks monitoring should be done frequently), hopefully the trend should be decreasing… This is not per se a burndown chart and more to be seen as an analogy (as prediction on when a risk will be handled is very difficult, almost impossible).

Risk Spider ChartRisk Burndown Chart

 

 

 

 

 

 

All materials mentioned in this post can be found in this Risk Matrix. As usual, feel free to enrich and react!

About the Author

Donald Havas

French technical evangelist and blogger with extensive working experience in the technology industry field (corporate IT, professional services and product development). Passionate about software development processes, innovation, new technology & industry trends and the gaming industry. And promoting simplicity and pragmatism on top of everything.

Visit Website

There are no comments yet, add one below.

Leave a Comment

Your email address will not be published. Required fields are marked *

*