The term risk is tossed around way too easlily these days. Just like we toss around complexity, complex, or those other terms that have self induced confusions - leadership versus management, complex versus complexity, coaches versus mentors, responsibility versus accountability or agile versus lean. When we assume - wrongly that definitions don't matter, we're just being lazy.
So back to risk. First of all risk is based on uncertainty. There are two types of certainty
- Aleatory Uncertainty - that arises through the natural, unpredictable variation in the performance of the system under study.
- Epistemic Uncertainty - due to a lack of knowledge about the behaviour of the system that is conceptually resolvable.
We must distinguish between these two types of uncertainty when starting our probabilistic risk assessment for project work. The next understanding is about probabilities.
"probability is fundamentally the same concept regardless of whether it appears in the model of the worldor in the subjective distributions for the parameters. There is only one kind of uncertainty stemming from our lack of knowledge concerning the truth of a proposition, regardless of whether this proposition involves the possible values of the hydraulic conductivity or the number of earthquakes in a period of time. Distinctions between probabilities are merely for our convenience in investigating complex phenomena. Probability is always a measure of degree of belief."
In, Mosleh, A., Bier, V. M., and Apostolakis, G. (1988). A critique of current practice for
the use of expert opinions in probabilistic risk assessment. Reliability Engineering and
system safety, 20, 63-85.
So How Do We Manage In The Presence of Uncertainty
This first thing to do is NOT assume that the system is emerging in a random manner. That notion provides no support for those funding the project. We must have a PLAN to determine is the project is headed in any direction that will result in it be DONE in any form acceptable to those providing the money.
So we need to start by answering the question what is the probability of some future event. The notion that we can't ask and answer this question is one of those other nonsense concepts. Of course we can ask and answer. You do it all the time. What's the probability of rain today is answered by loking outside or maybe looking in this mornings paper, or even on your Android at weather.com.
Our first step is to not try to manage the Aleatory Uncertainty but to understand the probability distributions resulting from this uncertainty and manage in the presence of this uncertainty.
What's the probability of completing on of before May 3rd, 2013? Good question. What uncertainties are in the current schedule? What's the probability of this projects costing $136M or less on or before May 3rd, 2013? Good question. What uncertainties are in the Basis of Estimate?
Next for Epistemic Uncertainty, we must discover what we don't know. This is called mitigating the risk or buying down the risk. This is one way Agile is connected to risk management. Let's build this gadget and see what happens. From that we'll know more and can remove some of the risk when we build the real thing. This by the way is called prototyping - Dah, been doing that for centuries, don't know software development didn't figure that out.
As an aside there is another approach using Evidence Theory, for managing in the presence of risk. This approach requires more advanced understanding of the project attributes, so for now the approach described here will be the starting point.
Just as an aside
There are differences between terms, this is why we have dictionaries.
One of my favorites is Accountability versus Responsibility. We use a Responsibility Assignment Matrix (RAM) on our programs. It is required by the ANSI-748-B Guidelines. It states who is doing what. But Accountability is not the same as Responsibility. The Accountable person is just that singularly accountable for the outcome. The person - the single point contact for making things happen. No group accountability. The group can share responsibility. But only one can be accountable. This is a notion not well understood in many domains.
Agile versus Lean - ask the Agile and Lean folks for the difference. They are distinctly different at their core. Lean manufacturing may contain some agile processes. Lean Aerospace defined at the Lean Aerospace Initiative is now called the Lean Advancement Initiative.
Management versus leadership - read the US Army Field Manual FM6-22 titled Army Leadership, Competent, Confident, Agile. Notice FM 6-22 is about agility on the battlefield, interesting? Wounder if all those agile management "leaders" have read how real agile leadership works when lives are at stake?
Leadership is the process of influencing people by providing purpose, direction, and motivation
while operating to accomplish the mission and improving the organization. Management is about the processes used to lead. There can be managers, but they most likely follow a process.
Complex versus complicated has nice clean, well established dictionary definitions. I know there is a tendency to make up new words and claim credit, by read Beyond the Hype to see that it's generally a bad idea.
So in the end the Program Manager is Accountable for managing in the presence of risk. The PM can have others Responsible for managing the risks - the Risk Manager. But in the end when the launch vehicle blows up on the launch pad, it's the Program Manager who is accountbale. Our when JP Morgan looses $2B is a risky trade it is Jamie Diamond who is accountable.
