Building a Risk-Tolerant Schedule

Technical and programmatic disruptions in project plans don’t need to negatively impact cost, performance, or schedule metrics.?However, traditional planning approaches are not an adequate defense. This white paper outlines the six steps for building a risk-tolerant schedule using a field-proven approach.

In two prior white papers in this risk management series — “Risk/Opportunity” and “Managing Schedule Risk” — the importance of planning risk management tasks and managing different types of uncertainty in the project schedule was presented. This approach lays the foundation for building a risk-tolerant project schedule that identifies programmatic risk and implements the needed mitigation activities.

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

1. Measures of progress must be quantitative rather than qualitative,
2. Normal and foreseen risk handling must be explicitly visible in the plan and
3. Unforeseen risks must be acknowledged, and actions must be taken when they occur.

Risk Management Structure

This chart describes the Risk Management structure

To build a risk-tolerant schedule, the PMBOK 3rd Edition instructs us to:

• Identify the scheduled activities needed to complete the project.
• Sequence these activities in their order of dependency.
• Estimate the resources required 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 since it defines processes that can be used to build the schedule, it fails to address the core weakness of most planning processes by not being specifically designed to be Risk Tolerant in four ways:

1. It is activity–based, not risk mitigation-based. Technical risk is identified in PMBOK, but its connection to and with programmatic risk is not defined. [1]
2. It is activity–based, not maturity assessment-based. Progress is measured by the passage of time and resource consumption, not by increasing technical or programmatic maturity.
3. It is activity–based, with no quantitative basis of assessing the risk reduction effort from the current state to completion. Explicit risk buy-down activities are not discussed in a manner consistent with an integrated plan.
4. §11.5.2 of the PMBOK describes the recommended activities for Risk Response Planning, but it does not clarify how to integrate these mitigation activities into the plan.

Measurable Maturity and Embedded Risk Management

Building a Risk-Tolerant schedule starts with understanding that the traditional approaches to planning described above leave out the elements needed for risk tolerance. These elements begin with identifying and assessing the project, product, and process states as part of the schedule.

Steps in Building a Risk-Tolerant Plan

Define the measurable maturity of the project events. These assessment points can be determined based on the capabilities or fidelity of the deliverables agreed upon by the customer. Capabilities describe a defined outcome that is not the conclusion but lays the groundwork for continued value delivery.?[2] Objectives are reached, and the operational value is delivered when a defined capability is available. Features and functions describe the static and dynamic behaviors of a system. Still, 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 answers the question: to achieve the objective of this project, what capabilities must be possessed?

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! Instead, 100% of a partially defined capability, product, or service clearly states what “done” looks like at each place along the way to the completion of the project.

Define the work needed to deliver the Significant Accomplishments and their Exit Criteria. This focuses on defining what “done” looks like for each exit criterion. These tasks should represent the vast majority of the activities in the plan. Any 1.???? other work should be classified as Level of Effort.

Rank each task according to an ordinal risk scale. Each task must be ranked since it is unclear in the beginning which tasks will be critical to the completion of the schedule and which will interact and cause programmatic risks to appear.

The ranking of risk. Six basic classes are commonly used. [3] The probability scales commonly used are un-calibrated in most instances. These types of scales (un-calibrated) generally produce poor results unless the process is well structured, stable and repeatable.

Define alternative paths through the schedule for unknown risks, which are risks with a probability of occurrence but an unknown impact. The plan indicates these paths as branching probabilities.

The result is a plan where risks and their mitigations are visible, with risk ranking for each task delivering results for each Exit Criteria.

Increasing the Probability of Program Success

Cost and Schedule growth for any project or program is created when there are:

1. 1. Impractical technical performance expectations,

2. Impractical cost and schedule estimates,

3. Insufficient risk assessments, and

4. Unexpected technical challenges.

These are all based on poorly performed and ineffective risk management. These primary causes contribute to the program's technical and programmatic shortfalls. The table below shows the causes and their contributing factors that reduce the probability of program success, documented in various sources.

The Root Causes of cost and schedule growth and technical shortfall start with:

1. Failing to clearly define what Done looks like in terms of Measures of Effectiveness and Measures of Performance for the outcomes before starting project work,
2. Not quantifying the reducible and irreducible uncertainties that pose risks affecting the probability of success of the program and
3. Not effectively managing the risks created by these uncertainties regarding the Measures of Performance associated with each Measure of Effectiveness during the program's execution.

Processes and Practices

"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 into the other risk management activities of planning, assessment, and handling." [5]?

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 Significant Accomplishments and their Exit Criteria.

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

Learning to create a risk-tolerant schedule and managing the technical and programmatic risks this schedule represents is a practice. A high technology program manager once noted, "You can't learn surgery from reading a book — you need to 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, does not provide an integrated approach to Cost, Performance, and Schedule risk management.?

Other texts that should be on the shelf of any competent risk management professional include:

• Making Hard Decisions, 2nd Edition, by Robert T. Clemen, Duxberry Press, 1996;?
• Introduction to Statistical Decision Theory, by John W. Pratt, Howard Raiffa, and Robert Schlaifer, MIT Press, 1995;?
• Quantitative Risk Analysis, by David Vose, John Wiley and Sons, 2000; and?
• Practical Risk Assessment for Project Management, by Stephen Gray, John Wiley and Sons, 1995.

Bibliography

1. PMBOK?, the British Standards Institute, the UK Institution of Civil Engineers, and 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 realizing unwanted, negative consequences of an event. Opportunities are generally events that require intentional actions to achieve value. Risks are events that can be ignored.
2. "Agile Program Management: Moving from Principles to Practice," Glen B. Alleman, Cutter Agile Project Management Advisory Service, Volume 6, Number 9.
3. Appendix H: Some Characteristics and Limitations of Ordinal Scales in Risk Analyses, in Effective Risk Management, Edmund Conrow, AIAA, 2003.
4. Although using ordinal values is simple, it is fraught with problems. Ordinal are a standard approach to risk ranking. If ordinal scales are used, their values must be derived from the underlying probability data or be calibrated with actual probability data. This is a complex topic that is best addressed in a book-length manner. The best sources are Appendix H and Appendix J of?Effective Risk Management, E. H. Conrow.
5. Risk Management Guide for DOD Acquisition, pp. 88.