Agile Program Risk Management

Managing Risk Across Multiple Agile Projects

(From flickr: gagilas)[/caption]

All human endeavours involve Risk. Software development projects as evidenced by their high failure rates are certainly no exception. A successful project is not the result of luck, but of anticipating, understanding and managing the Risks of the project. A successful portfolio of projects is therefore the result of anticipating, understanding and managing the cumulative Risk of all of the projects in your portfolio.

In my previous post “Five Simple Steps to Agile Risk Management”, I presented a method for Agile Risk Management. Experience has shown me that the approach works well for almost any type of project as well as for projects of pretty much any size. It is, however, a rare organization that has a single project underway at any given time, so while managing Risk in your individual projects is a good thing, we clearly need “more good”. “More good” is to have a comprehensive, consistent and up to date view of Risk across all projects. This article outlines a process for aggregating the Risks associated with a portfolio of projects so that Risk across multiple projects can easily be identified, reported, tracked and managed.

In many organizations, there are monthly or quarterly reviews of a portfolio or program by senior management to ascertain the progress. Risk assessment is an important facet of project management, and assessing and reporting on the Risks of projects is thus an essential part of this regular review. This high level view of Risk must have a level of detail and organization of the information appropriate to the target audience and also for the program manager(s) so both groups can keep tabs on all of the projects in the portfolio. In particular, senior management needs to be able to quickly understand the issues and determine which (if any) require their attention. For these purposes, the full detail of all Risks in all projects is far too much information so we need an effective means of aggregating, grouping and filtering information so that anything unnecessary is removed and the important information is brought into focus.

At a high level, program managers and executives are most interested in the external effects of the projects. In other words, they worry about the impact of the project risk on the company, its finances, customers, partners, reputation (brand), and so forth. Fortunately, the Agile Risk Management methodology I presented in my previous post provides us with everything we need to create such a summary. In that article, I suggested the following categories into which your various project Risks might be placed.

These categories tend to work well in most organizations, but they may not be right for yours so adjust them to your specific needs. In my previous post I also presented a Project Risk Registry for tracking the Risks in a project. Below is an Enhanced Risk Registry that I use in situations where I need to track more than one project, and where I need to report an aggregated view of Risks across those projects.

Enhanced Project Risk Registry

Enhanced Project Risk Registry (Click on image to enlarge)

In this Enhanced Risk Registry, I track how each identified Risk affects the seven Risk Classes (Solution…Scope). Each of these values are the combined Risk Vectors (Probability x Impact = Risk) for the individual Risks identified in the project. For practical reasons, I would not normally include Green Risks in the Registry. Individual Risks can change dramatically over the life of a project, and once a Risk has been recorded, it remains in the Registry until the project closes – even if the Risk turns Green. For example: In Risk SP-006 (Customer issue LX113 resolved) this issue may return because the fix itself was flawed. Keeping it in the registry reminds us to keep an eye on it to make sure it doesn’t return. As well, I maintain an additional column (not shown here) that contains the Risk Mitigation Strategy for each of the tracked Risks. This column will be of particular interest to management as they will want to know what you are doing about managing the identified Risks.

For each of the tracked Risks, I use a simple formula for each tracked Risk that takes the maximum value across the seven Risk Classes. In SP001 we see values ranging from 1 through 25, but the Risk for this item is 25 – the maximum of the seven Risk Class values. The reason I use the maximum instead of an average (or some other formula) is that if all values will tend towards a mean (as an average would do), then the true Risks would be obscured. I mentioned previously, but it is worth restating that the Risk values must be entered by the respective SMEs and not the PM. This ensures that the category expert’s assessment is captured. The next thing to note is that for each of the Risk Class columns, I also calculate the maximum display it by Class below its respective column. This is the Project Risk for each Risk Class.

So far what we have is the SME view of Risk for this particular project, and by now you are probably wondering what Adjusted Risk is in the above chart. This is the PM’s adjustment of Risk for this particular project. This is not an attempt to hide or obfuscate Risk. Instead, it is the PM’s assessment in consultation with the rest of the team to adjust the Risk rating based on additional information that may not be available to the SMEs that the time of their assessment. It may be also an adjustment of the Risk based on organizational focus. For example, a company that develops guidance systems for NASA might place the highest value on the Solution, whereas a company in the rapidly changing world of social networking might consider Time-line to be the most important Risk Class. There is no easy or formulaic way to make these adjustments as they are based on experience (been there done that) of the people making the adjustments, and on the culture of the organization. In no case should such adjustments be done without consultation. Whenever you make adjustments to the Risk, make sure you record the rationale for the adjustments.

Program/Portfolio Risk

Now that you have entered your project Risk in your enhanced Risk Register, expand your assessment by creating a Risk Register for each of the projects in your portfolio. Once you have done that, you can roll up the Adjusted Risk for all of your projects into the Portfolio or Program view of Risk. Here is an example:

Portfolio Risk Registry (Click on image to enlarge)

With this register, we can see at a glance the Risks for the entire portfolio of projects. The comparison can be easily made not only for the Risk of each project, but also comparing each Risk Class across all of the projects. The bottom line called Category Risk is the Organizational Risks across all projects. From this particular example, it is easy for management to see that projects SP and CP need particular attention. SP looks like the whole project is tipping strongly in the wrong direction and project failure may be imminent. CP looks like it has a serious Risk associated with Privacy (think about the recent TJX credit card info theft). AP6 might also be a concern, and the management team may want to have a closer look at it.

No doubt when you present this information, you will be faced with questions about the specifics of the ratings.  Because you have individual project Risk Registries, you will have the information at hand (including SME assessments) to provide as part of your presentation. Keep in mind that you may also be asked about ratings that appear to be too low, and you should be able to explain the rationale for those as well. Again, the SME assessments will be of tremendous value to you in your presentation.

How Often?

Project Risks can change dramatically during the course of a project so a portfolio assessment should be done at least once per quarter – ideally every month. Each time you do a review, you may want to identify one or two projects for a deep dive assessment. The choice to do this has a lot do with the size and culture of your organization, but give it consideration for inclusion as part of the standard process in your organization. Regardless of the frequency, remember to focus on the difficult (usually Risky) things first and if a project is going to fail, then fail early by dealing with those issues early. Your job is to try to beat the odds and not be in the one third of all projects that fail outright, or even the one third that are seriously challenged. You want to be in that top one third and your chances of success are much better if you identify and manage the Risks early. This process will help you stay on top of the issues and thus help you reduce your Risk.

Good luck!

As  always, I look forward to reading your comments.

Michael

Michael

I am an independent consultant who has been leading software teams, designing, building and delivering software for nearly three decades. It’s still as exciting and enjoyable for me today as at was when I wrote my very first Hello World program and saw it spring to life in front of me.