Building Risk Tolerance

Technical and programmatic disruptions in project plans don’t have to negatively impact cost, performance, or schedule metrics. But traditional approaches to planning are not an adequate defense. In the third and final article in this risk management series, the author outlines the six steps for building a risk-tolerant schedule.

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 are taken when they occur.

Risk Tolerance means that disruptions in the technical or programmatic plans can be tolerated in a way that does not negatively impact the cost, performance, or schedule (C-P-S metrics) of the plan.

A Risk Management Structure

The figure below describes the Risk Management structure defined in Risk Management Guide for DoD Acquisition. This will be the structure used for developing the Risk Tolerant schedule. It is the Risk Planning, Risk Handling, and Risk Monitoring process that forms the basis of this article.

To build a risk-tolerant schedule, the PMI PMBOK Edition 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 duration 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 in that it defines the processes that might be used to build the schedule, it fails to address the core weakness of most plans not specifically designed to be risk-tolerant on four counts:

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 as the passage of time and consumption of resources, not the increasing technical or programmatic maturity.
3. It is activity-based, with no quantitative basis for 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. PMBOK describes the recommended activities for Risk Response Planning, but it fails to make it clear 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, leaves 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 assessment points can be determined in terms of capabilities or fidelity of the deliverables agreed to by the customer. Capabilities describe a defined outcome that is not the final conclusion but lay the groundwork for the continued delivery of value.[2] 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 reaching a point in time. Capabilities provide 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 each accomplishment, traceable to each project Event assessment point. 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 the 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 a level of effort.
4. ?Rank each task according to an ordinal risk scale. Each task must be ranked since, it is not clear at the beginning which tasks will be critical to the completion of the schedule, and which ones 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. Ordinal scales can be defined for various risk domains:

These examples can have 3 to 4 intermediate ordinal values, but unless the proper class of ordinal value is used and these scales calibrated poor results will be the only outcome.[4]

5. 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.?

?6. 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.

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 back 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 metrics 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 a risk-tolerant schedule, and managing the technical and programmatic risks represented by this schedule is a 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 these are two good starting points: Risk Management Guide for DoD Acquisition, Fifth Edition (Version 2.0), Department of Defense, DefenseAcquisitionUniversity, June 2003, and Effective Risk Management: Some Keys to Success, Edmund H. Conrow, AIAA Press, 2003. These are recommended for the sole purpose that they are practicum guides. PMBOK, while introductory in nature, does not provide an integrated approach to Cost, Performance, and Schedule risk management.?

As well, there are other texts that should be on the shelf of any competent risk management professional: 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.

[1] 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.

[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 the use of ordinal values is simple it is fraught with problems. Ordinal is 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 best addressed in a book-length manner. Appendix H and Appendix J of Effective Risk Management, E. H. Conrow are the best sources.

[5] Risk Management Guide for DOD Acquisition, pp. 8