What is Agile Risk Management? (Part 3)

Project signals and background uncertainty

In my last couple of posts, we talked about Knightian Risk and Knightian Uncertainty. Today we are going to look more closely at how the risk and uncertainty are related. (From now on when I use the terms risk and uncertainty, I will mean Knightian risk and Knightian uncertainty.) We will also use more practical examples. In the real world, the outcomes that we care about tend to depend on events more complex than single rolls of the dice — they depend on the aggregate effect of many related risks.

For example, before deciding if we should do a project, we need to make a series of assumptions about external factors (e.g. market prices and competitor activity) and internal factors (e.g. solution specifications and cost estimates). Each assumption is a discrete known risk. Together, these known risks form the project risk profile. We model different project scenarios by assuming different values for the separate known risks. Using traditional risk management and other analytical techniques, we calculate overall project risk by aggregating individual known risks.

To feel confident that we can effectively decide whether or not our project concept “adds up”, we need to surpass what we believe is the threshold of sufficient knowledge. Below this threshold, we exist in a state too uncertain to have confidence in our predictive capability. It’s not that we know nothing, but the bits and pieces of information we do have are inchoate. Above the sufficient knowledge threshold (i.e. the tipping point between uncertain and risk-manageable circumstances), we believe we can fit data into a coherent pattern that supports reliable predictions. After the tipping point is achieved, we recognize the features of a predictive model. Additional knowledge won’t necessarily change the terms of our predictive model, but will increase its precision. Although we can never achieve 100% certainty, more knowledge will increase our confidence in our ability to calculate the likelihood of a successful outcome and make a good decision.

We can think of the relationship between risk and uncertainty in signal-to-noise terms. Using our project risk profile as an example, as we approach the sufficient knowledge threshold, our project concept starts to emerge from background uncertainty much like an audio signal emerges from background noise. More knowledge strengthens the project “signal.” Beneath the knowledge threshold, the project signal is imperceptible. Let’s look at a few examples.

The picture below represents when we can’t identify any meaningful predictive pattern. No project signal is discernible. Maybe we are simply too ignorant to recognize a potential project opportunity, in which case the project concept is unknown. Or maybe the project concept we imagine is inherently unviable, in which case the project concept is unknowable. Either way — to put it bluntly — we are “clueless”.


Agile Risk Management 2 from SolutionsIQ

The next picture represents when we have assembled some of the necessary knowledge (e.g. market price and contractor costs) but not all (e.g. subcontractor availability and project duration) that is sufficient to form a coherent and complete predictive model. In such a case, “we know enough to be dangerous”. Maybe a project possibility is emerging from background uncertainty, or maybe we are chasing shadows and fooling ourselves; which, is not entirely clear. It’s at this emergent stage, when we are most susceptible to the errors of over- and under-confidence or if we prefer, since we are using the signal-to-noise metaphor, false positives and false negatives. For this example, a false positive is when we think we see a coherent project pattern that really does not exist and a false negative is when we don’t recognize a real project possibility. This emergent phase is the zone where Agile risk management practices help us manage through uncertainty in ways that traditional risk management cannot (see last week’s post). We definitely will be discussing this in more detail in later posts.

Know enough to be dangerous

Agile Risk Management Dangerous 2 SolutionsIQ

However, If we are confident that we can model all the critical factors with a reasonable level of certainty (let’s say you have have customer and supplier contracts in hand), as we can see in the picture below, the project signal is clear and strong. Background uncertainty still exists, but is presumed to consist of highly unlikely or inconsequential events that are not expected to grow in significance and jeopardize project outcomes. We now feel comfortable that we can make a well-informed rational decision.


Agile Risk Management Well Known 2 SolutionsIQ

For commercial initiatives, determining whether we are clueless, know enough to be dangerous, or are well-informed is part of the business case decision. We will discuss this in detail in my next post.

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 United States License.