Risk Analysis

With the many problems that we have experienced in developing large-scale systems, we have included the subject of risk analysis as a formal element of systems engineering. In broad terms, risk may be explored in four key areas from the perspective of the CSE: (1) schedule risk, (2) cost risk, (3) performance risk, and (4) societal risk.

Schedule risk is prevalent, of course, under tight deadlines that must be met and that may have penalties associated with not meeting critical milestones. In such a situation, the critical path and all near-critical paths must be examined in detail to assure that schedule risk is minimized. Cost risk may be dominant when new development efforts are required along with the


High-cost high-effectiveness system \

Knee-of-the curve" / sytem

Low-cost low-effectiveness system Minimum effectiveness requirement


Figure 7.5. Cost-effectiveness notions.

introduction of new technologies. Pushing the state of the art often results in considerable cost risk and the CSE and his or her team must examine all cost uncertainty areas extremely closely. Another factor is the type of contract under which the system is being procured. The discussion in Chapter 4 provides some further insight into this latter issue.

The most difficult area is performance risk, and it generally leads to both schedule and cost problems. Performance risk can be minimized by assigning your best systems engineering team and incorporating as many commercial-off-the-shelf (COTS) and nondevelopmental item (NDI) components as possible.

Finally, there is the matter of societal risk. This is the risk to the public that could result from the deployment of the system in question. Examples might include nuclear power plants, chemical processing plants, systems that might release toxic materials into our air and water, and the like. It is a clear responsibility of the systems engineering team to acknowledge such risks and build a system that minimizes potential hazards to the public. Issues of public safety are now squarely a feature of building large-scale systems and therefore fall upon the systems engineering team to consider in detail. Other administrative risks, as cited in Chapter 3, remain generally within the purview of the Project Manager.

In essentially all aspects of risk assessment, there are two key factors that play a central role. These are:

1. The likelihood that a high-risk event or set of events will occur

2. The consequences, given the occurrence of the foregoing event(s)

The most serious risks, of course, are represented when both factors are high. Therefore, a careful analysis has to ferret out such possible situations and then try to reduce both factors. If the consequence factor cannot be significantly changed (e.g., the catastrophic failure of a manned space mission), then system modifications should be made that reduce the probability factor.

The above notions of high-risk likelihood and consequence can be incorporated into a two-way table or matrix that has been the basis for a variety of risk analyses. These analyses partition the likelihood into high, medium, and low, and do the same for the consequences. These are then explored by reference to Table 7.3.

If we construct such a risk table, we can readily conclude that the situations represented by the High-High cell are the ones to which we should pay most attention in terms of what can be done to mitigate the risk. The next two troublesome cells are, of course, shown as the High-Medium and the Medium-High cases. Finally, if the previous cases have been satisfactorily dealt with, it may be possible to move to the Medium-Medium case. There is normally considerable discretion with respect to the assignment of numerical values to probabilities as well as the consequences. As an example, for the former, one might consider the ranges listed below:

• High Probability: From 0.7 to 1.0 (as close to unity as measurable)

Consequences are often converted into dollar figures, unless other loss measures are more appropriate. This, however, is an area that can be quite controversial, especially when human lives are at stake with respect to negative consequences.

The manner in which the overall subject of risk analysis is approached can be quite varied. This may be illustrated by briefly looking at two agencies, the Department of Defense (DoD) and the National Aeronautics and Space Administration (NASA). The former, for example, defines risk management as [7.14]:

TABLE 7.3 Risk Table or Matrix

Low Probability

Medium Probability

High Probability

High Consequence Medium Consequence Low Consequence






Risk management is a program management responsibility and is the act or practice of controlling the risk drivers that adversely affect the program. It includes the process of identifying, analyzing, and tracking risk drivers, assessing the likelihood of their occurrence and their consequences, defining risk-handling plans, and performing continuous assessments to determine how risks change during the life of the program.

A sample format for a Risk Management Plan includes the following sections:

1. Introduction

2. Program summary

3. Definitions

4. Risk management strategy and approach

5. Organization

6. Risk management process and procedures

Special attention is paid to technical risk management, since it is often the case that technical risk ''is a significant driver of all other program risks'' [7.14]. The three primary approaches to technical risk management involve a detailed analysis of:

1. Critical processes

2. Deliverable products (usually identifiable from the work breakdown structure), and

3. Integrated processes and products

A brief look at some of NASA's documentation with respect to risk management reveals a serious attempt to define the life-cycle risk management elements [7.15], namely:

1. ISO 9001 compliance

2. Industry best practices: design and engineering

3. Key characteristic and critical process management

4. Industry best practices: manufacturing

5. Test/verification/validation

6. Supply chain integration and management

7. Implementation assurance

8. Independent assessment

We note the elements of best practices in industry and a topic known as verification and validation. This latter area was listed as one of the thirty elements of systems engineering and is discussed in a later section of this chapter.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment