Select Page

Categories

Creating Risk Profile Graphs
By Mike Griffiths

Risk management is an important activity on both traditional and agile projects. This article will introduce a method for quickly visualizing the risk status of a project and identifying risk trends.

A widely accepted definition of a risk is:

“A discreet occurrence that may affect the project for good or bad”

However, I prefer the less comprehensive, but higher impact statement:

“Today’s risks could be tomorrow’s problems”

We need to actively attack risks before they become problems on the project. Unfortunately, all too often risk analysis and risk management steps are conducted alongside the regular project tasks rather than being drivers for work scheduling. Risk management plans and risk lists are created, but their findings do not influence task selection and scheduling, then risks occur and people identify the issue “Oh look, risk #4 occurred”, but the risk mitigation steps had never made it into the project plan.

Agile projects have many opportunities to actively attack the risks on a project before they can become tomorrow’s problems. Iterative development allows high risk work to be tackled early in the lifecycle. Features (or stories) that carry high risk can be undertaken in early iterations to prove technology and remove doubts. Carefully balancing the delivery of business value and risk reduction is a wise strategy for feature selection that I will write more on shortly. Until then how do we illustrate the risks on our projects to all stakeholders?

Risks are generally assessed via two measures; the Risk Probability, a measure of how likely a risk is to occur; and Risk Impact, a measure of the consequence to the project should the risk actually occur. The product of Risk Probability and Risk Impact are gives the overall Risk Severity.

Risk Severity = Risk Probability X Risk Impact

This allows us to rank risks and determine risk mitigation priorities. If we give scores of Low(1), Medium(2), and High(3) to both Risk Probability and Risk Impact, we will see that high probability and high impact risks get a Risk Severity score of 3 X 3 = 9, Whereas a high probability, but low impact risk would be given a Risk Severity score of only 3 X 1 = 3.

It is possible to take the analysis of risks much further, using techniques such as Expected Value that assign percentage probabilities to the Risk Probability score and dollar values to the Risk Impact value (e.g. EV = 25% X $8000 = $2000), But for the purposes of illustrating risk profiles and trends, the abstract values of Risk Severity of 1-9 are all we require.

For any project we should engage the development team, sponsors, customers and other relevant stakeholders in the process of risk identification. Their ideas along with reviews of previous project’s lessons learned notes, risk logs, and industry risk profiles should be used to identify the known and likely risks for the project. Once we have this list we can undertake our risk analysis and assign probability and impact scores to each risk and calculate the risk severities. Similar to estimation, engage the team members in risk analysis because they are closer to the technical details and the process of inclusion generates increased buy-in to the risk management plan and mitigation actions. No involvement, no commitment.

The table below illustrates some risks and their associated probability, impact and severity scores for a fictitious project.

Risk List

As the project progresses it is valuable to track how our attempts to manage the project risks are working. The table below shows how the risks progress through the first four months of the project.

Risk Table

During these four months many of the project risks have been mitigated or avoided completely. For example, the first risk “JDBC driver performance” was proved to be not a problem by the deliberate inclusion of database features and performance testing during the first (one month) iteration. Hence the probability of this risk occurring was reduced from a “2” (Medium) to a “0” and so the risk Severity went from a “6” to “0”.

These details can be difficult to determine from just tables and so Risk Profile Graphs are an excellent way of showing status and trends as shown below:

Risk Profile Graph

Risk Profile Graphs are “stacked area graphs” of risk severity. 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.

For instance we can tell from the general downward trend that the project risks are reducing. These Risk Profile Graphs are an excellent way of demonstrating the value of “Iteration 0” activities that may not deliver much/any business value, but are extremely useful in proving approaches and reducing project risks.

Escalating risks and new risks are also easy to spot. In our example Risk 9 “Oracle Handheld Warehouse browser launch” escalated from a Severity 3 risk to Severity 9 risk in March. Risk 10 “PST Changes for British Columbia” is a new risk that was assessed as a Severity 4 risk in March and went down to a Severity 2 risk in April.

Risk Profile Graphs quickly inform stakeholders if the risks are moving in the right direction (downwards) or if issues and concerns are escalating. They provide a simple to interpret health-check for a your project and are quickly produced in tools like Excel. 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.

You can download the spreadsheet used to create these examples here

Mike Griffiths is an independent consultant specializing in effective project management. Mike was involved in the creation of DSDM in 1994 and has been using agile methods (Scrum, FDD, XP, DSDM) for the last 13 years. He serves on the board of the Agile Alliance and the Agile Project Leadership Network (APLN). He maintains a leadership and agile project management blog at http://www.LeadingAnswers.com

Recommended PM App

Recommended PM App

Categories