Page 903

17— Risk Management1

17.0— Introduction

In the early days of project management on many commercial programs, the majority of project decisions heavily favored cost and schedule. This favoritism occurred because we knew more about cost and scheduling than we did about technical risks. Technology forecasting was very rarely performed other than by extrapolating past technical knowledge into the present.

Today, the state of the art of technology forecasting is being pushed to the limits. For projects with a time duration of less than one year, we normally assume that the environment is known and stable, particularly the technological environment. For projects over a year or so in length, technology forecasting must be considered. Computer technology doubles in performance about every two years. Engineering technology is said to double every three or so years. How can a project manager accurately define and plan the scope of a three- or four-year project without expecting engineering changes resulting from technology improvements? What are the risks?

A Midwest manufacturing company embarked on an eight-year project to design the manufacturing factory of the future. The plant is scheduled to go into the construction phase in the year 2000. How do we design the factory of the future without forecasting the technology? What computer technology will exist? What types of materials will exist and what types of components will our customers require? What production rate will we need and will technology exist to support this production level?

Economists and financial institutions forecast interest rates. The forecasts appear in public newspapers and journals. Yet, every company involved in high tech does some form of technology forecasting, but ap-

1 This chapter was updated by Dr. Edmund H. Conrow CMC, PMP. Dr. Conrow has extensive experience in developing and implementing risk management on a wide variety of projects. He is the author of: Effective Risk Management: Some Keys To Success, American Institute of Aeronautics and Astronautics. Reston, VA, 2000. He can be reached at (310) 374 -7975 and www.risk-services.com

Page 904

pears very reluctant to publish the data. Technology forecasting is regarded as company proprietary information and may be part of the company's strategic planning process.

We read in the newspaper about cost overruns and schedule slips on a wide variety of large-scale development projects. Several issues within the control of the buyer, seller, or major stakeholders can lead to cost growth and schedule slippage on development projects. These causes include, but are not limited to:2

• Starting a project with a budget and/or schedule that is inadequate for the desired level of performance or scope (e.g., integration complexity).

• Having an overall development process (or key parts of that process) that favors performance (or scope) over cost and schedule.

• Establishing a design that is near the feasible limit of achievable performance or integration complexity at a given point in time.

• Making major project design decisions before the relationships between cost, performance, schedule, and risk are understood.

These four causes will contribute to uncertainty in forecasting technology and the associated design needed to meet performance requirements. And the inability to perfectly forecast technology and the associated design will contribute to a project's technical risk, and can also lead to cost and schedule risk.

Today, the competition for technical achievement has become fierce. Companies have gone through life-cycle phases of centralizing all activities, especially management functions, but are decentralizing technical expertise. By the mid 1980s, many companies recognized the need to integrate technical risks with cost and schedule risks, and other activities (e.g., quality). Risk management processes were developed and implemented where risk information was made available to key decision-makers.

The risk management process, however, should be designed to do more than just identify the risk. The process must also include: a formal planning activity, analysis to quantify the likelihood and predict the impact on the project, a handling strategy for selected risks, and the ability to monitor the progress in reducing these selected risks to the desired level.

A project, by definition, is something that we have not done previously and will not do again in the future. Because of this uniqueness, we have developed a ''live with it" attitude on risk and attribute it as part of doing business. If risk management is set up as a continuous, disciplined process of planning, assessment (identification and analysis), handling, and monitoring, then the system will easily supplement other systems as organization, planning and budgeting, and cost control. Surprises that become problems will be diminished because emphasis will now be on proactive rather than reactive management.

Risk management can be justified on almost all projects. The level of implementation can vary from project to project, depending on such factors as size, type of project, who the customer is, relationship to the corporate strategic plan, and corporate culture. Risk management is particularly important when the overall stakes are high and a great deal of uncertainty exists. In the past, we treated risk as a "let's live with it." Today, risk management is a key part of overall project management. It forces us to focus on the future where uncertainty exists and develop suitable plans of action to prevent potential issues from adversely impacting the project.

2 Edmund H. Conrow, "Some Long-Term Issues and Impediments Affecting Military Systems Acquisition Reform," Acquisition Review Quarterly, Defense Acquisition University, Summer 1995.

 

Page 905

17.1— Definition of Risk

Risk is a measure of the probability and consequence of not achieving a defined project goal. Most people agree that risk involves the notion of uncertainty. Can the specified aircraft range be achieved? Can the computer be produced within budgeted cost? Can the new product launch date be met? A probability measure can be used for such questions; for example, the probability of not meeting the new product launch date is 0.15. However, when risk is considered, the consequences or damage associated with occurrence must also be considered.

Goal A, with a probability of occurrence of only 0.05, may present a much more serious (risky) situation than goal B, with a probability of occurrence of 0.20, if the consequences of not meeting goal A are, in this case, more than four times more severe than failure to meet goal B. Risk is not always easy to assess, since the probability of occurrence and the consequence of occurrence are usually not directly measurable parameters and must be estimated by statistical or other procedures.

Risk has two primary components for a given event:

• A probability of occurrence of that event

• Impact of the event occurring (amount at stake)

Figure 17–1 shows the components of risk.

Conceptually, risk for each event can be defined as a function of likelihood and impact; that is,

In general, as either the likelihood or impact increases, so does the risk. Both the likelihood and impact must be considered in risk management.

Risk constitutes a lack of knowledge of future events. Typically, future events (or outcomes) that are favorable are called opportunities, whereas unfavorable events are called risks.

Another element of risk is the cause of risk. Something, or the lack of something, can induce a risky situation. We denote this source of danger as the hazard. Certain hazards can be overcome to a great extent by knowing them and taking action to overcome them. For example, a large hole in a road is a much greater danger to a driver who is unaware of it than to one who travels the road frequently and knows enough to slow down and go around the hole. This leads to the second representation of risk:

Risk increases with hazard but decreases with safeguard. The implication of this equation is that good project management should be structured to identify hazards and to allow safeguards to be developed to overcome them. If enough safeguards are available, then the risk can be reduced to an acceptable level.

TEAMFLY

Team-Fly®

 

Page 906

Figure 17–1. Overall risk is a function of its components.

17.2— Tolerance for Risk

There is no single textbook answer on how to manage risk. The project manager must rely upon sound judgment and the use of the appropriate tools in dealing with risk. The ultimate decision on how to deal with risk is based in part upon the project manager's tolerance for risk.

