Building Risk Tolerance into the Program Plan and Schedule

Managing the uncertainty in a network of tasks that describe a schedule is the topic of this paper. There are six steps for building a risk-tolerant schedule from field experience in aerospace, defense, and large construction projects.

The hope that risk can be "programmed" out of the project schedule is a false hope. However, we can manage uncertainties by understanding the risk types and the uncertainties that create these risks and addressing each in an appropriate manner.?

Building the Risk Tolerant Plan and Schedule

In Against the Gods: The Remarkable Story of Risk, author Peter Bernstein states one of the major intellectual triumphs of the modern world is the transformation of risk from a matter of fate to an area of study. Risk analysis is the process of assessing risks, while risk management uses risk analysis to devise management strategies to reduce or ameliorate risk. Managing the uncertainty in a network of tasks that describe a schedule is the topic of this paper.

A method for incorporating schedule risk management in a visible manner that provides governance of the project’s technical and programmatic performance is necessary for risk tolerance. This method is based on three core concepts shared by all risk–tolerant plans:

1. Measures of progress must be qualitative rather than quantitative, counting objects, and measuring the consumption of time and money, are not measures of progress. Measuring increasing product maturity against planned maturity is how risks are identified and handled.
2. Normal and foreseen risk handling must be explicitly visible in the plan. These risks include both the probabilistic uncertainty of the occurrence of an event and the naturally occurring variances in the underlying processes that create a risk to cost, schedule, and technical performance, and
3. Unforeseen risks must be acknowledged and actions are taken when they occur.

Risk Management Structure

The Figure below describes the Risk Management structure defined in the Risk Management Guide for DoD Acquisition. This will be the structure used for developing the Risk Tolerant schedule. The mechanics of managing risk are described in [1]. It is the Risk Planning, Risk Handling, and Risk Monitoring process that forms the basis of this article.

Risk management process areas form the basis of an integrated management approach. Each of these processes must be in place and performed as a whole for Risk Management to be effective. Failing to do this, creates more risk since the visibility of the programmatic and technical risks are then masked.

To build a risk-tolerant schedule, the PMBOK? instructs us to:

• Identify the scheduled activities needed to complete the project.
• Sequence these activities in their order of dependency.
• Estimate the resources needed for each task.
• Estimate activity durations using a variety of methods.
• Use this information to create a schedule.
• And control the changes to our schedule.

While this approach appears well grounded through processes used to build the schedule, it fails to address the core weakness of most risk planning processes by not specifically designing the schedule to be Risk Tolerant in four ways. These activities are:

1. Activity-based, not risk mitigation based. Technical risk is identified in PMBOK, but its connection to and with programmatic risk is not defined. [?]
2. Activity-based, not maturity assessment based. Progress is measured as the passage of time and consumption of resources, not the increasing technical or programmatic maturity along with the decreasing reducible or irreducible risk.
3. Activity-based, with no quantitative basis for assessing the risk reduction effort from the current state to completion. Explicit risk buys?down activities are not discussed in a manner consistent with an integrated plan.
4. §11.5.2 of PMBOK describes the recommended activities for Risk Response Planning, but it fails to make it clear how to integrate these mitigation activities in the plan.

Risk Buy-Down Activities

To make a plan risk-tolerant, the planner must include “Risk Buy-Down Tasks”.?These are like any other work activities in the plan. These tasks reduce the uncertainty in the project. The term uncertainty has a broader meaning than risk. Risk is created from Uncertainty, with comes in two forms: reducible and irreducible uncertainty.?Project planning involves uncertainty. This uncertainty is characterized by:?

1. Uniqueness – a project is a unique undertaking. This does not bode well for the management of technical or programmatic risk, since there is little if any, historical data by which to calibrate the models describing this risk.
2. Variability – various tradeoffs exist between performance, cost, schedule, quality, and risk. A model of these tradeoffs requires that the correlation between each of the elements of the model be known in some way.
3. Ambiguity – a state that emerges from the lack of clarity and structure as well as the built-in biases of estimating cost, schedule, and risk.?

Although mature organizations use many tools to support project planning, quantifying the uncertainty in these plans is not as common as we think. The PMBOK Guide identifies risk as a key area of concern but does not describe the management of the underlying uncertainty that produces the risk. Transforming project uncertainty into project risk management often requires that the concept of risk as an event ignores the source of risk emerging from the probabilistic and statistical nature of the project’s technical and programmatic activities.?

The concept that uncertainty and risk can be programmed out of the schedule is a false hope. Intrinsic variation pervades all natural systems. Observe or measure any characteristic of anything, and the result will vary from instance to instance. Plan or measure a task duration, or a cost associated with that task, and a natural variance will appear. Management thought leaders Walter Shewhart and?W. Edwards Deming taught that reacting to random changes in the system as if they mean something always degrades the process.?

Let’s put some bounds on the term uncertainty. There are four sources of uncertainty in projects and corresponding mechanisms to address them.

Identifying the Risk Mitigation Tasks in the Plan

Planning for risk management starts after risks have been identified and assessed. Risk Analysis makes use of mathematical models to evaluate the effects of choices of risk and mitigation.?Risk Analysis determines the sensitivity of risks to changes in independent and dependent factors described in the plan.

The actual schedule (a network of tasks) contains two types of uncertainty. These uncertainties are used to describe each of the project variations shown in Table 1 below. [ii]

• Systematic uncertainty is uncertainty about a specific parameter. This uncertainty comes from limited knowledge or data about the project.?These systematic uncertainties are due to things we could in principle know but don’t know in practice. This may be because they have not measured a quantity sufficiently accurately, because their model neglects certain effects, or because particular data are hidden. We need more knowledge (epistemology is the study of knowledge) about these uncertainties to protect the project from the risk they create and the resulting issues. This uncertainty is labeled epistemic or reducible uncertainty.
• Statistical uncertainty is representative of unknowns that differ each time we perform some class of work. The duration of any work, the first time it is performed, contains statistical uncertainty. This uncertainty comes from the stochastic behaviors of the underlying environment, system, processes, or project elements.

The probabilistic (Epistemic) uncertainty is addressed by mitigation tasks in the plan. If X occurs, I’ll deal with it by doing Y. This type of schedule risk planning is embedded in the baseline plan. Making these risks visible demonstrates explicit mitigation steps.

The statistical (Aleatory) uncertainty is addressed by first determining the probability distribution of the statistical processes that create the uncertainties. This does not mean the specific shape of the probability distribution function ? that should be done for the probabilistic uncertainties ? but the likelihood of occurrence profiles. This can be done through a risk classification scheme shown in Table 2.

For this approach to be effective, classification levels need to be calibrated to match the vocabulary of the project. Then the percentage overruns need to be calibrated to the class of project.

Next Steps

Using the risk rankings in Table 2, the explicit risk mitigation tasks (risk buy down for reducible risk or margin protection for irreducible risk) need to appear in the Integrated Master Schedule (IMS) as discrete activities and margin tasks in the same way any work activity does that deliver project outcomes.

With these risk mitigation activities in place, the next steps in building a risk-tolerant plan and schedule are:?

1. Identify probabilities for the various durations for activities in the plan and the durations of the mitigation activities – the period of exposure.
2. Assess the risk-adjusted completion dates for the deliverables defined in the schedule.
3. Assess the impact of these risks and the mitigations on the cost and schedule described in the activity network, including the residual risk after mitigation

Building a Risk Tolerant schedule starts with understanding that the traditional approaches to planning described above, leave out of the plan the very elements needed for risk tolerance. These elements start with the identification and assessment of the project, product, and process states as part of the schedule.

Steps in Building a Risk Tolerant Plan

1. Define the measurable maturity Events of the project. These are assessment points to determine if?the measures of effectiveness and performance of the capabilities and their deliverables agreed with the needed measure of effectiveness and performance by the customer. Capabilities describe a defined outcome that is not the final conclusion but lays the groundwork for the continued delivery of value.?Objectives are reached and the operational value is delivered when a defined capability is available for use. Features and functions describe the static and dynamic behaviors of a system, but they are not directly connected to a strategy, mission, or vision defined in the chartering session of the project. Milestones indicate the arrival of a point in time. Capabilities delivery provides an answer to the question: in order to achieve the objective of this project, what capabilities must be possessed?
2. Define the Significant Accomplishments and the Exit Criteria that deliver the needed Capabilities for the project. A capability is defined for each point along the maturity line – from immature to complete. Each Significant Accomplishment and its Exit Criteria needs to be worded as a past tense statement about the delivery of an end item. This delivery must be 100% of some defined result. No percentage complete is allowed! Rather 100% of a partially defined capability, product, or service clearly states what “done” looks like at each place along the way to completion of the project.
3. Define the work needed to deliver these Significant Accomplishments and their Exit Criteria. This provides the focus needed to define what “done” looks like for each exit criterion. These tasks should represent the vast majority of the activities in the plan. Any other work should be classified as Level of Effort.
4. Rank each task according to an ordinal risk scale. Each task must be ranked since, it is not clear in the beginning which tasks will be critical to the completion of the schedule, and which ones will interact and cause programmatic risks to appear.
5. The ranking of risk. Six basic classes are commonly used. [3] The probability scales commonly used are uncalibrated in most instances. These types of scales (un-calibrated) generally produce poor results unless the process is well-structured, stable, and repeatable. This is usually represented in the 5 x 5 chart [ cox paper]
6. Define the explicit tasks to mitigate the known risks. These are risks with a probability of occurrence and a probable impact. These tasks should be placed in front of Significant Accomplishments to provide a buffer or time for correction.
7. Define alternative paths through the schedule for unknown risks – risks with a probability of occurrence but with an unknown impact. These paths are indicated as branching probabilities in the plan.

The result is a plan where risks and their mitigations are visible with risk ranking for each task delivering results for each Exit Criteria. Table 4 shows how uncalibrated ordinal scales can be defined for various risk domains. [ii]

Processes and Practices of Risk Management

“Risk monitoring is the process that systematically tracks and evaluates the performance of risk–handling actions against established metrics throughout the project and develops further risk–handling options, as appropriate. It feeds information back into the other risk management activities of planning, assessment, and handling.”[[i]]?

