It is common to call our favorite sofware development method risk management. Agile calls itself risk management. #NoEstimate calls itself risk management.
To be a risk management process, several things have to be in place.
- The source of any risk is uncertainty. This uncertainty comes in two forms. Uncertainty that can be reduced with more knowledge. Uncertainty that cannot be reduced with more knowledge
- The first kind of uncertainty has a probability of occurring. It is event based. There is a 67% probability that if I turn on this motor the pump connected to it will leak all over the floor. We can buy knowledge about the undesirable outcome of the pump leaking on the floor.
- The second kind of uncertainty has a probability distribution function associated with it. If I leave for the airport the distribution of travel times is between 45 minutes and 70 minutes depending on the time of day, weather, and general traffic conditions. This type of uncertainty cannot be reduced with more information. It is simply part of the environment we live in. I can find out more details about the probability distribution function describing the traffic conditions, but I can really pay to buy more information about the uncertainty. Of course in today's world, new information can be learned with GPS, Google Maps, and road sensor systems.
With these uncertainties comes and associated risk. This risk can be of the same two types - reducible and irreducible. These two types of uncertainty have two fancy terms aleatory and epistemic.
A risk management method has processes used to manage the risk. These are usually defined as:
- Identify - the risk items on the project. These can be obvious or they can be subtle. They can be known or they can be unknown. If they are unknowable, that's a serious problem.
- Analyze - the known risk, analysis is needed to determine their probability of occurrence and impact on the project. If the risk is classified as unknown then some form of protection is needed. Fault tolerance, resilience as examples. If the risk is unknowable a Plan B is needed. In the project world, this usually means starting over.
- Plan - with the risks in hand, we need a plan to handel the outcomes from the risk. This is response plan.
- Track - as the project evolves the nature of the risk evolves as well. The probability of occruance can go up or down. The impact can go up or down. We need to know this.
- Control - with the plan in hand, we need to execute the plan. We need to control risk.
- Communicate - and of course we need to tell everyone we can about the risks.
Now when it is said an agile development method is a risk management process, ask which of these 6 process are addressed by the software development method, and what artifacts are produced by the software development method. Same for when someone says #NoEstimates is a risk management process. What aspects of #NoEstiomates are connected to the 6 processes of risk management. If not these 6 processes, what are the process used to manage risk?
The simple answer is neither agile nor #NoEstimates are risk management processes, no matter how much specific advovcates want them to be. They may be participants in the processes of managing risk. But they are not risk management processes.
So when you hear that phrase, listen carfully to how the term risk management has been redefined and how simply those making that statement have skipped over the processes of managing risk created by uncertainty. No matter how much they want their favorite development method or NOT ESTIMATING method to be a risk management method it is not.
Simply start with the definition of Risk Management. Look to SEI, PMI, ISO, NIST, NASA, DOD, ITIL, and other project management sources for expansion on the notion of risk. In the software development domain look to SEI again for management processes to handle risk.
So Here's My Reason For Why We Confuse Development Mehtods With Risk Management
We don't know what actual risk management processes look, so we redefine out favorite development method as risk management. It's that simple. We don't have a clear understanding of what risk management is, how it is defined by those performing risk management, and how projects that depend on risk management for their success actually operate in the presence of the uncertainty that creates risk.
This has been presented before, but never gets old. It's the introduction to how we manage our program in the presence of uncertainty.