The three commonly used classifications of tolerance for risk appear in Figure 17–2. They include the risk averter or avoider, the neutral risk taker, and the risk seeker or lover. The Y axis in Figure 17–2 represents "utility," which can be defined as the amount of satisfaction or pleasure that the individual receives from a payoff. (This is also called the project manager's tolerance for risk.) The X axis in this case is the amount of money at stake.

Figure 17–2. Risk preference and the utility function.

 

Page 907

With the risk averter, utility rises at a decreasing rate. In other words, when more money is at stake, the project manager's satisfaction or tolerance diminishes. With the risk lover, the project manager's satisfaction increases when more money is at stake (i.e., an increasing slope to the curve). A risk averter prefers a more certain outcome and will demand a premium to accept risk. A risk lover prefers the more uncertain outcome and may be willing to pay a penalty to take a risk.

17.3— Definition of Risk Management

Risk management is the act or practice of dealing with risk. It includes planning for risk, assessing (identifying and analyzing) risk issues, developing risk handling options, and monitoring risks to determine how risks have changed.

Risk management is not a separate project office activity assigned to a risk management department, but rather is one aspect of sound project management. Risk management should be closely coupled with key project processes, including but not limited to: overall project management, systems engineering, cost, scope, quality, and schedule.

Proper risk management is proactive rather than reactive. As an example, an activity in a network requires that a new technology be developed. The schedule indicates six months for this activity, but project engineers think that nine months is closer to the truth. If the project manager is proactive, he might develop a Risk Handling Plan right now. If the project manager is reactive (e.g., a "problem solver"), then he will do nothing until the problem actually occurs. At that time the project manager must react rapidly to the crisis, and may have lost valuable time when contingencies could have been developed. Hence, proper risk management will attempt to reduce the likelihood of an event occurring and/or the magnitude of its impact.

17.4— Certainty, Risk, and Uncertainty

Decision-making falls into three categories: certainty, risk, and uncertainty. Decision-making under certainty is the easiest case to work with. With certainty, we assume that all of the necessary information is available to assist us in making the right decision, and we can predict the outcome with a high level of confidence.

Decision-Making under Certainty

Decision-making under certainty implies that we know with 100 percent accuracy what the states of nature will be and what the expected payoffs will be for each state of nature. Mathematically, this can be shown with payoff tables.

 

Page 908

To construct a payoff matrix, we must identify (or select) the states of nature over which we have no control. We then select our own action to be taken for each of the states of nature. Our actions are called strategies. The elements in the payoff table are the outcomes for each strategy.

A payoff matrix based on decision-making under certainty has two controlling features.

• Regardless of which state of nature exists, there will be one dominant strategy that will produce larger gains or smaller losses than any other strategy for all the states of nature.

• There are no probabilities assigned to each state of nature. (This could also be stated that each state of nature has an equal likelihood of occurring.)

Example 17–1. Consider a company wishing to invest $50 million to develop a new product. The company decides that the states of nature will be either a strong market demand, an even market demand, or a low market demand. The states of nature shall be represented as N1 = a strong market, N2 = an even market, and N3 = a low market demand. The company also has narrowed their choices to one of three ways to develop the product: either A, B, or C. There also exists a strategy S4, not to develop the product at all, in which case there would be neither profit nor loss. We shall assume that the decision is made to develop the product. The payoff matrix for this example is shown in Table 17–1. Looking for the controlling features in Table 17–1, we see that regardless of how the market reacts, strategy S3 will always yield larger profits than the other two strategies. The project manager will therefore always select strategy S3 in developing the new product. Strategy S3 is the best option to take.

Table 17–1 can also be represented in subscript notation. Let Pi,j be the elements of the matrix, where P represents profit. The subscript i is the row (strategy), and j is the column (state of nature). For example, P2,3 = the profit from choosing strategy 2 with N3 state of nature occurring. It should be noted that there is no restriction that the matrix be square (i.e., the number of states of nature need not equal the number of possible strategies).

Decision-Making under Risk

In most cases, there usually does not exist one dominant strategy for all states of nature. In a realistic situation, higher profits are usually accompanied by higher risks and therefore higher probable losses. When there does not exist a dominant strategy, a probability must be assigned to the occurrence of each state of nature.

TABLE 17–1.  PAYOFF MATRIX (PROFIT IN MILLIONS)

  States of Nature

Strategy N1 = Up N

2 = Even N

3 = Low

S1 = A   $50 $40 –$50

S2 = B   $50 $50   $60

S3 = C $100 $80   $90

 

Page 909

Risk can be viewed as outcomes (i.e., states of nature) that can be described within established confidence limits (i.e., probability distributions). These probability distributions are obtained from well-defined experimental distributions.

Consider Table 17–2, in which the payoffs for strategies 1 and 3 of Table 17–1 are interchanged for the state of nature N3.

From Table 17–2, it is obvious that there does not exist one dominant strategy. When this occurs, probabilities must be assigned to the possibility of each state of nature occurring. The best choice of strategy is therefore the strategy with the largest expected value, where the expected value is the summation of the payoff times and the probability of occurrence of the payoff for each state of nature. In mathematical formulation,

where Ei is the expected payoff for strategy i, P i,j is the payoff element, and Pj is the probability of each state of nature occurring. The expected value for strategy S1 is therefore

Repeating the procedure for strategy 2 and 3, we find that E2 = 55, and E3 = 20. Therefore, based on the expected value, the project manager should always select strategy S1. If two strategies of equal value occur, the decision should include other potential considerations (time to impact, frequency of occurrence, resource availability, etc.).

To quantify potential payoffs, we must identify the strategy we are willing to take, the expected outcome (element of the payoff table), and the probability that the outcome will occur. In the previous example, we should accept the risk associated with strategy S1, since it gives us the greatest expected value. If the expected value is positive, then this risk should be considered. If the expected value is negative, then this risk should be proactively managed.

An important factor in decision-making under risk is the assigning of the probabilities for each of the states of nature. If the probabilities are erroneously

TABLE 17–2.  PAYOFF TABLE (PROFIT IN MILLIONS)

  States of Nature*

StrategyN

1

0.25*N

2

0.25*N

3

0.50*

S1  50 40   90

S2  50 50   60

S3100 80 –50

*Numbers are assigned probabilities of occurrence for each state of nature.

 

Page 910

assigned, different expected values will result, thus giving us a different perception of the best risk to take. Suppose in Table 17–2 that the assigned probabilities of the three states of nature are 0.6, 0.2, and 0.2. The respective expected values are:

In this case, the project manager would always choose strategy S3.

Decision-making under Uncertainty

The difference between risk and uncertainty is that under risk there are assigned probabilities, and under uncertainty meaningful assignments of probabilities are not possible. As with decision-making under risk, uncertainty also implies that there may exist no single dominant strategy. The decision-maker, however, does have at his disposal four basic criteria from which to make a management decision. The decision about which criterion to use will depend on the type of project as well as the project manager's tolerance to risk.

The first criterion is the Hurwicz criterion, often referred to as the maximax criterion. Under the Hurwicz criterion, the decision-maker is always optimistic and attempts to maximize profits by a go-for-broke strategy. This result can be seen from the example in Table 17–2. The maximax criterion says that the decision-maker will always choose strategy S3 because the maximum profit is 100. However, if the state of nature were N3, then strategy S3 would result in a maximum loss instead of a maximum gain. The use of the maximax, or Hurwicz, criterion must then be based on how big a risk can be undertaken and how much one can afford to lose. A large corporation with strong assets may use the Hurwicz criterion, whereas the small private company might be more interested in minimizing the possible losses.

A small company would be more apt to use the Wald, or maximin, criterion, where the decision-maker is concerned with how much he can afford to lose. In this criterion, a pessimistic rather than optimistic position is taken with the viewpoint of minimizing the maximum loss.

In determining the Hurwicz criterion, we looked at only the maximum payoffs for each strategy in Table 17–2. For the Wald criterion, we consider only the minimum payoffs. The minimum payoffs are 40, 50, and –50 for strategies S1, S2, and S3, respectively. Because the project manager wishes to minimize his maximum loss, he will always select strategy S2 in this case. If all three minimum payoffs were negative, the project manager would select the smallest loss if these were the only options available. Depending on a company's financial position, there are situations where the project would not be undertaken if all three minimum payoffs were negative.

The third criterion is the Savage, or minimax, criterion. Under this criterion, we assume that the project manager is a sore loser. To minimize the regrets of the

 

Page 911

sore loser, the project manager attempts to minimize the maximum regret; that is, the minimax criterion.

The first step in the Savage criterion is to set up a regret table by subtracting all elements in each column from the largest element. Applying this approach to Table 17–2, we obtain Table 17–3.

The regrets are obtained for each column by subtracting each element in a given column from the largest column element. The maximum regret is the largest regret for each strategy, that is, in each row. In other words, if the project manager selects strategy S1 or S2, he will only be sorry for a loss of 50. However, depending on the state of nature, a selection of strategy S3 may result in a regret of 140. The Savage criterion would select either strategy S1 or S2 in this example.

The fourth criterion is the Laplace criterion. The Laplace criterion is an attempt to transform decision-making under uncertainty into decision-making under risk. Recall that the difference between risk and uncertainty is a knowledge of the probability of occurrence of each state of nature. The Laplace criterion makes an a priori assumption based on Bayesian statistics, that if the probabilities of each state of nature are not known, then we can assume that each state of nature has an equal likelihood of occurrence. The procedure then follows decision-making value. Using the Laplace criterion applied to Table 17–2, we obtain Table 17–4. Using the Laplace criterion, the project manager would therefore choose strategy S1.

The important conclusion to be drawn from decision-making under uncertainty is the risk that the project manager wishes to incur. For the four criteria previously mentioned, we have shown that any strategy can be chosen depending on how much money we can afford to lose and what risks we are willing to take.

The concept of expected value can also be combined with "probability" or "decision" trees to identify and quantify the potential risks. Another common term is the impact analysis diagram. Decision trees are used when a decision cannot be viewed as a single, isolated occurrence, but rather as a sequence of several interrelated decisions. In this case, the decision-maker makes an entire series of decisions simultaneously.

Consider the following problem. A product can be manufactured using Machine A or Machine B. Machine A has a 40 percent chance of being used and Machine B a 60 percent chance. Both machines use either Process C or D. When Machine A is selected, Process C is selected 80 percent of the time and Process D 20 percent. When Machine B is selected, Process C is selected 30 percent of

TABLE 17–3.  REGRET TABLE

  States of Nature  Strategy N

1N

2N

3Maximum Regrets

S150 40     0   50

S250 30   30   50

S3  0   0 140 140

 

Page 912

TABLE 17–4.  LAPLACE CRITERION

Strategy Expected Value

S160

S2160/3

S3130/3

the time and Process D 70 percent of the time. What is the probability of the product being produced by the various combinations?

Figure 17–3 shows the decision tree for this problem. The probability at the end of each branch (furthest to the right) is obtained by multiplying the branch probabilities together.

For more sophisticated problems, the process of constructing a decision tree can be complicated. Decision trees contain decision points, usually represented by a box or square, where the decision-maker must select one of several available alternatives. Chance points, designated by a circle, indicate that a chance event is expected at this point.

The following three steps are needed to construct a tree diagram:

• Build a logic tree, usually from left to right, including all decision points and chance points.

• Put the probabilities of the states of nature on the branches, thus forming a probability tree.

• Finally, add the conditional payoffs, thus completing the decision tree.

Figure 17–3. Decision tree.

 

Page 913

Figure 17–4. Expanded tree diagram.

Consider the following problem. You have the chance to make or buy certain widgets for resale. If you make the widgets yourself, you must purchase a new machine for $35,000. If demand is good, which is expected 70 percent of the time, an $80,000 profit will occur on the sale of the widgets. With poor market conditions, $30,000 in profits will occur, not including the cost of the machine. If we subcontract out the work, our contract administration costs will be $5,000. If the market is good, profits will be $50,000; for a poor market, profits will be $15,000. Figure 17–4 shows the tree diagram for this problem. In this case, the expected value of the strategy that subcontracts the widgets is both positive and $4,500 greater than the strategy that manufactures the widgets. Hence, here we should select the strategy that subcontracts the widgets.

17.5— Risk Management Process

It is important that a risk management strategy is established early in a project and that risk is continually addressed throughout the project life cycle. Risk management includes several related actions involving risk: planning, assessment (identification and analysis), handling, and monitoring:3

3 This risk management structure, and some of the informatio in subsequent subsections, is derived from work performed by the Department of Defense in 1996–1998, and summarized in: "Risk Management Guide for DoD Acquisition," Defense Acquisition University and Defense Systems Management College, Second Edition, May 1999. This is quite simple the best introductory document on risk management that exists and it is applicable, with suitable tailoring, to a wide variety of projects, including commercial projects. (The URL to download this risk management guide free of charge at the time of this writing is: http://www.dsmc.dsm.mil/pubs/gdbks/risk_management.htm) Dr. Conrow's book, mentioned in note 2, uses this risk management process and explains some of the keys to tailor and implement it on a variety of projects.

 

Page 914

• Risk planning: This is the process of developing and documenting an organized, comprehensive, and interactive strategy and methods for identifying and tracking risk issues, developing risk handling plans, performing continuous risk assessments to determine how risks have changed, and assigning adequate resources.

• Risk assessment: This process involves identifying and analyzing program areas and critical technical process risks to increase the likelihood of meeting cost, performance, and schedule objectives. Risk identification is the process of examining the program areas and each critical technical process to identify and document the associated risk. Risk analysis is the process of examining each identified risk issue or process to refine the description of the risk, isolate the cause, and determine the effects.

• Risk handling: This is the process that identifies, evaluates, selects, and implements options in order to set risk at acceptable levels given program constraints and objectives. This includes the specifics on what should be done, when it should be accomplished, who is responsible, and associated cost and schedule. Risk handling options include assumption, avoidance, control (also known as mitigation), and transfer. The most desirable handling option is selected, and a specific approach is then developed for this option.

• Risk monitoring: This is the process that systematically tracks and evaluates the performance of risk handling actions against established metrics throughout the acquisition process and provides inputs to updating risk handling strategies, as appropriate.

17.6— Risk Planning

Risk planning is the detailed formulation of a program of action for the management of risk. It is the process to:

• Develop and document an organized, comprehensive, and interactive risk management strategy.

• Determine the methods to be used to execute a program's risk management strategy.

• Plan for adequate resources.

Risk planning is iterative and includes the entire risk management process, with activities to assess (identify and analyze), handle, monitor (and document) the risk associated with a program. The result is often the risk management plan (RMP).

Planning begins by developing and documenting a risk management strategy. Early efforts establish the purpose and objective, assign responsibilities for specific areas, identify additional technical expertise needed, describe the assessment process and areas to consider, define a risk rating approach, delineate procedures for consideration of handling options, establish monitoring metrics (where possible), and define the reporting, documentation, and communication needs.

 

Page 915

The RMP is the roadmap that tells the project team how to get from where the program is today to where the program manager wants it to be in the future. The key to writing a good RMP is to provide the necessary information so the program team knows the objectives, goals, and the risk management process. Since it is a roadmap, it may be specific in some areas, such as the assignment of responsibilities for project personnel and definitions, and general in other areas to allow users to choose the most efficient way to proceed. For example, a description of techniques that suggests several methods for evaluators to use to assess risk is appropriate, since every technique has advantages and disadvantages depending on the situation.

17.7— Risk Assessment

Risk assessment is the problem definition stage of risk management, the stage that identifies, analyzes, and quantifies program issues in terms of probability and consequences, and possibly other considerations (e.g., the time to impact). The results are a key input to many subsequent risk management actions. It is often a difficult and time-consuming part of the risk management process. There are no quick answers or shortcuts. Tools are available to assist evaluators in assessing risk, but none are totally suitable for any program and are often highly misleading if the user does not understand how to apply them or interpret the results. Despite its complexity, risk assessment is one of the most important phases of the risk management process because the caliber and quality of assessments can have a large impact on program outcomes.

The components of assessment— identification and analysis— are performed sequentially with identification being the first step.

Risk identification begins by compiling the program's risk issues. Project issues should be examined and identified by reducing them to a level of detail that permits an evaluator to understand the significance of any risk and its causes (e.g., risk issues). This is a practical way of addressing the large and diverse number of potential risks that often occur in moderate- to large-scale programs. For example, a WBS level 4 or 5 element may be made up of several risk issues associated with a specification or function.

Risk analysis is a technical and systematic process to examine identified risks, isolate causes, determine the relationship to other risks, and express the impact in terms of probability and consequence of occurrence.

17.8— Risk Identification

The second step in risk management is to identify all potential risk issues. This may include a survey of the program, customer, and users for concerns and problems.

Some degree of risk always exists in project, technical, test, logistics, production, and engineering areas. Project risks include cost, funding, schedule, con-

TEAMFLY

Team-Fly®

Page 916

tract relationships, and political risks. (Cost and schedule risks are often so fundamental to a project that they may be treated as stand-alone risk categories.) Technical risks, such as related to engineering and technology, may involve the risk of meeting a performance requirement, but may also involve risks in the feasibility of a design concept or the risks associated with using state-of-the-art equipment or software. Production risk includes concerns over packaging, manufacturing, lead times, and material availability. Support risks include maintainability, operability, and trainability concerns. The understanding of risks in these and other areas evolves over time. Consequently, risk identification must continue through all project phases.

The methods for identifying risk are numerous. Common practice is to classify project risk according to its source. Most sources are either objective or subjective.

• Objective sources: Recorded experience from past projects and the current project as it proceeds

• Lessons learned files

• Program documentation evaluations

• Current performance data

• Subjective sources: Experiences based upon knowledgeable experts

• Interviews and other data from subject matter experts

Risks can also be identified according to life-cycle phases, as shown in Figure 17–5. In the early life-cycle phases, the total project risk is high because of lack of information. In the later life-cycle phases, the financial risk is the greatest.

Any source of information that allows recognition of a potential problem can be used for risk identification. These include:

• Systems engineering documentation

• Life-cycle cost analysis

• Plan/WBS decomposition

• Schedule analysis

• Baseline cost estimates

• Requirements documents

• Lessons learned files

• Assumption analysis

• Trade studies/analyses

• Technical performance measurement (TPM) planning/analysis

• Models (influence diagrams)

• Decision drivers

 

• Brainstorming

• Expert judgment

Expert judgment techniques are applicable not only for risk identification, but also for forecasting and decision-making. Two expert judgment techniques are

 

Page 917

Figure 17–5. Life-cycle risk analysis.

the Delphi method and the nominal group technique. The Delphi method has the following general steps:

• Step 1: A panel of experts is selected from both inside and outside the organization. The experts do not interact on a face-to-face basis and may not even know who else sits on the panel.

• Step 2: Each expert is asked to make an anonymous prediction on a particular subject.

 

Page 918

• Step 3: Each expert receives a composite feedback of the entire panel's answers and is asked to make new predictions based upon the feedback. The process is then repeated as necessary.

Closely related to the Delphi method is the nominal group technique, which allows for face-to-face contact and direct communication. The steps in the nominal group technique are as follows:

• Step 1: A panel is convened and asked to generate ideas in writing.

• Step 2: The ideas are listed on a board or a flip chart. Each idea is discussed among the panelists.

• Step 3: Each panelist prioritizes the ideas, which are then ranked mathematically. Steps 2 and 3 may be repeated as necessary.

Expert judgment techniques have the potential for bias in risk identification and analysis. Factors affecting the bias include:

• Overconfidence in one's ability

• Insensitivity to the problem or risk

• Proximity to project

• Motivation

• Recent event recall

• Availability of time

• Relationship with other experts

There exist numerous ways to classify risks. In a simple business context, risk can be defined as:

• Business risk

• Insurable risk

Business risks provide us with opportunities of profit and loss. Examples of business risk would be competitor activities, bad weather, inflation, recession, customer response, and availability of resources. Insurable risks provide us with only a chance for a loss. Insurable risks include such elements as:

• Direct property damage: This includes insurance for assets such as fire insurance, collision insurance, and insurance for project materials, equipment, and properties.

• Indirect consequential loss: This includes protection for contractors for indirect losses due to third-party actions, such as equipment replacement and debris removal.

• Legal liability: This is protection for legal liability resulting from poor product design, design errors, product liability, and project performance failure. This does not include protection from loss of goodwill.

 

Page 919

• Personnel: This provides protection resulting from employee bodily injury (worker's compensation), loss of key employees, replacement cost of key employees, and several other types of business losses due to employee actions.

On construction projects, the owner/customer usually provides ''wrap-up" or "bundle" insurance, which bundles the owner, contractor, and subcontractors into one insurable package. The contractor may be given the responsibility to provide the bundled package, but it is still paid for by the owner/customer.

The Project Management Institute categorizes risks as follows:

• External–unpredictable: Government regulations, natural hazards, and acts of God

• External–predictable: Cost of money, borrowing rates, raw material availability

The external risks are outside of the project manager's control but may affect the direction of the project.

• Internal (nontechnical): Labor stoppages, cash flow problems, safety issues, health and benefit plans

The internal risks may be within the control of the project manager and present uncertainty that may affect the project.

• Technical: Changes in technology, changes in state of the art, design issues, operations/maintenance issues

Technical risks relate to the utilization of technology and the impact it has on the direction of the project.

• Legal: Licenses, patent rights, lawsuits, subcontractor performance, contractual failure

To identify risk issues, evaluators should break down program elements to a level where they can perform valid assessments. The information necessary to do this varies according to the phase of the program. During the early phases, requirement and scope documents, and acquisition plans may be the only program-specific data available. They should be evaluated to identify issues that may have adverse consequences.

Another method of decomposition is to create a Work Breakdown Structure (WBS) as early as possible in a program, and use this in a structured approach to evaluate candidate risk categories against candidate system or lower level designs. To use this approach, each element at level three of the WBS is further broken down to the fourth or fifth level and is subjected to a risk analysis. Items at

 

Page 920

system, segment or group, or subsystem levels, as well as management items, are assessed using attributes such as maturity and complexity of hardware and software items or the dependency of the item on existing systems, facilities, or contractors to evaluate their risk levels.

Another approach is to evaluate risk associated with some key processes (e.g., design and manufacturing) that will exist on a project. Information on this approach is contained in the government DoD directive 4245.7-M, which provides a standard structure for identifying technical risk areas in the transition from development to production. The structure is geared toward programs that are mid-to-late in the development phase but, with modifications, could be used for other projects. The directive identifies a template for each major technical activity. Each template identifies potential areas of risk. Overlaying each template on a project allows identification of mismatched areas, which are then identified as "at risk." Having used all applicable templates, the program manager will have created a "watch list" of production transition risk areas and can prioritize control actions— many of which will be the responsibility of systems engineering. DoD Directive 4245.7-M describes technical methods for reducing the risk in each identified area.

High-risk areas may reflect missing capabilities in the project manager's organization or in supporting organizations. They may also reflect technical difficulties in the design or development process. In either case, "management" of risk involves using project management assets to reduce the identified risks.

The value in each of these approaches to risk identification lies in the methodical nature of the approach, which forces disciplined, consistent treatment of risk. However, using any method in a "cookbook" manner may cause unique risk aspects of the project to be overlooked. Before acting on the outcome of any assessment, the project manager must review the strengths and weaknesses of the approach and identify other factors that may introduce technical, schedule, cost, program, or other risks.

17.9— Risk Analysis

Analysis begins with a detailed study of the risk issues that have been identified. The objective is to gather enough information about the risk issues to judge the probability of occurrence and cost, schedule, and technical consequences if the risk occurs.

Risk analyses are often based on detailed information that may come from:

• Comparisons with similar systems

• Relevant lessons-learned studies

• Experience

• Results from tests and prototype development

• Data from engineering or other models

Page 921

• Specialist and expert judgments

• Analysis of plans and related documents

• Modeling and simulation

• Sensitivity analysis of alternatives

Each risk category (i.e., cost, schedule, and technical) includes a core set of evaluation tasks and is related to the other two categories. This relationship requires supportive analysis among areas to ensure the integration of the evaluation process. Some characteristics of cost, schedule, and technical evaluations follow:

Cost Evaluation

• Builds on technical and schedule evaluation results

• Translates technical and schedule risks into cost

• Derives cost estimate by integrating technical risk, schedule risk, and cost estimating uncertainty impacts to resources

• Documents cost basis and risk issues for the risk evaluation

Schedule Evaluation

• Evaluates baseline schedule inputs

• Reflects technical foundation, activity definition, and inputs from technical and cost areas

• Incorporates cost and technical evaluation and schedule uncertainty inputs to program schedule model

• Performs schedule analysis on program schedule

• Documents schedule basis and risk issues for the risk evaluation

Technical Evaluation

• Provides technical foundation

• Identifies and describes program risks (e.g., technology)

• Analyzes risks and relates them to other internal and external risks

• Prioritizes risks for program impact

• Quantifies associated program activities with both time duration and resources

• Quantifies inputs for cost evaluation and schedule evaluation

• Documents technical basis and risk issues for the risk evaluation

Describing and quantifying a specific risk and the magnitude of that risk usually requires some analysis or modeling. Typical tools for use in risk analysis are:

• Life-cycle cost analysis

 

• Network analysis

• Monte Carlo simulation

• Estimating relationships

• Risk scales (typically ordinal probability and consequence scales)

• Quick reaction rate/quantity impact analysis

 

Page 922

• Probability analysis

• Graphical analysis

• Decision analysis

• Delphi techniques

• Work breakdown structure simulation

• Logic analysis

• Technology state-of-the-art trending

• Total risk-assessing cost analysis (TRACE)

• Defense science board templates (DoD Directive 4245.7-M)

Without any hard data, it may be necessary to use qualitative rather than quantitative data to assess potential damage. A common form of qualitative risk rating is as follows:

• High risk: Substantial impact on cost, schedule, or technical. Substantial action required to alleviate issue. High priority management attention is required.

• Moderate risk: Some impact on cost, schedule, or technical. Special action may be required to alleviate issue. Additional management attention may be needed.

• Low risk: Minimal impact on cost, schedule, or technical. Normal management oversight is sufficient.

Risk ratings are an indication of the potential impact of risks on a program. They are typically a measure of the likelihood of an issue occurring and the consequences of the issue, and often expressed as low, medium, and high. (Other factors that may significantly contribute to the importance of risk issues, such as frequency of occurrence, time sensitivity, and interdependence with other risk issues can also be noted and used either directly or indirectly in the rating methodology used.) The prioritization should be done based on a structured risk rating approach using relevant expert opinion and experience.

A major area of concern is how to arrive at a method for assigning risk levels. It is important to use agreed upon definitions (such as the "strawman" definitions above) and procedures for estimating risk levels, rather than subjectively assigning them, since each person could easily have a different understanding of words typically used to describe both probability distributions and risks. Figure 17–6 shows what some probability statements mean to different people. An important point to grasp from this figure is that a nontrivial variation in probability (e.g., 0.3) exists for more than half of the statements evaluated.

A risk viewed as easily manageable by some managers may be considered hard to manage by less experienced or less knowledgeable managers. Consequently, the terms "high," "medium," or "low" risk are relative terms. Some managers may be risk averse and choose to avoid recognized risk at all reasonable cost. Other managers may be risk seekers and actually prefer to take an approach with more risk. The terms "high,'' "medium," and "low" risk may change

 

Page 923

Figure 17–6. What uncertainty statements mean to different people.

with the turnover of managers and their superiors as much as with the project events.

Program managers can use risk ratings to identify issues requiring priority management (medium or higher risk). Risk ratings also help to identify the areas that should be reported within and outside the program. Thus, it is important that the ratings be portrayed as accurately as possible.

Previously, we showed that risk quantification could be found by use of an expected value calculation. However, there are more sophisticated approaches that involve templates combined with the expected value model. Here, ordinal scales (scales whose values are rank ordered) are commonly used to represent different aspects of the probability of occurrence (e.g., due to technology) and consequence of occurrence (e.g., cost, schedule, and technical). While such scales, tailored to your project, can be a useful methodology for estimating risk, great care must be taken in using them. A common abuse of such probability and consequence scales is performing mathematical operations on the results, which can

TEAMFLY

Team-Fly®

 

Page 924

TABLE 17–5.  EXAMPLE OF ORDINAL TECHNOLOGY "PROBABILITY" MATURITY SCALE

Definition Scale Level

Basic principles observed E

Concept design analyzed for performance D

Breadboard or brassboard validation in relevant environment

C

Prototype passes performance tests B

Item deployed and operational A

easily lead to erroneous results because the true scale interval values are unknown (e.g., a five level scale labeled 0.2, 0.4, 0.6, 0.8, and 1.0 almost certainly does not have values of equal 0.2 increments between adjacent scale levels).

The following simple example illustrates the proper use of ordinal scales in project risk analysis, and provides some recommendations for properly representing the results.4 Please note, these scales should not be used on your project— they are only provided as an illustration.

Example 17–2. A single "probability" of occurrence scale, related to technology maturity, is used, as shown in Table 17–5. In reality, technical risk will typically encompass a number of additional risk categories in addition to technology maturity, such as engineering, and so on. However, the use of a single risk category simplifies subsequent computations and is sufficient for illustration purposes. For the technology maturity "probability" scale, assume that low = scale levels A and B, medium = scale level C, and high = scale levels D and E. (Note: this information does not correspond to low, medium, and high risk, and is only an indicator of where breakpoints will occur when used in developing the risk mapping matrix later in this section. Letters are provided for scale levels instead of numbers to discourage you from attempting to perform invalid mathematical operations on the results.)

Three consequence of occurrence scales, for cost, schedule, and technical, are used and given in Table 17–6. For each of the three consequence of occurrence scales, assume that low = scale levels A and B, medium = scale levels C and D, and high = scale level E. (Note: this information does not correspond to low, medium, and high risk, and is only an indicator of where breakpoints will occur when used in developing the risk mapping matrix later in this section.)

Given the mapping information associated with the "probability" of occurrence and consequence of occurrence scales, a mapping matrix was developed and is given in Table 17–7. [Note: the interpretation of some of the levels is subjective given that three divisions were used for both the "probability" and consequence of

4 This example is from: Edmund H. Conrow, Effective Risk Management: Some Keys To Success. Reston, VA: American Institute of Aeronautics and Astronautics, 2000. Copyright © 1999, Edmund H. Conrow. Used with permission of the author.

 

Page 925

TABLE 17–6.  EXAMPLE OF ORDINAL COST, SCHEDULE, AND TECHNICAL CONSEQUENCE OF OCCURRENCE SCALE

CC

CS

CT

Scale Level

>10% Can't achieve key team or major program milestone

Unacceptable E

7%–<10% Major slip in key milestone or critical path impacted

Acceptable; no remaining margin D

5%–<7% Minor slip in key milestones, not able to meet need date

Acceptable with significant reduction in margin

C

<5% Additional resources required able to meet need date

Acceptable with some reduction in margin

B

Minimal or no impact

Minimal or no impact Minimal or no impact A

occurrence scales versus the five possible levels (one per scale level), along with three resulting risk levels (low, medium, and high). A mapping matrix with different "probability" of occurrence and/or consequence of occurrence relationships (e.g., low = scale levels A and B, medium = scale levels C and D, and high = scale level E for both "probability" and consequence of occurrence scores), or five resulting risk levels (low, low medium, medium, medium high, and high), or a different risk mapping could also have been used for this example.]

We'll now evaluate two different items associated with a commercial high-grade digital camera, using the above risk analysis methodology. Remember, these risk issues are hypothetical and only used to illustrate how to apply the risk analysis methodology.

In the first case, a high performance commercial charge coupled device (CCD) exists that is in preprototype development. The CCD will be included in a high-grade digital camera. The risk issue is whether or not the desired signal to noise ratio can be achieved to meet low light operating requirements and avoid an increased level of image "grain" during operation. The potential cost conse-

 

Page 926

quence of this occurring is a 6 percent cost impact for a third design, fabrication, and test iteration (two iterations are baselined). The potential schedule consequence of this occurring is additional resources required, but able to meet the need date. The potential technical consequence of this occurring is acceptable performance, but no remaining margin. In this example, the resulting probability of occurrence score from Table 17–5 is Level C (preprototype maturity), and from Table 17–6, CC = Level C, CS = Level B, and CT = Level D. Given this information and the risk mapping matrix in Table 17–7, the risk levels relative to cost, schedule, and technical are medium, low, and medium, respectively, as illustrated in Table 17–8.

In the second case, a high density digital storage card is in the concept formulation stage. This storage card will be included in the same high grade digital camera as the CCD previously discussed. The risk issue is the ability to achieve the desired bit density for the card to store the desired number of very high resolution images. Here, the bit density is presumed to be a factor of five times greater than the existing state of the art. The potential cost consequence of not achieving the desired bit density is a 20 percent cost impact for additional technology advancement of the storage medium, plus one or more additional redesign, fabrication, and test iterations. The potential schedule consequence of this occurring is a major slip in introducing the digital camera with the desired high density storage card. The potential technical consequence of this occurring is unacceptable performance because the desired number of high resolution, high dynamic range images cannot be stored with existing density storage cards. (It is presumed here that multiple lower density storage cards cannot be substituted for a single high density card.) In this example, the resulting probability of occurrence score from Table 17–5 is Level D (concept design analyzed for performance), and from Table 17–6, CC = Level E, CS = Level D, and CT = Level E. Given this information and the risk mapping matrix in Figure 17–7, the risk levels relative to cost, schedule, and performance are high, high, and high, respectively, as illustrated in Table 17–8.

Of the results for the two candidate risk issues given in Table 17–8, the higher risk item is the digital storage card. Note also that if the risk level is collapsed to a single value by taking the maximum of the three risk levels relative to cost, schedule, and technical consequence, then the CCD low light performance risk is medium, while the digital storage card bit density risk is high.

Had there been n technology risk categories instead of the one used here (technology maturity), then there would have been n × 3 total scores to report for

TABLE 17–8.  EXAMPLE OF RISK SCORING SUMMARY SHEET

    Risk Level

WBS Number WBS Item/Issue Cost Schedule Technical

1.1.1 CCD low light performance M L M

1.2.3 Digital storage card bit density H H H

 

Page 927

each risk issue. If desired, this could be reduced to three risk scores per risk issue by using a conservative ranking approach and taking the maximum score for cost consequence, schedule consequence, and technical consequence. Similarly, if desired this could be reduced to one risk score per risk issue by using a conservative ranking approach and taking the maximum of all risk scores across cost, schedule, and technical consequence.

Finally, given that a medium or higher risk level exists for both the camera CCD low light performance and the digital storage card bit density, risk handling plans (discussed in Section 17.11) should be developed for both risk issues. (Note: All risk issues should be analyzed before selecting risk handling strategies.)

Another common product of risk analysis is a "watch list." Items placed on a "watch list" often include indicators of the start of the problem and consequences that are likely to occur. An example of this is the cost risk of production due to an immature technical data package. When production starts before the technical data package has been adequately engineered for producibility, the first unit cost may be higher than planned. A typical "watch list" is structured to show the trigger event or item (for example, long-lead items delayed), the related area of impact (production schedule), and later, as they are developed, the risk handling actions taken to reduce the potential for or impact from that event (such as ensuring early identification of long-lead items, placing contractor emphasis on early delivery, etc.).

The "watch list" is periodically reevaluated and items are added, modified, or deleted as appropriate. Should the trigger events occur for items on the "watch list" during a project, there would be immediate cause for risk assessments to be updated and risk handling methods to be selected.

17.10— The Monte Carlo Process

The Monte Carlo process, as applied to risk management, is an attempt to create a series of probability distributions for potential risk items, randomly sample these distributions, and to then transform these numbers into useful information that reflects quantification of the potential risks of a real world situation. Monte Carlo simulation has been used to determine risks in design of service centers, time to complete an activity in a project, inventory management, and thousands of other applications.

A summary of the steps used in performing a Monte Carlo simulation for cost and schedule follows. Although the details of implementing the Monte Carlo simulation will vary between applications, many cases use a procedure similar to this.

1. Identify the lowest WBS or activity level for which probability distribution functions will be constructed. The level selected will depend on the program phase— lower levels will be selected as the project matures.

 

Page 928

2. Develop the reference point estimate (e.g., cost or schedule duration) for each WBS element or activity contained within the model.

3. Identify which WBS elements or activities contain estimating uncertainty and/or risk. (For example, technical risk can be present in some cost estimate WBS elements and schedule activities.)

4. Develop suitable probability distributions for each WBS element or activity with estimating uncertainty and/or risk.

5. Aggregate the WBS element or activity probability distributions functions using a Monte Carlo simulation program. When performed for cost, the results of this step will typically be a WBS Level 1 cost estimate at completion and a cumulative distribution function (CDF) of cost versus probability. These outputs are then analyzed to determine the level of cost risk and to identify the specific cost drivers. When performed for schedule, the results of this step will be a schedule at the desired (WBS) level and CDFs of schedule versus probability. The CDFs will typically represent duration or finish date at the desired activity level, but can include other variables as well. These outputs are then analyzed to determine the level of schedule risk and to identify the specific schedule drivers.

Note: it should be recognized that the quality of Monte Carlo simulation results are only as good as the reference point estimates and associated probability distributions used in the simulation. If this data is not carefully obtained and accurate, the results can be misleading, if not erroneous.

Example 17-3. The manager of a service center is contemplating the addition of a second service counter. He has observed that people are usually waiting in line. If the service center operates 12 hours per day and the cost of a checkout clerk is $60.00 (burdened) per hour, simulate the manager's problem using the Monte Carlo method, assuming that the loss of good will is approximately $50.00 per hour.

The first step in the process is to develop procedures for defining arrival rates and service rates. The use of simulation implies that the distribution expressions are either nonexistent for this type of problem or do not apply to this case. In either event, we must construct either expressions or charts for arrival and service rates.

The arrival and service rates are obtained from sample observations over a given period of time and transformed into histograms. Let us assume that we spend some time observing and recording data at the one service counter. The data recorded is the time between customer arrivals and the number of occurrences of these arrivals. The same procedure is repeated for servicing. We record the amount of time each person spends at the checkout facility and the number of times this occurs. This data is shown in Table 17–9 and transformed to histograms in Figures 17–7 and 17–8. From Table 17–9 and Figures 17–7 and 17–8, five people entered the store within one minute of previous customers. The five customers may have come at the same time or different times. Likewise 18 people entered

Page 929

TABLE 17–9.  ARRIVAL AND SERVICE RATE DATA

Arrivals

Arrival Time between Customers (Min.)

Number of Occurrences

  0     5

  5     7

  8     1

10     9

12   12

15   20

16   18

18   10

20     9

25     5

30     4

  100

 

Services

Service Time at Checkout Counter (Min.)

Number of Occurrences

10     5

12   10

14   15

16   20

18   20

20   15

22   15

  100

within 16 minutes of other customers. The service rates are handled in the same manner. Fifteen people required 14 minutes of service and 20 people required 18 minutes of service.

The second step transforms the arrival and service histograms into a step-function type chart in which for every number there corresponds one and only one arrival and service rate. To develop these charts, it is best to have 100 observances for both arrivals and services discussed in the first step and shown in Table 17–9.

The step-function charts are based upon 100 numbers. Consider the service data in Table 17–9. We let the numbers 1 through 5 represent 10 minutes of service since there were 5 observations. Ten observations were tabulated for 12 minutes of service. This is represented by the numbers 6 through

 

15. Likewise, the numbers 16 through 30 represent the 15 observations of 14 minutes of service. The remaining data can be tabulated in the same manner to complete the service chart. The service step-function chart is shown in Figure 17–9 and the arrival step-function chart is shown in Figure 17–10. Some points on these charts are plateau points, as the number 15 on the service chart. The number 15 refers to the

 

Page 930

Figure 17–7. Arrival rate histogram.

left-hand most point. Therefore, 15 implies 12 minutes of service, not 14 minutes of service.

The third step requires the generation of random numbers and the analysis. (See Table 17–10.) The random numbers can be obtained either from random number tables or from computer programs that contain random number generators. These random numbers are used to simulate the arrival and service rates of customers from the step-function charts in Figures 17–9 and 17–10. Random numbers are generated between 0 and 1. However, it is common practice to multiply these numbers by 100 so as to have integers between 0 and 99 or 1 and 100. As an example, consider the following 10 random numbers: 1, 8, 32, 1, 4, 15, 53, 80, 68, and 82. The numbers are read in groups of two, with the first number representing arrivals and the second representing service. From Figure 17–10, the number 1 corresponds to a 0 arrival rate. From Figure 17–9, the number 8 corresponds to 12 minutes of service. Therefore, assuming that the store opens at 8:00 a.m., the first customer arrives at the checkout facility at approximately 8:00 a.m. and leaves at 8:12, after requiring 12 minutes of service at the checkout counter. The second pair of points are 32 and 1. The first number, 32, indicates that the second customer arrives 12 minutes after the first customer, at 8:12. But since the first customer is through the service facility at 8:12, the second customer will not have to wait. His 10 minutes of service at the checkout counter will begin at 8:12 and he will finish at 8:22. The third customer arrives at the same time as the sec-

 

Page 931

Figure 17–8. Service rate data.

ond customer and requires 12 minutes service. But since the second customer is in the service facility, the third customer must wait in the queue until 8:22 before entering the service facility. Therefore, his waiting time is 10 minutes and he leaves the service facility at 8:34 (8:22 + 12 minutes service). The fourth customer arrives 15 minutes after the third customer (at 8:27) and requires 20 minutes service. Since the service facility is occupied until the third customer leaves at 8:34, the fourth customer must wait seven minutes in the queue. This process is repeated for 16 customers and the results are shown in Table 17–10.

The fourth step in the process is the final analysis of the data. The data shown in Table 17–10 consisted of 16 customers processed in the first four hours. The summation of the waiting time for the four hours is 230 minutes. Since the store

 

Page 932

Figure 17–9. Step-function chart for random number service rates.

is opened for 12 hours, the total waiting time is 3 × 230, or 690 minutes. At $50.00 per hour loss of good will, the manager loses approximately $575 per 12-hour day because of waiting-line costs. The manager can put in a second service counter. If he pays the worker $60.00 per hour burdened for a 12-hour day, the cost will be $720.00. Therefore, it is more economical for the manager to allow people to wait than to put in a second checkout facility.

17.11— Risk Handling

Risk handling includes specific methods and techniques to deal with known risks, identifies who is responsible for the risk issue, and provides an estimate of the cost and schedule associated with reducing the risk, if any. It involves planning and execution with the objective of reducing risks to an acceptable level. The evaluators who assess risk should begin the process by identifying risks and developing handling options and approaches to propose to the program manager, who selects the appropriate one(s) for implementation. There are several factors that can influence our response to a risk, including but not limited to:

TEAMFLY

Team-Fly®

Page 933

Figure 17–10. Step-function chart for random number arrival rates.

TABLE 17–10.  SINGLE QUEUE MONTE CARLO SIMULATION MODEL

Random Number (Arrival)

Arrival Time Increment: Min.

Arrival Time

Random Number (Service)

Service Time Increment: Min.

Service Begins

Service Ends

Waiting Time (Min.)

  1   0.0   8:00   8 12.00   8:00   8:12   0.0

32 12.00   8:12   1 10.00   8:12   8:22   0.0

4   0.0   8:12 15 12.00   8:22   8:34 10.00

53 15.00   8:27 80 20.00   8:34   8:54   7.00

68 16.00   8:43 82 20.00   8:54   9:14 11.00

87 20.00   9:03 83 20.00   9:14   9:34 11.00

17 10.00   9:13 47 16.00   9:34   9:50 21.00

32 12.00   9:25 64 18.00   9:50 10:08 25.00

99 30.00   9:55 10 12.00 10:08 10:20 13.00

72 16.00 10:11 39 16.00 10:20 10:36   9.00

82 18.00 10:29 41 16.00 10:36 10:52   7.00

7   5.00 10:34 65 18.00 10:52 11:10 18.00

30 12.00 10:46 92 22.00 11:10 11:32 24.00

77 18.00 11:04 32 16.00 11:32 11:48 28.00

96 25.00 11:29 82 20.00 11:48 12:08 19.00

30 12.00 11:41 41 16.00 12:08 12:24 27.00

Total waiting time = 230.00 minutes

Page 934

• Amount and quality of information on the actual hazards that caused the risk (descriptive uncertainty)

• Amount and quality of information on the magnitude of the damage (measurement uncertainty)

• Amount and quality of information on probability of occurrence

• Personal benefit to project manager for accepting the risk (voluntary risk)

• Risk forced upon project manager (involuntary risk)

• Confusion and avoidability of the risk

• The existence of cost-effective alternatives (equitable risks)

• The existence of high-cost alternatives or possibly lack of options (inequitable risks)

• Length of exposure to the risk

Risk handling must be compatible with the RMP and any additional guidance the program manager provides. A critical part of risk handling involves refining and selecting the most appropriate handling option(s) and specific approach(es) for selected risk issues (often those with medium or higher risk levels).

Personnel who evaluate candidate risk handling options may use the following criteria as starting points for evaluation:

• Can the option be feasibly implemented and still meet the user's needs?

• What is the expected effectiveness of the handling option in reducing program risk to an acceptable level?

• Is the option affordable in terms of dollars and other resources (e.g., use of critical materials, and test facilities)?

• Is time available to develop and implement the option, and what effect does that have on the overall program schedule?

• What effect does the option have on the system's technical performance?

Risk handling options include: risk assumption, risk avoidance, risk control, and risk transfer. Although the control option (often called mitigation) is commonly used in many high technology programs, it should not automatically be chosen. All four options should be evaluated, and the best one chosen for each risk issue.

The options for handling risk fall into the following categories:

• Risk assumption (i.e., retention): The project manager says, ''I know the risk exists and am aware of the possible consequences. I am willing to wait and see what happens. I accept the risk and its impact should it occur."

• Risk avoidance: The project manager says, "I will not accept this option because of the potentially unfavorable results."

• Risk control (i.e., prevention or mitigation): The project manager says, "I will take the necessary

 

measures required to control this risk by continuously reevaluating it and developing contingency plans or fall-back positions. I will do what is expected."

 

Page 935

• Risk transfer: The project manager says, "I will share this risk with others through insurance or a warranty, or transfer the entire risk to them. Perhaps I can convert the risk into an opportunity."

We now explore each of these risk handling options in somewhat greater detail.

Risk assumption is an acknowledgment of the existence of a particular risk situation and a conscious decision to accept the associated level of risk, without engaging in any special efforts to control it. However, a general cost and schedule reserve may be set aside to deal with any problems that may occur as a result of various risk assumption decisions. This risk handling option recognizes that not all identified program risks warrant special handling; as such, it is most suited for those situations that have been classified as low risk.

The key to successful risk assumption is twofold:

• Identify the resources (e.g., money, people, and time) that will be needed to overcome a risk if it materializes. This includes identifying the specific management actions (such as retesting, and additional time for further design activities) that may occur.

• Ensure that necessary administrative actions are taken to identify a management reserve to accomplish those management actions.

Risk avoidance involves a change in the concept, requirements, specifications, and/or practices to reduce risk to an acceptable level. Simply stated, it eliminates the sources of high or possibly medium risk and replaces them with a lower risk solution. This method may be used in parallel with the up-front requirements analysis, supported by cost/requirement trade-off studies. It may also be used later in the development phase when test results indicate that some requirements cannot be met, and the potential cost and/or schedule impact would be severe.

Risk control does not attempt to eliminate the source of the risk but seeks to reduce or mitigate the risk. It manages the risk in a manner that reduces the likelihood and/or consequence of its occurrence on the program. This option may add to the cost of a program, and the selected approach should provide an optimal mix among the candidate approaches of risk reduction, cost effectiveness, and schedule impact. A summary of some common risk control actions includes:

• Alternative design: Create a backup design option that uses a lower risk approach.

• Demonstration events: Demonstration events are points in the program (normally tests) that determine if risks are being successfully reduced.

• Design of experiments: This engineering tool identifies critical design factors that are sensitive, therefore potentially medium or higher risk, to achieve a particular user requirement.

• Early prototyping: Build and test prototypes early in the system development.

 

Page 936

• Incremental development: This is design with the intent of upgrading system parts in the future.

• Key parameter control boards: The practice of establishing a control board for a parameter may be appropriate when a particular feature (such as system weight) is crucial to achieving the overall program requirements.

• Manufacturing screening: For programs in the mid- to late-development phases, various manufacturing screens (including environmental stress screening) can be incorporated into test article production and low rate initial production to identify deficient manufacturing processes.

• Modeling/simulation: Modeling and simulation can be used to investigate various design options and system requirement levels.

• Multiple development efforts: Create systems that meet the same performance requirements. (This approach is also known as parallel development.)

• Open systems: Use of carefully selected commercial specifications and standards can result in lower risk levels.

• Process proofing: Particular processes, especially manufacturing and support processes, are critical to achieving system requirements.

• Reviews, walk-throughs, and inspections: These three actions can be used to reduce the likelihood and potential consequences of risks through timely assessment of actual or planned events.

• Robust design: This approach uses advanced design and manufacturing techniques that promote quality and capability through design.

• Technology maturation efforts: Normally, technology maturation is used when the desired technology will replace an existing technology that is available for use in the system.

• Test-analyze-and-fix (TAAF): TAAF is the use of a period of dedicated testing to identify and correct deficiencies in a design.

• Trade-off studies: Arrive at a balance of engineering requirements in the design of a system. Ideally, this also includes cost, schedule, and risk considerations.

• Use of mock-ups: The use of mock-ups, especially man–machine interface mock-ups, can be utilized to conduct early exploration of design options.

• Use of standard items/software reuse: Use of existing and proven hardware and software, where applicable, can potentially reduce risks.

Risk transfer may reallocate risk from one part of the system to another, thereby reducing the overall system and/or lower-level risk. It may also redistribute risks between the buyer (e.g., government) and the seller (e.g., prime contractor), or within the buyer or seller teams. It should be considered as part of the requirements analysis process. Risk transfer is a form of risk sharing and not risk abrogation on the part of the buyer or seller, and it may influence cost objectives. An example is the transfer of a function from hardware implementation to software implementation or vice versa. (Risk transfer is also not deflecting a risk issue because insufficient information exists about it.) The effectiveness of risk transfer depends on the

 

Page 937

use of successful system design techniques. Modularity and functional partitioning are two design techniques that support risk transfer. In some cases, risk transfer may concentrate risk issues in one area of the design. This allows management to focus attention and resources on that area. Other examples of risk transfer include the use of insurance, warranties, bonding (e.g., bid, performance, or payment bonds), and similar agreements. These agreements are typically between the buyer and seller such that the consequent "costs" of failure will be assumed by the seller for some agreed to price. That price may be in terms of profit dollars, schedule changes, product performance modifications, or other considerations.

Risk handling options and the implemented approaches have broad cost implications. The magnitude of these costs are circumstance-dependent. The approval and funding of handling options and specific approaches should be done by the project manager or Risk Management Board (or equivalent) and be part of the process that establishes the program cost, and performance and schedule goals. The selected handling option and approach for each selected risk issue should be included in the program's acquisition strategy.

Once the acquisition strategy includes the risk handling strategy for each selected risk issue, the cost and schedule impacts can be identified and included in the program plan and schedule, respectively.

17.12— Risk Monitoring

The monitoring process systematically tracks and evaluates the effectiveness of risk handling actions against established metrics. Monitoring results may also provide a basis for developing additional risk handling options and approaches, or updating existing risk handling approaches, and reanalyzing known risks. In some cases monitoring results may also be used to identify new risks and revise some aspects of risk planning. The key to the risk monitoring process is to establish a cost, performance, and schedule management indicator system over the program that the program manager and other key personnel use to evaluate the status of the program. The indicator system should be designed to provide early warning of potential problems to allow management actions. Risk monitoring is not a problem-solving technique, but rather, a proactive technique to obtain objective information on the progress to date in reducing risks to acceptable levels. Some techniques suitable for risk monitoring that can be used in a program-wide indicator system include:

• Earned value (EV): This uses standard cost/schedule data to evaluate a program's cost performance (and provide an indicator of schedule performance) in an integrated fashion. As such, it provides a basis to determine if risk handling actions are achieving their forecasted results.

• Program metrics: These are formal, periodic performance assessments of the selected development processes, evaluating how well the develop-

 

Page 938

ment process is achieving its objective. This technique can be used to monitor corrective actions that emerged from an assessment of critical program processes.

• Schedule performance monitoring: This is the use of program schedule data to evaluate how well the program is progressing to completion.

• Technical performance measurement (TPM): TPM is a product design assessment that estimates, through engineering analysis and tests, the values of essential performance parameters of the current design as effected by risk handling actions.

The indicator system and periodic reassessments of program risk should provide the program with the means to incorporate risk management into the overall program management structure. Finally, a well-defined test and evaluation program is often a key element in monitoring the performance of selected risk handling approaches and developing new risk assessments.

17.13— The Use of Lessons Learned

Risk issues that are analyzed to be medium or higher must be handled to the extent assets allow, to reduce their potential to adversely affect the program. All levels of management must be sensitive to hidden "traps" that may induce a false sense of security. If properly interpreted, these signals really indicate a developing problem in a known area of risk. Each trap is usually accompanied by several "warning signs" that show an approaching problem and the likelihood of failing to treat the problem at its inception.

The ability to turn traps into advantages suggests that much of the technical risk in a program can be actively handled via the control or transfer option, not merely watched and resolved after a problem occurs. In some instances it may pay to watch and wait. If the probability that a certain problem will arise is low or if the cost exceeds the benefits of "fixing" the problem before it happens, a do-nothing alternative (assumption risk handling option) may be advisable. Effective risk management makes selection of the do-nothing alternative a conscious decision rather than an oversight and may trigger an appropriate addition to the risk "watch list".

"Best practices" acknowledges that all of the traps have not been identified for each risk issue. The traps are intended to be suggestive, and other potential issues should be examined as they arise. It is also important to recognize that sources and types of risk evolve over time. Risks may take a long time to mature into problems. Attention must be properly focused to examine risks and lessons learned.

Lessons learned should be documented so that future project managers can learn from past mistakes.

Experience is an excellent teacher in risk management. Yet, no matter how hard we try, risks will occur and projects may suffer. As an example, we have over

 

Page 939

forty years of knowledge in going from new product development to production.5 We plan for risk management, identify and analyze risk issues, and develop ways of handling and monitoring risks, but some types of risk issues commonly occur on projects that are mid to late in the development phase. Some examples of these risk issues are now given.

Risk Issue: Design process. The design process must reflect a sound design policy and proper engineering disciplines and practices— an integration of factors that influence the production, operation, and support of a system throughout its life cycle. Nevertheless, concepts are often selected, demonstrated, and validated with little thought given to the feasibility of producing a system employing those concepts. This omission is then carried forward into design, with voids appearing in manufacturing technology and absence of proven manufacturing methods and processes to produce the system within affordable cost. One of the most common sources of risk in the transition from development to production is failure to design for production. Some design engineers do not consider in their design the limitations in manufacturing personnel and processes. The predictable result is that an apparently successful design, assembled by engineers and highly skilled model shop technicians, goes to pieces in the factory environment when subjected to rate production. A design should not be produced if it cannot survive rate production without degradation.

Prevention. The potential to produce a system must be investigated carefully during the planning phase by means of appropriate producibility analyses. Voids in manufacturing technology projects and manufacturing methods and processes peculiar to the design of the specific system, subsystem, and components must be addressed during engineering development.

Risk Issue: Design Reviews. While most engineering development projects usually require formal design reviews, they often lack specific direction and discipline in the design review requirement, resulting in an unstructured review process that fails to fulfill either of the two main purposes of design review, which are (1) to bring additional knowledge to the design process to augment the basic program design and analytical activity and (2) to challenge the satisfactory accomplishment of specified design and analytical tasks needed for approval to proceed with the next step in the process.

Prevention:

• The customer and their contractors recognize that design reviews represent the "front line" where readiness for transition from development to production is decided ultimately. Design review policy, schedule, budget, agenda, participants, actions, and follow-up are decided in view of this foremost need.

5 Adapted from Transition from Development to Production. DoD 4245.7, Department of Defense, September 1985. These risk areas may occur on a variety of projects, but it may not be possible to take decisive action to deal with them until midway in the development phase.

 

Page 940

• Design reviews should be included in all projects in accordance with existing customer requirements. A design review plan must be developed by the contractor and approved by the customer.

Risk Issue: Life. Life tests are intended to assess the adequacy of a particular equipment design when subjected to long-term exposure to certain operational environments. Due to the time-consuming nature of these tests, various methods have been used to accelerate test times by exposure to more stringent environments than those expected in actual operational use. These methods may give misleading results due to a lack of understanding of the acceleration factors involved.

Many projects are forced into conducting life tests after the systems are placed in use and before reliability requirements are achieved. As a result, life tests are performed after the start of production, and costly engineering change proposals (ECPs) and retrofit programs must be initiated in an attempt to "get well" with less than optimum design solutions.

Prevention:

• Include life testing in the overall system integrated test plan to ensure that testing is conducted in a cost-effective manner and to meet program schedules.

• Use test data from other phases of the test program to augment the system and subsystem life testing by reducing the time required to prove that reliability requirements are met.

• Use life test data from similar equipment, operating in the same environment, to augment the equipment life testing in order to gain confidence in the design.

Risk Issue: Manufacturing plan. Involvement of production and manufacturing engineering only after the design process has been completed is a fundamental error and a major transition risk. Consequences of late involvement are: (1) an extended development effort required for redesign and retest of the end-item for compatibility with the processes and procedures necessary to produce the item and (2) lower and inefficient rates of production due to excessive changes in the product configuration introduced on the factory floor. Increased costs and schedule delays are the result of this approach.

Prevention. The following represent the key elements of a manufacturing plan:

• Master delivery schedule that identifies by each major subassembly the time spans, need dates, and who is responsible.

• Durable tooling requirements to meet increased production rates as the program progresses

• Special tools

• Special test equipment

• Assembly flowcharts

 

Page 941

Risk Issue: Quality manufacturing process. The introduction of a recently developed item to the production line brings new processes and procedures to the factory floor. Changes in hardware or work flow through the manufacturing facility increase the possibility of work stoppage during rate production. Failure to qualify the manufacturing process before rate production with the same emphasis as design qualification— to confirm the adequacy of the production planning, tool design, manufacturing process and procedures— can result in increased unit costs, schedule slippage, and degraded production performance.

Prevention:

• The work breakdown structure, production statement of work, and transition and production plans do not contain any conflicting approaches. Any discrepancies among these documents are identified and resolved before production is started.

• A single-shift, eight-hour day, five-day workweek operation is planned for all production schedules during initial start-up. Subsequent manpower scheduling is adjusted to manufacturing capability and capacity consistent with rate production agreements.

• The drawing release system must be controlled and disciplined.

• The manufacturing flow must minimize tooling changes and machine adjustments and ensure that alternate flow plans have been developed.

• A mechanism must be established that ensures the delivery of critical items with long-lead time four to six weeks before required.

• All new equipment or processes that will be used to produce the item must be identified.

Risk Issue: Manpower and personnel. Product development and support systems must be designed with as complete an understanding as possible of user manpower and personnel skill profiles. A mismatch yields reduced field reliability, increased equipment training, technical manual costs, and redesign as problems in these areas are discovered during demonstration tests and early fielding. Discovery of increased skill and training requirements late in the acquisition process creates a difficult catch-up problem and often leads to poor system performance.

Prevention:

• Manpower and skill requirements must be based on formal analysis of previous experience on comparable systems and maintenance concepts.

• Manpower cost factors used in design and support trade-off analyses must take into account costs to train or replace experienced personnel, as well as the true overhead costs.

Risk Issue: Training, materials, and equipment. On some programs, training requirements are not addressed adequately, resulting in great difficulty in operation and support of the hardware. Training programs, materials, and equipment such as

TEAMFLY

Team-Fly®

 

Page 942

simulators may be more complex and costly than the hardware they support. Delivery of effective training materials and equipment depends on the understanding of final production design configuration, maintenance concepts, and skill levels of personnel to be trained. On many programs, training materials and equipment delivery schedules are overly ambitious. The results include poor training, inaccuracies in technical content of materials, and costly redesign and modification of training equipment:

Prevention:

• Contractors must be provided with clear descriptions of user personnel qualifications and current training programs of comparable systems, to be used in prime hardware and training systems design and development.

• On-the-job training capability must be incorporated in the prime equipment design as a method to reduce the need for additional training equipment.

Problems

17–1 You have $1,000,000 worth of equipment at the job site and wish to minimize your risk of direct property damage by taking out an insurance policy. The insurance company provides you with their statistical data as shown below:

Type of Damage Probability (%)Amount of Damage (Loss) (%)

Total 0.02 100

Medium 0.08   40

Low 0.10   20

No Damage 99.8     0

If the insurance company uses expected value to calculate premiums, then how much would you expect the premium to be, assuming the insurance company adds on $300 for handling and profit?

17–2 You have been asked to use the expected-value model to assess the risk in developing a new product. Each strategy requires a different sum of money to be invested and produces a different profit payoff as shown below:

  States of Nature

Strategy Complete Failure Partial Success Total Success

S1

<$50K> <30K> 70K

S2

  <80K>   20K 40K

S3  <70K>     0 50K

S4<200K> <50K> 150K

S5      0     0     0

Page 943

Assume that the probabilities for each state are 30 percent, 50 percent, and 20 percent, respectively.

a. Using the concept of expected value, what risk (i.e., strategy) should be taken?

b. If the project manager adopts a go-for-broke attitude, what strategy should be selected?

c. If the project manager is a pessimist and does not have the option of strategy S5, what risk would be taken?

d. Would your answer to part C change if strategy S5 were an option?

17–3 Your company has asked you to determine the financial risks of manufacturing 6,000 units of a product rather than purchasing them from a vendor at $66.50 per unit. The production line will handle exactly 6,000 units and requires a one-time setup cost of $50,000. The production cost is $60/unit.

Your manufacturing personnel inform you that some of the units may be defective, as shown below:

% defective 0 1 2 3 4

probability of occurrence (%)

40 30 20 6 4

Defective items must be removed and replaced at a cost of $145/defective unit. However, 100 percent of units purchased from vendors are defect-free.

Construct a payoff table, and using the expected-value model, determine the financial risk and whether the make or buy option is best.

17–4 Below are four categories of risk and ways that a company is currently handling the risks. According to Section 17.11, which risk handling options are being used? More than one answer may apply.

a. A company is handling its high R&D financial risk by taking on partners and hiring subcontractors. The partners/subcontractors are expected to invest some of their own funds in the R&D effort in exchange for sole-source, long-term production contracts if the product undergoes successful commercialization.

b. A company has decided to handle its marketing risks by offering a family of products to its customer base. Different features exist for each product offered.

c. A company has product lines with a life expectancy of ten years or more. The company is handling its technical risks by performing extensive testing on new components and performing parallel technical development efforts for downstream enhancements.

d. A company has large manufacturing costs for its high tech products. The company will not begin production until it has a firm commitment for a certain quantity. The company uses learning curves and project management to control its costs.

17–5 A telecommunications firm believes that the majority of its income over the next ten years will come from organizations outside of the United States. More specifically, the income will come from third world nations that may have very little understanding or experience in project management.

 

The company prepared Figure 17–11. What causes the increasing risks in Figure 17–11?

 

Page 944

Figure 17–11. Future risks.

17–6 In the 1970s and 1980s, military organizations took the lead in developing ways to assess total program risk. One approach was to develop a rigorous process for identifying specific technical risk at the functional level and translating this detailed information through several steps. In this way, it was believed that risks could easily be monitored and corrected, as shown in Figure 17–12. Why is this method not being supported today?

Figure 17–12. Technical risk identification at appropriate management levels (ONAS P 4855-X).

 

Page 945

17–7 As an example of the situation in Problem 17–6, Figure 17–13 shows risk categories at the program, subsystem, and functional levels. Starting at the bottom, data are developed for five engineering indicators and rated according to ''high," "medium," or "low" risk. Results of this assessment are then summarized for each subsystem to provide a system overview. This is often considered a template risk analysis method. What are the advantages and disadvantages of this approach? Why is this method not used extensively today?

17–8 With the explosion of computer hardware and software during the 1970s and 1980s, companies began developing models to assess the technical risk for the computer hardware and software effort. One such model is discussed in this problem. Although some people contend that there may still exist applicable use for this model, others argue that the model is obsolete and flawed with respect to current thinking. After reading the paragraphs below, explain why the model may have limited use today for technical risk management.

Previously, we showed that risk quantification could be found by use of an expected-value calculation. However, there are more sophisticated approaches that involve templates combined with the expected-value model. Here, we can develop mathematical expressions for failure and risk for specific types of projects.

Risk can be simply modeled as the interaction of two variables: probability of failure (Pf) and the effect or consequence of the failure (Cf). Consequences may be measured in terms of technical performance, cost, or schedule. A simple model can be used to highlight areas where the probability of failure (Pf) is high (even if there is

Figure 17–13. Variation of risk identification products with management level (ONAS P 4855-X).

 

a low probability of occurrence). Mathematically, this model can be expressed as the union of two sets, Cf. Table 17–11 shows a mathematical model for risk assessment on hardware–software projects. In other words, the risk factor (defined as Pf × Cf) will be largest where both Pf and Cf are large, and may be high if either factor is large.

In this case, Pf is estimated by looking at hardware and software maturity, complexity, and dependency on interfacing items. The probability of failure, Pf, is then quantified from ratings similar to the factors in Table 17–11. Cr is calculated by looking at the technical, cost, and schedule implications of failure. For example, consider an item with the following characteristics:

• Uses off-the-shelf hardware with minor modifications to software database

• Is based on simply-designed hardware

• Requires software of somewhat minor increase in complexity

• Involves a new database to be developed by a subcontractor

Using Table 17–11, the probability of failure, Pf, would be calculated as follows:

Assume that the weighting factors for a, b, c, d, and e are 20 percent, 10 percent, 40 percent, 10 percent, and 20 percent, respectively.

PM (hardware) = 0.1 0.2 PM (h) = 0.02

PM (software) = 0.3 0.1 PM (s) = 0.03

PC (hardware) = 0.1 0.4 PC  (h) = 0.04

PC (software) = 0.3 0.1 PC  (s) = 0.03

PD= 0.9 0.2 PD

= 0.18 

      = 0.30

Then, assuming the weighting factors shown in equation (2) of Table 17–11 are as indicated above, the this item would be 0.30.

If the consequence of the item's failure because of technical factors would cause some problems of a correctable nature, but correction would result in an 8 percent cost increase and two-month schedule slip, the consequence of failure, Cf , would be calculated from Table 17–11 as follows:

 

Ct = 0.3 0.4 C

t = 0.12

Cc = 0.5 0.5 C

c = 0.25

Cs = 0.5 0.1 C

s = 0.12

  0.42

 

Page 948

Then Cf for this item [assuming that the weighting factors in equation (3) of Table 17–11 are as indicated above] would be 0.42.

From equation (1) of Table 17–11, the risk factor would be

In other words, the risk associated with this item is medium. Because most of the risk associated with this example arises from software changes, in particular the use of a subcontractor in this area, we can conclude that the risk can be reduced when the computer software developer is held "accountable for work quality and is subject to both incentives and penalties during all phases of the system life cycle."

Similar risk analyses would be performed for all other items and a risk factor would be obtained for each identified risk area. Risk areas would then be prioritized according to source of the risk (for example, are other items exhibiting excessive risk due to subcontractor software development?).

Case Studies

Teloxy Engineering (A)

Teloxy Engineering has received a onetime contract to design and build 10,000 units of a new product. During the proposal process, management felt that the new product could be designed and manufactured at a low cost. One of the ingredients necessary to build the product was a small component that could be purchased for $60 in the marketplace, including quantity discounts. Accordingly, management budgeted $650,000 for the purchasing and handling of 10,000 components plus scrap.

During the design stage, your engineering team informs you that the final design will require a somewhat higher-grade component that sells for $72 with quantity discounts. The new price is substantially higher than you had budgeted for. This will create a cost overrun.

You meet with your manufacturing team to see if they can manufacture the component at a cheaper price than buying it from the outside. Your manufacturing team informs you that they can produce a maximum of 10,000 units, just enough to fulfill your contract. The setup cost will be $100,000 and the raw material cost is $40 per component. Since Teloxy has never manufactured this product before, manufacturing expects the following defects:

% defective 0 10 20 30 40

probability of  occurrence (%)

10 20 30 25 15

All defective parts must be removed and repaired at a cost of $120 per part.

1. Using expected value, is it economically better to make or buy the component?

 

Page 949

2. Strategically thinking, why might management opt for other than the most economical choice?

Teloxy Engineering (B)

Your manufacturing team informs you that they have found a way to increase the size of the manufacturing run from 10,000 to 18,000 units, in increments of 2,000 units. However, the setup cost will be $150,000 and defects will cost the same $120 for removal and repair.

1. Calculate the economic feasibility of make or buy.

2. Should the probability of defects change if we produce 18,000 units as opposed to 10,000 units?

3. Would your answer to question 1 change if Teloxy management believes that follow-on contracts will be forthcoming? What would happen if the probability of defects changes to 15 percent, 25 percent, 40 percent, 15 percent, and 5 percent due to learning-curve efficiencies?

TEAMFLY

Team-Fly®