This post was originally made in June 2010. However, I wanted to make it part of my “Agile Project Manager” series, so I’ve updated and extended it a bit…hope you enjoy v2.
I often find myself teaching various classes on agile methods. One of my more popular sessions surrounds the mapping of traditional project management techniques towards the agile methods. I do this quite often in a wide variety of venues. One metric I’ve noticed is that the more PMP’s in the audience the more spirited the discussions become.
One of the core translation areas between traditional and agile project management relates to risk management. I often get a lot of pushback from the PMP’s telling me that the agile approaches to risk management simply won’t work. Their arguments are more based on traditional thinking, PMBOK guidance, and “we’ve always done it this way” pattern; rather than a situational response to individual project needs. I usually just leave it that agile risk management is “different” and move onto safer topic areas. But I usually want to add more flavor and this post seemed like a good opportunity to do so.
Traditional Risk Management
In this view, the Project Manager is managing the risk. The premise is that you need a highly skilled and experienced PM to adequately control and manage project risks. That risk can be anticipated, planned, reduced, avoided, transferred, positive, triggered, and mitigated.
One of the first activities with any project is to begin the compilation of a risk list so one can manage the project risks. These risks can be gleaned in a wide variety of methods — team brainstorming, speaking directly to key stakeholders, analyzing previous projects, and from the technology and business climate.
Once identified, teams often evaluate the size of each risk. A common mechanism is to gather likelihood and impact from the project team, then multiply the likelihood of the risk occurring against the impact the risk would have. So, something like the following table:
| Potential Risk |
Likelihood of Occurrence: 0 – minimal/none 1, 2, 3 – Certain! |
Impact of Risk: 0 – minimal/none 1, 2, 3 – Project Failure! |
Risk Priority |
| 50% of technical team will leave for a competitive position | 0 | 3 | 0 |
| The open source LAMP stack will be acquired by Oracle | 1 | 2 | 3 |
| Chance we will deliver 100% of the agreed functionality? | 3 | 1 | 3 |
| System Performance will not meet requirement levels; only 50% | 2 | 2 | 4 |
| Business stakeholders will be confused on required features | 3 | 2 | 6 |
Once you’ve accumulated a “complete” list of risks and analyzed their “priority”, then a plan is put in place to detect and mitigate the risks that are most likely to occur. Quite often, this is a very detailed plan that is formulated with all of the projects functional teams — expending quite a bit of time and effort towards these hypothetical risks both in upfront planning and in ongoing monitoring and discussion.
Comments