What a delicate subject to broach. I will be an objective observer and not assign any blame on the gulf spill until the details are available, but I would like to use this tragedy to discuss how it relates to project risk planning. I am guessing that something was overlooked during the formal risk planning process related to the Deepwater Horizon oil rig drilling into the Gulf of Mexico.
I have been using agile project management methods for 10 years and have attended numerous agile training courses and conferences. In all of my training and experiences I have never heard anyone discuss formal risk planning as it relates to an agile process.
If you take agile training you will hear folks like me say “agile is continuous risk management”. This is a true statement. We take risk out of the requirements by working face to face with the customer. We take risk out of the build by continuously integrating the code. We take out the risk of delivering buggy code, or code that goes beyond the need, by using Test Driven Development. So if we are performing all of these practices do we really need to do any upfront work related to formal risk analysis and planning? The answer is yes, sometimes it still makes a lot of sense to do formal risk planning.
If you are not familiar with formal risk planning, let me provide a high level synopsis.
First we sit down as a team – executives, managers, business folks, and technology folks. We discuss everything that could go wrong with the project and create a list of potential risks. Once the list is complete we talk about the impact if the risk materializes. In figure 1 you can see an example of a risk assessment. In this example we note that Risk ID # B1, “incomplete migration”, only scores a 1 on the impact scale, meaning if the risk materializes the impact will be minimal.
Figure 1
Continuing with our example, Risk ID # B5, “Insufficient resources”, is scored as a 5 on the impact scale, meaning if it happens we are in big trouble. We probably will not be able to deliver any project value if this risk materializes.
Once the team identifies the impact of a risk, they move to the probability of the risk occurring. If we stick with our previous two examples, Risk ID # B1 has a .25 (25%) chance of occurring. Risk ID # B5 has a .75 (75%) chance of occurring. Since B1 is low risk and low impact, we are going to accept it and not do any contingency planning.
Since B5 is high impact and high probability, we need to lay out our plan for managing this risk throughout the project.
As I mentioned at the start, this exercise makes sense on some agile projects. I cannot provide specific criteria for you to use, but I can tell you what encourages me to do this exercise at the start of a project:
1) When I am working on a project with high dependency on groups outside of the project team.
2) When a sponsor or business owner has a history of delaying or cancelling projects due to disregard of project risks.
3) When the technical team sees numerous business risks that the business customer cannot see or envision.
4) When I am working on a CYA project. Agile is all about collaboration and shared ownership, but on occasion you may find yourself managing a project where you need to CYA due to the political environment.
5) Projects with a long period of time for iteration zero work (iteration zero is work needed to establish a foundation before coding begins, such as ordering and installing servers, working through contracts with vendors, and obtaining help from teams outside of your control). In my experience this would be a project with an iteration zero longer than 3 weeks.
6) When the customer wants to. If your customer enjoys this exercise and it makes them more comfortable on understanding the project risks, do it.
7) When an internal project management governance group requires this process.
8) Whenever you are using technology that has never been used by the team before.
Use your knowledge and experience as a project manager to help the team determine when this exercise provides value.
Lastly, when you do use formal risk planning do not consider it a one-time event. Find a regular day and time to update the risks and manage them throughout the project.
Please contact me if you would like a copy of my risk assessment template: greg@gssolutionsgroup.com
I agree wholeheartedly with your assessment that it would appear risk management had not been successfully planned in this project. Risk has it’s basis in the uncertainty present in all projects. Known risks can be addressed as you have stated by interviewing the customer, experts and making it a constantly iterative process. Unknown risks need to have a contingency plan established by the team. The greater the damage that can be done, loss of life etc, the more important the need for a contingency plan. In agile environments, due to the speed of the sprint, the quicker the project, the less exposure to risk. Even then, when the potential damage is great, you must have a plan to address that risk.