Yes, this is an actual post on a LinkedIn forum
When the role of the project manager is to push the rock up the hill and then let it roll down again, there is little chance of success, and in the end little need for project management or the project manager. Cancel the project, everyone just go home.
Risk Management is how adults management projects - Tim Lister
There have several rounds of how to use analogies and how not to use analogies in the past few years.
These involved notions like agile is an untended garden. Actually and untended garden and called a weed patch.
Or we can't really stop and develop a strategy, because we're always putting out fires. Actually firemen rarely put out fires. They spend the majority of their time preventing fire with fire safety, inspections, fire inspections. Their job is to never have fires start.
And of course for false analogies of the double pendulum as a stand in for chaos and unpredictability. Since the equations of motion are easily defined - an exercise for any upper division physics student - and a MathLab plugin, you can plot the path of the double pendulum.
And my favorite the attractor analogy, in which it is presumed that some how in chaos theory the attractor attracts. Without understanding that those pretty pictures of the attractor are the result of the underlying equations for the system.
So with that in mind, there is a new book from one of my favorite authors, Douglas Hofstadter, Surfaces and Essences. In the book Hofstadter makes the case for analogy as the fuel for creative thinking. Using Robert Oppenheimer's quote...
whether or not we talk about discovery or of invention, analogy is inevitable in human thought, because we come to new things in science with what equipment we have, which is how we have learned to think, and above all how we learned to think about the relatedness of things.
But as always we need to take care to assure that those analogies we use to expand the conversation, don't violate the laws of physics, gardening, or mathematics.
More discussion on LinkedIn about risk, risk management, types of risk, and definitions of risk and opportunity. The "risk management" community in the domains I work is based on Department of Defense, Department of Energy, Department of Homeland Security, NASA, ITIL, AACEI (Association for the Advancement of Cost Engineering International), Nuclear Regulatory Commission, INCOSE (International Council of Systems Engineering), OGC Management of Risk, GAO, and Deloitte's Risk Management Framework.
Several core concepts get confused. So before taking any deep dive into "managing risk," these need to be established.
What is Risk
There are many definitions of risk from a variety of sources. In the end these definitions are all pretty much the same.
Here's a good definition that can be used in probably any domain.
Risk refers to the uncertainty that surrounds future events and outcomes. It is the expression of the likelihood (probability of occurrence) and (probability of) impact of an event with the potential to influence the achievement of an organization’s objectives. - Managing Risk in Government: An Introduction to Enterprise Risk Management, IBM Center for The Business of Government.
I've edited this a bit to remove the likelihood measure and replace it with the probability just to keep the math straight. You'll see why below when it comes to ordinal values in the risk matrix - a bad idea.
There is a time honored approach to ranking a risk, by calculating some number. This number is meanigless of course, because it has no scale, it is just a ordinal number. We need cardinal numbers for actual risk management.
Risk = Probability of Occurrence x Impact
This is a trick question. The risk matrix approach that results from this calculation treats these numbers as likelihood not probabilities. But in fact they are probabilities. As well they are Ordinal numbers (1, 2, 3, 4, 5 usually) and as such represents the relative ranking of the likelihood of occurrence, not the actual probability of occurrence.
This approach starts with a major problem - a show stopper problem. The two values on either side of the multiplication sign are probability distributions, not real numbers. There is no MULTIPLY operator between two probability distributions. The is the CONVOLUTION operator, but that is not likely to be of much value to ordinary project management staff. One starting point for a better understanding of the problems with the risk multiplier and risk matrix approach is the work of Tony Cox. Optimal Design of Qualitative Risk Matrices to Classify Quantitative Risks. Tony's source paper provides the basis for this discussion, "What's Wrong with Risk Matricies."
To put it in blunt terms.
The combination of Ordinal Scales and Risk Matricies are Fatally Flawed
In this link, it is stated again, so I'll restate it here
It is a category mistake to multipy ordinal numbers
By category error it means the objects, the categories, do not have the proper properties to work with the operators. For some more discussion of this topic and a bit of counter discussion, see What's Right with Risk Matricies.
Where does risk come from?
Risk comes from uncertainty. There are two kinds of uncertainty.
The critical point here is the reducibility and the irreducibility of these uncertainties.
How is Risk Maanged?
We must start with a risk management process. There are several, but they are essentially the same. Here's my favorite, there are others of course, but this one covers all the steps.
So What's the Point Here?
Cost estimating methods have been around for a long time. The current processes found in agile use a points system, sometimes a Fibonacci series to bin the values of the points.
The challenge with this approach is the estimate in agile is not monetized so we can't really tell if the Total Allocated Budget (TAB) is sufficient for the project at any point in time, unless the capacity for and the quality of the ourcomes is steady - that is Level of Effort.
With the LOE approach, the capacity for work is the critical measurement needed for estimating the cost at completion. As well continuous updating of this capacity for work is needed and correctly done on good agile projects.
But there are other issues with this LOE approach on larger projects:
So the examples like that found at Projects @ Work, don't really consider any of the underlying uncertainties in estimating. Without the next level down - statistically adjusted estimates of the work effort, the capacity for work, the quality of that work, and the interdependencies between those work activities and their products, the simple and maybe even simple minded approaches to estimating have limits to scaling.
This is one of those topics where everyone is right in some way, depending on the domain, context in the domain, and scale of that domain. As agile enters the larger acquisition community, where we're spending other peoples money - maybe 100's of millions of dollars, care needs to be taken when applying un-monetized, non-probabilistic, non-joint probability (cross correlations between work element) and non-stochastic forecasting models. The real world is not that simple.
Over the past weeks there have been several discussions on the forums and Blogs amount risk and risk management. Here's a short post on those topics and their impact on project performance.
Risk Comes from Uncertainty
Risk does not exist by itself. Risk is created when there is uncertainty. If I am certain that it is going to rain this afternoon, then there is no risk of rain. It's going to rain with 100% probability. There is no uncertainty about the forecast of rain.
So first we need uncertainty to have a risk. But there are two classes of uncertainty:
Aleatory uncertainty refers to the inherent uncertainty due to the probabilistic variability.
This type of uncertainty is Irreducible, in that there will always be variability in the underlying variables.
These uncertainties are characterized by a probability distribution.
The parameter that is being measured - duration, RPM, discharge from a river flow, is stochastic and cannot be reduced.
Epistemic uncertainty refers to limited knowledge we may have about the system (modeled or real). This type of uncertainty is reducible.
If we have more information, we can take more measurements, conduct more tests, "buy" more information. This type of uncertainty can be reduced.
The parameter being measures is usually a characteristic of the material or the physical process. The uncertainty is related to the "lack of knowledge," about this parameter.
Handling Risks Created from Uncertainty
Aleatory uncertainty and the resulting risk is modeled with a Probability Distribution Function. This PDF describes all the possible values the process can take and the probability of each value. For a single toss of a coin, there is a 50% probability it will be either heads or tails. For multiple tosses of a fair coin the probability distribution of the total number of heads or the total number of tails is a binomial distribution that looks like this for the numbers of HEADs from fair coin being tossed 20 times.
The PDF for the possible durations for the work in the project can be determined in several ways. It turns out we can buy knowledge about aleatory uncertainty through Reference Class Forecasting and past performance modeling. This new information then allows us to update - adjust - our past performance on similar work will provide information about our future performance. But the underlying processes is still random, and our new information simply created a new aleatory uncertainty PDF.
Epistemic risk 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.
Risk statements are used to define and model these event based risk:
- IF-THEN - says if we miss our next milestone then 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 don't 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 can have an explicit or an implicit risk handling plan. I use the work handling with special purpose. We handle risks in a variety of ways. Mitigation is one of those ways. But the risk handling work is actual work. It is in the schedule. We are doing work to mitigate the risk. We are buying down the risk, or we are retiring the risk. In all cases, we are spending money, and consuming time to reduce the probability that the risk will occur. 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.
The second approach to handling an epistemic risk is the have Management Reserve to cover the cost of the consequences when the risk occurs. Sometimes the term contingency is used. Both Management Reserve and Contingency may be used together. In both cases, money is set aside to handle the risk. We also need time as well, so we may have schedule reserve. But this gets confused many times with schedule margin, but it is still needed.
Risk Management is how Adults Manage Projects
One of the posters stated what would be considered a Lame response to the processes and seeming conplexity of managing risks on non-trivial projects, by stating you're making this to complex - Just Do It. It was lame. Here's the response to those who objective in what ever way to doing risk management.
First answer the question what is the value at risk for your project? Don't know? Go find out. Then ask the project sponsor or the person giving you money to manage the project, if they would be willing to lose that money outright. Just write it off when the risk comes true. Probably not would be the answer. So go do the risk management process.
Here's Tim Lister's advice. The section title is Lister's quote and should be used every time some lame response comes back about risk management.
Forecasting involves making projections about future performance on the basis of historical and current data.
The chart below is a synthetic (same as fake) Cost Performance Index at the program level 2½ years. The area on the right is the forecast of possible values of the CPI given the historical behaviour, with tuning parameters and smoothing functions.
The next step is to use real program performance data over some realistic period of time - say 4 year - and use H-W (or a similar forecasting tool), to confirm that a less that complete assessment, say take 2 years of data, forecast a 6 month value, and see of the actual 2 year, 6 month value come out close the to the forecast.
This is all done in R, with very simple commands, once the time series for the CPI is formatted and partitioned properly.
Recent Comments