The Art of Risk Analysis

I’ve been involved in delivering projects for over twenty years now and during that time have seen the good, the bad and the ugly.  Stories of the good are sometimes brought up as “feathers in one’s cap”, the bad ones tend to be reminders of how challenging delivering projects when people, process and technology are involved but how about the ugly ones?

Those are the ones that are talked about the most and also the ones you wish to avoid at all costs.

One of the main goals for anyone leading a project is to prevent and mitigate bad events from happening even before they happen.  This should really be a goal for everyone involved in project delivery, with each person playing their part to share any news that would impact delivery to get it quickly exposed and resolved.

However, this is much harder to do than meets the eye.  One traditional way to find out when projects are heading in the right direction is to risk analysis.  Often, project leads do not spend enough time performing risk analysis activities, usually performing the activity early in the project and then spending little time afterwards, placing that much appraised “check in the box” in required activities in delivering.

Risk analysis is not considered a core part of Agile delivery, instead favoring daily stand ups to identify impediments and addressing them as they come up during the delivery cycle.  However, I’ve found few project delivery teams that don’t recognize the importance of reviewing risk independently and creating some level of a risk register as noted by Mike Cohn in his blog on Agile risks (http://www.mountaingoatsoftware.com/blog/agile-teams-and-risk-management).

There are many risk registers and recommend using the following fields and perspectives on their use.

  • Title – high level description of risk in as simple terms as possible
  • Description – Enough detail for every team member to understand, but does not include steps to solve
  • Probability – Usually given as a metric of 1 (low) to 5 (almost certain) based on 20% tier levels.  I’ve used 6 before when a risk has changed in an active issue impacting delivery.
  • Impact – Also given as a metric of 1 (low) to 5 (very high) with the same tier levels.  The product of the Probability x Impact should be your stack ranking of priority for addressing risks
  • Owner – This is often the ScrumMaster / Project Manager, similar to an impediment, but can be the team as the person who as responsible in closing the risk or with a consulting engagement may be owned by a key client member
  • Mitigation and Contingency Plans – This should include the actual steps to mitigate the risk as if it has already happened
  • Expected Duration – This should provide the estimated number of days the risk will last.  If this is a chronic risk that has been accepted as unavoidable (i.e. limited infrastructure availability so no QA environment), recommend still tracking it, but make the Expected Duration zero

Risk Analysis

Here’s the really important part.  To truly ensure proper risk management, the risk register should be reviewed on a regular basis (typically weekly but once a sprint is acceptable too).  The overall value of the register should be added up from the top 5 (or up to 10 for larger projects) and managed similarly to a product backlog.  Use the Expected Duration of those top 5 risks to measure progress in a Risk Burn chart, which will be discussed in more detail in the next blog.

Risks exist for any delivery and should be carefully reviewed and managed on a regular basis.  To ignore risks is to ignore the future of your project health.  Consider prevention and the awareness level brought by regular, organized risk reviews in order to detect and mitigate those risks before they grow and further damage the success of your delivery.

Advertisements