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 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.
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.