This is the final installment of a three part series on Risk Management. Part one discussed how I think about business risk. Part two dealt with how to think about technical risk. This post will address some things to think about when considering logistical risk.
Logistical Risk
Logistical risk deals timing and team member availability. These are your people and money risks. Once the business risks are mitigated and we have proven there is a viable solution, this is where the team can really scale the project and build out the bulk of the solution. Here we are answering questions about having the people to do the work. We are monitoring to see if we are making the progress we expected at the beginning. Are we going to have to make any tradeoffs to hit our market date?
Logistical Risks deal with people. Do we have enough people to do the work and are our original assumptions about their capacity going to hold?
In reality, you are dealing with all three types of risk all through the project. The focus becomes logistical risk once you have tackled the other high risk areas of the project and are ready to get down to the business of building out the product. On a large team, you have probably broken your core team up to seed other small teams on the project. As the project scales, you are working to make sure the interactions between the teams are running smoothly. You are concerned with establishing a stable team velocity, grooming the backlog, and making sure that you are regularly delivering business value.
You are working to make sure that the team has everything it needs to be successful. You are actively removing impediments, and interacting with other parts of the business to prepare for your final product delivery. You are probably coordinating the availability of extended team members, managing external dependencies, and possibly dealing with unexpected departures. Logistical risk is about managing the team through the life of project execution.
In Conclusion
I have witnessed too many Project Managers dealing with risk as something external to the project. It is as if the project is on one track and risk management is on another. Risk management is not a separate process that lives outside the way we build software. Risk management needs to be built into the very fabric of the project itself.
Delivering product to customers mitigates all kinds of risk, let's do that a lot. Continuous integration mitigates risk, let's do that too. Continuous testing mitigates risk, let's test all the time. These are not things that the technical team just does, they are things that project managers need to make sure is happening. We need to make sure they are built into the foundation of our project management approach.
Logistical risk deals timing and team member availability. These are your people and money risks. Once the business risks are mitigated and we have proven there is a viable solution, this is where the team can really scale the project and build out the bulk of the solution. Here we are answering questions about having the people to do the work. We are monitoring to see if we are making the progress we expected at the beginning. Are we going to have to make any tradeoffs to hit our market date?
Logistical Risks deal with people. Do we have enough people to do the work and are our original assumptions about their capacity going to hold?
In reality, you are dealing with all three types of risk all through the project. The focus becomes logistical risk once you have tackled the other high risk areas of the project and are ready to get down to the business of building out the product. On a large team, you have probably broken your core team up to seed other small teams on the project. As the project scales, you are working to make sure the interactions between the teams are running smoothly. You are concerned with establishing a stable team velocity, grooming the backlog, and making sure that you are regularly delivering business value.
You are working to make sure that the team has everything it needs to be successful. You are actively removing impediments, and interacting with other parts of the business to prepare for your final product delivery. You are probably coordinating the availability of extended team members, managing external dependencies, and possibly dealing with unexpected departures. Logistical risk is about managing the team through the life of project execution.
In Conclusion
I have witnessed too many Project Managers dealing with risk as something external to the project. It is as if the project is on one track and risk management is on another. Risk management is not a separate process that lives outside the way we build software. Risk management needs to be built into the very fabric of the project itself.
Delivering product to customers mitigates all kinds of risk, let's do that a lot. Continuous integration mitigates risk, let's do that too. Continuous testing mitigates risk, let's test all the time. These are not things that the technical team just does, they are things that project managers need to make sure is happening. We need to make sure they are built into the foundation of our project management approach.
Interesting series of posts. As a PMP I am familiar with the different types of risk, but I am wondering if agile has any unique proposals for how to identify/analyze/manage these risks on a project. I typically have a risk log in Excel that I review with my project team on a regular basis, depending on how important the risks are at any given time. I'm just getting into agile and would love to know if there are any risk management tools/processes unique to agile.
Posted by: CR | Monday, May 12, 2008 at 01:54 PM
Thanks for the reply CR. Sorry for the delay getting out a response. I have been travelling and a bunch of other writing to do.
I am a PMP as well and I see value in what that set of processes has to offer. Being diciplined about qualitative and quanitative risk analysis is essential for successful project execution.
In practice, I think that many (not all) project managers get risk wrong. Many PM risk lists focus on things like: we might be late, someone might leave, we might run out of money. Those things all need to be managed, but they are not external to the project. Keeping them in a separate management process (i.e. a risk list that is periodically reviewed) falls short.
We need too add to these lists risks around how we deliver business value, business alignment, market changes, product suitabilility, technical uncertainty, team member capability, expected throughput against measured throughput, team size, dynamics, team formation, team communication, camraderie, etc. I think sometimes these kinds of things seem out of the control of the project manager.
But... these are the things that either cause us to be successful or result in failure.
In my opinion, and I have not really seen it said this explicitly elsewhere... Agile IS risk management. Risk management is built into the very fabric of the process. Loosely coupled requirements, frequent delivery, constant integration, constant testing, pair programming, refactoring, simplicity, daily standups, review meetings, relative estimating, measuring velocity, colocating the team. On and on, every practice in agile mitigates risk.
Its not that as a PM we shouldn't track risk in a list, but... risk is pervasive so our risk mitigation should be pervasive.
Make sense?
Posted by: Mike Cottmeyer | Sunday, May 18, 2008 at 09:57 AM
CR - In case you are following this thread, this post was in response to your question...
http://blog.versionone.net/blog/2008/05/agile-is-risk-m.html
Posted by: Mike Cottmeyer | Tuesday, May 20, 2008 at 08:11 AM