Agile Risk Management—Viewed Through a Different Lens
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 PMPs 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 PMs 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, planning, 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, a common method is to 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.
| 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 | 2 |
| 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 project’s functional teams—expending quite a bit of time and effort towards these hypothetical risks both in upfront planning and in ongoing monitoring and discussion.
A Quick Point of Context
Oh, and I need to get this point out of the way. My primary context for this post is technology projects. If you’ve managed a technology-driven project, IT project, development effort, integration project, etc., you will certainly agree that these beasties are “different” than other types of projects. And yes, their risks are different too. Rarely can you predict risks early on in these projects. Why? Because you simply haven’t done it before—so you have little to no experience with this specific type of project or technology within the team chartered with implementing it.
The variability in complex software projects is what undermines traditional risk management in my view. We try to expend all of our effort in up-front risk management. Rather, we should expend most of our efforts towards figuring out what we do and do not know. We should decide how to design and code this particular widget I.e. do some of the project work before trying to predict risk. Let the risks emerge from our efforts rather than trying to predict them.
Agile Risk Management
This nicely leads into the essence of agile risk management being an emergent approach. First of all, you rarely hear the agile methods focus on risk at all. Why? Because we flip the notion of planning risk on its ear a bit. How is that? Well, instead of guessing or planning for risk, one of the central themes of the agile methodologies is to deliver real working software in very thin slices of functionality in time-boxed iterations. Realization of risk occurs quickly and abruptly. It hits you in the face as a team at the earliest possible moment. Quite often it surfaces in a daily stand-up meeting.
Is it solely the responsibility of the project manager? No, in the agile case the self-directed team is primarily responsible for detecting, acting on, and mitigating risk…and here’s the important part, in real-time, as each risk occurs. It’s a whole-team and reactive view towards risk.
The team often engages in strategies surrounding risk by how they approach iteration planning. They have the choice of what to build first, so very often the development strategy is to load risky items first—
- To do early experimentation to see how the team will respond to technical challenges and the unknown.
- To measure the velocity of the team to understand their capacity to meet business milestones.
- To engage stakeholders in assessing requirements as they evolve…in real-time and on working software.
Conclusions
Now all of that being said, I don’t think we throw out all of the traditional approaches in agile contexts. For example, I think it a very healthy exercise for larger-scale agile projects to assess and understand the Top 10 risks they might be facing. In addition, to also look for more systemic or organizational risks and do a bit of up-front planning.
But don’t spend too much time there. Nor in exhaustive detection strategies or mitigation plans. Setup a straw man risk structure and then start leveraging the emergent nature of agile iterations to surface risks quickly.
Now for you traditional project managers listening in, I wonder if some of these agile approaches might be applicable in your current contexts!
Don’t forget to leave your comments below
This is my initial blog for Project Times and I’m certainly happy to be joining the community. So, a little about me.