Yesterday's Post What Is Risk? was a response to a tweeter post conjecturing
Risk is not there to be mitigated, it's there to be eliminated
This, of course, is not factually true. Risk is the result of uncertainty, which comes in two kinds for all projects, for everything actually. Aleatory uncertainty, from the naturally occurring variances in the process and Epistemic uncertainty from the probabilistic event-based processes that impact the project. Epistemic uncertainty and the risk it creates can be reduced with handling processes. Aleatory uncertainty and the risk it creates can NOT be reduced. Only margin can be provided to protect the project's cost, schedule, and technical performance from this risk.
This brings me to the next tweet, that is equally wrong ...
Estimates lead to buffers. Buffers lead to waste. Waste leads to ruin.
Buffers (margin) are the ONLY means of handling aleatory uncertainty and the risk it creates. Let me say this again, aleatory uncertainty, create a risk that is NOT reducible. This risk cannot be reduced (NO risk can be eliminated), since it comes from a naturally occurring process (stationary or non-stationary stochastic process), that is external to the project.
The only means of handling the risk created by aleatory uncertainty is with margin - schedule margin, cost margin, technical margin. To suggest that buffers (margin) are waste, and those lead to ruin, ignores the basic principle of decision making in the presence of uncertainty.
When aleatory uncertainty is present, and it is present in all development work unless you're watching a clock tick, then you need margin. With this margin, you're late, over budget, and have a reduced probability that what you're producing won't work before you start.
Before looking at how to model and handle the Aleatory uncertainties, let's look at Epistemic Uncertainty and the resulting risks.
The risk created by Epistemic Uncertainty represents resolvable knowledge, with elements expressed as the probabilistic uncertainty of a future value related to a loss in a future period of time. Awareness of this lack of knowledge provides the opportunity to reduce this uncertainty through direct corrective or preventive actions.
Epistemic uncertainty, and the risk it creates, is modeled by defining the probability that the risk will occur, the time frame in which that probability is active, and the probability of an impact or consequence from the risk when it does occur, and finally, the probability of the residual risk when the handing of that risk has been applied.
Epistemic uncertainty statements define and model these event‒based risks:
- If‒Then ‒ if we miss our next milestone then the project will fail to achieve its business value during the next quarter.
- Condition‒Concern ‒ our subcontractor has not provided enough information for us to status the schedule, and our concern is the schedule is slipping and we do not know it.
- Condition‒Event‒Consequence ‒ our status shows there are some tasks behind schedule, so we could miss our milestone, and the project will fail to achieve its business value in the next quarter.
For these types of risks, we need an explicit or an implicit risk handling plan. The word handling is used with special purpose. "We Handle risks" in a variety of ways. Mitigation is one of those ways. However, in order to mitigate the risk, we must introduce new effort (work) into the schedule. We are buying down the risk, or we are retiring the risk by spending money and/or consuming time to reduce the probability of the risk occurring. Or we could be spending money and consuming time to reduce the impact of the risk when it does occur. In both cases, we are taking action to address the risk.
There are four kinds of reducible risks on all projects:
- Reducible Cost Risk - is often associated with unidentified reducible Technical risks, changes in technical requirements and their propagation that impacts cost.
- Reducible Schedule Risk - Schedule Risk Analysis (SRA)(Monte Carlo Simulation, Method of Moments for example) is an effective technique to connect the risk information of project activities to the baseline schedule, to provide sensitivity information of individual project activities to assess the potential impact of uncertainty on the final project duration and cost.
- Reducible Technical Risk - is the impact on a project, system, or entire infrastructure when the outcomes from engineering development do not work as expected, do not provide the needed technical performance, or create higher than the planned risk to the performance of the system.
- Reducible Cost Estimating Risk - is dependent on technical, schedule, and programmatic risks, which must be assessed to provide an accurate picture of the project cost. Cost risk estimating assessment addresses the cost, schedule, and technical risks that impact the cost estimate.
If we are to have confidence in showing up at the needed time, for the needed cost, with the needed capabilities produced by our work - in the presence of Epistemic Uncertainty - we're going to need to identify these uncertainties, estimate the probability of their risk occurrence, the probability that the handling actions will reduce them, and the probability of the residual risk after the handling is complete.
Managing in the presence of Epistemic Uncertanty, and the Risk it creates requires we make Estimates.
Risk Management is How Adults Manage Projects - Tim Lister
Manage risk, make estimates, be and Adult
Wrap Up
Risk does not standalone, Risk comes from Uncertainty - reducible uncertainty and irreducible uncertainty
You cannot remove the risk without first removing the uncertainty.
For those interested in future understanding how risk is managed on software-intensive system of systems using agile development here's a bibliography from our several decades of doing just that for Enterprise, embedded control systems, and space and defense systems.
