An Agile Approach to Risk Management

by Donna Fitzgerald, Senior Consultant, Cutter Consortium

A recent discussion on the NewGrange list server [1] began with the question, "Is there really anything that a project manager does that is more important than risk management?" As the discussion unfolded, there was a general consensus that a risk-centered perspective would definitely stand any project management in good stead. With that in mind, I would like to suggest a few risk-centered activities that are in keeping with an agile risk management.

Risk Planning: there are steps that can be taken before a single specific risk has been identified for the project, and it's possible that these activities -- even more than the follow-on actions -- will determine the success or failure of the project.

1. In every company there is an off org-chart network of people who get things done. They're in every functional area of a company and they're the only ones to call when something unforeseen goes wrong and you need help. Building your project team so that you're tied into that network from the start is often a make or break issue.

2. Only hire people who come with their dancing shoes. No matter how well you plan at the beginning of a project, something will change. Hiring a team that is flexible gives you the ability to adjust to almost anything.

3. Create a "learning organization" culture in your project team. Not all change is bad. Sometimes things happen that create an opportunity to do it better, faster, cheaper. By creating an environment where your team looks for opportunities to exploit as well as disasters to avoid you maximize your probability of success.

Risk Assessment: there are wonderful formal planning techniques that can be done here, but the single most effective agile risk management technique a PM can use is active listening.

1. Talk to your team -- your users -- and learn to hear between the words. Short of a natural disaster, there are seldom any real surprises on a project that someone didn't warn you about.

2. Dealing with Cassandras. Every project has team members who are always letting you know that disaster is right around the corner.

Some of their input is good and some of it is just so much noise. A friend of mine had a technique he called negative branching that is very effective in dealing with people who always see the negative. In cases where a team member insists the sky is falling, ask them to map out the series of negative events that will have to happen to make the situation a real crisis. If you think they're objective enough on their own, you can ask them to give you a probability of each event occurring. Mathematically, they can usually prove to themselves that the odds of what they're worried about are lower than they think. Additionally, you can both agree that if event A on their list happens, you will both be on the lookout for early warning signs of event B (90% of the time, Cassandras have real risks but they are at least three levels down the event chain, maybe more).

Risk Mitigation: every project will have a unique risk mitigation/ contingency plan but there are a number of actions that can be taken even before other project-specific risks are identified.

1. Identify staffing weaknesses. Every project should have at least some "utility players" and, depending on the size of the project, some redundancy. It's impossible to plan for family illness, emotional crises, or other things that can happen to human beings, but no one resource should be so critical that losing that person significantly delays the project.

2. Develop Plan B. This technique is almost mandatory for projects with a high degree of technical risk. Also develop the criteria you will use to tell you when to begin implementing plan B. Understanding the difference between a contingency plan (we will do this if plan A fails) and a mitigation plan (we'll do this to lessen the chance that plan A will fail) can be the difference between success and failure.

Risk Monitoring: once you've identified your risks, keeping an eye out for them is relatively painless. There are other things though that can help.

1. Pay particular attention to the early warning signs. There are almost always precursors to any actual risk event. Some of the most common risk symptoms are:

   • A high number of unresolved issues on the issue list

   • Persistent disagreements among the staff about what should be done on the project and how

   • Early slippages in the schedule

2. Have an alligator review. Some times when you're in the thick of things, it's hard to be sure that you're not missing something. One very effective and underused solution to this problem is a form of peer review. The purpose of this is solely to review risks and potential risks. This is not a formal quality check and the prima fascia assumption is that the project is well managed and on track.

Taking an agile approach to risk management is best described as adopting an attitude that likens risk management to breathing. It is automatic and it's necessary to keep the project alive. In the final analysis, the secret of agile risk management requires nothing more complicated as identifying anything and everything that is blocking progress toward delivering the project and ruthlessly eliminating it as a problem.

-- Donna Fitzgerald, Senior Consultant, Cutter Consortium

[1] NewGrange Center for Project Management (www.newgrange.org)