Post written by Troy Tuttle, Project Leader and Software Process Coach at AdventureTech
Risk management is nothing new to the project management community. But in software projects, the traditional approaches to managing risk are far from ideal. Traditionally, we have produced project documents with nice-looking risk matrices that are neatly categorized by severity and impact. This is nice to look at, but how does it help us manage real project risk? We seem to be good at identifying risk, but we give little or no guidance to project stakeholders on how to make decisions based on this information.
In software projects, effective risk management is about the process of making decisions—specifically, deciding the optimal time to execute a decision. The Lean software movement provides us with much better guidance in the form of principles and decision frameworks.
Take, for example, starting a large software project at your company. How do we insure we are not throwing this money away? In a traditional software project, we would come up with a “Grand Plan” that represents the project from A to Z and we would present that to decision makers for funding approval. With funding secured, we start that project boulder rolling down the hill.
When will we know we are building the right thing?
In this Grand Plan approach, we do not typically know until the very end, when the money is all spent. There is no actionable risk mitigation.
Grand Plan projects have little opportunity to manage risk along the way because most or all the the commitments are made at the beginning. For example, if we estimate our project cost to be $1 million, we secured that much funding from the overall budget and committed it all to the project at the beginning. What if we changed our strategy and decision making process? Would we better manage financial risk if we fund the first phase, say $200,000, then decide if it would be worth spending more? If so, then we are deferring the commitment of our entire funding amount until we know the project is succeeding.
Think about the same problem in our specifications. A typical Grand Plan will specify the product in total, to a high degree of detail. If we apply a preference to defer commitments in our specifications, what would our project plans look like? They would be a lot smaller, take less time to generate, and would be more meaningful. Instead of detailing precise requirements months in advance, we can defer that commitment until we have better information about the marketplace, our team, or the product itself.
Real Options, as applied to software development, gives us a nice decision framework for determining when to defer commitments. The model is described as:
- Options have value.
- Options expire.
- Never commit early unless you know why.
This approach is not complicated, but it has big implications. For many organizations, better risk management could save precious project funds. It could also be the difference between the next great product and something much less useful.
What do you think? How do you handle risk on projects?