Visual Risk Management
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.
Agile Risk Board
To visualize the (agile) risk management, you also have the "Agile Risk Board" to place on the information radiator too.
The description here:
Agile and Risk
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
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 & Associates
Amazon Cloud Computing With C#/.Net
Amazon Cloud Computing With Java
Understanding Programming Languages
Essays on SOA AND EAI - A Pocket Guide
Important to manage risks visually
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
Delivering Performance Under Schedule and Resource Pressure: Lessons Learned at Google and Microsoft
Ivan Filho Mar 06, 2014
Andrew Stellman Mar 06, 2014