Most companies desire to get to the marketplace in a timely manner because the rewards for being the first-to-market can be huge in both profitability and market share. Getting to the marketplace quickly often entails using concurrent engineering, or overlapping activities. The critical question is, “How much overlapping can we incur before we get diminishing returns?”
The risks involved with overlapping activities are shown in Figure 17–22.
Overlapping activities can lead to schedule compression and lower costs. However, too much overlapping can lead to excessive rework and unanticipated problems that can gen- erate significant schedule slippages and cost overruns. Finding the optimal overlapping point that increases benefits while decreasing rework is difficult.
Although there may exist numerous reasons for the rework, two common problems are:
● Combining new technology development and product development technology
● An insufficient test and evaluation program
Risk and Concurrent Engineering 699
DANGER
LOSSES AND DAMAGES
CONTINGENCY PLANS AND MITIGATION STRATEGIES
HAZARDS
FIGURE 17–20. Perfect planning.
Optimal Compression
Target Cost or Schedule Behind
Schedule or Over Budget
Schedule Compression or Lower Cost
Low High
Percent of Activity Overlapping FIGURE 17–22. Overlapping risks.
DANGER
HAZARDS
CONTINGENCY PLANS AND MITIGATION STRATEGIES LOSSES AND
DAMAGES
FIGURE 17–21. Imperfect planning.
To illustrate why these problems occur, consider a situation where the sales and mar- keting force promises the marketplace a new product with advanced technology that hasn’t yet been developed. To compress the schedule, the product development team be- gins designing the product without knowing whether or not (and when) the technology can be developed. Production teams are asked to develop manufacturing plans without having any drawings. This results in massive changes when the product final reaches production.
There are three questions that need to be continuously addressed:
● Can the new technology be developed?
● Can we demonstrate the new technology within the product?
● Can the product then be manufactured within the time, cost, and performance (i.e., reliability) constraints?
Simultaneous development of technologies and products has become commonplace.
To decrease the risks of rework, there should be a demonstration that the technology can work as expected. Leading firms that use concurrent engineering do not include a new technology in a product until the technology reaches a prescribed level of maturity. They have disciplined processes that match requirements with technological capability before product development is launched. These companies have learned the hard lesson of not committing to new products that outstrip their technological know-how. These practices stem from their recognition that resolving technology problems after product development begins can result in a tenfold cost increase; resolving these problems in production could increase costs by a hundredfold.
Some commonly accepted practices to reduce risks include:
● Flexibility in both the resources provided and the product’s performance require- ments to allow for uncertainties of technical progress
● Disciplined paths for technology to be included in products, with strong gate- keepers to decide when to allow it into a product development program
● High standards for judging the maturity of the technology
● The imposition of strict product development cycle times
● Rules concerning how much innovation can be accepted on a product before the next generation must be launched (these rules are sometimes referred to as tech- nology readiness levels)
Collectively, these factors create a healthy environment for developing technology and making good decisions on what to include in a product.
Overlapping activities can be very risky if problems are discovered late in the cycle.
One common mistake is to begin manufacturing before a sufficient quantity of engineer- ing drawings is available for review. This normally is the responsibility of systems inte- gration personnel. Systems integration should conclude with a critical design review of en- gineering drawings and confirmation that the system’s design will meet requirements—a key knowledge point. It should also result in firm cost and schedule targets and a final set of requirements for the current version of the product. Decision-makers should insist on a mature design, supported with complete engineering drawings, before proceeding to even
Risk and Concurrent Engineering 701
limited production. Having such knowledge at this point greatly contributes to product success and decreases costly rework.
As an example, Boeing had released over 90 percent of the engineering drawings on its 777-200 airplane halfway through its product development program. This allowed Boeing to have near certainty that the design for the 777-200 airplane would meet re- quirements. On the other hand, a different program had released only about half of its en- gineering drawings at approximately the same point in development. The other program encountered numerous technical problems in testing that resulted in redesigns, cost in- creases, and schedule delays.
Companies intent on decreasing the risks of concurrent engineering have found ways to employ testing in a manner that avoids late-cycle churns, yet enables them to efficiently yield products in less time, with higher performance, and at a lower cost. Generally, these practices are prompted by problems—and late-cycle churn—encountered on earlier prod- ucts. Both Boeing and Intel were hurt by new products in which testing found significant problems late in development or in production that may have been preventable. Boeing ab- sorbed cost increases in one line of aircraft and delivered it late to the first customer; Intel had to replace more than a million microprocessors that contained a minor, but neverthe- less well-publicized, flaw. On subsequent products, these firms were able to reduce such problems by changing their approach to testing and evaluation and were able to deliver more sophisticated products on time, within budget, and with high quality.
Boeing encountered significant difficulties late in the development of its 747-400 air- liner, which delayed its delivery to the customer and increased costs. When the 747-400 was delivered to United Airlines in 1990, Boeing had to assign 300 engineers to solve problems that testing had not revealed earlier. The resulting delivery delays and initial service prob- lems irritated the customer and embarrassed Boeing. Boeing officials stated that this expe- rience prompted the company to alter its test approach on subsequent aircraft, culminating with the 777-200 program of the mid-1990s. According to company officials, the 777-200 testing was the most extensive conducted on any Boeing commercial aircraft. As a result, Boeing delivered a Federal Aviation Administration–certified, service-ready 777-200 air- craft at initial delivery and reduced change, error, and rework by more than 60 percent.
A hallmark of the 777-200’s success was the extended-range twin-engine certification for transoceanic flight it received from the Federal Aviation Administration on the first air- craft. This certification is significant because it normally takes about two years of actual operational service before the Federal Aviation Administration grants extended range cer- tification. In the case of the 777-200, the testing and evaluation effort provided enough confidence in the aircraft’s performance to forego the operational service requirements.
Intel has also employed testing to reduce late-cycle churn on its new microprocessors.
According to Intel officials, the company learned this lesson the hard way—by inadver- tently releasing the initial Pentium®microprocessor with a defect. After the release, Intel discovered a flaw in one of the Pentium®microprocessor’s higher level mathematical functions. Using analytical techniques, Intel concluded that this flaw would not signifi- cantly affect the general public because it would occur only very rarely. Intel, however, miscalculated the effect on the consumer and was forced to replace more than a million microprocessors at a cost of about $500 million. Intel underwent a significant corporate
change in its test approach to ensure that bugs like this did not “escape” to the public again.
As a result, the performance of subsequent microprocessors, like the Pentium®Pro and Pentium®III microprocessors, has significantly improved. Despite adopting a much more rigorous testing and evaluation approach, Intel did not increase the amount of time it took to develop new, more sophisticated microprocessors. In fact, Intel’s rate of product release increased over time.8
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 its statistical data as shown below:
Problems 703
8. A More Constructive Test Approach Is Key to Better Weapon System Outcomes, Best Practice Series, GAO/NSIAD-00-199, Government Accounting Office, July 2000, pp. 23–25.
Amount of Type of Damage Probability (%) 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 han- dling 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 dif- ferent 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
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 S5were 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 produc- tion line will handle exactly 6,000 units and requires a one-time setup cost of $50,000. The pro- duction 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 40 30 20 6 4
occurrence (%)
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–23. What causes the increasing risks in Figure 17–23?
17–6 In the 1970s and 1980s, military organizations took the lead in developing ways to as- sess 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–24. Why is this method not being supported today?
17–7 As an example of the situation in Problem 17–6, Figure 17–25 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?
Problems 705
Inexperienced
Customer's Knowledge
Experienced
Simple
Contract Type
Complex
Incr easing Risks
FIGURE 17–23. Future risks.
THE ROL
L-UP PROCESS
EXISTING DATA
ENGINEERING FUNCTIONA
ITEM L S SUBSYSTEMS
PROGRAM
INDICATORS MAN
AGEMENT COST PROD
UCTI ON TE
ST DESIGN
FUNCTIONAL MANAGEMENT SUBSYSTEM MANAGEMENT UPPER AND MIDDLE MANAGEMENT FOR ACTION BY:
4. . . WHICH IN TURN ARE COMBINED INTO PROGRAM-LEVEL INDICATORS.
3THE FUNCTIONAL ITEM INDICATORS ARE COMBINED TO PRODUCE SUBSYSTEM INDICATORS . . .
2THESE DATA ARE USED TO PREPARE ENGINEERING RISK INDICATORS IN EACH AREA OF CONCERN FOR FUNCTIONAL ITEMS.
1THE PROCESS STARTS WITH A BASE- LINE OF DOCUMENTATION (DESIGN GOALS, TEST DATA, ETC.) NORMALLY ASSOCIATED WITH A PROGRAM.
FIGURE 17–24. Technical risk identification at appropriate management levels (ONAS P 4855-X).
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 specifictypes 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 a low probability of occurrence).
Mathematically, this model can be expressed as the union of two sets,PfandCf. Table 17–14 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 PfandCfare large, and may be high if either factor is large.
In this case,Pfis 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–14.Cfis calculated by looking at the technical, cost, and sched- ule implications of failure. For example, consider an item with the following characteristics:
DESIGN
TEST
PRODUCTION
COST
MANAGEMENT
LEGEND: = "HIGH" = "MEDIUM" = "LOW"
SONAR WARHEAD PROPULSION
FLEET EXERCISE
COMMAND
&
CONTROL SUBSYSTEM
SUMMARY
ENGINEERING INDICATORS PROGRAM
SUMMARY
WEIGHT LENGTHCG
FIGURE 17–25. Variation of risk identification products with management level (ONAS P4855-X).
● 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–14, the probability of failure,Pf, would be calculated as follows:
Problems 707
TABLE 17–14. A MATHEMATICAL MODEL FOR RISK ASSESSMENT (1) Risk Factor = Pf+Cf-Pf•Cf
(2)Pf=a•PM
hw+b•PM
sw+c•PC
hw+d•PC
sw+e•PD (3)Cf=f•Ct+g•Cc+h•Cs
where: where:
PM
hw= Probability of failure due to degree of hardware maturity Ct= Consequence of failure due to technical factors PM
sw= Probability of failure due to degree of software maturity Cc= Consequence of failure due to changes in cost PC
hw= Probability of failure due to degree of hardware complexity Cs= Consequence of failure due to changes in schedule
PC
sw= Probability of failure due to degree of software complexity PD= Probability of failure due to dependency on other items
and where: a, b, c, d,andeare weighting factors and where: f, g,andhare weighting factors
whose sum equals one. whose sum equals one.
Maturity Factor Complexity Factor
(PM) (PC)
Magnitude
Hardware Software Hardware Software
Dependency Factor PM
hw PM
sw PC
hw PC
sw
(PD)
Existing Existing Simple Simple Independent of existing system,
0.1 design design facility, or associate contractor
Minor Minor Minor Minor Schedule dependent on existing
0.3 redesign redesign increases in increases in system, facility, or associate complexity complexity contractor
Major Major Moderate Moderate Performance dependent on existing
0.5 change change increase increase system performance, facility, or
feasible feasible associate contractor
Technology New software, Significant Significant Schedule dependent on new system 0.7 available, similar to increase increase/major schedule, facility, or associate
complex design existing increase in # of contractor
modules
State of art, State of art, Extremely Extremely Performance dependent on new 0.9 some research never done complex complex system schedule, facility, or
complete before associate contractor
(continues)
Assume that the weighting factors for a, b, c, d,andeare 20 percent, 10 percent, 40 per- cent, 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–14 are as indicated above, the Pfon 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–14 as follows:
Ct⫽0.3 0.4 Ct⫽0.12
Cc⫽0.5 0.5 Cc⫽0.25
Cs⫽0.5 0.1 Cs⫽0.12
0.42
TABLE 17–14. A MATHEMATICAL MODEL FOR RISK ASSESSMENT (Continued)
Magnitude Technical Factor Cost Factor Schedule Factor
(Ct) (Cc) (Cs)
Minimal or no consequences, Budget estimates not exceeded, Negligible impact on program, unimportant some transfer of money slight development schedule
0.1 (low) change compensated by available
schedule slack
Small reduction in Cost estimates exceed budget Minor slip in schedule (less than 1 0.3 (minor) technical performance by 1 to 5 percent month), some adjustment in
milestones required Some reduction in Cost estimates increased by Small slip in schedule 0.5 (moderate) technical performance 5 to 20 percent
Significant degradation in Cost estimates increased by Development schedule slip 0.7 (significant) technical performance 20 to 50 percent in excess of 3 months
Technical goals cannot Cost estimates increased in Large schedule slip that affects
0.9 (high) be achieved excess of 50 percent segment milestones or has
possible effect on system milestones
ThenCffor this item [assuming that the weighting factors in equation (3) of Table 17–14 are as indicated above] would be 0.42.
From equation (1) of Table 17–14, the risk factor would be 0.30⫹0.42⫺(0.30)(0.42)⫽0.594
In other words, the risk associated with this item is medium. Because most of the risk associ- ated 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 ob- tained 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?).
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 dis- counts. 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 re- quire 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 manu- factured this product before, manufacturing expects the following defects:
% defective 0 10 20 30 40
probability of 10 20 30 25 15
occurrence (%)
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?
2. Strategically thinking, why might management opt for other than the most economical choice?
Case Studies 709
CASE STUDIES