• Exclusive updates on:

# Visual Risk Management

by Vikas Hazrati on Apr 13, 2010 |

Irrespective of the size of the project, stakeholders feel confident when they can a keep track of the risks and their mitigation strategies. Agile heavily promotes the use of information radiators. Keeping in line with the philosophy of radiators, Agilists suggested different ways of depicting risks visually for easy tracking and mitigation.

Denis suggested that one of the best ways to visually represent risk is to use a Risk Heat Map. In this map, vertical axis represents the probability of a given risk occurring. Horizontal axis depicts the impact that the risk will have on the project or program should it materialize.

According to Denis,

One of the benefits of this method of displaying risks is that it’s easy to see how risky the program or project is. If all the risks are clustered in the top right of the diagram then clearly your managing a very risky program or project.

Likewise, Mike Griffiths suggested that risks could be visually tracked using the Risk Profile Graphs. Risks in the risk profile graphs are stacked on top of each other on the basis of their risk severity.

Risk Severity = Risk Probability X Risk Impact.

The risk severity scores for each risk are plotted one on top of another to give a cumulative severity profile of the project. When risks and their history of severities are displayed like this it is much easier to interpret the overall risk status of the project.

Mike Cohn suggested the use of a Risk Burndown Chart. A pre-requisite for this technique is the calculation of risk census. The census is merely a list of a project’s top risks along with the probability of the risk occurring and the size of the loss that would occur if it did. Mike suggested that the projects should use the top ten risks of the project for the purpose of census.

As an example, suppose a risk has a probability of 20% and if the risk materializes then the number of days lost are 15. Then the risk exposure if 20% of 15 which is 3 days. The risk burndown chart is then created by plotting the sum of the risk exposure values from the census chart.

Ideally, with each passing iteration, the cumulative risk should come down. If it is not coming down then there is a need to allocate some dedicated time in the sprint to focus on mitigating the risk.

Hence, though visually depicting risk might not seem as important as the story burndown chart, but it is equally important. As Mike Griffiths mentioned,

Tracking the reduction of project risks is a metric that is useful on projects, it is not a core metric like features delivered, but one we are actively trying to control and relevant to the goal of delivering successful projects.

Rate this Article

Relevance
Style

## Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

## Get the most out of the InfoQ experience.

### Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Agile Risk Board by jc grosjean

Interesting.
To visualize the (agile) risk management, you also have the "Agile Risk Board" to place on the information radiator too.
The description here:
www.agile-ux.com/2009/07/23/agile-risk-board/

Agile and Risk by Chris Matts

Agile seems to have a strange relationship with risk. The reason I use Agile approaches is because they offer much more sophisticated tools for managing risk, namely real options. Given the level of sophistication of Agile I find it amusing that "best practice" for agile risk management is to create radiators.

Identifying a few obvious risks and displaying colourful graphics is not risk management (The equivalent of flying a flag up-side down). For each identified risk, you need to understand how long you have to recover from the realisation of the risk and then implement options to ensure you can recover in that timeframe.

Risk management is active. Its a discipline.

How long before people take risk seriously instead and look at proper risk management rather than simply displaying RAG status ( something that pointy haired management types have been doing for years ).

Lets not overdo things by aditya yadav

I humbly like to put forward a point that Agile techniques are a means to an end (Business Goals) there is a very thin line between doing Agile well and overdoing it. I for one am not a purist but a pragmatist.

e.g. One of our Global Financial Institution clients once told me "You cannot put up cards on the wall because thats not allowed but if you want I can give you touch screen LCD monitors, as many as you want and then you hook them up with Mingle" A wall is a priced commodity, lets use it carefully, every team need visualizations close to their area. How much of wall space do we intend to use?

This is the last thing I plan to put up there. I would rather putup things like cross project dependency walls, architect and analyst card walls, approval/deployment statuses if I had the freedom to.

My 2 cents.

Aditya Yadav
Aditya Yadav & Associates
Amazon Cloud Computing With C#/.Net
Amazon Cloud Computing With Java
Understanding Programming Languages
Deploying HTML5
Essays on SOA AND EAI - A Pocket Guide

Important to manage risks visually by Dave Nicolette

IMO it's important to manage risks actively and continually as Chris points out. At the same time, I appreciate Aditya's advice to avoid overdoing things. I usually have a visual indicator of risks and their status in the team room. The article presents some useful formats, and there's another useful one based on the work of Lister and DeMarco. One example is here: www.agile-ux.com/2009/07/23/agile-risk-board/

I like simple tools that serve their purpose. Some of the approaches described in the article seem a bit complicated. I find a couple of rules of thumb useful for keeping things simple while still keeping up with risks:

1. At the team level, a "risk" is a potential blocker to delivery. Some teams dump a lot of other types of items into their list of "risks," like "We haven't used Oracle before," or "We don't understand the full scope of this feature set." Those aren't risks at all, they're just things to learn. So, one way to keep things simple and focused is to remove items from the risk board that aren't really impediments to delivery.

2. Don't think of risk cards in the same way as story cards. A risk should have an individual owner, a mitigation strategy, a proposed resolution, and a date by which the risk must be resolved or (at least) mitigated, contained, or avoided, as well as a Plan B in case that can't be done by the date. The impact from the Product Owner's perspective must be clearly communicated to everyone. But I haven't found any need to make it any more complicated than that.

Re: Important to manage risks visually by Dave Nicolette

After clicking submit I noticed someone had already posted a link to that other risk board. Sorry!

Re: Agile and Risk by Dave Nicolette

Real Options and agile are orthogonal.
Close

#### by

on

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

6 Discuss
 General Feedback feedback@infoq.com Bugs bugs@infoq.com Advertising sales@infoq.com Editorial editors@infoq.com Marketing marketing@infoq.com InfoQ.com and all content copyright © 2006-2016 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with. Privacy policy