Risk management is about making informed decisions by consciously assessing what can go wrong, as well as the likelihood and severity of the impact when that possibility comes true. The heart of Risk Management is making informed decisions in the presence of the uncertainties that create risk.
Managing in the presence of these uncertainties involves the evaluation of the trade-offs associated with risk mitigation in terms of their costs, benefits, and risks, and the evaluation of the impact of current decisions on future options. This process of risk management embodies the identification, analysis, planning, tracking, controlling, and communication of risk.
The sources of uncertainty for all domains, project or not comes in two forms:
Identifying and responding to the risks produced by these uncertainties is the purpose of Risk Management.
A straight forward process for Managing Risk looks like this. There may be others, but what ever the process is suggested it needs to address the six areas of Risk Management in the upper left corner of this diagram and the data model shown here.
The development and deployment of software intensive systems continues to suffer large cost overruns, schedule delays, and poor technical performance. This should be of no surprise to anyone working in the software business.
Research shows these failures result from failing to deal appropriately with the uncertainties in the development of complex, software-intensive and software-dependent systems. Many development communities lack a systematic way of identifying, communicating, and resolving technical uncertainties that are present on all projects. Often the focus is on the symptoms of cost overruns and schedule delays rather than on the root causes in product development. Simply asking the 5 Ways is never sufficient to manage in the presence of risk. The cause and effect processes must be understood and corrective actions produced to fix the cause rather than treat the symptom. Here's the basis of Root Cause Analysis. So when you hear something (like estimating) is the Smell of Dysfunction, you'll know that can't possible be true and it's not made true by asking why without a process to find and fix the Root Cause.
When we hear #Noestimates is Risk Management, that's not only not true, it can't possibly be true.
By Progress to Plan I mean actually Progress to Plan. The Plan is the Product Roadmap for the delivery of the needed Capabilities the customer is paying for. These capabilities need to appear at the needed time for the business strategy to be fulfilled. In some parts of our work the business strategy is replaced by a Mission. But the needed Capabilities at the needed time is still the same.
If those Capabilities don't appear at the needed time, the simple Return on Investment calculation is disrupted. Since the time cost of money is ALWAYS at play in any business.
Now for the Punch Line
If we are managing in the presence of uncertainty, using time cost of money as one (just one, more are below) of the measures of our business or mission success, we need to make decisions in the presence of uncertainty to increase the probability of success.
But first a short interlude on Project Success. It is popular in the Agile and #NoEstimates community to conjecture that project success is not about on-time, on-budget, or performance. First if you show up late and over budget with your working software you need to ask those paying you if they consider that a success.
So now what does project success mean?
Success means different things to different people. Projects are conceived with a business perspective in mind. The goal of the project is usually focused on producing a better result or increasing organizational performance—more profits, additional growth, and improved market position. Otherwise why are we funding this work? [1]
There are four dimensions of project success. [1] Each of these dimensions operates in the presence of uncertainty.
- Project efficiency
- Did we spend the money as planned to earn back the produced value?
- While spending this money, did we meet the schedule goal?
- Meeting budget goal?
- Impact on the customer
- Meeting function performance?
- Meeting technical specification?
- Fulfilling customer needs?
- Solving the customer's problem?
- Customer is using the resulting system to solve the identified problem with the provided technical and functional performance?
- Customer is satisfied with the system and the results it produces?
- Business success
- The results of the project are a business success?
- The project has created a larger market share for the firm?
- Preparing for the future
- New markets have been opened?
- New product line have been created?
- New technology has been developed?
These four dimensions can to be applied across a spectrum of projects and tailored to fit the needs of those projects. Here's one approach to identifying projects across that spectrum.
- Agile alone is not risk management. It's a contributor to the Risk Management process.
- You can't make decisions in the presence of uncertainty - the uncertainty that creates the risks that must be managed to increase the probability of project success - without estimating
- The probability of occurrence of a reducible risk.
- The probability that the mitigations will reduce the impact.
- The statistical range of the variances in the irreducible uncertainties that create schedule risk.
You can't manage risk without estimating. And as we know Risk Management is how Adults Manage Projects - Tim Lister. If you're saying you're managing risk and you're not estimating, then you're not managing risk. And you're not behaving like an adult with other peoples money.
[1] Project Success: A Multidimensional Strategic Concept, Aaron J. Shenhar, Dov Dvir, Ofer Levy and Alan C. Maltz, Long Range Planning 34 (2001) 699–725
