Programmatic Risk Management – Part 1
Article 1 in a Series on Risk Management
By Glen Alleman

The goal of any project is to produce the product or service, on-time, on-budget, and on-specification. This goal, of course, is difficult to achieve in an exact way. Getting close to budget, schedule, and specification becomes the real goal.

So the core question for project management performance measures (on-time, on-budget, and on-specification) is “how close can we get?” The answer to that question requires us to understand the risks that drive the actual project away from the ideal project. And the risk factors are both technical and programmatic.

All three elements of the project – cost, schedule, and technical performance – can drive performance “off baseline”. Off Baseline means away from the original plan... in other words, we’re not going to meet the cost, schedule, and technical performance goals as originally planned.

This series of articles will describe the programmatic risk aspects of project management. Programmatic risks impact the cost and schedule elements. As a project manager, the technical aspects of the project are usually in the hands of the technical staff, leaving the cost and schedule aspects to you.

When we use the term risk, what we should really mean is: “can our project tolerate risks?” and “can we be successful in the presence of risk?”. Both technical risks and programmatic risks are built into any project by the very nature of projects in the real world.

So first, we need to recognize the core aspects of managing projects – especially technical projects. Examples of technical projects are designing and building a complex structure with all of its related systems, or developing a large and complex software application. Technocrats manage technical projects, and this is driven by the need to adhere to both the profession of engineering and the profession of managing engineering projects.

This approach is very useful when we have reliable, predictable and operational projects. Single point failures are managed within an “engineering” culture with built–in redundancy.

But the problem with this approach is: (a) Hierarchical structures try to ensure organizational control and accountability; (b) Complex systems are prone to failure; (c) Budget and schedule issues add to the technical complexity; and (d) Interactive failure modes abound for both technical and programmatic risk situations.

The goal of creating a Risk Tolerant project is to make visible these problems and provide the opportunity for their solution. I will expand on these issues in later articles in this series.

But here in Part 1, we need to acknowledge there are two kinds of risk on any project: (1) Technical Risk – uncertainty about the functional and performance aspects of the program’s technology that impacts the ability to produce the product and often creates delays in the schedule; and (2) Programmatic Risk – uncertainty about the duration and cost of the activities that deliver the functional and performance elements of the program independent of the technical risk.

And what we must do is connect these two risks into an integrated model of the project and answer: (a) when the technical uncertainty arises what is the impact on the schedule and cost? (b) When the programmatic (schedule or cost) uncertainty arises what is the impact on the functional and performance aspects? In other words, the two types of risks must be understood to be interrelated.

In preparation for the next article, we additionally need to understand one more concept... Programmatic risk is about “uncertainty” in the cost and schedule, and therefore, and therefore, is reflected in the uncertainty in the numbers (metrics) around cost and schedule. Uncertainty, in plain English, is about the “lack of certainty.” Uncertainty is about the variability in the performance measures like cost, duration, or quality. And uncertainty is also about a level of ambiguity and lack of clarity that naturally comes with variability.

Uncertainty, as well, arises from the basic processes of work itself. This is "Deming uncertainty." It is the statistical noise built into the work process. Both of these sources of uncertainty impact cost and schedule. Trying to control the noise adds little value. Trying to control the lack of certainty arising from ambiguity and lack of clarity does have value. We can often do something about lack of certainty.

Discovering the known and unknown sources of bias and ignorance helps identify where we can focus our efforts in clarifying uncertainty. Bias is our natural inclination to do something a certain way, by habit, or by not knowing about other ways. Ignorance is not knowing about the hidden aspects or factors of the project - the requirements or problems that we haven't encountered or realized yet.

If we can get clear about the sources of uncertainty in cost and schedule, we can usually take appropriate steps to better control cost and schedule.This is an underlying process that can be used in risk management in projects of all types and sizes. It is especially useful and important in large, high-cost, and high-risk projects.

In Part 2, we’ll learn about some of the attributes of programmatic risk, how to classify them, and how to handle these risks in the normal course of managing in the presence of uncertainty.

This article is the first of a series on project 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