If monitoring is passive, then it is just a bookkeeping function. Proactive risk monitoring provides quantitative information to decision makers through variance in the Cost, Performance, Schedule, and changes in the risk analysis data. Earned Value provides cardinal values for Cost and Schedule (C-S) metrics. Technical Performance Measures provide cardinal values for Performance (P) metrics. The C-P-S cardinal values are the basis of a continuous risk management process by aligning risk reduction tasks with the Significant Accomplishments and their Exit Criteria.

These risk monitoring metrics provide adjustments to the risk handling strategy and the Risk Handling Plan and provide information to update the risk probability and risk consequence portion of the risk analysis.

Learning to create risk-tolerant schedules and managing the technical and programmatic risks created by uncertainties represented by this schedule is a professional practice. A high technology program manager once noted, “You can’t learn surgery from reading a book — you need to successfully complete a surgical residency.”?

No amount of attending seminars or reading books or articles (even these articles) will provide the solution to managing schedule risks. But there are two good starting points: Risk Management Guide for DoD Acquisition, Fifth Edition (Version 2.0), Department of Defense, Defense Acquisition University, June 2003, and Effective Risk Management: Some Keys to Success, Edmund H. Conrow, AIAA Press, 2003.

These are recommended practicum guides. PMBOK?, while introductory in nature, does not provide an integrated approach to Cost, Performance, and Schedule risk management.?

There are other texts that should be on the shelf of any competent risk management professional, including Making Hard Decisions, 2nd Edition, Robert T. Clemen, Duxberry Press, 1996; Introduction to Statistical Decision Theory, John W. Pratt, Howard Raiffa and Robert Schlaifer, MIT Press, 1995; Quantitative Risk Analysis, David Vose, John Wiley and Sons, 2000; and Practical Risk Assessment for Project Management, Stephen Gray, John Wiley and Sons, 1995.

These all provide the basis for understanding the issues with traditional approaches to risk management and its flaws. The paper, “Building A Credible Performance Measurement Baseline,” in Measureable News, 2014.04 provides the mechanics for correcting these flaws.

Foot Notes

[i] PMBOK?, the British Standards Institute and the UK Institution of Civil Engineers as well as numerous internal risk management handbooks combine risk and opportunity into single assessment criteria. It could be argued that risk includes both opportunities and losses. However, there is rarely an opportunity without the possibility of loss. On the other hand, there is almost always a chance of loss without opportunity. The PMBOK approach changes the definition of risk: the potential for the realization of unwanted, negative consequences of an event. Opportunities are generally events that require intentional actions in order to achieve value. Risks are events that can be ignored. For a detailed discussion of this issue as well as a definitive presentation of risk management, see Appendix E, “Changing the Definition of Risk – Why Risk It?” Robert N. Charette, in Effective Risk Management: Some Keys to Success, 2nd Edition, Edmund H. Conrow, American Institute of Aeronautics and Astronautics Press, 2003.

[ii] “Distinguishing and integration aleatoric and epistemic variation in uncertainty quantification,” Kamaljit and Paul Dupuis, ESAIM: Mathematical Modeling and Numerical Analysis, Volume 47, Issue 3, Page 635- 662, 2013.

[iii] Department of Defense Risk, Issue, and Opportunity Management Guide for Defense Acquisition Programs, June 2015, Office of the Deputy Assistant Secretary of Defense for Systems Engineering, Washington, D.C.

Bibliography

1. “Building A Credible Performance Measurement Baseline,” Glen B. Alleman, Thomas J. Coonce, and Rick A. Price?Measurable News, 2014.04, College of Performance Management.
2. Department of Defense Risk, Issue, and Opportunity Management Guide for Defense Acquisition Programs, June 2015, Office of the Deputy Assistant Secretary of Defense for Systems Engineering, Washington, D.C.
3. Risk Management Guide for DOD Acquisition, pp. 88.
4. Risk Happens!: Managing Risk and Avoiding Failure in Business Projects, Mike Clayton, Marshall Cavendish Business, 2011.
5. Managing Risk: Methods for Software Systems Development, Elaine M. Hall, SEI Series in Software Engineering, 1998.
6. Technical Risk Management, Jack V. Michaels, Prentice Hall, 1996.
7. Project Risk Management: Process, Techniques, and Insights, Second Edition, Chris Chapman and Stephan Ward, John Wiley & Sons, 2003.
8. Effective Opportunity Management for Project: Exploiting Positive Risk, David Hillson, Taylor & Francis, 2004.
9. Against the Gods: The Remarkable Story of Risk, Peter L. Bernstein, John Wiley & Sons, 1996.
10. “A Hybrid Method to Deal with Aleatory and Epistemic Uncertainty in Risk Assessment,” Palash Dutta and Tazid Ali, International Journal of Computer Applications, Volume 42, Number 11, march 2012.
11. Continuous Risk Management Guidebook, Software Engineering Institute, 1996.
12. Practical Project Risk Management: The ATOM Methodology, David Hillson and Peter Simon, Management Concepts, 2007.