Programmatic Risk Management - Part 2
Article 2 in a Series on Risk Management
By Glen Alleman

The first article introduced the idea of “uncertainty” in cost, schedule, and technical performance of projects. This uncertainty is defined literally as the “lack of certainty.” This is a tautology of course, but important for understanding the concepts of programmatic risk.

The idea that uncertainty and the risk that it produces can be “programmed out” of the schedule or a cost model is a false hope. All schedules and their associated costs have uncertainties. Uncertainty is about the variability in the performance measures of the project. Uncertainty is about the ambiguity associated with a lack of clarity. Discovering the sources of this uncertainty or ambiguity is the beginning of a programmatic risk management process. In many cases uncertainty arises from the basic processes of the work. This is the Deming uncertainty. (http://webserver.lemoyne.edu/~wright/deming.htm) 

This is the “noise” associated with the normal operations of a project. Work never completes in exactly the planned amount of time in the exactly the planned sequence. Items cost “more or less” what was planned. This uncertainty is a natural statistical process built into the project work. 

Trying to manage away this uncertainty is likely a futile effort, a waste of time, and actually not possible. The Japanese call this “Muda” in the Lean context. It’s the noise in the system. Accept the noise, have a buffer for the noise, allow variances to occur. 

The first question is while managing in the presence of this natural variability is, “what are the limits to these variances that are acceptable for the project?” “What are the error bands on the variability for cost and schedule?” If the error bands are set too tight, the project management staff “chases their tail,” trying to keep cost and schedule within too tight limits. It is a waste of time and effort to try to control the naturally occurring variances in the plan. 

One approach sets the error bands wide enough to not trigger an exception report for these variances. This approach is “good enough” but what is missing is the knowledge of “how wide is wide enough?” for a specific set of tasks or during a specific phase of a project? What should we tolerate for the naturally occurring variances? What is the impact on the schedule of these variances? 

To understand the source of this natural variance, we need to understand – and accept – that project schedules and their associated costs are networks of random variables. The values of duration are not “point” numbers (scalars). They are “estimates” of the completion time drawn from a probability distribution of the underlying population of all completion times possible for the specific task. 

Next we need to understand there are two types of random variables: (1) static, which are part of the underlying processes of the project and are fixed; (2) dynamic which are evolving over time. These second type are called stochastic variances. These are driven by system time delays – someone is late, the echo of that late delivery impacts future in some random way. The interactions between all the elements in the project is not well understood, disruption in one area of the project impacts other areas.

The dynamic uncertainty is about the unknowns and possibly the unknowable. The static uncertainty in a program can be addressed directly in the plan with mitigation tasks. The dynamic uncertainty arises from the dynamic interactions between the tasks of the plan. This interaction and the outcomes to the end date cannot be modeled with static paradigms. What is needed is a tool that can deal with these types of variances. This is a Monte Carlo Simulation approach to modeling interactions and their impact on other elements of the plan.

The Process of Risk Management 

We’ll get to the concept of Monte Carlo Simulation in a few more editions. For now we still need to clarify a few details about variances and their impacts on cost and schedule. First let’s restate what programmatic risk management is all about.

Managing programmatic risk requires anticipation that identifies risks, also requires understanding of the source of risk, the impacts of these risks, and the interaction between the risks and the plan. A process is needed to guide the risk management activities. This process must address both the programmatic as well as technical risk.

In our next edition, we’ll learn about two standard processes to manage risk. One, the US Department of Defense Risk Management Framework. The other the, Software Engineering Institute Continuous Risk Management Process. Both are available for “free” from their respective sources. Both are supportive of each other and can be combined. Both are applied daily on high risk, high reward programs – like flying to the International Space Station, building the Joint Strike Fighter, and even deploying large IT systems.

So let’s leave with the first of many “words of wisdom”...

Risk Management is How Adults Manage Projects

This article is the second of a series by Glen on risk management. See Glen's bio on the Meet the Experts page. He can be reached at Lewis & Fowler or at his blog, Herding Cats.

Filed under Risk Management