Value Creation in the Product Development Process

Value Creation in the Product Development Process

by

James P. Chase

Bachelor of Science, Aerospace Engineering and MechanicsUniversity of Minnesota, 1999

Bachelor of Arts, English Language and LiteratureUniversity of Minnesota, 1999

Submitted to the Department of Aeronautics and Astronauticsin Partial Fulfillment of the Requirements for the Degree of

Master of Science in Aeronautics and Astronautics

at theMassachusetts Institute of Technology

December 2001

©2001 Massachusetts Institute of TechnologyAll rights reserved

Signature of Author ..........................................................................................................................................................Department of Aeronautics and Astronautics

December 21, 2001

Certified by .......................................................................................................................................................................Edward M. Greitzer

Associate Department Head, Department of Aeronautics and AstronauticsThesis Supervisor

Certified by .......................................................................................................................................................................Hugh L. McManus

Principal Research Engineer, Lean Aerospace InitiativeThesis Supervisor

Certified by .......................................................................................................................................................................John J. Deyst, Jr.

Professor, Department of Aeronautics and AstronauticsThesis Supervisor

Accepted by ......................................................................................................................................................................Wallace E. Vander Velde

Professor of Aeronautics and Astronautics Chair, Committee on Graduate Students

2

Written in the shadow of the September 11th terrorist

attacks, this thesis is dedicated to the victims in the

hope that the knowledge herein will contribute, in its

fashion, to lasting peace and security.

3

Value Creation in the Product Development Process

by

James P. Chase

Submitted to the Department of Aeronautics and Astronautics on December 21, 2001in Partial Fulfillment of the Requirements for the Degree of

Master of Science in Aeronautics and Astronautics

ABSTRACT

A framework for value creation in the product development process is proposed as an aid forvisualizing and understanding value in complex processes and thus guiding resource allocation,process measurement, and process improvement. The framework is based on informationreceived from a variety of industry site visits and stresses process value. It defines process valuein product development as the approach of the enterprise in creating a desired product for thecustomer, continuing profit for the shareholder, and lifetime satisfaction for the employee. Thefour principal elements of the framework include tasks, resources, environment, andmanagement. These elements are further divided into several levels of value attributes, affordinga constructive view of value creation.

Several sets of data provide observations on portions of the framework. An analysis of industrywork breakdown structures revealed (i) tasks contribute markedly different types of value amongprograms, implying that no single definition of "the product development process" exists at adetailed level, (ii) lower level tasks contain more enabling activities, supporting the notion thatimprovement efforts should focus at a detailed level of the process, and (iii) programstransitioning to lean include more tasks emphasizing cost/schedule, advocating that companiesshould recognize cost/schedule more explicitly. A survey showed that engineers spend over 70%of their time on communication-related activities, suggesting that achieving effectivecommunication should be a priority of process improvement efforts. Finally, programs usingearned value management had greater consistency and fewer delayed tasks than programs whichtracked task completion dates only.

Thesis Supervisors: Edward M. GreitzerH.N. Slater ProfessorDepartment of Aeronautics and Astronautics

Hugh L. McManusPrincipal Research EngineerLean Aerospace Initiative

John J. Deyst, Jr.ProfessorDepartment of Aeronautics and Astronautics

4

I expect to pass through life but once, if therefore there

be any kindness I can show, or any good thing I can do

to any fellow being, let me do it now, and not defer or

neglect it, as I shall not pass this way again.

– William Penn

5

ACKNOWLEDGEMENTS

As suggested later in the thesis, graduate research is similar to the product development process.The core areas of tasks, resources, environment, and management were as critical in my researchas they are in the product development process. This analogy helps to recognize the importanceof others in the success of research. Resources, environment, and management are linked withfaculty advisors, industry members, colleagues, friends, family and faith. Thus, the successfulcompletion of this work is a testament to the many hours that others have contributed. I amgrateful for these contributions and consider myself fortunate for having the opportunity to workwith those listed here.

I am especially thankful to my three advisors (Ed Greitzer, Hugh McManus, and John Deyst),Earll Murman, Simon Walter-Hansen, and the Lean Aerospace Initiative. Ed instilled a level ofrigorousness that will follow me well beyond this research. Hugh provided considerable insightfrom his knowledge of lean practices. John is responsible for the consistent theme of riskreduction that pervades the thesis. Earll went well beyond his available time to provide adviceon the research process. Simon donated many hours (and then some) to help with the onlinesurveys. And, the Lean Aerospace Initiative (LAI) provided my research funding.

LAI Faculty and Staff

I would like to thank the many members of LAI who provided intellectual guidance. KirkBozdogan and Deborah Nightingale inspired the work on communication. Al Haggerty andJoyce Warmkessel offered insight on the management sections. Eric Rebentisch provided initialhelp on the research framework. Tom Shields “located” funding for my academic pilot study.And, Frances Meale and Robin Palazzolo’s weekly assistance was invaluable.

Industry Members

The participation of industry was an essential component of the research. Many industrymembers gave their time through interviews, surveys, and discussions. In particular, I amindebted to Adi Choudri, Ed Harmon, and Ed Peterson for their continued support and advice.Others also provided considerable time, including Jim Ayers, Bill Carrier, Sarah Hotaling,Mukesh Luhar, Russell Parker, George Reynolds, Kevin Smith, Kerry Sugimoto, Robert Tock,and Jeff Wessels. Finally, former colleagues, Josh Bernstein and Tyson Browning, successfullybridged the gap between industry and academia in their support of the research.

Fellow Graduate Students

My LAI colleagues were a source of inspiration and support. For example, I will never be ableto appropriately reference the ideas contributed by Rob Dare, Rich Millard, and Alexis Stanke. Iam also thankful to the members of my pilot study, including Sandra Kassin-Deardorff, JacobMarkish, Michelle McVey, Rhonda Salzman, Carissa Tudryn, and Mandy Vaughn. In sum, eachof these colleagues, and now friends, contributed to a positive and memorable experience.

Friends, Family, and Faith

The expertise from LAI and industry means little, however, without a solid foundation of friends,family, and faith. In addition to those referenced above, I would like to give special thanks to

6

David Nistler for his review of several thesis chapters, Monica Herlofsky for her ideas on thecommunication survey, and Breanna Ahmad for the continued, yet always unexpected, deliveriesof “high-calorie cuisine.” My parents (Claire and Pat) and sister (Jeanne) have contributedcontinual patience, guidance, help, and understanding. They have proven to be constant rolemodels that I continue to look up to. Finally, God is ever present and ultimately my guide forpast, present, and future work.

7

TABLE OF CONTENTS

CHAPTER 1: INTRODUCTION AND EXECUTIVE SUMMARY.................................................................13

1.1 MOTIVATION AND PROBLEM STATEMENT..................................................................................................13

1.2 KEY QUESTIONS.........................................................................................................................................14

1.3 RESEARCH OVERVIEW ...............................................................................................................................14

1.4 SUMMARY OF THESIS CONTRIBUTIONS ......................................................................................................15

CHAPTER 2: THE LEAN PHILOSOPHY .........................................................................................................17

2.1 ORIGINS OF LEAN.......................................................................................................................................17

2.2 LEAN PRINCIPLES.......................................................................................................................................18

2.2.1 Specify Value....................................................................................................................................18

2.2.2 Identify the Value Stream.................................................................................................................20

2.2.3 Create Continuous Flow..................................................................................................................20

2.2.4 Organize Customer Pull ..................................................................................................................21

2.2.5 Pursue Perfection ............................................................................................................................21

2.3 EXAMPLES OF LEAN IMPLEMENTATION .....................................................................................................22

2.4 SUMMARY ..................................................................................................................................................23

CHAPTER 3: PRODUCT DEVELOPMENT OVERVIEW..............................................................................24

3.1 INTRODUCTION TO THE PRODUCT LIFECYCLE ............................................................................................24

3.1.1 Concept Development ......................................................................................................................26

3.1.2 Preliminary Design..........................................................................................................................27

3.1.3 Detailed Design ...............................................................................................................................27

3.1.4 Test & Evaluation ............................................................................................................................27

3.1.5 Production .......................................................................................................................................28

3.1.6 Support and Operations...................................................................................................................28

3.2 IMPORTANCE OF PRODUCT DEVELOPMENT ................................................................................................29

3.3 COMPLEXITY AND THE THREE DIMENSIONS OF PRODUCT DEVELOPMENT ................................................31

3.3.1 The Product......................................................................................................................................32

3.3.2 The Process......................................................................................................................................32

3.3.3 The Organization .............................................................................................................................33

3.4 PERVASIVE COMMUNICATION IN PRODUCT DEVELOPMENT ......................................................................33

3.4.1 Communication Architecture...........................................................................................................34

3.4.2 Collaborative Design and Development..........................................................................................34

3.5 FUNDAMENTAL METRICS OF THE PRODUCT DEVELOPMENT PROCESS.......................................................35

3.5.1 Performance.....................................................................................................................................36

3.5.2 Cost ..................................................................................................................................................37

8

3.5.3 Schedule ...........................................................................................................................................37

3.5.4 Risk...................................................................................................................................................38

3.5.5 Balancing Performance, Cost, Schedule, and Risk .........................................................................39

3.6 SUMMARY ..................................................................................................................................................39

CHAPTER 4: VALUE IN PRODUCT DEVELOPMENT.................................................................................40

4.1 WHY IS VALUE IMPORTANT? .....................................................................................................................40

4.1.1 Resource Allocation.........................................................................................................................40

4.1.2 Process Measurement ......................................................................................................................41

4.1.3 Process Improvement.......................................................................................................................41

4.2 WHAT IS VALUE? .......................................................................................................................................41

4.3 VALUE IN PRODUCT DEVELOPMENT ..........................................................................................................44

4.3.1 Value Engineering and Value Analysis (VE/VA).............................................................................44

4.3.2 Lean Product Development .............................................................................................................47

4.4 TOOLS FOR QUANTIFYING VALUE IN PRODUCT DEVELOPMENT ................................................................47

4.5 SUMMARY ..................................................................................................................................................50

CHAPTER 5: DELIVERING VALUE IN PRODUCT DEVELOPMENT ......................................................51

5.1 INITIAL OBSERVATIONS .............................................................................................................................51

5.1.1 Considerations of Value...................................................................................................................51

5.1.2 Perspective of Value ........................................................................................................................52

5.2 CONCEPTUAL FRAMEWORK FOR VALUE CREATION AND DELIVERY .........................................................52

5.3 RESEARCH PROPOSITIONS ..........................................................................................................................54

5.4 EXTENDING THE FRAMEWORK FOR VALUE................................................................................................55

5.4.1 Creating Value via the “Right” Tasks.............................................................................................57

5.4.2 Facilitating Value Creation via the “Right” Resources..................................................................60

5.4.3 Facilitating Value Creation via the “Right” Environment .............................................................61

5.4.4 Delivering Value via the “Right” Management Approach .............................................................61

5.5 SUMMARY ..................................................................................................................................................63

CHAPTER 6: DATA COLLECTION..................................................................................................................64

6.1 SCOPE OF DATA COLLECTION ....................................................................................................................64

6.2 METHODOLOGY FOR TASK RESEARCH.......................................................................................................67

6.2.1 Work Breakdown Structures Gathered ............................................................................................67

6.2.2 Task Categories ...............................................................................................................................68

6.2.3 Value Attributes ...............................................................................................................................68

6.2.4 Lean Penetration Assessment ..........................................................................................................69

6.2.5 Relationships Between Tasks and Value Attributes.........................................................................69

9

6.2.6 Data Analysis...................................................................................................................................69

6.2.7 Quantifying Task Value ...................................................................................................................69

6.2.8 Data Analysis...................................................................................................................................71

6.3 METHODOLOGY FOR RESOURCES RESEARCH ............................................................................................71

6.3.1 Site Visits and Interviews.................................................................................................................72

6.3.2 Interview Notes and Literature Review ...........................................................................................72

6.4 METHODOLOGY FOR ENVIRONMENTAL RESEARCH ...................................................................................72

6.4.1 Communication Survey ....................................................................................................................73

6.4.2 Data Analysis...................................................................................................................................73

6.4.3 Case Studies on Successful Environments .......................................................................................74

6.4.4 Data Analysis...................................................................................................................................74

6.5 METHODOLOGY FOR MANAGEMENT RESEARCH........................................................................................74

6.5.1 Task Completion Data .....................................................................................................................75

6.5.2 Data Analysis...................................................................................................................................75

6.5.3 Technical Uncertainty Data.............................................................................................................76

CHAPTER 7: ANALYSIS AND RESULTS ........................................................................................................77

7.1 TASK RESEARCH ........................................................................................................................................77

7.1.1 Analysis of Work Breakdown Structures .........................................................................................77

7.1.2 Analysis of Industry and Academic Surveys ....................................................................................84

7.1.3 Discussion of Task Value.................................................................................................................88

7.2 RESOURCE VALUE......................................................................................................................................89

7.3 RESEARCH ON COMMUNICATION IN THE ENVIRONMENT ...........................................................................90

7.3.1 Analysis of Communication Surveys................................................................................................90

7.3.2 Brief Case Studies of Successful Industry Teams ............................................................................94

7.3.3 Discussion of Environment Value....................................................................................................95

7.4 MANAGEMENT RESEARCH .........................................................................................................................96

7.4.1 Analysis of Schedule Completion Data............................................................................................96

7.4.2 Managing Technical Uncertainty ..................................................................................................101

7.4.3 Discussion of Management Value..................................................................................................102

CHAPTER 8: SUMMARY ..................................................................................................................................104

CHAPTER 9: REFERENCES.............................................................................................................................106

APPENDIX A: DISCUSSION OF RESOURCE VALUE .............................................................................111

A.1 KNOWLEDGE ............................................................................................................................................111

A.2 PEOPLE .....................................................................................................................................................112

10

A.2.1 Proficiency .....................................................................................................................................112

A.2.2 Diversity.........................................................................................................................................112

A.2.3 Empowerment ................................................................................................................................113

A.2.4 Mentorship .....................................................................................................................................113

A.2.5 Leadership .....................................................................................................................................114

A.3 TOOLS ......................................................................................................................................................114

A.3.1 Information Gathering Tools .........................................................................................................115

A.3.2 Knowledge Application Tools........................................................................................................116

APPENDIX B: CASE STUDIES OF SUCCESSFUL TEAM ENVIRONMENTS .....................................118

B.1 “TWELVE DAYS OF AUGUST,” F-18E/F, BOEING ....................................................................................118

B.2 DEVELOPING NEW PRODUCTS TEAM, JET PROPULSION LABORATORY, NASA.......................................119

B.3 MISSION CONTROL CENTER, JOHNSON SPACE CENTER, NASA ..............................................................119

APPENDIX C: PILOT STUDY OF ACADEMIC RESEARCH ..................................................................121

C.1 METHODOLOGY OF ACADEMIC CASE STUDY...........................................................................................121

C.2 TASK VALUE ............................................................................................................................................122

C.3 TIME VERSUS TASK VALUE ......................................................................................................................124

C.4 RESULTS OF THE PILOT STUDY.................................................................................................................124

APPENDIX D: RESEARCH SURVEYS AND DEFINITIONS....................................................................125

D.1 INFORMED CONSENT FOR SURVEYS .........................................................................................................125

D.2 TASK SURVEY FOR MEASURING VALUE (INDUSTRY)...............................................................................126

D.3 ORIGINAL VALUE ATTRIBUTE DEFINITIONS USED IN INDUSTRY TASK SURVEYS ....................................127

D.4 TASK SURVEY FOR MEASURING VALUE (ACADEMIA) .............................................................................129

D.5 SURVEY FOR COMMUNICATION IN THE AEROSPACE INDUSTRY ...............................................................130

D.6 DEFINITIONS FOR COMMUNICATION SURVEY ..........................................................................................131

D.7 TECHNICAL UNCERTAINTY SURVEY ........................................................................................................133

11

LIST OF FIGURES

FIGURE 1.1: STRUCTURE FOR "VALUE CREATION IN THE PRODUCT DEVELOPMENT PROCESS"....................................14

FIGURE 1.2: CONCEPTUAL FRAMEWORK OF THE PRODUCT DEVELOPMENT PROCESS ..................................................15

FIGURE 2.1: PRODUCT VERSUS PROCESS VALUE IN PRODUCT DEVELOPMENT .............................................................19

FIGURE 3.1: PRODUCT LIFECYCLE PROCESS (LAI, 1998) .............................................................................................26

FIGURE 3.2: TPM UNCERTAINTY IN THE LIFECYCLE PROCESS .....................................................................................29

FIGURE 3.3: LIFECYCLE COST COMMITTED (ADAPTED FROM FABRYCKY AND BLANCHARD, 1999) ............................30

FIGURE 3.4: MANAGING COMPLEXITY TO CREATE VALUE...........................................................................................31

FIGURE 3.5: PRODUCT PERFORMANCE VIA TECHNICAL PERFORMANCE MEASURES.....................................................36

FIGURE 3.6: MANAGING PERFORMANCE, COST, AND SCHEDULE UNCERTAINTY .........................................................38

FIGURE 4.1: CUMULATIVE CASH FLOW OF THE PRODUCT LIFECYCLE..........................................................................43

FIGURE 4.2: MEASURING VALUE (SHILLITO AND DEMARLE, 1992; TANAKA, 1973) ..................................................46

FIGURE 5.1: CONCEPTUAL FRAMEWORK FOR VALUE CREATION AND DELIVERY.........................................................53

FIGURE 5.2: FRAMEWORK FOR DELIVERING VALUE IN PRODUCT DEVELOPMENT........................................................56

FIGURE 6.1: DATA COLLECTION ACROSS THE FRAMEWORK ........................................................................................65

FIGURE 7.1: VALUE VERSUS TIME (TYPE OF TASK) ......................................................................................................87

FIGURE 7.2: VALUE VERSUS TIME (STUDENT SATISFACTION) ......................................................................................88

FIGURE 7.3: EFFECTIVENESS OF COMMUNICATION MODES ..........................................................................................92

FIGURE 7.4: TIME VERSUS VALUE OF COMMUNICATION MODES..................................................................................94

FIGURE 7.5: ESTIMATED VERSUS ACTUAL COMPLETION (A-2 & A-5) .........................................................................98

FIGURE 7.6: PRODUCT DEVELOPMENT VERSUS MANUFACTURING TASK COMPLETION................................................99

FIGURE 7.7: HISTOGRAM OF PRODUCT DEVELOPMENT TASK COMPLETION (A-2 & A-5) ............................................99

FIGURE 7.8: ESTIMATED VERSUS ACTUAL COMPLETION (SITE B-5)...........................................................................100

FIGURE 7.9: HISTOGRAM OF PRODUCT DEVELOPMENT TASK COMPLETION (B-5)......................................................101

FIGURE 7.10: TPM PLANNED PROFILE AND RISK REDUCTION (BROWNING, 2001)....................................................102

FIGURE C.1: PARTIAL DATA SET OF STUDENT RESEARCH..........................................................................................122

FIGURE C.2: CUMULATIVE VALUE OF STUDENT RESEARCH .......................................................................................123

FIGURE C.3: COMPARISON OF RESEARCH CASE STUDIES ...........................................................................................123

FIGURE C.4: ACTIVITY VALUE SUMMARY ..................................................................................................................124

FIGURE D.1: ONLINE TASK SURVEY FOR MEASURING VALUE (INDUSTRY)................................................................126

FIGURE D.2: ONLINE TASK SURVEY FOR MEASURING VALUE (ACADEMIA) ..............................................................129

FIGURE D.3: ONLINE SURVEY FOR COMMUNICATION IN THE AEROSPACE INDUSTRY ................................................130

FIGURE D.4: ONLINE SURVEY FOR MEASURING TECHNICAL UNCERTAINTY..............................................................133

12

LIST OF TABLES

TABLE 3.1: DEFINITIONS OF THE PRODUCT LIFECYCLE PROCESS .................................................................................25

TABLE 4.1: VALUE DEFINITIONS FOR PRODUCT DEVELOPMENT...................................................................................45

TABLE 4.2: TOOLS FOR QUANTIFYING VALUE IN PRODUCT DEVELOPMENT.................................................................48

TABLE 5.1: PROPOSED ELEMENTS OF VALUE................................................................................................................51

TABLE 5.2: VALUE CONTRIBUTION OF TASKS TO ENTERPRISE VALUE .........................................................................58

TABLE 5.3: VALUE ATTRIBUTES OF PRODUCT DEVELOPMENT TASKS..........................................................................59

TABLE 5.4: VALUE CONTRIBUTION OF RESOURCES ......................................................................................................60

TABLE 5.5: VALUE CONTRIBUTION OF THE ENVIRONMENT ..........................................................................................61

TABLE 5.6: VALUE CONTRIBUTION OF THE MANAGEMENT APPROACH........................................................................62

TABLE 6.1: SITE KEY FOR DATA COLLECTION..............................................................................................................66

TABLE 6.2: METHODOLOGY FOR TASK VALUE .............................................................................................................67

TABLE 6.3: LIST OF WORK BREAKDOWN STRUCTURES COLLECTED ............................................................................68

TABLE 6.4: SURVEY PARTICIPANTS FOR MEASURING VALUE OF TASKS ......................................................................70

TABLE 6.5: METHODOLOGY FOR RESOURCE VALUE.....................................................................................................71

TABLE 6.6: INTERVIEWS ACROSS AEROSPACE PRODUCT DEVELOPMENT.....................................................................72

TABLE 6.7: METHODOLOGY FOR ENVIRONMENTAL VALUE..........................................................................................73

TABLE 6.8: COMMUNICATION SURVEY PARTICIPANTS .................................................................................................73

TABLE 6.9: SUMMARY OF CASE STUDY DATA ..............................................................................................................74

TABLE 6.10: METHODOLOGY AND MANAGEMENT VALUE ...........................................................................................75

TABLE 6.11: SOURCES OF DATA FOR TASK COMPLETION .............................................................................................75

TABLE 6.12: TECHNICAL UNCERTAINTY DATA ............................................................................................................76

TABLE 7.1: WORK BREAKDOWN STRUCTURE WORD ANALYSIS ..................................................................................78

TABLE 7.2: ANALYSIS OF WORK BREAKDOWN STRUCTURES .......................................................................................79

TABLE 7.3: PROPOSED RELATIONSHIPS BETWEEN TASK CATEGORIES AND VALUE ATTRIBUTES.................................80

TABLE 7.4: VALUE CONTRIBUTION OF TASKS FROM PROGRAMS AND PROCESSES .......................................................81

TABLE 7.5: ASSESSMENT OF LEAN PENETRATION IN PRODUCT DEVELOPMENT ...........................................................82

TABLE 7.6: COMPARISON OF PROGRAMS AND DETAILED PROCESSES...........................................................................83

TABLE 7.7: COMPARISON OF HIGH AND LOW LEAN PENETRATION ..............................................................................84

TABLE 7.8: VALUE CONTRIBUTION OF TASKS FROM INDUSTRY PROCESSES.................................................................85

TABLE 7.9: VALUE CONTRIBUTION OF TASKS FROM ACADEMIC RESEARCH ................................................................86

TABLE 7.10: CURRENT TIME ALLOCATION IN PRODUCT DEVELOPMENT (IN %)...........................................................91

TABLE 7.11: COMPARISON OF COMMUNICATION EFFECTIVENESS FOR ENGINEERS AND MANAGERS...........................93

TABLE 7.12: PROPOSED SUGGESTIONS FOR THE PRODUCT DEVELOPMENT ENVIRONMENT..........................................95

TABLE 7.13: PROGRAMS USED FOR EVALUATING SCHEDULE CONSISTENCY ...............................................................97

13

Chapter 1: Introduction and Executive Summary

In 1996, Womack and Jones published Lean Thinking, which has become a primary guide for the

transition to lean within the aerospace industry. Their book suggested five lean principles that

enable corporations to reduce cost and time, while increasing quality. Aerospace organizations

have successfully responded to these recommendations in their manufacturing operations.

However, design, development, and testing activities have not yet achieved the same level of

success in implementing lean principles. Despite a number of lean initiatives in "above the shop

floor" activities, only a few improvements have been realized (McManus & Harmon, 2001).

The Lean Aerospace Initiative product development team has addressed several research projects

that explore the application of lean to complex system product development. For example, Slack

(1998) initially demonstrated that lean principles are applicable to product development,

Browning (1998) provided a useful approach for modeling cost, schedule, and performance, and

the 1998 LAI summer workshop identified seven types of information waste. These research

projects pointed out the need for an understanding of what value means in product development,

which is the subject of the thesis.

This chapter serves as an introduction and executive summary for value in product development.

The research motivation in the next section leads to a problem statement and set of key questions

that are addressed. The principal result of the thesis is a framework for value creation in the

product development process. In addition to the framework, some lessons are drawn from the

data collected and several insights are discussed.

1.1 Motivation and Problem Statement

The first principle of lean is specifying the value. During the product development process,

however, value is difficult to understand. The complexity of the process, distance from the final

customer, shifting market conditions, and uncertainties of technical performance, cost, and

schedule, all make a simple definition of value based on customer needs unworkable for process

improvement. Alternatively, concentrating on the cost of the product development process,

which makes up only a small fraction of the lifecycle cost, does not focus attention on the

14

appropriate aspects. Hence, a framework for understanding the nature of value in product

development is desired. Such a framework should allow the decomposition of the complexities

of value and give insight into how various aspects of product development value might be

measured and improved. The framework should be supported by both qualitative understanding

of industry practices and quantitative data on the aspects of value defined in the framework.

1.2 Key Questions

Key questions to be addressed include:

• How is value defined during product development? How can value be quantified before the

beginning of the use life?

• Given the definition of value, how can one understand the product development process, in

order to find out how to best create this value? Are the existing tools adequate to do the job,

or are more advanced models needed?

• What metrics can be established to measure value during product development, and can they

be used in real circumstances?

1.3 Research Overview

The thesis structure is shown in Figure 1.1. The initial chapters explore the lean philosophy

(Chapter 2), the product development process (Chapter 3), and value (Chapter 4). These

chapters define the principal considerations for developing a framework of value creation.

Chapter 2:

Lean Philosophy

Chapter 3:

Product Development

Chapter 4: Value in

Product Development

Chapter 5: Framework

for Value Creation

Chapter 6:

Data Collection

Chapter 7:

Results

Chapter 8:

Summary

Figure 1.1: Structure for "Value Creation in the Product Development Process"

15

The insight gained from the background material is then combined with a series of industry site

visits to produce the conceptual framework shown in Figure 1.2 and discussed in Chapter 5.

This framework, and its associated breakdown of value attributes, is a principal outcome of the

thesis. The four elements of the larger framework, explained in Section 5.4, include tasks,

resources, environment, and management. Although its validation is beyond the scope of the

research, several sets of data were acquired that provide insight on specific areas of the

framework.

Task 1

Task 2

Task n

Resources

Resources

Info.

Info.

Info. Risk

Risk

Risk

Process Value

Product $$

Resources

Performance

Schedule

ProductValue

Cost

Figure 1.2: Conceptual Framework of the Product Development Process

The scope and methodology of the data collection is presented in Chapter 6, which included

more than eighty interviews, four types of surveys, 15 work breakdown structures, and four sets

of task completion data. Its analysis, presented in Chapter 7, provides several observations

summarized in the next section on thesis contributions.

1.4 Summary of Thesis Contributions

1) The recognition of process value apart from product value. In manufacturing, value is

typically defined as a product meeting performance, cost, and schedule specifications.

However, in product development, it may be more useful to consider process value. Process

value can be defined as the ability to perform with maximum quality at minimum cost.

Intuitively, this can be thought of as the effectiveness of the process in reducing performance,

cost, and schedule uncertainty (Browning, 1998; Browning, 2001; Deyst, 2001). In product

16

development, considering process value allows improvement even when the ultimate impact

on product value cannot be determined.

2) The value creation framework of Chapter 5. Its decomposition of the process into the

elements of tasks, resources, environment, and management aids the visualizing and

understanding value in complex processes. This understanding can in turn be used to assist

in resource allocation, process measurement, and process improvement.

3) Analysis of industry work breakdown structures (WBS’s). This analysis reveals that 85% of

tasks, as specified by the WBS, contribute to customer value via design, development, and

risk reduction activities. The WBS’s show great variety in product development processes,

illustrating the difficulty of defining a product development process at any but the highest

level. Most of the tasks in high-level WBS’s appear to contribute value directly to the

product; however, low-level (process) WBS’s show more supporting tasks. This supports the

idea (Browning, 1999) of analyzing product development at the lowest practical level.

4) A survey on communication. A high percentage of time in product development is spent on

communication-related activities (in comparison to isolated activities). This emphasizes the

importance of communication, particularly as it relates to process improvement. The survey

also showed that face-to-face or small group discussion is still the most effective means of

communication.

5) An analysis of four sets of task completion data. This showed that a rigorous approach to

managing the schedule (that is, earned value management) can reduce the number of tasks

behind schedule. This result suggests that it is possible to manage the timely completion of

product development tasks, leading to the realization of product value through an emphasis

on process value.

17

Chapter 2: The Lean Philosophy

This chapter introduces the lean philosophy, including its origin, its five basic principles, and

several results from implementation efforts. Companies have historically pursued many

activities to increase corporate profits, including process changes such as standardizing workflow

and reengineering initiatives. The common theme among these activities was usually cost

reduction. In the last two decades, however, a new concept, lean, has been introduced to the

industrialized world. Unlike previous attempts directed at cutting costs, lean is directed at

maximizing value (Browning, 2001). It is the philosophy of continuous improvement of

corporate processes to maximize value given limited resources. This perspective emphasizes

delivering customer satisfaction. Although lean applies to all processes, most implementation

efforts have been directed at manufacturing. More recently, these efforts have broadened to

include other areas, such as product development. This chapter presents a brief review of lean

that includes several insights that apply to the study of value in product development.

2.1 Origins of Lean

Two decades ago, the U.S. automobile industry faced a crisis due to Japanese competition.

Japanese cars typically required half the effort to design and manufacture, yet contained fewer

than half the number of defects. U.S. executives maintained that this quality was specific to the

Japanese culture and could not be replicated in the U.S. However, a comprehensive survey of

automobile firms by Womack, Jones, and Roos (1990) changed that belief. Their book, The

Machine that Changed the World, brought to light a new method for product design and

manufacturing. This philosophy, later termed lean production, emphasizes flexibility and

customer value, rather than the batch and queue process of mass production. The method

originates at the heart of the Toyota Production System, which continues to be "hailed as the

source of Toyota's outstanding performance as a manufacturer" (Spear and Bowen, 1999).

The crisis of high costs and poor performance of U.S. automakers in the early 1980s led directly

to their desire to adopt lean practices. A few years later, the aerospace industry faced a crisis

with the end of the cold war and similarly pursued lean practices. As these two sectors of the

18

economy strove to develop lean practices, it was quickly realized that the Toyota Production

System was not easily duplicated (Spear and Bowen, 1999). The system was not just composed

of tools and practices, but of a fundamental philosophy that made it enormously flexible and

adaptable. Womack and Jones (1996) explored this philosophy in their second book, Lean

Thinking, which discussed five key principles.

2.2 Lean Principles

In Lean Thinking, Womack and Jones (1996) proposed five central ideas to describe lean. These

principles are (i) specify value, (ii) identify the value stream, (iii) create continuous flow, (iv)

organize customer pull, and (v) pursue perfection. These principles are central to establishing a

lean enterprise and, in several instances, have been adopted verbatim by leading aerospace firms

as tactics for implementing lean.

2.2.1 Specify Value

The first lean principle is to precisely specify value. Womack and Jones (1996) define value as

"a capability provided to a customer at the right time at an appropriate price, as defined in each

case by the customer." This definition is useful for applications where the final product is

explicitly defined, such as manufacturing. For product development, however, it is less helpful.

In practice, lean assessments of product development tend to fall back on ad hoc

characterizations concerning which activities add value. Although simple applications of this

lean principle can often root out obvious wastes found in most product development processes,

optimization of the processes cannot be achieved without a more specific definition of value.

This idea is a primary motivation for this research on value in product development.

As applied to product development, the first principle highlights an important conclusion. An

innovative environment requires two types of value: product value as described by Womack and

Jones (1996) and process value, which is largely untouched in value literature. The difference

between these types of value is illustrated in Figure 2.1.

19

Lifecycle Activities

Market Introduction

Decreasing Uncertaintyin Product Development

Estimated

Actual

Process Value

Product Value

Figure 2.1: Product versus Process Value in Product Development

Figure 2.1 shows product value as the estimated and later actual value of the product as it

progresses through product development and into production. When Womack and Jones define

value as "a capability," they are defining the value of the physical product. In production, this is

an appropriate definition as little doubt exists. In contrast, product development (as discussed in

Chapter 3) embodies enormous uncertainty.1 The product development process decreases this

uncertainty, which leads to a definition of process value as the decreasing uncertainty that

activities provide.

Process value and product value are thus not necessarily correlated. A good process that

efficiently reduces uncertainty will not always achieve the program objectives. An example of

this is the Iridium satellite constellation. Despite using modern processes and arriving on

schedule and under budget, it drove its parent company into bankruptcy due to an insufficient

customer base. This uncertainty in product value has prompted some industry experts (e.g.,

Reinertsen, 1997) to caution against a specific set of best practices.

1 Uncertainty, as defined here, is the variance in performance, cost, and schedule of the expected product.

20

2.2.2 Identify the Value Stream

The value of a product is determined through a sequence of actions that eventually delivers the

product to the customer. This sequence forms the value stream, which the Lean Aerospace

Initiative (1999) has characterized as "the sum of the specific actions performed on a product to

carry it from raw material state into the hands of the customer." Womack and Jones (1996) point

out that the concept of a value stream is slightly different than the value chain, originally

introduced by Porter (1980), who emphasizes shorter sequences of activities designed to fulfill

near-term objectives. Identifying and evaluating the value stream has proven useful to industry

(Millard, 2001). Millard describes value stream analysis and mapping (VSA/M) as the

understanding and improvement of business processes using illustrations to show the product

flow towards a final outcome.

The primary benefit of VSA/M lies in its ability to arrange the process into specific, sequential

actions that can be analyzed and improved. Since an understanding of value creation is at the

heart of this improvement, it follows that the creation of value must also be decomposed to the

level of actions.

2.2.3 Create Continuous Flow

Once the value stream has been identified, the process of continuous flow can be introduced.

Continuous flow, as characterized by one industry site, is "the progressive achievement of tasks

that transform (with no stoppages, backflows, or unnecessary work) relatively raw material or

information into a customer desired product or service." Henry Ford introduced this idea in

1913, when he switched to continuous flow for the Model T and successfully reduced the

assembly effort by 90% (Womack and Jones, 1996). Womack and Jones use Ford's example to

state that "tasks can almost always be accomplished much more efficiently and accurately when

the product is worked on continuously." Moreover, they suggest that getting value to flow faster

"exposes hidden waste in the value stream." The concept of continuous flow may be applied in

all phases of the product lifecycle. Unfortunately, this concept has not yet been introduced in

many areas of industry. For example, McManus and Harmon (2001) have reported that 62% of

the product development tasks they examined were found to be idle at any given time in a

21

detailed member study. This statistic is in line with their other findings from kaizen events that

show 50 to 90% idle time.

Continuous flow is probably the most important aspect of value creation. Assuming that product

development follows the historical path of production, continuous flow represents the next major

leap in process improvement. Organizations that successfully implement continuous flow in

design, development, and testing activities will obtain large reductions in time and cost. Thus,

an effective definition of value should embrace the concept of continuous flow.

2.2.4 Organize Customer Pull

The fourth principle is pull, which "is a system of cascading instructions from a downstream

customer to upstream in which nothing is produced by the upstream supplier until the

downstream customer signals a need" (Womack and Jones, 1996). Sales forecasts do not drive

production and instead products are produced as customers signal their desire. This lets

customers pull what they need rather than providers pushing unwanted products.

To apply pull, Toyota created an information and production control system (Cochran, 2000). At

the heart of the system are kanban cards that signal what to produce and when to produce it.

These cards control the pace and level of production, eliminating run size delay in

manufacturing. In product development, the cards are sometimes used to signal the need for

specific information. This concept has not generally been applied in the aerospace industry,

where product development is far from achieving the level of customer pull found in Toyota

(McManus and Harmon, 2001).

2.2.5 Pursue Perfection

The final step in achieving a lean enterprise is pursuing perfection. Pursuing perfection implies

process improvement is never done and increases in efficiency can be achieved repeatedly. For

example, industry has successfully increased efficiency in some processes by upwards of 30%

each time they revisit a process (Womack and Jones, 1996). Womack and Jones also argue that

transparency, or unrestrained access to data, is the most important aid to perfection and that it

creates an environment where it is easy to discover better ways to create value.

22

2.3 Examples of Lean Implementation

Womack, Jones, and Roos (1990) originally presented a few illustrations of lean implementation

from a small number of industry sectors. Since then, there have been many successful

applications of lean, particularly in the production of durable goods. The results of these efforts

have rippled through the economy, motivating Postrel (2001) to write that lean is responsible

"for most of the dampening of the business cycle" experienced in the last decade.

Examples in manufacturing include the Ford Motor Company, which is realizing "major

improvements to culture, cost and order to delivery time" at its Chicago assembly plant by using

new infrastructure and value stream mapping tools (Fowler, 2001). The Department of Defense

invested $96 million in several lean projects and has documented a two to one return (LAI,

1999). The improvements have included a 50% reduction in microwave power module (MPM)

costs, 40% reduction in AMRAAM missile cycle time, and an $18 million price reduction on the

C-17 main landing gear pod and cargo door. Other examples include a turnaround of a

Lockheed Martin facility in Georgia that was credited, in part, to the use of lean initiatives

(Squeo, 2000), and a European plant in Augsburg that has now been designated a DASA Centre

of Excellence, following the implementation of lean engineering (Cook, 2000). The F-16

program also experienced substantial savings, including 50% less floor space and 60-80% less

cycle time with the use of lean (Lewis, Norris, & Warwick, 2000). These savings have even

expanded beyond the prime contractors. At Boeing, Wichita, a web-based customer pull system

"saved hundreds of millions of dollars" in reduced inventory ("Informed Innovation," 1999).

The success of lean manufacturing techniques has spurred the industry to introduce lean to the

product development phase as well. For example, Northrop Grumman has organized 24 lean

initiatives above the shop floor (Cool, 2001), which made a direct impact on "enhanced

competitiveness and financial performance." Perhaps one of the best examples is the F/A-18 E/F

aircraft (winner of the Collier Trophy), which was produced below cost, on-schedule, and with

comparatively superior performance (Cool, 2001). Although lean was not formally

implemented, Stanke (2001) has suggested that the program incorporated many aspects of a lean

enterprise in its development phase.

23

Despite these improvements, lean is not fully implemented. The Lean Aerospace Initiative

(1999) surveyed industry leaders regarding the extent of lean implementation in the aerospace

industry. The result showed that less than 50% of the activities in each business area had

participated in improvement efforts. In particular, lean implementation efforts had been

attempted in less than 20% of product development activities. Moreover, the majority of sites

interviewed believed that this improvement is only the tip of the iceberg. One reason for the

delayed application of lean is the difficulty in translating lean from the manufacturing

environment to the product development process.

2.4 Summary

The lean philosophy is not just a single-use "solution" to fix current corporate problems. Rather,

lean is a lifelong philosophy of increasing customer, employee, and shareholder value by more

efficiently producing products desired by the customer. At the heart of lean is an understanding

of the creation of value, which serves as a primary motivation for this research. Value is

traditionally considered to be the value of the product, but in product development, it is more

fruitful to consider the value of the process. Another insight into value creation comes from

VSA/M, where decomposition of the process into specific actions suggests that an effective

value methodology will similarly partition the process. There is also potential for continuous

flow to improve the product development process. Finally, this chapter illustrated that most of

lean success has been in production techniques, in contrast to product development where the

lean principles have been found difficult to implement.

24

Chapter 3: Product Development Overview

In considering value creation in product development, it is necessary to explore the product

development process in a rigorous fashion. This chapter is thus devoted to the product

development process, consisting of the preliminary design, detailed design, and test & evaluation

phases of the product lifecycle. The influence of product development on lifecycle cost is

discussed, and lean theory is found to be a useful process improvement framework. A primary

challenge in implementing lean is seen to be the difficulty in understanding value in the complex

environment of aerospace product development. This complexity exists on three levels

(product, process, and organization), which must be addressed simultaneously.

3.1 Introduction to the Product Lifecycle

The product lifecycle is the identification, development, and production of new products to fulfill

changing customer needs. The lifecycle is described in Table 3.1 from several academic and

industry sources. The table illustrates the three primary elements. Concept development is the

identification of customer needs and working with the customer to produce suitable design

requirements. Product development consists of the design and testing phases. Production is the

manufacturing of the product for delivery and support to the customer. Although these elements

are shared by most of the industry, some products are created in such limited quantities that the

production phase is unnecessary. In an organization visited, where this occurred, the use of lean

terminology was non-existent, demonstrating how lean has flowed from production into product

development.

Table 3.1 illustrates the definition of product development used in this research, which

emphasizes the preliminary design, detailed design, and test & evaluation phases of the product

lifecycle. This characterization was chosen because it highlights the period between the contract

with the customer and resulting build-to package. Since it is assumed that the most appropriate

product requirements have been chosen, this research addresses the challenge of satisfying the

specified requirements via the product development process.

25

Table 3.1: Definitions of the Product Lifecycle Process

Rosenau,

2000

Ulrich et al,

1995LAI, 1998 Site A, 20002 Site D, 20002 Site E, 20002 This

Research

Customer Needs

Analysis

Advanced

Studies

Define Mission

Requirements

Define Concepts

Co

nce

pt

Dev

elo

pm

ent

Fuzzy

Front End

Concept

Development

System

Definition

Customer

Needs

Develop Concept

Preliminary

Analysis

Concept

Development

System Level

Design

Preliminary

Design

Preliminary

Design

Perform Preliminary

Definition

[Product]

Definition

Preliminary

Design

Detailed

Design

Detailed

Design

Perform Detailed

Definition

Design Detailed

Design

Pro

du

ct D

evel

op

men

t Stages &

Gates

Testing and

Refinement

Fabrication,

Assembly,

Integration,

& Testing

Product

Development

Build First Test

Article

Development Test and

Evaluation

Pre-profit

Sales

Production Production

Pro

du

ctio

n

Continued

Sales

Production

Ramp-up

Production Production

Support

Operations

Support and

Operations

An organization (E) visited in the course of this research has described the product lifecycle as

the "categorization of everything that should be done to accomplish a project into distinct phases,

separated by control gates. Phase boundaries are defined so that they provide more-or-less

natural points for go/no-go decisions." Typically, at the end of each phase there is a review by

the organization to ensure the program is meeting performance, cost, and schedule objectives.

These reviews establish intermediate checkpoints through which all new products must proceed.

The Lean Aerospace Initiative (1998) further refined their framework as shown in Figure 3.1.

The pyramid is illustrative of the increasing information generated from the program. The

information flow is tracked, with each step using internal inputs (the outputs of previous steps)

and external inputs (constraints, common practices and standards, etc.) to produce a set of

products passed to the next level. Risks are also considered at each step in this model. Only the

2 The organizations visited are labeled A-F (see Chapter 6), and are not identified pursuant with LAI guidelines.

26

highest level of the model is shown, and its expanded version includes additional detail not

depicted here (LAI, 1998).

(Design Risk)

(Manufacturing Risk)

(Performance Risk)

(Operational Risk)

DetailDesign

Customer Requirements

ConstraintsStrategies Systems Requirements

ProgramAttributes Design To

Build To

Qual Design

DesignStandards

ProductionStandards Hardware

SystemDef’n

PreliminaryDesign

FAIT

Production

Time

Figure 3.1: Product Lifecycle Process (LAI, 1998)

For this research, six phases in the product lifecycle are considered, as described in the following

subsections. The phases selected are not a unique definition of the process. Rather, their

selection is intended to provide the greatest clarity to the reader. The lifecycle phases are (i)

concept development, (ii) preliminary design, (iii) detailed design, (iv) test & evaluation, (v)

production, and (vi) operations & support.

3.1.1 Concept Development

Concept development includes the initial identification of the customer needs and the conversion

of those needs into product requirements and specifications. For example, one organization (F)

that participated in this research is heavily involved in the conceptual development of military

aircraft and unmanned vehicles. They initiate the development effort by translating the needs of

the military into product specifications that can be used for design.

This phase of the product lifecycle process initiates the architecture of the "technical baseline."

The resolution of the technical baseline is increased throughout the development process to

include functional and performance specifications for hardware, software, information items, and

processes; interface requirements; specialty engineering requirements; verification requirements;

data packages, documentation and drawing trees; and application of engineering standards

(NASA, 1995). This structure provides the initial guidance for preliminary design.

27

3.1.2 Preliminary Design

In this phase, an assessment is made regarding the development and production of the product.

Some activities include the search for commercial-off-the-shelf (COTS) components, inclusion

of company standards, determination of make/buy decisions, acceptance and test strategy, and

use of trade studies. These activities, combined with the system requirements from the previous

phase, form the basis for several outputs, such as the systems requirements document, cost

targets, subsystem specifications, system interfaces, test plans, system concepts (mock-up

layouts), manufacturing concepts, and producibility assessment. These outputs are discussed at

the preliminary design review, before a "go/no-go" decision to continue on to the detailed design

phase (LAI, 1998).

3.1.3 Detailed Design

In the detailed design phase, the emphasis shifts from the decomposition of the product (as

evidenced by the numerous requirements documents of preliminary design) to creating the final

design. The primary elements of this phase include design, analysis, and simulations. These

activities result in a "build-to package", or BTP, which is presented at the critical design review.

The BTP typically includes the product definition, the manufacturing processes, and the logistics

plan, including safety, support, hazards, and maintainability (LAI, 1998). As illustrated in

Figure 3.1, fabrication, assembly, integration and testing (FAIT) is initiated concurrently with

this phase and runs as a parallel activity into production.

3.1.4 Test & Evaluation

The objective of this phase is to eliminate technical and manufacturing risks prior to high-rate

production. Test and evaluation involves the construction and evaluation of multiple pre-

production versions, or prototypes, of the product. Typically, there are two classes of prototypes.

Early (alpha) prototypes are designed using the intended materials, but flexible manufacturing

processes, and later (beta) prototypes are created using the correct materials and processes, but

with a different assembly scheme than the final product. The beta prototypes are generally used

to answer questions regarding performance and reliability (Ulrich and Eppinger, 1995).

Performance and reliability are major components of the development process. Industry

personnel have suggested that this phase accounts for "two thirds of the development cost." For

28

example, to qualify for extended twin-engine operations, the Boeing 777 flight-test program was

"the most extensive in Boeing history, a total of 7,400 hours" (Condit, 1996). Similarly, the

software code for a successful military aircraft had "2,140 requirements in the test plan and spent

nearly four years in testing," as described by an industry manager. In satellite development, the

system test and evaluation phase often surfaces major problems that require the developers to

change "fixed" parameters at a high cost and time delay. Once this phase is complete, the

product is ready for production.

3.1.5 Production

In the production phase, the product is manufactured and delivered. Depending on the

complexity of the production process, the delivery of products can increase continuously or via a

step function. For example, aircraft are typically produced in two stages: low-rate initial

production (LRIP) and high-rate production (HRP).

This phase realizes corporate and customer value, as production generates cash flow to sustain

operations. Rosenau (2000) emphasizes two phases of production separated by the break-even

point: pre-profit sales and continued sales. He proposes that the objective of new product

development is to advance as quickly as possible to the point of profitability.

3.1.6 Support and Operations

Involvement of the company rarely ends with product delivery, and there is usually a lengthy

period of time that involves the support and operation of the product. The product may require

rework, additional upgrades, or service as a result of operational wear. Given its extensive

product knowledge, the original equipment manufacturer (OEM) is generally involved in

providing these services to the customer. The additional commitment may continue for years, or

possibly decades. For instance, the B-52 has been operational for nearly fifty years, requiring

numerous service modifications (Hernandez, 1999). This period of support is generally the most

profitable for aerospace companies. For example, the Pratt & Whitney division of United

Technologies discounts its jet engines heavily, relying on the profits generated by providing

support and spare parts (Womack & Jones, 1996).

29

3.2 Importance of Product Development

The study of value in product development requires a clear definition of the product development

process. However, little consensus exists in current literature for a single definition. Ulrich and

Eppinger (1996) describe product development as "the set of activities beginning with the

perception of a market opportunity and ending in the production, sale and delivery of a product."

Other authors (see Table 3.1) regard product development separate from concept development or

production. NASA (1995) further refines this definition, as distinct from preliminary design

activities. This research will define product development as the preliminary design, detailed

design, and test & evaluation phases of the product lifecycle.

The product development process is fixed between two critical points: the product requirements

document at the end of conceptual development and the "build-to package" that has completed

the test & evaluation phase. This period is the transformation of customer requirements into a

set of instructions that allows for the production of the desired product. Figure 3.2 uses the

uncertainty3 in technical performance measures (TPMs) to illustrate this process. TPMs are

introduced with the program requirements document (A), and the uncertainty of their outcome is

eliminated with the finalized build-to package (B). This reduction in uncertainty may be

considered equivalent to value (Browning, 1998; Browning, 2001; Deyst, 2001).

ConceptDevelopment

PreliminaryDesign

DetailedDesign

Test &Evaluation Production

Support &Operations

A

B

Product Development

Figure 3.2: TPM Uncertainty in the Lifecycle Process

3 TPM uncertainty is the variance, or range, associated with the expected performance of the product.

30

The responsibility of product development to determine TPMs indicates its unique disposition

within the entire lifecycle. The reduction of uncertainty shown in Figure 3.2 corresponds with

the remaining leverage that management can exert. In other words, as the TPMs are defined,

management no longer has the ability to change them without incurring considerable increases in

cost and schedule. Furthermore, the definition of the TPMs commits nearly 80% of the lifecycle

cost, while incurring less than 15% of the cost (Fabrycky and Blanchard, 1991). This

relationship, illustrated in Figure 3.3, highlights the importance of product development.

ConceptDevelopment

PreliminaryDesign

DetailedDesign

Test &Evaluation

ProductionSupport &Operations

100

80

60

40

20

Remaining ManagementLeverage

Cost Incurred

Cost Committed

Figure 3.3: Lifecycle Cost Committed (adapted from Fabrycky and Blanchard, 1999)

The significance of Figure 3.3 is that value in product development must be examined as it

affects the entire lifecycle. Otherwise, a danger exists in sub-optimizing the process, leading to

undesired consequences in production where redesign is difficult. This observation suggests that

lean must be applied with an emphasis on downstream value, rather than immediate cost cutting.

In production, lean emphasizes the value of the product, as it is transformed from raw materials

into a finished good. The focus is on manufacturing, where lean principles such as flow, pull,

and perfection can be applied to a production-orientated value stream. This environment reduces

the need for communication beyond related manufacturing activities, which may explain why

communication is not explicitly included in the five principles of lean. When multiple phases are

considered, as in product development, it will be shown (in Section 3.4) that communication is

critical to the delivery of lifecycle value.

31

3.3 Complexity and the Three Dimensions of Product Development

The complexity of product development has been the greatest hurdle of most process

improvement methodologies. This complexity is based on the three dimensions of product

development: the product, process, and organizational architectures.4 For example, the

development of a modern aircraft involves tens of thousands of parts, thousands of tasks, and

thousands of individuals interrelated across different functional and corporate organizations

(Eppinger & Ulrich, 1995; Condit, 1996). Managing this complexity occurs through system

decomposition, as illustrated in Figure 3.4. "Complex systems are successively divided into

pieces that are less complex, until they are simple enough to be conquered" (NASA, 1995).

Figure 3.4: Managing Complexity to Create Value

In Section 2.2.1, the relationship between product and process value was discussed with the

suggestion that process value, not product value, should be the focus of improvement in product

development. This section adds a third dimension, organization, to the discussion of complexity

and value in product development.

4 Product, process, and organizational dimensions are based the "fundamental triangle of society problem solving"

by Warfield (1976) and the research of Browning (2001) and Eppinger (2001),

32

3.3.1 The Product

Product decomposition results in the product architecture, which is established during the

preliminary design phase. The method for categorizing the components varies with each

organization. A general portrayal is, respectively, system, subsystem, and component (Eppinger,

2001), although further categories are available, such as the system, segment, element,

subsystem, assembly, subassembly, and part (NASA, 1995). Selecting a specific product

architecture for a given product has far-reaching implications, affecting product performance,

product change, product variety, component standardization, and manufacturability (Ulrich and

Eppinger, 1996).

The problem of determining product architecture illustrates the conflict of product value versus

process value. Selecting the best product architecture represents product value. However, the

results of the decision will not be known until it is too late to select a different architecture.

Thus, process value, or selecting the best process, is emphasized in product development. The

difference between these methods occurs in the measurement of the results. In manufacturing,

the product is measured (following Six Sigma methodology), whereas in product development,

the process should be the basis for measuring value. This hypothesis contributes to the

framework of value creation in Chapter 5.

3.3.2 The Process

Process decomposition commonly leads to the work breakdown structure (WBS) that separates

into team-level activities and individual-level tasks. The WBS is similar to the product

architecture, except that it contains pieces of work necessary for program completion. Typically,

several related documents are linked to the WBS, such as the cost account structure, the

schedule, and the product requirements (NASA, 1995). The association of process architecture

with cost and schedule creates an ideal environment for measuring value. Thus, most lean

implementation efforts are directed towards development processes (McManus and Harmon,

2001), rather than the product or organization. Malone (2001) concurs with this proposition and

argues that "processes…are the key building blocks for inventing new organizations. We need to

give as much attention to managing the process as we have in the past to managing the

products." He goes on to suggest the creation of "process knowledge repositories" that are

33

consistent, user-friendly collections of knowledge about activities, their variations, and their

interrelationships. This idea is being pursued by several sites visited in the course of this

research.

3.3.3 The Organization

Until recently, aerospace companies were usually functional organizations, where employees

spent the majority of their time with coworkers who shared their engineering discipline.

Problems encountered included weak product teams and poor communication across disciplines.

A modern approach of product teams eliminates these problems, yet sacrifices the increased

knowledge shared by the entire discipline (Allen, 1977). This dilemma prompted the use of

matrix organizations (Trott, 1998) that characterize most of the aerospace industry. In matrix

organizations, employees divide their responsibility between their functional groups (such as

structures, aerodynamics, or quality assurance) and integrated product teams (IPTs). On a

complex program, such as the Boeing 777, there might be over 200 teams, involving multiple

phases of the product lifecycle (Condit, 1996).

IPTs are important to the study of value, because they represent the environment where distinct

functional groups agree on the product design and manufacturing plan. This agreement increases

the likelihood of reducing the uncertainty, or variance, of technical performance measures.

Thus, an effective process improvement methodology will most likely be applied within the

environment of the integrated product team.

3.4 Pervasive Communication in Product Development

"Effective communication is vital" was the phrase echoed unequivocally by all of the product

development sites visited. Clark and Fujimoto (1991) show that intense, bilateral communication

is critical for problem solving. Individuals must be able to effectively communicate within their

IPTs, their functional disciplines, across the organization, and with other organizations. Matrix

organizational structures and concurrent development require an even greater level of

communication. Allen (1977) and Bernstein (2000) studied this area extensively and

recommended a variety of methods to increase verbal communication as a means for enhancing

34

performance. The relationship Allen documented, between communication and performance,

suggests that increased communication will lead to increased value in product development.

3.4.1 Communication Architecture

Despite the need for communication, it is not easily integrated into the organizational

community, and it is probably the most rapidly changing area of product development and the

study of value. The advance of technology has made it possible to create high quality

information channels that contribute to increased value. Ulrich and Eppinger (1996) have

emphasized that these information channels are critical to fully understanding the design

constraints and the customer needs. For example, Ford Motor Company interactively links

designers in Turin, Italy and Dearborn, Michigan before expensive models must be constructed,

thus saving a great deal of time and money (Suris, 1996). Advances such as these have

promoted planned communication networks that link suppliers, developers, and customers,

providing clear value to the process. However, these networks are not always successful.

One industry site (A) studied communication flow across a product team and found broken

communication links (where only one person felt they were communicating with another) in

32% of the cases. In other instances, overly formalized communication architectures can

become so burdensome "that members of the team may try to circumvent the process" (NASA,

1995). This circumvention leads to emergent communication pathways, an otherwise helpful

phenomenon that increases with the co-location of IPTs (Allen, 1977).

3.4.2 Collaborative Design and Development

This research builds on the current lean principles and suggests that collaborative design and

development activity, augmented by co-location, is the heart of value creation in product

development. A number of researchers have extolled the benefits of collaborative teamwork.

Paulus and Yang (2000) have shown evidence that it enhances creativity and innovation. Their

result is consistent with the finding from the Lean Aerospace Initiative (1999) that "teaming

across multiple tiers of the supply chain early in the design process fostered innovation in

product architecture, resulting in significant quality improvements, 40-60% cost avoidance, and

25% reduction in cycle time." Similarly, Iansiti (1998) found the same result in the computer

35

industry that "in the most effective workstation and server projects, critical decisions were made

rapidly and jointly by a dedicated core business team…who met daily."

Collaboration involves the exchange of information, ideas, experiences, and insights, and it

occurs when the exchange is jointly undertaken and purposeful, with the expectation of mutually

beneficial results (Miles, 2000). An example of collaboration involves the design of the Boeing

777, as recounted by Boeing CEO Philip Condit:

An airline member of one team that was designing an electronics bay pointed out that the

light was positioned directly overhead. That seemed like a logical place for a light, to our

engineers. But the airline rep explained that when a maintenance person is actually

working in the bay, his head and shoulders block most of the light, making it very

difficult to see. So, we changed the design, and put two lights on the sides of the bay. A

small thing perhaps, but that kind of valuable customer insight was reflected in more than

1,000 design modifications to the 777. (Condit, 1996)

The result is that a great deal of communication is necessary to create the collaborative

environment illustrated above. Thus, communication must be a pervasive part of product

development, leading to the conclusion that it is an integral component of value.

3.5 Fundamental Metrics of the Product Development Process

The objective of aerospace firms is to create profits by delivering products desired by customers

at the right time and at an appropriate price. The success of product development is best

measured by shareholder return on investment (ROI), which may be considered equivalent to

shareholder value. As the final outcome measure, however, ROI responds very slowly to current

business strengths and weaknesses. For this reason, it is useful to have other, more timely

metrics, such as cost, cycle time, revenue, performance, resource utilization, etc. There are four

general types of metrics that are most recognized in product development: performance, cost,

schedule, and risk. Value in product development has historically been regarded as the

appropriate balance of these metrics. The majority of industry personnel interviewed identified

the first three of these metrics, and many included risk as well. This corresponds directly to

public and proprietary literature, which also addresses these metrics. For example, NASA

(1995) states that the objective of systems engineering is "to see to it that the system is designed,

36

built, and operated so that it accomplishes its purpose in the most cost-effective way possible,

considering cost, schedule, and risk."

3.5.1 Performance

For most of the 20th century, performance was the number one driver in aerospace product

development (Condit, 1996; Womack and Jones, 1996). Designs consistently attempted to fly

higher, faster, or farther. However, the time and cost necessary to achieve these performance

gains meant that other aspects of the product were compromised. For instance, the space shuttle

main engine is still rebuilt after each mission at a high cost and time delay. In the last decade,

the emphasis on performance has shifted to include more balance between performance,

schedule, and cost.

Performance is usually measured using technical performance measures (TPMs), also known as

product parameters. These parameters (such as weight, range, and lift-to-drag) should attempt to

completely describe the product, so that design alternatives may be objectively compared

(NASA, 1995). The data collected from TPMs are additionally tracked in a "requirements

watch-list," where the risk of not meeting the specifications is determined. Performance is

generally a difficult metric to use for value due to the variety and ambiguity of most TPMs.

Although a few deterministic cases exist (where an objective function can be applied), most

efforts at combining TPMs result in subjective, weighted ratios that lack the confidence of

program managers. Nevertheless, Figure 3.5 provides a notional view of performance value that

has been found useful in product development.

TPM-1

TPM-2

TPM-n

Performance Level

Figure 3.5: Product Performance via Technical Performance Measures

37

3.5.2 Cost

Performance may have been predominant in the past, but cost is now the decisive factor in most

development programs. For example, airlines have stated, "their number one priority is for

airplanes that are less expensive to own and operate" (Condit, 1996). Similarly, other programs,

such as the F-22, are experiencing "a war on costs" (Mushala, 2001). A criterion for long-term

success is becoming affordability, and industry is, as described by one program manager,

"actively searching for cost-cutting opportunities."

Cost is not a simple metric. NASA (1995) describes the system lifecycle cost as "the total direct,

indirect, recurring, nonrecurring, and other related costs incurred, or estimated to be incurred in

the design, development, production, operation, maintenance, support, and retirement over the

planned life span of a project." This definition spans multiple years and organizations, leading to

difficulty in its use to optimize lifecycle value. Furthermore, the large overhead costs that

accompany most aerospace firms preclude the use of cost as an effective measure for process

improvement. Instead, the program schedule has been found more practical, as it can be

associated more easily with individual tasks.

3.5.3 Schedule

The schedule (in the form of a work breakdown structure or integrated master schedule) is

typically required for product development, because activities need time for completion in a way

that respects their underlying time-precedence relationships (NASA, 1995). A schedule is

created by the program manager, who (i) identifies program objectives, (ii) constructs initial

plan, (iii) gathers additional opinions, (iv) revises, and (v) finalizes the plan. The program

manager rarely uses historical data, relying, instead, on the previous experience of the team.

Since the manager is responsible for the execution of the schedule, their objective is to include

sufficient schedule margin to ensure a predicted completion date. This objective is usually

balanced by a competitive interest or contract deadline introduced by the customer.

The schedule is also employed to monitor and control the product development process. The

duration of each task is compared against the schedule as a means for managing the process.

This methodology was imported from manufacturing, where value is equated to the control of

quality, cost, and time. Also from manufacturing, cycle time (or the time for a single product to

38

run through a process) is being used with greater frequency to manage process improvement. On

several site visits, it was common for corporate management to initiate a process improvement

activity by starting with an objective of a 20 to 50% reduction in cycle time.

3.5.4 Risk

Risk is not generally regarded in the same category as the previous metrics. Since risk is the

unknown variability of an expected outcome, it is considered to be a property of performance,

cost, and schedule. However, because of the primary role it plays in product development, it is

usually segregated. In the product development context, risk denotes a combination of the

likelihood and consequence of an undesired event (NASA, 1995), and it generally exists in the

forms of technical, cost, schedule, technology, market, and business risk (Browning, 1998;

Browning, 1999).

Either formally or informally, risk is considered in some fashion on a product development

program. In a formal process, there is risk identification, analysis, mitigation, and tracking. This

process may require extensive resources and contingency plans. An informal process uses

significantly fewer resources, and it places more responsibility on engineers to recognize

potential pitfalls. In the study of value, risk has not been introduced until recently. Browning

(1998 and 2001) and Deyst (2001) have proposed that the reduction of risk can be used to

manage the product development program. They suggest an approach of tracking uncertainty to

evaluate product development success. For example, Figure 3.6 shows a high-level illustration

of how uncertainty may be used to illustrate failure and success. The objective is to determine

the likelihood of failure and eliminate the odds of it occurring through resource allocation.

Objective

SuccessFailure

Figure 3.6: Managing Performance, Cost, and Schedule Uncertainty

39

3.5.5 Balancing Performance, Cost, Schedule, and Risk

Best lifecycle value is achieved through a balance of performance, cost, schedule, and risk. This

statement was found to be the prevailing industry theory, from a series of site visits. The idea is

similar to the System Engineer's Dilemma:

To reduce cost at constant risk, performance must be reduced. To reduce risk at constant

cost, performance must be reduced. To reduce cost at constant performance, higher risks

must be accepted, and to reduce risk at constant performance, higher costs must be

accepted. (NASA, 1995)

However, findings by Iansiti (1998) in computer hardware development and Womack, Jones,

and Roos (1990) in the automobile industry conflict with this perception. Iansiti discovered that

"the speed of development is inversely proportional to the resources allocated." In other words,

hiring more engineers increases, rather than decreases, development time. Furthermore,

Womack, Jones, and Roos (1990), demonstrated, using Toyota versus General Motors as an

example, that performance, cost, schedule, and risk may be simultaneously improved in product

development. Thus, this research suggests that the industry perception of balance is incorrect

and could potentially hinder process improvement efforts.

3.6 Summary

The product development process is defined for this research as the preliminary design, detailed

design, and test & evaluation phases of the product lifecycle. It exerts considerable influence on

the lifecycle, since it commits 80% of the expected cost, while only incurring 15% (Fabrycky

and Blanchard, 1999). Thus, value creation in the product development process must be studied

in the context of the entire lifecycle. Rather than focusing on the individual steps of a value

stream, such as in manufacturing, value in product development rests on a complex web of

communication across functional and corporate organizations. This communication contributes

to value creation and leads to the collaborative design environment of the integrated product

team (Allen, 1977). Finally, the four fundamental metrics of value (performance, cost, schedule,

and risk) are considered (NASA, 1995).

40

Chapter 4: Value in Product Development

The previous chapters discussed the lean philosophy and product development. This chapter

pursues a more rigorous understanding of value. It presents some of the history on value in

philosophy, economics, and product development, and it discusses the many definitions and

some specific tools that, in a sense, quantify value. The objective is to present a suitable

foundation for value that is used in the conceptual framework of Chapter 5.

4.1 Why is Value Important?

Many researchers have explored the topic of value because of its importance across many fields.

In engineering, a primary objective is to improve on the current state, or create additional value.

To add value, it is first necessary to understand it, which is why Womack and Jones (1996) list

the specification of value as the first principle of lean engineering. This principle has proven

beneficial in manufacturing, where it has been helpful in identifying the overall effectiveness and

efficiency of activities (Deyst, 2001). In product development, value is similarly sought after,

although the search has been more difficult. The Lean Aerospace Initiative (1998) has stated that

"to properly measure the effectiveness of the product development process we must address the

‘value’ associated with product development activity at each step of the process." Similarly in

industry, managers from nearly all of the sites interviewed stated the need for some measure of

value. Industry members maintain that the identification and measurement of value serves three

main purposes in product development: resource allocation, process measurement, and process

improvement.

4.1.1 Resource Allocation

Resource allocation is the critical executive challenge (Rosenau, 2000). Currently, the process of

allocating limited resources typically occurs through verbal discussion, as seen during the

majority site visits. Team leads present their needs to a program board, which then decides

where to allocate remaining resources. Often, there is no follow-up of this process. Rather, a

"corporate memory" exists that tracks past performance. A precise definition of value would

allow for more objective decisions.

41

4.1.2 Process Measurement

Manufacturing often defines value as reduced cycle time and fewer defects. Using this approach,

manufacturers have had success in measuring current process performance. For example, a

baseline process measurement is usually obtained by determining the cycle time and the number

of defects produced. Unfortunately, product development lacks a similar understanding of value.

Measuring the baseline often reduces to measuring the cycle time, with little consideration given

to the quality of the process.

4.1.3 Process Improvement

Once a process has been measured, it is a candidate for process improvement. A precise

understanding of value would allow the comparison of several processes to determine where the

greatest potential for improvement lies. Once a process is identified, it can be given new tools or

reengineered to provide greater value. Thus, an understanding of value not only provides the

baseline for process improvement, but also the results.

4.2 What is Value?

The Oxford English Dictionary (1989) gives eight high-level definitions for value, each with

more specific definitions, providing a total of 22 distinct meanings. In the first of these

definitions, value is the "amount of some commodity, medium of exchange, etc., which is

considered to be an equivalent for something else; a fair or adequate equivalent or return." And,

the last definition given is in regards to painting, "due to proper effect or importance; relative

tone of color in each distinct section of a picture." These multiple definitions forewarn of the

complexity and subjectivity that obstruct a firm understanding of value. Loosely speaking,

however, value is a measure of worth or importance of something, with a more useful definition

being the topic of considerable debate.

Lloyd (1993) studied value extensively in a paper on government contracting. He found value to

be an ambiguous and "weak criterion by which to judge acquisition policy." His work provides

42

insight to the discussion of value in product development, along the themes of axiology5 and

economics. In axiology, Lloyd looked at value from classical until modern times (citing

philosophers such as Aristotle, Rescher, Mudge, Edel, Pareto, and Gauthier) and concluded that:

The results of axiology have…failed to produce a consistent, meaningful standard of

value on which to judge policy. To base policy on personal preferences (as much value

theory amounts to), is to continue regulating contracts as we have in the past, without any

change in substance. (Lloyd, 1993)

In economics, Lloyd considered the classical view based on utility value, a Marxist approach of

labor value, and the neoclassical perspective of market value. In particular, he emphasized the

idea from the Austrian school of economics that value is both subjective and objective.

Subjective value depends upon the possession of some good "to satisfy a want, provide some

gratification, afford some pleasure, or spare some pain." And, objective value signifies "the

capacity of a good to bring about some definite extrinsic result." His conclusion centered on the

value definitions of marginal utility and cost-benefit analyses, as shown below.

If marginal utility determines value, though, this naturally means that it all boils down to

whose perception, personal preferences, or utility are at stake, which is hardly a

meaningful standard for the development of acquisition policy…Measurement decisions

in cost-benefit analysis may clearly reflect subjective or ideological determinations.

Further, to include externalities and intangibles in the analysis means that their

assessment "may tend to have the status of highly subjective guesses." Our hope for

objective criteria in value theory in the form of cost-benefit analysis has thus proved

fruitless. (Lloyd, 1993)

As Smart (1966) noted, history "is strewn with wrecks of theories of value," leading to Lloyd's

final conclusion directed at acquisition policy that "one would be hard pressed to choose a less

helpful standard than value." Although this conclusion warns of the difficulty associated with

choosing a standard for value in product development, some success has been found in the study

of corporate value.

5 Axiology is the field of philosophical study that deals with the general theory of value. It has sought a unified

philosophy of value, but is generally regarded as unsuccessful (Lloyd, 1993).

43

Corporate value is important because it has promoted the measurement of value for individual

company products. Using general accounting practices, products are described by three

economic indicators: net present value (NPV), internal rate of return (IRR), and the break-even

point (B/E). These three concepts are illustrated using a cumulative cash flow chart (see Figure

4.1). The NPV is the sum of all of the discounted cash flows over a specified period. The IRR is

the expected rate of return from the investment. And, the B/E is the period of time required to

recoup the investment.

ProductDevelopment

Time

Break Even Point

Production, Support, and Operations

NPV

Investment

Figure 4.1: Cumulative Cash Flow of the Product Lifecycle

Figure 4.1 illustrates two aspects of the product development process. Although it directly

affects the shape of the entire lifecycle curve, it appears here as a liability. This chart might

suggest the reduction or containment of the initial investment because short-term realities are

often considered more important than long-term objectives.

In sum, the concept of value, at a detailed level, has eluded a useful definition, beyond that

proposed by Millard (2001) when he advised, "do what is good." Its prevailing subjectivity has

led to multiple definitions that rely primarily on the observer, rather than some objective

criterion. Still, some success has been found in economics, where the laws of supply and

demand have effectively determined corporate value. Corporate value has led to a type of

product value, where the measures of NPV, IRR, and B/E characterize the value of new

products. These measures generally consider product development to be a cost rather than a

44

value-added activity. Executives, however, recognize the importance of product development,

and their view has led to alternative characterizations of value in product development.

4.3 Value in Product Development

Previous sections have highlighted the challenge of value in product development. It is critical

to the lifecycle process, yet it is generally treated as a liability via general accounting practices.

This conflict has given rise to several alternative definitions for value in product development.

Table 4.1 lists definitions for value that have been proposed by academics and industry experts.

The value definitions span two primary movements: value engineering & analysis and lean

engineering. This is observed from the definitions as they originate with performance and cost,

grow to include schedule, and finally consider risk as the fundamental elements of value.

Additionally, the value definitions raise the issue of product versus process value. This

difference is best shown using the 1998 definitions given by Slack (a LAI research assistant) and

the LAI product development team. The former emphasizes the utility, importance, availability,

and cost of the product, whereas the latter stresses the process capability in contributing to the

form, fit, or function of the product. In the innovative environment of product development,

process value is deemed more useful.

4.3.1 Value Engineering and Value Analysis (VE/VA)

Several decades ago, the movement of value engineering and value analysis swept through the

product development process. The founder of value engineering, Larry Miles (1961), defined

value as the appropriate performance and cost. His insight was the result of working for General

Electric in World War II, where material shortages required the partial redesign of many

products. Miles found that the redesign effort forced developers to consider function, rather than

a priori beliefs on what was needed for the product. This change of emphasis surprisingly

improved the performance, at a lower cost, and prompted the rise of value engineering.

Kaufman (1985) advanced value engineering when he defined value as function divided by cost.

He noted that value as viewed by the producer equals function divided by cost, but as viewed by

the buyer means perceived benefits divided by price. Unfortunately, Kaufman was unable to

45

quantify function (Lloyd, 1993). In this regard, Keeney and Raiffa (1976) provided some help

with the multi-attribute utility theory (MAUT). MAUT decomposes a product into descriptive,

yet quantifiable attributes and uses utility theory to combine these attributes into a single

descriptive function of performance (NASA, 1995). Generally, however, MAUT has been

difficult to apply and suffers from a lack of confidence in the product development community.

Table 4.1: Value Definitions for Product Development

Source Value Definition

Miles, 1961 Value is the appropriate performance and cost.

Kaufman, 1985 Value is function divided by cost.

Shillito &

DeMarle, 1992

Value is the potential energy function representing the desire between people and products.

Womack &

Jones, 1996

Value is a capability provided to a customer at the right time at an appropriate price, as defined in

each case by the customer.

Slack, 1998 Value is a measurement of the worth of a specific product or service by a customer and is a

function of:

(1) Product’s usefulness in satisfying customer need

(2) Relative importance of the need being satisfied

(3) Availability of the product relative to when it is needed

(4) Cost of ownership to the customer

LAI, 1998 Value is anything that directly contributes to the “form, fit, or function” of the build-to package or

the buy-to Package

• Form: Information must be in concrete format, explicitly stored

• Fit: Information must be (seamlessly) useful to downstream processes

• Function: Information must satisfy end-user and downstream process needs with an

acceptable probability of working (risk)

Browning, 1998 [Value is] balancing performance, cost, and schedule appropriately through planning and control.

Deyst, 2001 Value is the amount by which risk is reduced per resource expended.

Stanke, 2001 [Value is] a system introduced at the right time and right price which delivers best value in mission

effectiveness, performance, affordability and sustainability and retains these advantages

throughout its life.

Site A Value is anything that enhances performance (form, fit, & function) as measured by cost,

schedule, and risk from the perspective of the customer, be they external and internal.

Site A "Value is a balance between performance, schedule, and cost."

Site C Value is a product design and manufacturing plan that enable the building and delivery to the

customer of a product that meets the form, fit, and function requirements that the customer wants.

Site D Value is the knowledge that adds form, fit, or function to the "design-to" package.

Site D "Value happens when all of the stakeholders agree."

Site F "Value is in the eye of the beholder. It must be tied to who is making that judgment and what the

alternative is."

46

A more recent work on value that arose from the value engineering movement is Value: Its

Measurement, Design, and Management, by Shillito and DeMarle (1992). In their book, they

compile a number of methods for using value in process improvement. They contend that:

The basis of value measurement is the ability to gauge the value of elements in a system

using subjective measurements of relative importance and costs...Assigning numerical

weights to the value of components in a product or service establishes their value and

uncovers areas where improvements are needed. (Shillito and DeMarle, 1992)

Once numerical values for importance and cost have been obtained, they are graphed in the

format of Figure 4.2. The relative importance is plotted against the relative cost. Shillito and

DeMarle, citing their earlier work, suggest the products (or product features) should have an

importance over cost ratio of one (such as B). Points lying above the line (A) should be

considered for additional resources, whereas points lying below the line (D) are targets for

process improvement initiatives. Tanaka (1973) extended the theory with the Optimum Value

Zone, shown in Figure 4.2. He proposes that activities close to the origin (C) are also areas of

considerable value.

Relative Cost

A

C

B

D

OptimumValue Zone

Figure 4.2: Measuring Value (Shillito and DeMarle, 1992; Tanaka, 1973)

Although Shillito and DeMarle emphasize this approach for measuring product value (consistent

with value engineering), the method is sufficiently general that the value of development tasks or

47

activities may also be ascertained in this fashion. This adaptation summarizes much of the value

engineering and value analysis movement. Its emphasis on product value generated several

useful methodologies and benefited specific areas of manufacturing, yet contributed less

effectively to the improvement of the product development process.

4.3.2 Lean Product Development

More recently, lean has been applied to product development in the aerospace industry. The five

principles of lean have previously been discussed, and this section will focus on the definition of

value within lean. Womack and Jones (1996) defined value as "a capability provided to a

customer at the right time at an appropriate price, as defined in each case by the customer." This

definition is product-centered and is more suitable for manufacturing than product development.

A better definition, for product development, is that value is "anything that directly contributes to

the 'form, fit, or function' of the build-to package or the buy-to package" (LAI, 1998). This

definition is useful because it provides a method for judging the value of the process. Another

process-centered definition is from Deyst (2001) that defines value as "the amount by which risk

is reduced per resource expended." These definitions have only been recently proposed, yet

industry has begun to use them in kaizens (or lean events).

4.4 Tools for Quantifying Value in Product Development

If value encompasses the elements of performance, cost, schedule, and risk, as suggested in

Section 3.5, then the quantification of value can be found in dozens of process- or management-

related tools. The significance of this idea is that all tools, regardless of their explicit association

with value, measure value in one form or another. For example, scheduling, risk mitigation, or

relational tools may all be identified with value. The product development process uses a

considerable number of such tools, of which over 30 were reviewed for this research. From this

list, eight were chosen as particularly relevant for the quantification of value (see Table 4.2).

The primary consideration in the selection of these tools was their ability to measure specific

intervals of the process, as this partitioning of the process is critical to the study of value

(Sobelman, 1958; Womack & Jones, 1996).

48

Table 4.2: Tools for Quantifying Value in Product Development

Reference6 Name Value Definition Metric(s)

Ulrich and

Eppinger, 1995

Gantt Chart Schedule Program completion (time)

Thompson and

Strickland, 1998

Critical Path Management

(CPM)

Schedule Duration of critical path

(time)

Thompson and

Strickland, 1998

Activity Based Costing (ABC) Cost Cost of activity ($)

Department of

the Air Force,

2000

Earned Value Management

System (EVMS)

Cost and schedule performance

to plan

Cost performance index &

schedule performance

index (ratios)

Steward, 1981 Design Structure Matrix (DSM) Structured communication Number and pattern of

interactions (#)

Davis, 2001 Balanced Scorecard Operational plan, customer

satisfaction, quality, people, etc.

Subjective indices (1-5 or

1-10)

Womack and

Jones, 1996;

Millard, 2001

Value Stream Analysis &

Mapping (VSA/M)

Direct value added to the

customer

Subjective (value-added,

required non-value-added,

or non-value-added

Browning, 2001;

Deyst, 2001

Risk Value Method or Risk

Value Model

Performance risk TPM uncertainty (ratio)

Probably the oldest and most commonly used process tool is the Gantt chart that aids in

scheduling multiple activities and tasks. Value is implicitly associated with a timely and

predictable schedule, usually measured in hours or days. If all other factors are assumed

constant, value increases as scheduling time decreases. This is usually a poor assumption,

however, as illustrated by the Systems Engineer's Dilemma discussed earlier (NASA, 1995).

The second methodology is a critical path management (CPM). It is similar to a Gantt chart,

although it emphasizes the sequence of activities "whose combined required times define the

minimum possible completion time for the entire set of tasks" (Ulrich & Eppinger, 1995). The

critical path associates value with the reduction of this minimum completion time. The benefit

of this tool is that it may often lead to immediate, short-term improvements in the process.

6 In the case of the Gantt chart, CPM, ABC, EVMS, and the balanced scorecard, the reference is not the original

source of the management tool.

49

Another common technique is activity based costing (ABC). This is an accounting practice used

to associate expenses with specific activities or tasks. Rather than divide costs between

personnel, software, overhead, etc., ABC links individual costs with the activities that created

them. Value, in this context, is correlated with cost, where the objective is to reduce the cost

associated with each activity.

The earned value management system (EVMS), as the fourth tool, has gained recently in industry

popularity. Programs such as the F/A-18 E/F, B-2, and THAAD have used EVMS for program

management. EVMS tracks cost and schedule performance to plan. Increasing value is

correlated with reaching milestones under the planned budget. The benefit of EVMS is that,

through rigorous control of the process, it surfaces problems before they lead to lengthy delays.

The next methodology is the Design Structure Matrix (DSM) (Steward, 1981). It maps the

relationships or channels of communication between tasks. DSM methodology describes the

product development process in an iterative manner. Browning (1998) extended DSM

methodology in his doctoral thesis to model the iteration of program schedule and cost. One

advantage of using DSMs is that they identify productive and non-productive communication

between system elements, tasks, and people, contributing to process improvement.

The sixth tool is the balanced scorecard that subjectively rates processes to ensure a balanced

approach to value. Scorecards are often used with slightly different sets of enterprise attributes.

For example, a division at Boeing uses the enterprise attributes of operational plan, customer

satisfaction, quality, and people (Davis, 2001). Each are rated subjectively on a 1-10 scale. The

result is a system that approximates value across a host of different tasks and functional

disciplines. The benefit of using the balanced scorecard is that it can successfully identify

diverse types of value.

Another methodology that uses a subjective approach is value stream analysis and mapping

(VSA/M). Womack and Jones (1996) proposed the idea that tasks may be categorized as value-

added (VA), required non-value-added (RNVA), or non-value-added (NVA). Using these labels,

VSA/M visually depicts the flow of information in product development, allowing the

restructuring of the process to facilitate the value contribution from tasks. Millard (2001) found

50

VSA/M to be an effective method for process improvement in product development. A principal

benefit of VSA/M is that it emphasizes direct value added to the customer.

Finally, the risk value method and risk value model are similar tools proposed, respectfully, by

Browning (2001) and Deyst (2001). The methods emphasize measuring value through the

reduction of risk. Essentially, successful product development is the procedure by which the

uncertainty (or the variance) of technical performance measures is eliminated in a planned and

systematic way (Browning, 1998; Browning, 2001; Deyst, 2001). The methods are ideal for

activities such as testing, where performance remains unchanged, but risk is significantly

reduced.

This research suggests that these methodologies provide a foundation for the quantification of

value. However, none capture the full complexity of value in product development, and few

express value in a fashion explicit enough to be used in process improvement efforts.

4.5 Summary

A review of value in the product development process suggests that a process-centered definition

of value is needed. For example, two useful definitions include “anything that directly

contributes to ‘form, fit, or function’ of the build-to package” (LAI, 1998) or “the amount by

which risk is reduced per resource expended” (Deyst, 2001). Additionally, it is important to

address value through detailed increments of the development process. Each increment of the

process (such as a task or subtask) should be considered as it affects communication,

performance, cost, schedule, and risk throughout the lifecycle. Although no current management

tool includes all of these traits, there are several tools that help forge a complete picture. Of

these, eight were examined in greater detail for their relationship to product development value.

A successful approach to maximizing value will include elements from each of these tools, while

maintaining an emphasis on delivering lifecycle value. These insights contribute to the value

creation framework of Chapter 5.

51

Chapter 5: Delivering Value in Product Development

This chapter integrates the ideas presented in the previous chapters into a conceptual framework

for the creation and delivery of value in product development, which is supported in the

remaining chapters.

5.1 Initial Observations

In this section, several observations are surfaced that are relevant to product development value.

Section 5.1.1 combines earlier insights into three principal themes and Section 5.1.2 considers

the best perspective for assessing value.

5.1.1 Considerations of Value

Chapters 2-4 surfaced the eight elements of value outlined in Table 5.1. They are related to three

distinct areas of product development, as shown in the table. Process value and decomposition

suggest focusing on the process architecture. Continuous flow, lifecycle perspective, and

communication advocate a collaborative environment. The use of management tools,

particularly those that treat schedule and technical risk, indicate that a management approach

must be part of a framework for value creation.

Table 5.1: Proposed Elements of Value

Value Should Consider the… Section(s) Themes

Process- Process, rather than the product 2.2.1, 3.3.1,

4.3.2, 5.1.2

Decomposition- Individual task level of the process architecture 2.2.2, 3.3.2

Process

Architecture

Continuous Flow- Continuous flow of information to produce the product 2.2.3

Lifecycle Perspective- Perspectives of all stakeholders and lifecycle phases 3.2

Communication- Role of communication in product development 3.4

Collaborative

Environment

Schedule- Task duration as a measure of value 3.5.3

Technical Risk- Reduction of uncertainty as a measure of value 3.5.4

Management- Capability of management tools to quantify value 4.4

Management

Approach

52

5.1.2 Perspective of Value

An important question regarding value is "who determines value?" Value is different in the eyes

of each stakeholder. Customers measure value through the performance and cost of the products

they receive. The shareholder considers value as the combined profits from all company

products. The government requires regulatory compliance, as a subset of the greater

environmental need for safety. Employees request fulfillment and stability. Finally, the

enterprise seeks to balance each of these perspectives, while maximizing shareholder value.

The idea of a process-centered value definition is helpful in this discussion. The pursuit of

process value suggests that the product (or customer value) is not the sole objective, and a larger

corporate perspective is needed. Value should be considered as it affects the product line, or even

all products, in contrast to one-time applications for specific products. Browning (2000) presents

a useful illustration:

The first version of a new, commercial aircraft does not maximize value to the customer.

The initial design contains many sub-optimal characteristics, including over-designed

elements such as the wings. However, the initial product can provide good enterprise

value by meeting customers’ near-term expectations while providing a platform upon

which to base product upgrades, such as stretched fuselage versions, etc. These upgrades

do a better job of maximizing value to particular customers. (Browning, 2000)

To expand this idea, maximizing value should maintain the perspective of enterprise value. For

example, selecting necessary software, building knowledge repositories, or allocating critical

resources should be done in context of the corporation rather than specific products. This idea

supports a process-centered definition of value, and it encourages a more helpful perspective of

value than is usually found at a detailed level of product development.

5.2 Conceptual Framework for Value Creation and Delivery

The ideas presented in Section 5.1 may be incorporated into a description of value creation.

Here, a conceptual framework is presented that illustrates the delivery of value in product

development (see Figure 5.1). It includes many of the principles previously discussed, including

the representation of process versus product value.

53

Task 1

Task 2

Task n

Resources

Resources

Info.

Info.

Info. Risk

Risk

Risk

Process Value

Product $$

Resources

Performance

Schedule

ProductValue

Cost

Figure 5.1: Conceptual Framework for Value Creation and Delivery

In Figure 5.1, product development tasks are shown creating information and reducing the risk of

the product. These tasks need internal inputs (from previous tasks) and external resources (such

as people and tools). The tasks contribute to the information package necessary to define the

design and/or contribute to lowering the risk to an acceptable level. Finally, the tasks pass

information to succeeding tasks.

This framework illustrates two types of value (also shown earlier in Figure 2.1). Process value is

created from the selection and coordination of resources and tasks. Regardless of the specific

product, an experienced, talented team is a valuable asset. Although this team may not always

achieve the customer objectives (representing product value), they will reduce the risk for the

enterprise and ascertain whether the objectives are attainable. In contrast, product value is a

measure of the product created, often described as a balance of performance, cost, and schedule.

The challenge for lean practitioners lies in determining how to maximize process value

throughout the development effort. Investigating process value, as mentioned earlier, requires

the study of the process architecture, environment, and management approach. Additionally,

resources should also be considered, given their contribution of preexisting value, flowing into

the process architecture.

54

5.3 Research Propositions

The framework presented in Figure 5.1, combined with the previous chapters, allows three

research propositions to be drawn. These propositions establish a structured approach for

maximizing process value.

(1) Value in product development is the approach of the enterprise in creating an

effective product for the customer, continuing profit for the shareholder, and lifetime

satisfaction for the employee. This view of value cannot be expressed by a single,

quantitative metric. Rather, value is embodied in a structured approach (or template)

that emphasizes a combination of qualitative and quantitative tools to maximize

overall process value.

The evidence supporting this proposition has been found throughout the research. Sections

2.2.1, 3.3, 3.5, 4.2, and 5.1 illustrate the complexity of product development and the need to

introduce a broader perspective. These sections also emphasize process value, which is

composed of such diverse areas as resources, tasks, and communication. It is unreasonable to

expect a single metric to measure each of these areas. However, Section 4.4 presents several

methodologies that have successfully quantified value in subsets of the product development

process. This success suggests that rather than the measurement of a single metric, value should

be more flexible, such as an approach to the development process (or set of lean principles).

(2) Despite the use of many tools for improving facets of the product development

process, a framework, or set of guidelines, does not exist for the creation of lean

design and development programs.

Until recently, most concerted efforts at process improvement were directed at the manufacturing

sector. Thus, familiar methodologies such as Six Sigma, statistical process control, and even the

lean principles were originally intended for preexisting, repetitive processes. These

methodologies are now transitioning to the environment of the product development process.

Often, the results are successful, as described in Section 2.3. For example, emphasis on value

has increased coordination with the customer, value stream mapping has eliminated some of the

waste, and continuous flow has increased concurrent development. However, the manufacturing

roots of these tools continue to provide a subtle bias, emphasizing the improvement of old and

55

repetitive processes. Furthermore, these tools often lack a direct association with communication

and iteration, two critical elements of the product development process (see Sections 3.2, 3.3,

and 3.4). For these reasons, a new set of guidelines is needed that provides the framework for

lean product development.

(3) A useful set of principles for product development includes four themes of value,

including the "right" tasks, resources, environment, and management approach.

These themes must be treated as distinct elements of value.

The proposed themes are suggested from the elements of value in Table 5.1 and the conceptual

framework in Figure 5.1. Tasks and resources are explicitly labeled in the picture and are

supported by sections describing process value (Sections 2.2.1, 3.3.1, 4.3, and 5.1.2). The

"right" environment is surfaced from the need for continuous flow (Section 2.2.3), a lifecycle

perspective (Section 3.2), and communication (Section 3.4). Finally, an effective management

approach should be employed that measures the outcomes of performance, cost, and schedule.

5.4 Extending the Framework for Value

Given the propositions of the previous section, the objective of this thesis is the exploration of a

framework for value creation, following the identification of tasks, resources, environment, and

management approach as the principal elements of value. The result of this work is the proposal

of a complete framework (see Figure 5.2), described in the remaining sections of this chapter,

and partial evidence for its validation is presented in Chapters 6 and 7. The framework provides

practitioners with a structure to pursue process improvement centered on process value, and the

evidence serves as an initial inquiry that provides some insight, but more importantly, acts as a

foundation on which to conduct further research.

56

• Desired requirements• Management reserves• Estimate & uncertainty

• Geographic location• Office layout

• Functional definition• Process definition• Reduction of risk

• Form of final output• Communication• Enabling other tasks

• Cost/schedule• Resource improvement

• Job satisfaction

• Proficiency• Diversity• Empowerment• Mentorship• Leadership

• Knowledge application• Information gathering

• Knowledge application• Information gathering• Other activities

• Technical work• Process-related work• Team building

Tasks Resources Environment Management

CustomerValue

IntermediaryValue

ShareholderValue

EmployeeValue

People

Tools

KnowledgeTime

Allocation

CommunicationEffectiveness

TeamOrganization

Performance

Create Facilitate Deliver

• Desired value• Management reserve• Estimate & uncertainty

• Desired value• Management reserve• Estimate & uncertainty

Cost

Schedule

Process Value Product Value

Figure 5.2: Framework for Delivering Value in Product Development

57

Three types of value are shown in the framework of Figure 5.2. The first column, under tasks,

represents the principal building blocks of value, usually specified via the process architecture or

work breakdown structure (WBS). Tasks contribute several types of value, as further explained

in this research, building ultimately to enterprise value. The next two columns, resources and

environment, facilitate the product development process. Although they do not, in the strictest

sense, create value, the resources and environment have a direct influence on the process.

Finally, the fourth column emphasizes the delivery of value. In other words, it is the successful

management of cost, schedule, and performance that leads to the satisfaction of the relevant

stakeholders.

The framework presented in Figure 5.2 is highly interdependent, as may be noticed by the

similarity of the subheadings. A given activity in product development will include aspects

across several categories. Thus, some themes consistently appear in the framework. For

instance, knowledge application (or design, analysis, testing activities) and information gathering

are common themes found in the framework. In the following subsections, the framework is

described in greater detail, setting the stage for the data collection in the next chapter. It should

also be mentioned that the framework evolved concurrently with the data collection and analysis.

5.4.1 Creating Value via the “Right” Tasks

An initial step of the product development process is the selection of the most appropriate tasks,

usually described in a process architecture or work breakdown structure. Currently, program

managers develop these documents based on their experience and consultation with a select

group of engineers. Occasionally, they will use a template to select tasks, adjusting it as

necessary for a particular program. This selection process provides an opportunity to instill the

use of value, as a guide for the allocation of resources.

Measuring the value of tasks, however, generally proves difficult, since tasks add value from a

variety of perspectives. Depending on the task, the customer, shareholder, employee or

government may see it as value-added. Furthermore, there is rarely a single metric that describes

the utility of the majority of tasks found in the work breakdown structure. Thus, the balanced

scorecard approach was chosen as the means for evaluating the diverse types of value provided

by product development tasks. Although the method is subjective (usually relying on a 1-5 or 1-

58

10 rating system), it has been used to successfully identify gaps in current programs. Following

this method, a list of value attributes was created to describe the value provided by product

development tasks (see Table 5.2). The attributes were chosen based on a perspective of value,

in which the enterprise balances the needs of the customer, shareholder, employee, and

government. In addition to these stakeholders, the intermediary was added as an important

element. Intermediaries are the successive tasks and/or employees that lead to the completed

objective (such as the build-to package). Their inclusion is necessary for studying value at a

detailed level of product development.

Table 5.2: Value Contribution of Tasks to Enterprise Value

Perspective Description Value Attribute: Task contributes to…

V1. Functional performance of end product

V2. Definition of processes to deliver productCustomer

The customer considers the build-to package to

be of primary importance. The BTP leads to the

production of a product that meets the customer

requirements at an affordable cost. V3. Reduction of risks and uncertainties

V4. Form of final output

V5. Facilitating communicationIntermediary

Intermediaries need the right information in a

useful format to enable the effective and efficient

completion of tasks.V6. Enabling other tasks

V7. Cost and/or schedule emphasis

Shareholder

Shareholders desire a high return on their

investment. At the task level, this is

accomplished via short-term cost/schedule

savings or long-term infrastructure improvement.V8. Learning or resource improvement

EmployeeEmployees regard job satisfaction as their

principal requirement.

V9. Employee job satisfaction

En

terp

rise

Val

ue

Government,

supplier, end-

users, etc.

The government, suppliers, end-users etc.

provide a host of additional needs that are often

implicitly considered in the perspectives above.

V10. Other

The proposed list of value attributes is defined in Table 5.3. The definitions cover several

classes of value, from direct contribution to the end product to employee satisfaction. The

definitions also attempt to capture aspects of what in lean terminology might be called

“necessary non-value-added” tasks, such as enabling tasks. Historically, the first three

categories, representing customer value, are the most important.

59

Table 5.3: Value Attributes of Product Development Tasks

Task Contributes to…7

V1. Functional Performance of End Product

The task affects the functionality of the end product delivered to the customer. It should contribute directly to either

the function or the form that affects the function. For example, related tasks include requirements specification,

design decisions, material/part/subsystem specification, etc. This definition also includes all aspects of design from

the initial draft to the final document.

V2. Definition of Processes to Deliver Product

The task directly affects the processes necessary to deliver the end product to the customer. It includes the design or

procurement of the tools and processes necessary for manufacturing, testing, certification and/or other downstream

processes, such as the creation of test procedures.

V3. Reduction of Risks and Uncertainties

The task contributes to eliminating the uncertainty in performance, cost, and/or schedule. Typically, tasks include the

analysis, fabrication, and testing of the product. However, other areas might include the testing of tools/production

processes, risk analysis, and cost/schedule management. Each of these areas helps to reduce uncertainty, leading

to the success (or in some cases failure) of the product.

V4. Form of Final Output

The task directly contributes to the final documentation given to the customer or manufacturer. This typically includes

the design of the materials, parts, subsystems, and systems. Additionally, the larger build-to package will include

instructions for the manufacture of the product.

V5. Facilitating Communication

The task aids necessary communication. This is usually exemplified by reviews or meetings, but may also include

discussion with other company or industry personnel. Related tasks pursue an objective of providing the necessary

information to all team members for the efficient design and development of the product.

V6. Enabling Other Tasks

The task is necessary for other tasks to proceed, although it does not directly contribute to the design, production, or

testing of the product. Examples include non-essential areas of management and documentation. For instance,

approvals and documentation outside of the build-to-package add indirect value.

V7. Cost and/or Schedule Emphasis

The task emphasizes cost and/or schedule, usually associated with reducing the cost or labor of the product. For

example, the use of Gantt charts, earned value management, or other management tools is applicable. Similarly,

tasks that focus on manufacturing or support costs are also relevant.

V8. Learning or Resource Improvement

The task contributes to the skill base necessary to do future work. This definition includes developing greater

knowledge, improving tools or processes, creating new technologies, and communicating this knowledge throughout

the team.

7 The definitions have been adapted from a set originally proposed by McManus (2000b).

60

V9. Employee Job Satisfaction

The task is interesting and enjoyable. It is considered a positive experience that increases the desire of the

employee to do similar tasks. This criterion is highly subjective and may only be determined by the person

responsible for completing the task.

V10. Other

Task performs a necessary or valuable function not covered in the above categories. Examples might include

contributions to work environment or environmental impact reduction, satisfying of regulatory or contractual

requirements, the following of existing processes, and other needs.

5.4.2 Facilitating Value Creation via the “Right” Resources

Once the necessary tasks have been selected, the next step is selecting the “right” resources to

effectively carry out the program. The importance of resources surfaced from more than 80

interviews conducted with industry members.8 In the majority of cases, engineers and managers

spoke of specific resources (such as people or tools) as the primary ingredients for successful

product development. The results from these interviews and a brief literature review are shown

in Table 5.4. Additionally, knowledge is important but often overlaps with people and tools. For

instance, tacit knowledge typically resides in people and explicit knowledge is found in tools.

Table 5.4: Value Contribution of Resources

Attribute Description

Proficiency Adequate training should ensure proficiency, despite a technologically evolving workplace

Diversity Opportunities should exist to develop diverse backgrounds across the product lifecycle

Empowerment Employees should have responsibility, accountability, and authority (RAA)

Mentorship Collaboration and guidance should be a leadership priority

Peo

ple

Leadership Key positions should have the most appropriate people

Knowledge

Application

Efficient tools should be employed to directly apply knowledge in the creation of value

(such as CAD, CAM, etc.)

Kn

ow

led

ge

To

ols

Information

Gathering

Efficient tools should allow the swift access of tacit and explicit knowledge across the

extended enterprise

8 The research interviews and site visits are discussed in Section 6.2.

61

5.4.3 Facilitating Value Creation via the “Right” Environment

The third step of successful product development is creating the “right” environment. The

environment facilitates the delivery of value in product development by promoting effective

communication. In studying the environment, it can be partitioned into three areas: time

allocation, communication effectiveness, and team organization as shown in Table 5.5. Time

allocation is the percentage of time spent on value-added, enabling, and other activities. In

manufacturing, similar metrics have been kept where the time spent directly with the product has

been measured. Communication effectiveness looks at the role of different types of

communication to conduct technical, process-related, and team activities. Finally, the team

organization is an important consideration. Co-location is considered the most effective, but it is

sometimes difficult to employ in programs involving large numbers of people. Also important is

the office layout, which can help promote communication (Allen, 1977).

Table 5.5: Value Contribution of the Environment

Attribute Description

Knowledge ApplicationKnowledge application is the direct creation of value, such as in design, analysis,

or testing activities

Information GatheringInformation gathering is the enabling value that allows sufficient knowledge to

develop before being applied

Tim

e

Allo

cati

on

Other Activities Other activities are generally unrelated to the task at hand

Technical WorkTechnical work is the primary function of a job, as outlined by the job description,

and includes knowledge application and information gathering

Process Related WorkProcess related work is associated with the process side of a job, typically

consisting of suggestions or mandated changes on how a job is performed

Co

mm

un

icat

ion

Eff

ecti

ven

ess

Team BuildingTeam building relates to the social interaction necessary for a good working

environment

Geographic LocationGeographic location is the distance separating the team members and the

extended enterprise

Tea

m

Org

aniz

atio

n

Office LayoutOffice layout is the internal building configuration where the team is located,

including cubicles, meeting rooms, and other facilitating rooms

5.4.4 Delivering Value via the “Right” Management Approach

The final step of successful product development is selecting the “right” management approach.

This step, in particular, delivers the ultimate value to the customer through the management of

62

performance, cost, and schedule. Earlier, Section 3.5 reviewed these elements, suggesting that

the objective of the product development process is the successful reduction in uncertainty (or

estimated variance) of each element. As shown in Table 5.6, the process of uncertainty reduction

may be decomposed for each element into the (i) desired value, (ii) management reserve, and

(iii) ongoing estimate and uncertainty. The desired value is the initial goal of the product

development process, which will meet the cost, schedule, and performance requirements of the

customer or marketplace. Associated with this goal, there is usually a budgeted reserve should

the product fail a particular specification. This reserve allows greater flexibility to deliver a

successful product. Finally, the management approach should provide continual awareness of

the expected values (expressed as a range) of performance, cost, and schedule. By measuring the

uncertainty (or variance) of the expected outcome, resources may be allocated to eliminate the

risk of failure.

Table 5.6: Value Contribution of the Management Approach

Attribute Description

Desired Requirements Desired performance requirements describe the performance envelope desired by

the customer or marketplace

Management Reserves Management reserves for performance are the possible concessions that are

considered acceptable by the customer or marketplace

Per

form

ance

Estimates & Uncertainties Performance estimates and uncertainties are the ongoing estimates and ranges of

key parameters or technical performance measures (TPMs)

Desired Value Desired value for cost is the initial price which the customer or marketplace finds

acceptable

Management Reserve Management reserve for cost is the additional cost (beyond the desired value)

that may be born by the customer or marketplaceCo

st

Estimate & Uncertainty Cost estimate and uncertainty are the ongoing estimate and expected range of

the final cost

Desired Value Desired value for schedule is the initial delivery date which the customer or

marketplace finds acceptable

Management Reserve Management reserve for schedule is the additional time (beyond the desired

value) that is still considered acceptable

Sch

edu

le

Estimate & Uncertainty Schedule estimate and uncertainty are the ongoing estimate and expected range

of the final product delivery

63

5.5 Summary

This chapter presented a framework that describes the elements that contribute to value creation

in the product development process. It is suggested that tasks are the building blocks of value

and contribute multiple types of value to the stakeholders. The resources and environment

facilitate the creation and delivery of value by providing the knowledge, communication, and

necessary time to the process. Finally, the management approach delivers a product desired by

the customer with the right cost and at the right time. The traditional management metrics (that

is, performance, cost, and schedule) bridge the boundary between process value and product

value. The value framework presented in this chapter is used in the subsequent chapters as a

foundation for investigating specific aspects of value creation and delivery.

64

Chapter 6: Data Collection

The framework in Chapter 5 presents a broad decomposition of value in product development.

Fully testing and validating this framework is beyond the scope of the thesis. Instead, the

framework is presented as a representation of value that aids in the visualization and

understanding of value. This chapter illustrates the use of the framework as a guide for the

collection and presentation of data, with the outcome of increased understanding in a few

localized areas. The following sections review the scope of the data collected and the

methodologies used to collect it.

6.1 Scope of Data Collection

Several aspects of the framework were examined using eight methods of collecting data,

including a variety of interviews, surveys, and industry data (see Figure 6.1). With each set of

data, a specific objective was addressed, providing insight on an aspect of the development

process. For instance, the interviews with industry members surfaced the importance of resource

value, which was not originally considered as part of the framework. Similarly, the three case

studies (Appendix B) gathered anecdotal evidence on successful team environments. Several

types of surveys were used to obtain descriptive information concerning industry tasks, academic

tasks, communication, and technical uncertainty (Appendix D). The most detailed level of

information was found in collections of work breakdown structures and task completion data.

The data represent a broad cross-section of the aerospace industry, as shown in Figure 6.1. Four

aerospace companies (A-D) and two government organizations (E & F) contributed the majority

of the data. Additionally, data were taken from the doctoral research of Browning (G) (1998),

the previous experience of an advisor (H) (McManus, 2000a), and participating graduate students

at the Massachusetts Institute of Technology (I). The data represent more than 120 people, 15

programs, and three case studies. This participation is described in detail in the following

sections, where the notation followed is <organization-program.trial> for attributing the data.

For example, A-1.2 signifies Organization A, Program 1, and Trial 2. The checkmarks in Table

6.1 denote participation via the specified methods of data collection.

65

Tasks Resources Environment Management

• Desired requirements• Management reserve• Estimate & uncertainty

Performance

Process Value Product Value

1 15 work breakdown structures analyzed (1,600+ tasks)

2 46 surveys of industry tasks

3 110 surveys of academic research tasks

4 84 industry interviews of PD resources & brief literature review

5 59 surveys on time allocation and communication

6 3 brief case studies on the environments of successful teams

Insufficient surveysreceived for usefulanalysis

• Proficiency• Diversity• Empowerment• Mentorship• Leadership

People4

• Knowledge application• Information gathering

Tools 4

• Knowledge application• Information gathering• Other activities

TimeAllocation

5

• Technical work• Process-related work• Team building

CommunicationEffectiveness

5

• Geographic location• Office layout

TeamOrganization

6

• Functional definition• Process definition• Reduction of risk

CustomerValue

1,2,3

• Desired value• Management reserve• Estimate & uncertainty

Schedule

7

• Job satisfaction

EmployeeValue

2, 3

• Form of final output• Communication• Enabling other tasks

IntermediaryValue

1,2,3

• Cost/schedule• Resource improvement

ShareholderValue

1,2,3

Knowledge4

7 0 surveys on TPM estimates and uncertainty

8 4 teams, 235 tasks analyzed by schedule completion

• Desired value• Management reserve• Estimate & uncertainty

Cost

8

Figure 6.1: Data Collection Across the Framework

66

Table 6.1: Site Key for Data Collection

Method of Data Collection10

Org.Type of

OrganizationSites

Organization

- Team.Trial

Description of Program or

Detailed Process91 2 3 4 5 6 7 8

A-1 Subsystem Development √

A-2 Subsystem Development √ √

A-3 System Development √

A-4 Test & Evaluation √ √ √

A Commercial 1

A-5 Information Systems Support √

√ √

√

B-1 Engineering Change Process √ √

B-2.1 Engineering Redesign Proposal √ √

B-2.2 Engineering Redesign Proposal √

B-2.3 Engineering Redesign Proposal √

B-3 Software Development √

B-4 Subsystem Development √

B-5 Subsystem Development √

B Commercial 3

B-6 Subsystem Development

√ √

√

C-1 Technology Development √

C-2 Cost Estimation Process √C Commercial 3

C-3 Build-to Package Release Process √

√ √

D Commercial 1 D - √ √

E Government 2 E-1 Avionics Development √ √ √

F Government 2 F - √ √

G Commercial - G-1 System Development √ √ √

H - - H-1 Structural Analysis Process √ √ √ √

I-1.1 Graduate Research on Lean √

I-1.2 Graduate Research on Lean √

I-1.3 Graduate Research on Lean √

I-1.4 Graduate Research on Lean √

I-1.5 Graduate Research on Lean √

I MIT 1

I-2 Technical Graduate Research √

“12 Days of August,” F/A-18 E/F, Boeing √ √

Developing New Products, Jet Propulsion Laboratory, NASA √ √

Mission Control Center, Johnson Space Center, NASA √ √

9 The sources of data are differentiated between programs and processes (that is, breakdowns of tasks into subtasks).

10 Methods of data collection (1-8) follow the numbering of the previous page (Figure 6.1).

67

6.2 Methodology for Task Research

Within the proposed framework, tasks are considered the principal building blocks of value

creation, since they represent the physical design and creation of the product. Given this

proposition, the research addresses three key questions in regards to product development tasks.

Table 6.2 lists the key questions and the methodology for analyzing the data collected. The

results of this analysis are presented in Section 7.1.

Table 6.2: Methodology for Task Value

Key Questions Addressed11 Methodology

6.2.1 Initial work breakdown structures gathered from industry programs

6.2.2 Tasks separated into categories

Q1: What types of value do

tasks contribute?

6.2.3 Value attributes for tasks defined as part of the larger framework (Q1)

6.2.4 Programs assessed by lean penetration

6.2.5 Relationships proposed between tasks, value attributes, and program

assessment

Q2: How do task lists (or work

breakdown structures) differ

among programs and levels

of detail?6.2.6 Data analyzed to differentiate program work breakdown structures (Q2)

6.2.7 Surveys created to measure task value (see Appendix D)Q3: Can task value be

quantified in a useful fashion

(and, if so, how)?6.2.8 Resulting data from industry and academic teams analyzed (Q3)

6.2.1 Work Breakdown Structures Gathered

The work breakdown structures obtained from industry sites are listed in Table 6.3. The data

shown include type of program, average task duration, number of tasks, levels of hierarchy, and

lifecycle phase. In most cases, the programs include several hundred tasks, last from four

months to several years, and span preliminary and detailed design phases. Several detailed

processes are listed that have durations of only a few days. These processes add the most

specific tasks, or subtasks, of product development. Additionally, the work breakdown

structures provide the names (and sometimes descriptions) of hundreds of product development

tasks. Thus, the analysis presented is limited by the detail of the work breakdown structures

collected, which generally consist of one or two lines per task.

11 The questions addressed by the research were developed concurrently with the analysis of the data.

68

Table 6.3: List of Work Breakdown Structures Collected

Lifecycle Phase (1-5)12

SourceAverage Program or

Process Duration

Number of

Tasks

Levels of

Hierarchy Start End

A-1 - 304 3 ~ 2.3 ~ 5.0

A-2 256 days 55 2 ~ 2.5 ~ 4.3

A-3 889 days 1,603 5 ~ 2.5 ~ 5.0

A-4 204 days 106 2 ~ 4.2 ~ 5.0

A-5 101 days 51 2 - -

B-3 445 days 30 2 ~ 1.7 ~ 4.7

B-4 611 days 647 6 ~ 1.7 ~ 4.3

C-1 270 days 246 6 ~ 1.4 ~ 2.5

E-1 1,907 days 125 3 ~ 1.7 ~ 5.0

Pro

du

ct D

evel

op

men

t P

rog

ram

s

G-1 171 days 38 4 ~ 1.7 ~ 3.0

B-1 - 33 3 ~ 4.90 ~ 4.95

B-2 - 14 2 ~ 4.90 ~ 4.95

C-2 - 42 1 ~ 1.40 ~ 1.45

C-3 22 hours 34 1 ~ 3.90 ~ 3.95Det

aile

d

Pro

cess

es

H-1 - 13 1 ~ 3.50 ~ 3.55

6.2.2 Task Categories

Using the work breakdown structures, categories of tasks were created to represent the majority

of product development tasks. Following functional analysis theory proposed by Miles (1961),

verb-noun combinations were chosen to create a comprehensive set of categories for product

development tasks, including ten verbs and eleven nouns (see Section 7.1.1). Nearly all of the

tasks on the WBS’s were mapped into the resulting 110 task types.

6.2.3 Value Attributes

As discussed in Section 5.4.1, the value attributes from the framework were incorporated into the

analysis of product development tasks. The list of value attributes addresses the question of

12 Lifecycle phases include concept development (1), preliminary design (2), detailed design (3), test & evaluation

(4), and production (5).

69

“what types of value do tasks contribute?” It is proposed that tasks contribute ten possible types

of value, as discussed in the previous chapter.

6.2.4 Lean Penetration Assessment

Lean penetration, or the corporate knowledge of lean practices, is generally easier to determine

than whether an organization is lean. Since lean penetration often correlates with using lean

practices, a comparison is desired between lean penetration and work breakdown structures.

This comparison provides insight on how lean practices are reflected in WBS’s. To accomplish

this objective, the lean penetration of each program was rated as either high or low, based on (i)

industry recognition such as awards, accomplishments, and contracts, (ii) LAI literature

including theses and unpublished reports, and (iii) personal or advisor observations from visiting

and interviewing program personnel.

6.2.5 Relationships Between Tasks and Value Attributes

Using the structure of the previous subsections, relationships were defined to connect the task

categories and value attributes. The 110 types of tasks were then mapped to zero, one, or two of

the value attributes. This transformation was used to suggest the types of value contributed by

task descriptions in work breakdown structures.

6.2.6 Data Analysis

The resulting data (in Table 7.4) consist of a series of percentages, calculated using Equation 1,

that give the relative percentage contributed to each type of value (per program).

% =# of tasks with designated attribute

# of detailed tasks per program/process(1)

This information was used to draw a number of comparisons regarding the differences between

(i) programs and processes, (ii) levels of lean penetration, and (iii) aggregate levels of value (that

is, customer, shareholder, etc. categories). The results address the second question posed.

6.2.7 Quantifying Task Value

To address the third question, additional data were collected via task surveys from industry and

academic teams. The intent of the surveys was to determine whether the value generated by a

70

given task value can be quantified in a useful fashion. For this purpose, surveys were fashioned

in which employees or students rated the contribution to the various aspects of value made by

each task. The surveys were available online and evolved slightly over the course of the study

(see Appendix D). Using the surveys, employees could rate tasks according to the degree of

value contributed. The rating scale was 1-5, where five is a significant contribution, one is little

to no contribution, and N/A (or zero) signifies “not applicable.” Additionally, the amount of

direct effort (in hours) required by the task was collected, along with optional comments.

Twelve groups, listed in Table 6.4, participated in this segment of the research. These groups

included a portion of an earlier program (A-4), three of the earlier processes (B-1, B-2, and H-1),

a social science research group (I-1), and a technical research group (I-2).

Table 6.4: Survey Participants for Measuring Value of Tasks

Lifecycle Phase (1-5)Sources

Scheduled

Tasks

Tasks

Measured

Hours per

Task Start End

A-4 10 12 - ~ 4.2 ~ 5.0

B-1 33 413 0.6 ~ 4.90 ~ 4.95

B-2.1 14 713 2.2 ~ 4.90 ~ 4.95

B-2.2 14 513 1.7 ~ 4.90 ~ 4.95

B-2.3 14 513 1.3 ~ 4.90 ~ 4.95

Ind

ust

ry P

roce

sses

H-1 13 13 - ~ 3.50 ~ 3.55

I-1.1 - 34 2.3 ~ 1.5 ~ 2.1

I-1.2 - 26 6.5 ~ 1.5 ~ 2.1

I-1.3 - 10 4.7 ~ 1.5 ~ 2.1

I-1.4 - 20 8.3 ~ 1.5 ~ 2.1

I-1.5 - 15 5.5 ~ 1.5 ~ 2.1

Aca

dem

ic P

roce

sses

I-2 - 20 2.5 ~ 1.5 ~ 2.1

The academic research groups were employed in this study as a pilot group (see Appendix C).

Graduate student research is similar to product development, as a product (the thesis) is designed

and delivered to a customer (the university). There are, however, some differences. Research

13 Process subtasks cancelled midway through research study.

71

activity generally lacks a detailed structure, and a document similar to an industry WBS is

unavailable. Success is more difficult to measure in graduate research. Also, the attributes of

value are different. The attributes of Table 5.3 were replaced with a list of attributes relevant to

the completion of a graduate thesis. Nevertheless, academic research offers useful information

(specific to this study) for evaluating the product development process.

6.2.8 Data Analysis

The data from the industry and academic processes were analyzed following the work of Shillito

and DeMarle (1992) and Tananka (1973). They proposed that value could be measured by

graphing relative cost (or time in this case) against importance (measured using the attribute

rankings). Graphs of the academic data, using their technique, are shown in Section 7.1.

6.3 Methodology for Resources Research

No quantitative data were collected on the value of resources. Insights regarding resources

emerged from the site visits and literature review. Since resource value was a prevalent theme in

the site visits, the site visit interviews are described here. In a majority of cases, industry

members characterized specific people or software tools as critical elements for a successful

program. Table 6.5 shows the key questions and relevant methodology.

Table 6.5: Methodology for Resource Value

Key Questions Addressed Methodology

Q1: From an industry perspective,

what are the principal contributors of

value in product development?

6.3.1 Interviews, indirectly related to resource value, were

conducted across a broad cross-section of the aerospace

industry

Q2: How might this value be quantified

to enable process improvement?

6.3.2 Interview notes and literature search surfaced principal

elements and suggestions for quantification (Q1 and Q2)

72

6.3.1 Site Visits and Interviews

Table 6.6 summarizes the six organizations visited, including twelve sites and over eighty

engineers and managers.14 In each case, an introduction to the facility was provided, followed by

time with lean practitioners and product development teams. The interviews were primarily

exploratory, but they surfaced several predominant themes, including the importance of

resources (specifically software applications and people).

Table 6.6: Interviews Across Aerospace Product Development

Type of Organization Sites Visited People Interviewed

A Commercial 1 ~ 15

B Commercial 3 ~ 36

C Commercial 3 ~ 16

D Commercial 1 ~ 4

E Government 2 ~ 8

F Government 2 ~ 5

6.3.2 Interview Notes and Literature Review

To surface the principal elements of resource value, the combined notes from the site visits and

literature review were consulted. The framework for resource value was created from this

information. It is discussed in Section 7.2 and Appendix A.

6.4 Methodology for Environmental Research

Earlier (in Sections 2.2.3, 3.2, and 3.4), it was suggested that a collaborative environment is an

important element of value in product development. With this in mind, research was undertaken

to understand the value inherent in communication. Table 6.7 illustrates the key questions and

methodology relevant to this section of the research.

14 In addition to site visits, industry members were engaged at seminars and conferences.

73

Table 6.7: Methodology for Environmental Value

Key Questions Addressed Methodology

Q1: How much time is spent on communication

versus isolated work in product development?

6.4.1 Surveys created to measure communication time and

effectiveness

Q2: How effective do industry members

consider different forms of communication?

6.4.2 Resulting data from engineers and managers

analyzed (Q1 and Q2)

6.4.3 Brief case studies conducted on successful teamsQ3: What are the characteristics of the

environment of some successful product

development teams?6.4.4 Case study data combined to form suggestions for

the environment (Q3)

6.4.1 Communication Survey

The survey, shown in Appendix D, was created to address two principal questions regarding

communication in product development: (i) how much time is spent on various forms of

communication? and (ii) how effective are different forms of communication? The survey

requested the participants to estimate the amount of time spent on activities, such as meetings (of

assorted sizes), email, literature, etc. Additionally, the participants were asked to rate the

effectiveness of each form of communication. A summary of the survey participants is shown in

Table 6.8. Participants were from a pool of engineers and managers that (i) had been involved in

the initial site visits or (ii) active members of the NASA Academy Alumni Association.15

Table 6.8: Communication Survey Participants

Section of Survey Organizations16 Participants Engineers Managers

Time Allocation 10 46 23 23

Communication Effectiveness 14 56 30 26

6.4.2 Data Analysis

Despite the small sample size, surprising agreement was found for both time allocation and

communication effectiveness. The data were aggregated by whether participants were engineers

or managers. The averages, for time allocation and communication effectiveness, were

15 Members of this organization include engineers and managers in the aerospace industry.

16 Participants included members from the six sites visited and (to a lesser degree) from eight other organizations

74

compared for each type of communication. Additionally, all of the data was combined into a

single chart, which plotted relative cost against importance (or, in this case, time versus

effectiveness). The results showed statistically significant differences between engineers and

managers, as discussed in Section 7.3.

6.4.3 Case Studies on Successful Environments

Data were also gathered via three case studies of small industry teams. The teams were chosen

based on their previous success and the degree of readily available information. Data were

collected via a few interviews at each site (specific to this study for one of the site visits) and a

few public sources (see Table 6.9).

Table 6.9: Summary of Case Study Data

Brief Case Studies Days on Site Interviews Other Sources

“12 Days of August,” F/A-18 E/F, Boeing 2 6 2

Developing New Products, Jet Propulsion Laboratory, NASA 1 4 1

Mission Control Center, Johnson Space Center, NASA 1 3 2

6.4.4 Data Analysis

For each site, a brief description of the team and accomplishments was created (see Appendix

B). Attention was given to the type of environment of each team, and similarities were grouped

together and are presented in Section 7.3.

6.5 Methodology for Management Research

Typically, cost, schedule, and projected performance are tracked to manage the product

development process. Product development sites, however, place varying amounts of stress on

the desired metrics. It has been proposed (Browning, 1998; Browning, 2001; Deyst, 2001) that

the uncertainty of technical performance metrics could be used as an alternate metric. Table 6.10

reflects two questions regarding what type of management approach is most suitable for product

development.

75

Table 6.10: Methodology and Management Value

Key Questions Addressed Methodology

6.5.1 Industry data obtained on program task completion (using two

management approaches)

Q1: How effective is a traditional

management approach17 versus

a more stringent approach such

as earned value management?6.5.2 Subtask and task levels analyzed for success of management in

controlling tasks (Q1)

Q2: Is measuring technical

uncertainty a viable alternative

for managing programs.

6.5.3 Task survey created to measure the uncertainty of technical

performance measures (Q2)

6.5.1 Task Completion Data

Data on the completion of tasks were acquired from four sources. Teams A-2 and A-5

contributed data that included estimates of percent completion at intervals throughout the tasks,

and included final task completion times. These teams used a Gantt chart (similar to most

aerospace sites) to manage the program. The next two teams, B-5 and B-6, submitted task

completion data that was managed via the earned value management system. Table 6.11

presents a summary of the data.

Table 6.11: Sources of Data for Task Completion

Source Type of Data Tasks Management Approach

A-2 Mid-task and task completion 55 Gantt Chart

A-5 Mid-task and task completion 51 Gantt Chart

B-5 Task completion 109 Earned Value Management

B-6 Task completion 20 Earned Value management

6.5.2 Data Analysis

The data of Table 6.11 presents an opportunity to compare a Gantt chart approach with an earned

value management system. The results of this comparison are presented in Section 7.4 and

include a small amount of manufacturing data (Spear and Bowen, 1999) provided as a sharp

contrast to the product development data.

17 A traditional approach generally relies on a Gantt chart (or task deadlines) as the principal form of process control.

76

6.5.3 Technical Uncertainty Data

A survey (shown in Appendix D) was created to measure technical uncertainty by collecting the

mean, minimum, and maximum values of technical performance measures following product

development tasks. Considerable difficulty, however, was experienced in finding participants for

the study. From more than 15 teams visited, only one was willing to contribute to the research,

and even then, this team was unable to submit uncertainty estimates over the two months of the

study (see Table 6.12). This result, or lack of a result, suggests that managing programs via

technical uncertainty is difficult without a major discussion of the concepts and approach.

Table 6.12: Technical Uncertainty Data

Source Surveys Comments

A-4 0 Only one participant was found, despite visiting three organizations

(including more than 15 teams)

77

Chapter 7: Analysis and Results

This chapter provides the analysis and results of the research outlined in the previous chapter.

Following the structure of the proposed framework, it is separated into the areas of tasks,

resources, environment, and management. For each section, the results are stated, followed by

analysis and discussion.

7.1 Task Research

The results from an analysis of the value contributed by industry tasks are below.

1) An analysis of WBS’s showed a large variance in the types of value contributed,

suggesting the difficulty of any single approach to maximizing value.

2) The majority (85%) of WBS tasks defined at a high level contribute value directly,

whereas a finer decomposition of tasks revealed fewer value-added tasks (54%).

3) WBS’s from programs with greater lean penetration emphasize cost/schedule to a

greater extent than programs with less lean penetration.

4) Although some difficulty was experienced in obtaining an adequate amount of

industry data, a study of an academic population showed that assessments of task

value are useful for process improvement.

7.1.1 Analysis of Work Breakdown Structures

Generally, product development programs use work breakdown structures (WBS’s) to describe

the specific tasks that lead to the desired product. WBS’s gathered from several product

development teams are analyzed below.

Types of Industry Tasks

To determine the most common types of tasks in product development, a word analysis was

employed. The WBS’s were combined to form a single list of 3,353 items, including phases,

activities, tasks, and subtasks. This list was further refined into 2,233 unique words, of which 86

surfaced as the principal verbs and nouns of product development.18 Table 7.1 places these

words into 21 specific categories.

18 Separating words into verbs and nouns corresponds with functional analysis theory proposed by Miles (1961).

78

Table 7.1: Work Breakdown Structure Word Analysis

Category & Definition19 Synonyms Found20

Plan- To devise or project a course of action Plan, manage, control, schedule

Design- To fashion according to a plan Design, develop, prepare, establish, draft, define,

identify, create, estimate, draw, derive

Analyze- To study the factors of a situation or a

problem in detail, leading to a solution

Analyze, study, model, evaluate, consider

Update- To bring up to date Update, modify, upgrade, revise

Complete- To bring to entirety or perfection Finalize, complete, release, signoff, transport, submit

Fabricate- To construct Fabricate, machine, integrate, install, drill, cast, build

Test- To put to the test or proof Test, demonstrate, verify, perform, validate, experiment

Procure- To obtain by any means Procure, accept, receive, locate, contract, obtain, acquire

Document- To furnish documentary evidence of Report, document

Ver

bs

Review- To come together for a common purpose Review, meet

Requirements- Requisite conditions Requirements, rules, constraints

Architecture- A unifying form or structure Architecture, interface, ICD

Software- Computer programs Software

Material- The substances, parts, or goods of which

anything is composed or may be made

Material, part

Subsystems- Subordinate portions of a system Avionics, subsystem, nozzle, hardware, thruster, nose

System- An assemblage of objects united by some

form of regular interaction or interdependence

Assembly, system

Tools- Anything which serves as a means to an end Fixture, tools, equipment

Production- The manufacture of goods Manufacturing, production

Process- A series of actions or operations definitely

conducing to an end

Process, BTP, procedure, method

Cost- The outlay of money, time, labor, etc. Cost, schedule

No

un

s

Performance- The execution of the functions or

operations of a product

Safety, risk, performance, hazard

Using the categories, each task from the work breakdown structures was individually examined

and placed into the appropriate categories of Table 7.1. The results, shown in Table 7.2, are

listed in terms of percentage, calculated using Equation 1. To avoid the duplication of tasks,

19 Definitions are adapted from Webster’s New Collegiate Dictionary (1956 & 2001).

20 Words listed include all associated forms.

79

only detailed tasks (or those with no subtasks) were considered, which reduced the list to 77% of

the original tasks. Additionally, the average values are shown for processes and programs. The

results show significant variance, a characteristic of the product development process.

% =# of tasks with designated attribute

# of detailed tasks per program/process(1)

Table 7.2: Analysis of Work Breakdown Structures

Percentage of Tasks Found in Programs or Detailed Processes Average

Task

Categories

A-1

A-2

A-3

A-4

A-5

B-1

B-2

C-1

C-2

C-3

D-1

D-2

E-1

G-1

H-1

Pro

cess

es

Pro

gra

ms

Plan 4 0 - 0 4 0 0 15 0 3 4 2 0 0 0 1 3

Design 45 38 - 2 24 15 0 28 0 0 32 33 15 44 8 5 29

Analyze 25 25 - 32 18 22 8 25 33 38 4 15 14 63 46 30 25

Update 11 7 - 5 47 11 0 7 2 3 24 17 25 22 0 3 18

Complete 4 11 - 9 0 19 31 4 10 12 4 24 21 4 0 14 9

Fabricate 9 2 - 18 0 0 0 9 0 0 8 2 0 0 0 0 5

Test 6 2 - 18 4 0 0 11 0 0 24 2 5 0 0 0 8

Procure 3 9 - 6 10 0 0 1 17 9 0 7 0 0 15 8 4

Document 25 22 - 8 12 22 62 10 19 18 60 29 65 33 15 27 29

Review 14 2 - 4 0 7 15 5 12 0 32 5 13 11 23 12 10

Requirements 12 2 - 0 4 0 23 15 0 0 28 19 19 11 0 5 12

Architecture 22 2 - 0 2 0 0 15 0 0 36 5 25 41 0 0 16

Software 11 4 - 3 80 0 0 25 0 0 52 3 3 0 15 3 20

Material 8 5 - 6 2 0 0 7 0 0 0 7 0 7 0 0 5

Subsystems 31 51 - 23 12 26 15 28 0 0 0 20 37 48 92 27 28

System 3 0 - 28 0 0 0 2 0 0 16 6 12 26 0 0 10

Tools 6 11 - 18 0 0 0 16 0 0 0 7 3 7 0 0 8

Production 0 11 - 0 0 0 0 7 0 0 0 18 2 11 0 0 6

Process 12 18 - 11 4 74 62 7 2 94 8 21 10 4 0 46 11

Cost 2 15 - 0 4 0 0 12 69 0 20 6 0 11 0 14 8

Performance 9 11 - 6 0 0 0 14 0 0 16 22 21 37 38 8 15

Other 2 0 - 7 0 7 8 5 29 21 8 3 0 4 0 13 3

0 – 9% 10 – 19% 20 – 49% 50 – 100%

80

Tasks and Value Attributes

To characterize the relationships between task categories from the previous subsection and the

value attributes proposed in Chapter 5, Table 7.3 displays the proposed relationships, produced

by considering what categories of value from Table 5.3 would be generated by each of the 110

verb-noun pairs. For instance, designing the requirements or subsystems contributes directly to

the functional performance of the end product (V1). Similarly, testing the software or system is

analogous to reducing uncertainty (V3). One exception is employee job satisfaction (V9), where

the nature of the task offers little evidence for how the employee feels about a specific task.

Additionally, some of the tasks provide multiple types of value, such as design tasks contributing

to functional performance (V1) and learning (V8).

Table 7.3: Proposed Relationships between Task Categories and Value Attributes

Objects

Actions Req

uir

emen

ts

Arc

hit

ectu

re

So

ftw

are

Mat

eria

l

Su

bsy

stem

s

Sys

tem

To

ols

Pro

du

ctio

n

Pro

cess

Co

st

Per

form

ance

Plan V6 V6 V6 V6 V6 V6 V6 V6 V6 V3/V7 V3

Design V1/V8 V1/V8 V1/V8 V1/V8 V1/V8 V1/V8 V2/V8 V2/V8 V2/V8 V3/V7 V3/V8

Analyze V3 V3 V3 V3 V3 V3 V3 V3 V3 V3/V7 V3

Update V1 V1 V1 V1 V1 V1 V2 V2 V2 V3/V7 V3

Complete V1 V1 V1 V1 V1 V1 V2 V2 V2 V3/V7 V3

Fabricate - - V3 V3 V3 V3 V3 V3 - - -

Test - - V3/V8 V3/V8 V3/V8 V3/V8 V3/V8 V3/V8 - - -

Procure V1 V1 V1 V1 V1 V1 V2 V2 V2 - -

Document V6 V6 V4 V4 V4 V4 V6 V4 V6 V6 V6

Meet21 V5/V8 V5/V8 V5/V8 V5/V8 V5/V8 V5/V8 V5/V8 V5/V8 V5/V8 V5/V7 V5/V8

V1 Functional performance of end product V5 Facilitating communication

V2 Definition of processes to deliver product V6 Enabling other tasks

V3 Reduction of risks and uncertainties V7 Cost and schedule emphasis

V4 Form of final output V8 Learning or resource improvement

21 Although discussion often reduces risk, it is not included as a formal means of reducing risk and uncertainty.

81

The use of Table 7.3 allows reduction of the WBS’s to 10 categories for comparing and

contrasting programs and processes. The disadvantages include the coarseness of the resulting

reduced data and its binary nature, since no weighting is given for either the magnitude of value

contributed or the relative importance or duration of the task. The results are shown in Table 7.4,

separated by programs with lean penetration, programs without lean penetration, and processes.22

The averages are listed at the bottom of the chart.

Table 7.4: Value Contribution of Tasks from Programs and Processes

Percent of Program/Process Tasks with Given AttributePrograms and

Processes

Days per

Task V1 V2 V3 V4 V5 V6 V7 V8 V9 V10

C-1 - 30 15 54 5 5 10 11 42 - 5

D-1 2223 48 4 48 28 32 44 20 72 - 8

D-2 76 41 34 34 17 5 19 6 38 - 3

Pro

gra

ms

w/le

an P

en.

G-1 8 44 11 63 11 11 30 7 48 - 4

A-1 - 48 15 42 7 14 24 1 58 - 2

A-2 41 38 16 35 4 2 18 11 40 - 0

A-4 4 10 12 67 2 4 6 0 24 - 7

A-5 17 75 2 22 8 0 14 6 27 - 0

Pro

gra

ms

w/o

Lea

n P

enet

rati

on

E-1 59 46 14 32 33 13 50 0 33 - 0

C-2 - 0 0 45 0 12 19 50 2 - 29

H-1 - 15 0 46 15 23 15 0 31 - 0

C-3 123 0 24 38 0 0 21 0 0 - 21

B-1 - 4 41 22 7 7 15 0 22 - 7Pro

cess

es

B-2 223 0 31 8 15 15 46 0 15 - 8

Average 34 16 40 11 10 24 8 32 - 7

Standard Dev. ±29 ± 13 ± 16 ± 10 ± 9 ± 14 ± 13 ± 20 - ± 8

0 – 9% 10 – 19% 20 – 49% 50 – 100%

Table 7.4 displays the data from this analysis, including the number of days (or in some cases

hours) per task. An initial observation is the large number of design (V1), risk reduction (V3),

22 Lean penetration is discussed further in the following subsection.

23 Number represents working hours per task, rather than days per task, and is not included in the calculations.

82

and resource improvement (V8) tasks, followed closely by enabling tasks (V6). The data help to

give a sense of what activities are conducted in product development. For example, 34% of tasks

are related to product development (V1), whereas only 16% are process development (V2).

There is large variability in the data, shown by the high standard deviations.

Lean Penetration of Organizations and Teams

As an example of the type of comparisons that may be made, programs may be compared with

respect to varying degrees of lean penetration, where lean penetration is the corporate knowledge

of lean methods. An assessment of lean penetration is made for each program in Table 7.5,

based on (i) industry recognition such as awards, accomplishments, and contracts, (ii) LAI

literature including theses and unpublished reports, and (iii) personal or advisor observations

from visiting and interviewing program personnel. More specific evidence is not provided, since

the programs cannot be identified for proprietary reasons. The work breakdown structures were

not consulted to avoid bias.

Table 7.5: Assessment of Lean Penetration in Product Development

Program or

Process

Assessment of

Lean PenetrationSupporting Evidence

A-1 Low LAI literature, personal observation

A-2 Low LAI literature

A-3 Low LAI literature, personal observation

A-4 Low LAI literature, personal observation

A-5 Low Personal observation

B-1 Low Personal observation

B-2 Low Personal observation

C-1 High LAI literature

C-2 Low Personal observation

C-3 Low Personal observation

D-1 High Industry recognition, LAI literature, personal observation

D-2 High Industry recognition, LAI literature, personal observation

E-1 Low LAI literature, personal observation

G-1 High LAI literature

H-1 Low Advisor observation

83

Comparison of Value Attributes in Work Breakdown Structures

Table 7.6 presents a comparison of value attributes between programs and detailed processes.

The results are displayed at two levels, presented earlier in Table 5.2. At a high-level, the four

perspectives of customer, intermediary, shareholder, and other value are used, and at a lower

level, the individual value attributes (V1-V8) are shown. The results show considerable

heterogeneity, or diversity, illustrating the complexity of the product development process.

Thus, a single approach for addressing value would most likely be ineffective. There are,

however, some statistically significant pairs of data. For example, at a higher level (that is,

programs), there are more tasks (specified by WBS’s) that are in the category of creating

customer value, whereas at the process level there are more supporting or enabling (and possibly

wasteful) tasks. These data would validate similar notions posed by researchers, including

Browning (1999).

Table 7.6: Comparison of Programs and Detailed Processes

Customer Value Intermediary Value Shareholder Value Other

Programs 85 ± 4 35 ± 22 47 ± 18 3 ± 3

Detailed Processes 54 ± 12 36 ± 19 14 ± 13 13 ±11

V1 V2 V3 V4 V5 V6 V7 V8 V10

Programs 42 ±17 14 ± 9 44 ±15 13 ±11 9 ±10 24 ±15 7 ± 6 43 ±15 3 ± 3

Detailed Processes 4 ± 7 19 ±18 32 ±17 8 ± 8 12 ± 9 23 ±13 0 ± 0 14 ±13 13 ±11

Pairs of data points that are statistically significant (that is, one-tail t-test < 0.05)

Another comparison is shown in Table 7.7, where the results are depicted with respect to the

level of lean penetration. Of primary interest are the similarities and differences in the pairs of

data. Customer and intermediary value are similar, whereas shareholder value shows a

significant difference. At a more detailed level, the sole statistically significant difference is the

emphasis on cost and schedule (V7), suggesting that programs with greater knowledge of lean

include larger emphasis on cost and schedule performance in their work breakdown structures.

Examples of this cost/schedule prominence include time management activities, earned value

management meetings, and design for cost tasks.

84

Table 7.7: Comparison of High and Low Lean Penetration

Programs Customer Value Intermediary Value Shareholder Value Other

High Lean Penetration 87 ± 3 36 ± 18 58 ± 18 5 ± 2

Low Lean Penetration 85 ± 5 34 ± 26 39 ± 14 2 ± 3

V1 V2 V3 V4 V5 V6 V7 V8 V10

High Lean Penetration 41 ± 8 16 ±13 50 ±12 15 ±10 13 ±13 26 ±15 11 ± 6 50 ±15 5 ± 2

Low Lean Penetration 43 ±23 12 ± 6 39 ±17 11 ±13 6 ± 6 23 ±17 4 ± 5 36 ±13 2 ± 3

7.1.2 Analysis of Industry and Academic Surveys

The previous approach (Section 7.1) used the proposed attributes of value to review industry

work breakdown structures. This section employs more direct input from employees (via

surveys) to evaluate industry tasks. Industry and academic teams submitted surveys over the

course of several weeks, which measured value using a 1-5 rating system for each value

attribute, and then aggregated the results to generate suggestions for process improvement.

Industry Task Surveys

Forty-six surveys were collected from industry participants. The results are shown in reduced

form in Table 7.8. The scores (from 1-5) of how much each task contributed to each value

attribute were summed for all tasks in the process. The results were normalized such that a

100% score meant that the survey participants thought all the tasks contributed at the 5 level to

the value attribute in question.

There are several problems with the industry data, limiting the results. The high scores indicated

that the survey participants tended to give high assessments to most tasks. The participants were

allowed to assign multiple aspects of value to each task, which they clearly did. Even more

problematic, however, are the low number of surveys collected (~8 per process) and the lack of a

lean set of processes for comparison. Due to these problems from the industry data, the results

are of limited use, and an additional study was conducted on academic research teams.

85

Table 7.8: Value Contribution of Tasks from Industry Processes

Percent of Tasks with Given AttributeIndustry Processes

Hours

/ Task V1 V2 V3 V4 V5 V6 V7 V8 V9 V10

A-4 Portion of Rocket Testing - 73 82 73 60 3 75 33 53 45 0

B-1 Engineering Change 0.6 29 66 37 91 97 - 26 34 94 0

B-2.1 Engineering Redesign Proposal 2.2 20 60 40 100 100 - 24 52 92 0

B-2.2 Engineering Redesign Proposal 1.7 20 84 32 92 96 - 20 60 84 0

B-2.3 Engineering Redesign Proposal 1.3 3 0 18 17 37 83 2 12 54 0

H-1 Structural Analysis - 60 60 40 60 40 - 0 40 50 8

Average 1.4 34 59 40 70 62 79 17 42 70 1

Standard Deviation ±0.7 ±27 ±31 ±18 ±31 ±41 ±6 ±14 ±17 ±23 ±3

Academic Task Surveys

The academic research study was more successful in obtaining data (see Appendix C). The

preliminary results from 125 surveys are shown in Table 7.9. Collecting the data involved a

methodology similar to the one discussed earlier in the chapter, with differences noted.24 In

general, the tasks averaged five hours in length and were similar in scope, usually consisting of

literature reviews, meetings, presentations, and site visits. For these tasks, a different set of value

attributes was developed, as illustrated in Table 7.9.

The attributes may be partitioned into four categories, based on their values. The first four (S1,

S2, S3, & S4) represent contributions to creating the research framework of the student, and in

each case occur in approximately 30% of the tasks. The next two (S5 & S6) involve results,

following the development of a framework. Since the participants were first-year graduate

students, it is understandable that they would not yet have completed this section of the thesis.

The third section is the contribution to advisor and industry knowledge. These areas are similar

and most likely reflect a general feeling that something has been accomplished. Finally, student

satisfaction and knowledge are well correlated, suggesting that learning and satisfaction are

correlated.

24 See Appendix C for a summary of the methodology and results of the academic data.

86

Table 7.9: Value Contribution of Tasks from Academic Research

Percent of Tasks with Given Value AttributeAcademic Research Projects

Hours

/ Task S1 S2 S3 S4 S5 S6 S7 S8 S9 S10

I-1.1 Graduate Research on Lean 2.3 34 30 15 39 13 1 35 8 62 57

I-1.2 Graduate Research on Lean 6.5 44 28 35 42 27 5 32 19 45 51

I-1.3 Graduate Research on Lean 4.7 20 43 27 27 0 0 7 33 70 77

I-1.4 Graduate Research on Lean 8.3 28 23 18 5 15 20 23 2 42 42

I-1.5 Graduate Research on Lean 5.5 18 29 18 18 0 0 24 24 64 60

I-2 Technical Graduate Research 2.5 45 50 53 42 3 5 38 38 88 83

Average 5.0 32 34 28 29 10 5 27 21 62 62

Standard Deviation ±2.3 ±12 ±10 ±15 ±15 ±11 ±8 ±11 ±14 ±17 ±16

S1 Contribution to problem definition S6 Contribution to results

S2 Contribution to background S7 Contribution to advisor knowledge

S3 Contribution to discussion S8 Contribution to industry knowledge

S4 Contribution to framework or hypothesis S9 Contribution to student satisfaction

S5 Contribution to case study or experiment S10 Contribution to student knowledge

Shillito and DeMarle (1992) state that the importance of a task and the time contributed to it

should be proportional. As previously shown (in Figure 4.2), ideal tasks should lie near a 45-

degree slope within the optimum value zone (Tanaka, 1973). Thus, the data in Table 7.9 may be

grouped in distinct sets to determine which characteristics contribute the most value. One

example of this analysis is shown in Figure 7.1, which combines the data by the type of task.

The data are plotted by relative time (that is, the relative durations of the activities) versus

relative thesis contribution (which is the average contribution to S1 through S5 of each activity).

Figure 7.1 shows that most research tasks fall near the “optimal” line. The only two points that

lie outside the optimum value zone are focused meetings and literature reviews. These tasks

typically involve information gathering (the former through discussion and the latter through

reading). It would be more efficient for the student to gather information from discussion, but

this value does not account for the time of the other participants. The literature review, however,

involves more work, but does not require additional personnel. Thus, the graph successfully

87

identifies elements that could be improved. Also, most of the activities relate to information

gathering, whereas only one (model development) relates to direct, isolated research.

0%

5%

10%

15%

20%

25%

30%

35%

40%

0% 5% 10% 15% 20% 25% 30% 35% 40%

Time (% of total)

Val

ue

(% o

f to

tal)

Focused MeetingGeneral MeetingLit. ReviewModel Devel.PresentationSite VisitOther

High Value

Low Value

Relative Time

R2 = 0.63

Figure 7.1: Value versus Time (Type of Task)

The next graph, Figure 7.2, places the 125 tasks into groups centered on student satisfaction.

The three categories are no/slight enjoyment, moderate enjoyment, and high enjoyment. The

data were then analyzed using these categories via the same technique as Figure 7.3. The result

is a near perfect correlation (0.98) that runs almost perpendicular to the optimal value zone. In

other words, the tasks that provide value to the research process, proportionately to the amount

of time spent on them, also provide the greatest satisfaction to the students.

Although the data presented in Figure 7.2 are based on academic research, related information

may be found in industry. According to a company-wide Boeing survey, the leading desires by

employees are (#1) involvement in decisions and (#2) encouragement to come up with new and

better ways (“Mixed Results,” 2000). In lean terminology, these are equivalent to

empowerment, which is central to the lean philosophy. Several other factors, including job

security and pay, rank near last in the list of twelve employee desires. The industry statistics in

conjunction with Figure 7.2 suggest that a link may exist between value creation and employee

satisfaction.

88

R2 = 0.984

0%

5%

10%

15%

20%

25%

30%

35%

40%

45%

50%

0% 10% 20% 30% 40% 50%

Time (% of total)

Val

ue (

% o

f to

tal)

No/Slight EnjoymentModerate EnjoymentHigh Enjoyment

R2 = 0.98

High Value ~ High Enjoyment

Low Value ~ Low Enjoyment

Relative Time

Figure 7.2: Value versus Time (Student Satisfaction)

7.1.3 Discussion of Task Value

The percentage of tasks extracted from the WBS, addressing various aspects of value, differed

markedly from program to program and process to process (see Table 7.4). This supports the

idea that there is not a single definition of "the product development process" at anything but the

highest level.

On average, the tasks of program WBS's, defined at a relatively high level, appeared to

concentrate on designing the product, producing the product definition, or reducing product

uncertainty or risk (activities that are assumed to create direct value for the user). However,

when tasks were further decomposed (in the process WBS's), a larger percentage of the subtasks

fell into supporting and enabling categories. This illustrates a dilemma when considering task

value; that is, a high-level perspective will indicate that all tasks directly contribute value, while

a finer decomposition of the same process will reveal required non-value added, or even purely

wasteful activities.25 However, this fine decomposition comes at greater and greater effort, and

may reach a meaningless limit. For example, in one of the process studies, engineers were asked

how they followed the very detailed process WBS, and their response was that the very detailed

25 Browning (1999) proposed the existence of this relationship.

89

WBS list was not followed. For any given application, many of the tasks in the WBS were

clearly unnecessary, and thus the engineers wisely skipped them. Hence improvement efforts

focused on WBS's will fail to see waste if focused too high, and will be difficult and possibly

unconnected with real problems if focused too low.

The WBS’s of programs judged to be taking place in more lean environments showed more

supporting tasks, primarily those concerned with cost and schedule management than in

traditional environments. This is interpreted as reflecting a higher consciousness of the need to

explicitly deal with cost and schedule issues, and it may or may not reflect more actual effort in

those areas.

Attempts to directly gauge task value by surveys were mostly unsuccessful. The results from

industry were both insufficiently numerous and highly inconsistent. The pilot study performed

on students developing theses was more successful, identifying (at least relatively) higher and

lower value tasks; this indicates that this method may have some utility if broadly applied.

7.2 Resource Value

The research on resource value, in contrast to the quantitative results of the previous section, is

anecdotal and derived from a large pool of interviews. Thus, the value attributes, shown earlier

in Table 5.4, represent the principal result from this component of the research. A summary of

this research is presented below, and a detailed discussion of the attributes is presented in

Appendix A.

Resources in product development may be considered the people, tools, and knowledge that

translate raw information into a finished product. The value of these resources reflects many

factors that are difficult to quantify. For instance, organizational value may be described by the

attributes of proficiency, diversity, empowerment, mentorship, and leadership. These attributes

may seem to conflict, but as Toyota has shown, their successful development is critical to

achieving a lean organization. Similarly, tools are increasingly providing value to industry

programs by facilitating information gathering and improving knowledge application.

90

7.3 Research on Communication in the Environment

The third area of value in product development is the environment. The right environment is an

effective location and layout for promoting communication and continuous flow. Additionally,

the environment should provide access to other stakeholders, such as the manufacturer,

customer, and end-user. Two primary results emerge from a survey on communication and a

study of three successful product development teams.

1) Industry surveys suggest a high ratio (perhaps three to one) exists between

interpersonal and isolated activities.

2) Face-to-face and small group discussion continue to be the most effective forms of

communication, despite advances in technology.

The environment is a critical element of successful product development. As Miles (2000)

suggests, managers “must invest in the design of an organizational setting in which

collaboration-driven innovation can be sustained and its output exploited.” Allen (1977)

conducted extensive research on the relationship between performance, communication, and co-

location. He concluded that communication and performance are well-correlated, and co-

location increases communication substantially. The research conducted in this thesis seeks to

expand upon his work, as the product development environment has shifted considerably in the

last two decades.

7.3.1 Analysis of Communication Surveys

Surveys were collected that requested engineers and managers to assess the time spent on a

variety of communication modes and their effectiveness in contributing value to the program.

Time Allocation

In Table 7.10, time allocation data were collected that emphasizes the communication aspect of

product development. Fifty-nine surveys were obtained, of which 23 were from engineers and

23 were from managers in product development. The remaining thirteen surveys were from

manufacturing, operations, and business support and did not provide a statistically significant

sample size for comparison.

91

Table 7.10: Current Time Allocation in Product Development (in %)

Modes of Communication Total for Product

Development (n = 46)

Engineers (n = 23) Managers (n = 23)

Face-to-face 16.5 19.1 14.1

Meeting (with 2-5 people) 10.4 8.7 12.0

Meeting (with 6+ people) 7.7 5.4 9.8

Telephone 6.3 6.1 6.6

Teleconference 3.5 3.3 3.7

Voicemail 2.6 2.0 3.1

Instant Messenger 0.8 0.6 1.0

Memos 2.0 1.5 2.4

Email 15.7 13.8 17.4

Mail 0.7 0.2 1.1

Reading formal literature 3.1 2.8 3.4

Reading informal literature 3.3 2.3 4.2

Browsing the web 3.5 4.8 2.4

Network other than web 2.8 4.1 1.5

Other time26 20.9 26.2 16.3

Hours per week 47.4 hours 44.6 hours 50.2 hours

Highlighted boxes represent statistically significant differences (t-test < 0.05)

An immediate observation from Table 7.10 is the large percentage of time spent on

communication-related tasks for both engineers and managers (respectively, 73.8% and 83.7%).

The number is reasonable for managers, but surprising for engineers, as one might assume that

they would spend a greater percentage of their time on isolated tasks, such as design or analysis.

Communication Effectiveness

Communication is generally useful in providing information over three broad areas: technical

work, process related work, and team building. These areas are similar to the three dimensions

discussed in Section 3.3, following the work of Warfield (1976) and Eppinger (2001). The

26 This category was not explicitly included in the first few surveys, and six surveys were adjusted to include this

category.

92

definitions of these areas used in the survey are listed in Appendix D. Each mode of

communication was evaluated on a 1-3 scale (that is, not effective, effective, and very effective),

following the definitions provided. The results of the communication effectiveness survey are

shown in Figure 7.3.

1.0 1.5 2.0 2.5 3.0

Instant Messenger - 1.3

Mail - 1.3

Voicemail - 1.3

Memos - 1.7

Teleconference - 1.7

Internal/External Network - 1.8

Telephone - 1.8

Reading Literature - 1.9

Email - 2.0

Meeting (with 6+ people) - 2.0

Meeting (with 2-5 people) - 2.5

Face-to-face - 2.6

Effectiveness (1 = not effective, 2 = effective, 3 = highly effective)

Technical Work

Process Related

Team Building

Figure 7.3: Effectiveness of Communication Modes

The modes of communication are listed in decreasing order of their average effectiveness. For

example, face-to-face communication was rated the most effective form, with an average score

of 2.6 (or fairly effective). Similarly, meetings of two to five people were rated 2.5. However, a

93

large drop (from 2.5 to 2.0) occurred as meetings increased beyond five members. (This trend

follows intuition in that as the number of people increase, the effectiveness decreases.)

Figure 7.3 also shows how modes of communication vary in effectiveness depending on their

function. In general, unless all communication occurs in person, a variety of communication

forms will be required, each contributing different types of value. Furthermore, interpersonal

communication is a critical element. It provides much more effective technical and process

communication than the other forms, and it is the primary source of team building value. Thus,

an effective workplace should emphasize this type of communication over other forms.

Another analysis was conducted on how engineers and managers consider different forms of

communication useful. Table 7.11 illustrates differences between the engineering and

management view of effectiveness. For process-related work, engineers consider voicemail or

memos more effective, whereas managers believe large meetings are effective for their purposes.

This suggests that perhaps there should be less large meetings through greater use of voicemail

or memos. In terms of technical work, engineers consider online networks and formal literature

more effective than their management counterparts.

Table 7.11: Comparison of Communication Effectiveness for Engineers and Managers

Communication Mode Function Engineers (n = 23) Managers (n = 23) T-Test Value27

Voicemail Process Related 1.7 1.3 0.015

Memos Process Related 2.2 1.7 0.025

Meetings (6+ people) Process Related 1.7 2.1 0.026

Browsing web Technical Work 2.2 1.9 0.060

Face-to-face Team Building 2.3 2.6 0.072

Formal Literature Technical Work 2.6 2.3 0.074

Internal Network Technical Work 2.3 1.9 0.099

Using the time allocation data of the previous subsection and effectiveness data of this

subsection, a time versus value chart was constructed (see Figure 7.4). The chart uses Shillito

and DeMarle’s (1992) method to define areas for improvement. Figure 7.4 reveals the relative

27 T-test values of less than 0.05 represent statistical significance.

94

usefulness per time of various communication modes. The trend line shown provides the same

insight as the line proposed by Tanaka (1973); that is, activities above the line should be given

additional time, whereas activities below the line are targets for improvement. The trend line

suggests that more time should be allocated for face-to-face discussion and small group

meetings, and it targets email (and to some extent the telephone) for improvement.

R2 = 0.670

0%

2%

4%

6%

8%

10%

12%

14%

16%

18%

20%

0% 5% 10% 15% 20% 25% 30%

Time (% of total)

Val

ue (

% o

f to

tal)

Meeting (2-5)

Email Telephone

Face-to-Face

Figure 7.4: Time versus Value of Communication Modes

7.3.2 Brief Case Studies of Successful Industry Teams

To provide a broader perspective on the environment, three successful industry teams were

selected as instances where the environment has contributed to the successful completion of an

objective. The information presented here is publicly available, although site visits were

conducted to interview relevant personnel. The three teams include the F/A-18 E/F program

(Boeing), Developing New Products (DNP) Team (NASA), and Mission Control Center

(NASA).

The results are presented in Table 7.12, and a brief discussion of each is presented in Appendix

B. Although most product development programs lack the characteristics suggested, each of the

teams studied exhibit the majority of them. All three programs provided separation between

regular activities conducted in the individual office and the work at hand. The three programs

used a display screen to provide constant communication of the design to each team member.

95

Two of the programs used support staff to help locate necessary information, and two brought in

outside stakeholders for their perspective.

Table 7.12: Proposed Suggestions for the Product Development Environment

Characteristics of the Environment

“Tw

elve

Day

s o

f

Au

gu

st”,

F-1

8E/F

Dev

elo

pin

g N

ew

Pro

du

cts,

JP

L

Mis

sio

n C

on

tro

l

Cen

ter,

JS

C

Design and analysis activities are isolated from other tasks in an area devoid of

distractions and apart from individual offices√ √ √

Information gathering is facilitated by a support staff for quickly finding the right

information√ √

Display screens are used to help continuously communicate design information √ √ √

Relevant stakeholders are invited to participate in the design process for significant

periods of time, while continuing to work on their regular tasks√ √

7.3.3 Discussion of Environment Value

As proposed in Table 5.1, the environment of the product development process should encourage

continuous flow, communication, and a lifecycle perspective. With this in mind, research was

conducted on time allocation, communication effectiveness, and environments of successful

teams. The primary result is a reaffirmation of the importance of communication, as it

encompasses a large share of development time. Effort must be made at managing

communication to prevent two problems from occurring. The first is that ineffective

communication may quickly lead to substantial waste. For example, a geographically separated

program, where team members only communicate via teleconferencing and email will suffer

through lack of interpersonal contact. The second problem is that too much communication can

quickly paralyze a program. Although modern tools have led to significant increases in

productivity, there is no substitute for face-to-face communication, which was the only form of

communication successful to address technical, process, and team value (Figure 7.3). Managers

should emphasize layouts in which interpersonal communication is promoted. The review of

three successful product development teams also found that tasks should be accomplished in a

distraction free environment with a specific objective at hand.

96

7.4 Management Research

The final area of value in product development is the management approach. Effective

management represents the bridge between process and product value, and it should ensure the

product meets performance, cost, and schedule specifications. This section reviews the

management approach by studying technical uncertainty and task completion.28 The principal

results of this component of the research are described below.

1) Progress in product development is difficult to estimate accurately from data on the

estimated percent completion of tasks.

2) From four programs studied, tight schedule and cost control (that is, application of an

earned value management system) showed significantly better schedule performance

(that is, 63% versus 27% of tasks were early or on time) than programs using a

traditional, or Gantt chart driven, management approach.

3) At a detailed level, engineers found it difficult to estimate the uncertainty in technical

performance measures.

7.4.1 Analysis of Schedule Completion Data

Current management techniques for product development have evolved from the manufacturing

sector, where the prevailing sentiment suggests consistency and performance to plan as the

primary means for guiding resource allocation. This perspective supports tools that measure

recurring cost and schedule, stressing the consistent use of resources. In product development,

Gantt charts are used in approximately 70% of programs for controlling the process (McManus,

2000). Similarly, the current industry-wide adoption of earned value management (EVM)

follows this trend of measuring performance to plan. However, few programs utilize a weekly

earned value system, where performance is measured against the plan each week. This technique

has proven to be effective (such as, F/A-18 E/F) in managing large, complex programs within

schedule and cost, while attaining all technical objectives (Haggerty, 2001). Weekly EVM

provides program management with rapid indication of schedule and cost problems, thus

allowing timely corrective action.

28 Cost is not considered due to the difficulty in obtaining proprietary data.

97

The successful use of Gantt charts or earned value management requires the process to be

predictable. So, program managers can anticipate the needs, strengths, and weaknesses of the

program and act accordingly to maximize the output. A question, however, is whether product

development processes are adequately predictable. To answer this, data were obtained from four

product development programs (see Table 7.13). Programs A-2 and A-5 use a traditional

approach (that is, simply providing a deadline for the completion of the tasks), and programs B-5

and B-6 used an earned value management system.

Table 7.13: Programs Used for Evaluating Schedule Consistency

Lifecycle Phase (1-6)Programs Tasks

Tasks

MeasuredDays / Task

Start Phase End Phase

A-2 55 31 16.3 ~ 2.5 ~ 4.3

A-5 51 24 49.2 - -

B-5 109 109 78.7 ~ 2.5 ~ 3.5

B-6 20 20 54.0 ~ 3.90 ~ 3.95

Traditional Approach

Over the course of the study, data were collected from 106 tasks of programs A-2 and A-5,

which includes completion times that ranged from a few hours to several months. In several

cases, the tasks were either incomplete or too short (that is, less than 3 days) to be used in the

study, resulting in 55 usable cases. After the data were normalized (by dividing the actual by

time by the estimated time), there was little difference between the averages of the programs.29

Thus, the data were combined to form a single set of results as shown in the following figures. In

Figure 7.5, mid-task data30 show the estimated percent completion of each task during its

execution. The results suggest that program personnel have great difficulty in estimating their

progress, relative to the completion date, for a traditional (or non-EVMS) approach.

29 The average timeliness ratios for the two programs were 3.8 (±5.6) and 3.8 (±5.1).

30 A total of 330 data points were obtained, or an average of six from each task.

98

Figure 7.5: Estimated versus Actual Completion (A-2 & A-5)

The relative accuracy is further illustrated in Figure 7.6, where only the data points in the range

of 20% to 80% of the actual completion time are plotted. The correlation (or accuracy) of the

data is compared against data from manufacturing.31 The difference in correlations (0.004 versus

1) shows a stark contrast. (The difference is probably an extreme case, since the product

development data represent a traditional management approach, whereas the manufacturing data

represent the world-class standard of the Toyota Production System.) Nevertheless, a

fundamental difference between development and manufacturing is illustrated.

31 The manufacturing data was obtained from Spear and Bowen (1999), which led to their first rule of the Toyota

Production System that “all work shall be highly specified as to content, sequence, timing, and outcome.” The

example that the data is based on is the installation of a front passenger seat. Toyota specifies the work instructions

for this task in intervals of approximately ten seconds. This type of accuracy allows the Toyota Production System

to maintain continual awareness of their progress. It should be noted, however, that manufacturing tasks are

“repetitive functions” whereas product development tasks are non-recurring “first time“ activities.

99

R2 = 0.004

0%

20%

40%

60%

80%

100%

20% 40% 60% 80%

Actual Task %-Completion

Est

. Tas

k %

-Com

ple

tion

R2 = 1

0%

20%

40%

60%

80%

100%

20% 40% 60% 80%

Actual Task %-Completion

Est

. Tas

k %

-Com

ple

tion

Figure 7.6: Product Development versus Manufacturing Task Completion

The histogram in Figure 7.7 represents the actual versus estimated completion times of the 55

product development tasks in cases A-2 and A-5. In line with past LAI research, the data

suggest that tasks are rarely completed ahead of schedule and usually have a decreasing

distribution to the right.

0

2

4

6

8

10

1214

16

Timeliness (ratio of actual vs. estimated time)

Freq

uenc

y

0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0 4.5 5.0 5.5 6.0 6.5 7.0 7.5 8.0 8.5 9.0 9.5 10+ 0.25

7% 20% 73%

Figure 7.7: Histogram of Product Development Task Completion (A-2 & A-5)

100

Earned Value Management System (EVMS)

Although the earned value management system was developed a number of years ago, it has

recently been the subject of increased attention. The Air Force and several corporations have

promoted its use across the industry, and successful implementations have included the F-18 E/F,

the B-2 (Solomon, 2000), and the software division of the Oklahoma City Air Logistics Center

(Lipke, 2000).

Figure 7.8: Estimated versus Actual Completion (Site B-5)

Figure 7.8 shows the weekly progress measurements of EVMS. ACWP is the actual cost of the

work performed, BCWP is the budgeted cost of the work performed, and BCWS is the budgeted

cost of the work scheduled. Of these measurements, BCWP is equivalent to the data shown

earlier in Figure 7.5 as the intermediate points represent estimates of completion. These data

were available for only one task, so it cannot be directly used for comparison with Figure 7.5.

Task completion results were obtained for two programs, B-5 and B-6. The data for B-5 are

displayed in Figure 7.9 and show that timeliness has increased from 20% of the tasks being on

time to 49% of the tasks being on time. Early completions are up from 7% to 15%, and late

completions have been reduced to 37%. The tasks from program B-6 produce a similar result, as

70% were completed on time and only 30% were significantly late. These data from two

programs are not conclusive, but it does suggest that product development tasks may be

controlled (and thus predicted) to a much greater degree than Figure 7.5 would suggest.

101

0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0 4.5 5.0 5.5 6.0 6.5 7.0 7.5 8.0 8.5 9.0 9.5 10+ 0.25

15% 49% 37%

Figure 7.9: Histogram of Product Development Task Completion (B-5)

7.4.2 Managing Technical Uncertainty

Rather than emphasizing the schedule (via performance to plan), other approaches emphasize the

pursuit of technical objectives. Many researchers (such as Huff, 1997; Kulick, 1997; Pisano,

1996) have suggested that this value may be quantified using technical performance measures

(TPMs).32 Thus, “by tracking the system’s TPMs, the project manager gains visibility into

whether the delivered system will actually meet its performance specification” (NASA, 1995).

Programs that have successfully implemented this approach, limited to TPM mean values,

include the C-17, Apache, and F/A-18 E/F (Haggerty, 2001).

Recently, Browning (1998) and Deyst (2001) have suggested that it is more useful to measure

the decreasing uncertainty of technical performance measures (see Figure 7.10). This shift in

thinking corresponds with the change from product to process value discussed in Section 4.3.

Product value is described by the combined value of TPMs, whereas process value is the

reduction in TPM uncertainty contributed by product development activities. This perspective

32 Technical performance measures may also be called measures of effectiveness (MOEs), figures of merit (FOMs),

and other names (Browning, 2001).

102

parallels the manufacturing methodologies of Six Sigma and statistical process control (SPC),

which ensure desired production yields are realized (Deyst, 2001). This also suggests that

management should measure TPM progress throughout the product development process, as a

means of ensuring the ability to deliver value to the customer.

Figure 7.10: TPM Planned Profile and Risk Reduction (Browning, 2001)

Measuring technical uncertainty at a detailed level proved difficult for this research. From the 15

teams that showed initial interest, only one team agreed to submit data, and this team found the

measurements quite difficult. Thus, over the course of several months, no data were collected at

a weekly or bimonthly level of detail. This result suggests that managing a program through

technical uncertainty is a considerable challenge.

7.4.3 Discussion of Management Value

The desired management approach should provide continual awareness of the technical

performance, cost, and schedule of the program. The emphasis should allow the program

manager to reallocate resources in order to deliver the desired product to the customer on or

ahead of schedule, within budget, and meeting all technical specifications. Currently, industry

typically uses either Gantt charts or EVMS to manage programs. The Gantt chart is considered

the more traditional and less costly approach. However, in the programs studied, a high degree

of variability was observed, leading to the significantly delayed completion of tasks. In contrast,

the programs using EVMS were completed more often on time. The small sample size of these

103

results prohibits any broad conclusions. However, it offers some evidence that higher degrees of

performance may be obtained in product development through a more rigorous management

system (such as EVMS). Ultimately, this added visibility and control produces the value that is

delivered to the customer. If technical performance measures are included in the EVMS, “the

confidence level of achieving schedule, cost, and technical performance of the program, and thus

delivering the value promised by the program, is significantly higher” (Haggerty, 2001). Even

further, tracking the uncertainty of the TPM’s would be a valuable addition to the mean values;

however, this was found to be extremely difficult in practice.

104

Chapter 8: Summary

This research presented a foundation of lean philosophy, product development process, and value

that led to a framework of value creation in the product development process. Data were

collected and analyzed, based on this framework. A summary of results is presented below.

Value Creation Framework

1) The product development process may be decomposed into a series of tasks that use

resources to create information and reduce risk, resulting in a product delivered to the

customer (see Figure 5.1). Within the framework, value may be divided into product value

and process value. In product development, tasks are often too far removed from the

customer for product value to be of use, and it is often more useful to focus on process value

in process improvement efforts. Process value is the approach of the enterprise in creating a

desired product for the customer, a continuing profit for the shareholder, and lifetime

satisfaction for the employee. Process value may be decomposed into tasks, resources,

environment, and management, and then subdivided further into a number of value attributes

(see Figure 5.2).

2) A value creation framework has been developed to aid in the visualization of value creation

in product development. The framework can be used, as demonstrated by the research, to

help analyze the product development process. Validation of the entire framework is beyond

the scope of the thesis, but the results from several sets of data are presented below.

Results from Task Research

3) The percentage of tasks that address various aspects of value differ markedly from program

to program and process to process (see Table 7.4), implying that there is not a single

definition of "the product development process" at anything but the highest level.

4) The majority of tasks defined at a high level appear to contribute directly to value. They are

directed at designing the product, defining the production process, or reducing the product

uncertainty or risk. However, when tasks are further decomposed (in process WBS’s), an

appreciable fraction (~30%) fell into supporting and enabling categories. A challenge of

105

considering task value is that a high-level perspective will indicate that all tasks directly

contribute value, while a finer decomposition of the same process will reveal non-value-

added activities. This is consistent with the view from Browning (1999) that addressing the

value of tasks must occur at the finest, practical level of detail.

5) The WBS’s of programs judged to be taking place in more lean environments showed more

supporting tasks, primarily those concerned with cost and schedule management, than those

taking place in traditional environments. This is interpreted as reflecting a higher

consciousness of the need to explicitly deal with cost and schedule issues.

6) Attempts to directly gauge task value by surveys were unsuccessful, because the data were

too sparse. The pilot study performed on students developing theses was more successful,

identifying higher and lower value tasks. The suggestion is that the methodology may have

some utility if broadly applied.

Results from Resources Research

7) The site visits conducted as part of this research consistently identified the appropriate

resources (primarily people and software tools) as critical to the success of programs.

However, metrics for assessing the value-creating potential of "human capital" and software

tools were not found. No quantifiable data on resource value were collected in this research.

Results from Environment Research

8) The importance of communication in product development activities, identified by many

previous authors (such as Allen, 1977 and Bernstein, 2000) was reinforced by the results of

this study. The engineers and managers surveyed gave high importance to face-to-face and

small group interactions.

Results from Management Research

9) Almost no correlation existed between estimated percent completion and the actual

completion time of industry tasks. Data from an earned value management system, however,

showed fewer tasks completed behind schedule (see Figure 7.9), suggesting that some control

is possible through a more rigorous management tool.

106

Chapter 9: References

Allen, Thomas. Managing the Flow of Technology. Cambridge: MIT Press, 1977.

Analytic Sciences Corporation. Applied Optimal Estimation. Ed. Arthur Gelb. Cambridge: MIT Press,

1974.

Argote, Linda and Paul Ingram. "Knowledge Transfer: A Basis for Competitive Advantage in Firms."

Organizational Behavior and Human Decision Processes 82.1. May 2000.

Bernstein, Joshua I. "Multidisciplinary Design Problem Solving on Product Development Teams."

Doctoral Thesis. MIT. Cambridge, 2000.

Boppe, Charles. Aerospace Product Design: 16.870 Course Material. MIT. Fall, 1999.

Browning, Tyson R. Correspondence with author. July, 2000.

Browning, Tyson R. "Complex System Product Development: Adding Value by Creating Information and

Reducing Risk" Lean Aerospace Initiative Report WP99-03. MIT. Cambridge, 1999.

Browning, Tyson R. "Modeling and Analyzing Cost, Schedule, and Performance in Complex System

Product Development" Doctoral Thesis. MIT. Cambridge, 1998.

Browning, Tyson R. “Modeling the Customer Value of Product Development Processes.” Proceedings of

the 11th Annual International Symposium of INCOSE, Melbourne, Australia, July 1-5, 2001.

Browning, Tyson R. “Sources of Performance Risk in Complex System Development.” Proceedings of

the 9th Annual International Symposium of INCOSE, Brighton, UK, June 6-10, 1999.

Burke, R. J. and C. Bolf. “Learning within Organizations: Sources and Content.” Psychological Reports.

59, 1187-1196, 1986.

Clark and Fujimoto. Product Development Performance. Cambridge: Harvard University Press, 1991.

Cochran, David. "Time in Manufacturing Systems." Presentation at a LAI Seminar, Cambridge. 2000.

Condit, Philip M. "Performance, Process, and Value: Commercial Aircraft Design in the 21st Century."

Speech at the World Aviation Congress and Exposition. Los Angeles. October 22, 1996.

Cook, Nick. "Eurofighter Production Plant Wins 'Center of Excellence' Rating." Jane's Defense Weekly.

July 12, 2000.

Cool, C. "Transition to a Lean Sigma Enterprise." Presentation at the LAI Plenary. Integrated Systems

Sector, Northrop Grumman. Cambridge. April 2001.

107

Davis, James B. "Splicing Lean into the DNA of Running a Healthy Business." Presentation at the LAI

Plenary. Boeing. Cambridge. April 2001.

Department of the Air Force. "An Introduction to Earned Value, For What Its Worth." Aerospace

Acquisition 2000: 3.1, 2000

Department of the Air Force. The Quality Approach: Air Force Handbook 90-52. Washington:

Department of the Air Force, 1996.

Deyst, John J. "A Model for Determining Value and Managing Risk in Product Development."

Unpublished Report. MIT. Cambridge, 2001.

Deyst, John. J. "Understanding Risk and Uncertainty." Presentation at the LAI Plenary. Cambridge. April

2001.

Donovan, J., R. Tully, and B. Wortman. The Value Enterprise: Strategies for Building a Value-Based

Organization. Toronto: McGraw-Hill Ryerson, 1998.

Eppinger, Steven D. "Three Views of Product Complexity." Presented at the LAI Plenary. Cambridge.

April 2001.

Fabrycky, W. J. and B. S. Blanchard. Life-Cycle Cost and Economic Analysis. New Jersey: Prentice Hall,

1991.

Fowler, B. "Ford Production System Lean Infrastructure." Presentation at the LAI Plenary. Ford Motor

Company. Cambridge. April 2001.

Haggerty, A. Correspondence with Author. December, 2001.

Hammersley, M., N. R. Shadbolt, D. A. Golightly, H. D. Cottam, and P. H. Riley. "Knowledge

Engineering for Web Based Knowledge Management: A Case Study from Rolls-Royce."

Knowledge Management. October 1999.

Hernandez, C. "Intellectual Capital White Paper." California Engineering Foundation: December 1999.

Iansiti, Marco. Technology Integration: Making Critical Choices in a Dynamic World. Boston: Harvard

Business School Press, 1998.

"'Informed Innovation' Will Lead to e-Business Success." Boeing News 59.29, 2000.

Kaufman, J. Jerry. Value Engineering for the Practitioner. North Carolina State University: Raleigh, NC,

1985.

Keen, Peter G. The Process Edge: Creating Value Where It Counts. Boston: Harvard Business School

108

Press, 1997.

Keeney, Ralph L. and Howard Raiffa. Decisions with Multiple Objectives: Preferences and Value

Tradeoffs. Cambridge: Cambrige University Press, 1976.

Lean Aerospace Initiative. "Detailed PD Process Model" Output from the LAI Product Development

Workshop. Los Angeles. August, 1998a.

Lean Aerospace Initiative. "LAI: Systems Offering Best Lifecycle Value." Presentation at a LAI Seminar.

Cambridge. June 1999.

Lean Aerospace Initiative. "Seven Information Wastes." Output from LAI Product Development

Workshop. Los Angeles. August 1998b.

Lewis, Paul, Guy Norris, and Graham Warwick. "Manufacturing Technology: Building to Win." Flight

International. July 25-31, 2000.

Lloyd, Robert. "Concept of Value in Government Contracting." Conference Paper. Acquisition Research

Symposium, 1993.

Malone, Thomas W. "Inventing the Organizations of the New Economy." Presentation at the LAI

Plenary. Cambridge. April 2001.

McManus, Hugh and E. Harmon. "Lean Product Development Definitions and Concepts." Presentation at

the LAI Plenary. MIT and Northrop Grumman. Cambridge. April 2001.

McManus, H. "Value: Assessment and Needs." Presentation at the LAI Product Development Workshop,

Sacramento. January 2000.

McManus, Hugh. "Value Attributes of Product Development." Unpublished Report. MIT. Cambridge,

2000b.

McManus, Hugh. "Value of Structural Analysis Activities." Unpublished Report. MIT. Cambridge,

2000a.

Miles, L. D. Techniques of Value Analysis and Engineering. NY: McGraw-Hill Book Company, 1961.

Miles, Raymond E., Charles C. Snow, and Grant Miles. "TheFuture.org." Long Range Planning 33, 2000.

Millard, Richard. "Value Stream Mapping and Analysis for Product Development." Masters Thesis. MIT.

Cambridge, 2001.

"Mixed Results: The Boeing Employee Survey." Boeing News 59.29, 2000.

Mushala, Michael. "F-22 War on Costs Kickoff" Presentation at the LAI Plenary. U.S. Air Force.

109

Cambridge. April, 2001.

NASA. NASA Systems Engineering Handbook. Pasadena: Jet Propulsion Laboratory, 1995.

Oxford English Dictionary. 2nd Edition. Oxford: Oxford University Press, 1989.

Paulus, Paul B. and Huei-Chuan Yang. "Idea Generation in Groups: A Basis for Creativity in

Organizations." Organizational Behavior and Human Decision Processes 82.1. May 2000.

Porter, Michael E. Competitive Advantage. New York: Free Press, 1985.

Postrel, Virginia. "The Real New Economy." New York Times. Reprinted in the Minneapolis Star

Tribune. February 2, 2001.

Reinertsen, Donald G. Managing the Design Factory: A Product Developer's Tool Kit. New York: Free

Press, 1997.

Rosenau, Milton D., Jr. Successful Product Development: Speeding from Opportunity to Profit. New

York: John Wiley & Sons, 2000.

Rulke, Diane Liang, Srilata Zaheer, and Marc H. Anderson. "Sources of Managers' Knowledge of

Organizational Capabilities." Organizational Behavior and Human Decision Processes 82.1. May

2000.

Sears, Michael M. "Earned Value Management." Speech at the 10th Annual International Integrated

Program Management Conference. October 19, 1998.

Shillito, M. Larry and David J. De Marle. Value: Its Measurement, Design, and Management. New York:

John Wiley & Sons, 1992.

Slack, R.A. "The Lean Value Principle in Military Aerospace Product Development" Lean Aerospace

Initiative Report RP99-01-16. MIT. Cambridge, 1999.

Smart, William. Introduction to the Theory of Value. Augustus M. Kelley Publishers, 1966.

Sobek, Durward K., II. "Going Against Conventional Wisdom: An Inside Look at Toyota's Product

Development System." Presentation. Montana State University. Sacramento. August 2000.

Sobelman, S. A Modern Dynamic Approach to Product Development, Dover, NJ: Office of Technical

Services (OTS), 1958.

Spear, Steven and H. Kent Bowen. "Decoding the DNA of the Toyota Production System." Harvard

Business Review. September-October, 1999.

Springsteen, Beth, Elizabeth K. Bailey, Sarah H. Nash, and James P. Woolsey. “Integrated Product and

110

Process Development Case Study: Development of the F/A-18E/F.” Institute for Defense

Analyses. IDA Document D-2228. January, 1999.

Squeo, Anne Marie. "Lockheed Plant in Georgia Sees A Turnaround." Wall Street Journal. July 9, 2000.

Stanke, Alexis. "A Framework for Achieving Lifecycle Value in Product Development." Masters Thesis.

MIT. Cambridge, 2001.

Steward, Donald V. "The Design Structure System: A Method for Managing the Design of Complex

Systems" IEEE Transactions on Engineering Management 28.3: 71-74, 1981.

Suris, O. "Behind the Wheel." Wall Street Journal. November 18, 1996.

Tanaka, M. "Evaluation of Function and Value Improvement by a Rating Approach." Proceedings of the

Society of American Value Engineers, 1973 International Conference, 69-77, May 1973.

Thompson, Arthur A., Jr. and A. J. Strickland, III. Strategic Management: Concepts and Cases. Boston:

Irwin McGraw-Hill, 1998.

Trott, Paul. Innovation Management & New Product Development. London: Pitman Publishing, 1998.

Tsai, Wenpin. "Social Capital, Strategic Relatedness and the Formation of Intraorganizational Linkages."

Strategic Management Journal 21, 2000.

Ulrich, Karl T. and Steven D. Eppinger. Product Design and Development. NY: McGraw-Hill, 1995.

Waltham, D. “DNP Overview.” Presentation at the NASA Jet Propulsion Laboratory, Pasadena, 2000.

Warfield, John. Societal Systems: Planning, Policy, and Complexity. NY: John Wiley & Sons, 1976.

Webster’s New Collegiate Dictionary. Merriam-Webster Online. http://www.m-w.com/home.htm, 2001.

Webster’s New Collegiate Dictionary. Springfield: G. & C. Merriam, 1956.

Wessels, J. "Managing Knowledge." Presentation at the LAI Plenary. Cambridge. March 2000.

Womack, James P. and Daniel T. Jones. Lean Thinking: Banish Waste and Create Wealth in Your

Corporation. New York: Simon & Schuster, 1996.

Womack, James P., Daniel T. Jones, and Daniel Roos. The Machine that Changed the World: The Story

of Lean Production. New York: Harper, 1990.

111

Appendix A: Discussion of Resource Value

Thompson and Strickland (1998) describe the value of resources as corporate strengths and

capabilities, which they suggest include the following abbreviated list.33

• Valuable human assets – an experienced, capable, or talented workforce

• Valuable physical assets – state-of-the-art plants, equipment, or software

• A skill or important expertise – technological or manufacturing know-how

These areas correspond with people, tools, and knowledge, as the ingredients that flow into

product development activities. The elements are not independent, since knowledge is often

considered a mixture of people and tools, residing as either tacit knowledge in the workforce or

explicit knowledge within tools. The discussion presented here stems from a series of

interviews. The interviews were conducted with several product development teams (as

described in the previous chapter), and the majority of the results stem from three programs that

were given “carte blanche” (as stated by one program manager) for obtaining program resources.

A.1 Knowledge

“The most valuable assets of the 20th century were its production equipment. The most

valuable assets of the 21st century will be its knowledge workers and their productivity.”

– Peter Drucker

The growing complexity of product development has led to knowledge as the “key asset whose

exploitation will determine success for many firms” (Miles, 2000). Knowledge is the “insights

and context from the mind - what the knower knows,” and it exists at the integration of people,

process, and technology (Wessels, 2000). Furthermore, it is seen as an “essential ingredient for

reducing lead times and maintaining the highest quality standards” (Hammersley et al, 1999).

33 The entire list includes organizational assets, intangible assets, competitive capabilities, organizational

achievement, and corporate alliances, which are considered less relevant to the task level of product development.

112

Despite the importance of knowledge, however, “research on how organizations recognize,

develop, and transfer knowledge is still in its infancy” (Rulke et al, 2000). Moreover, knowledge

in the aerospace industry has come to a critical period. Due to downsizing and retirement, many

thousands of jobs have been lost (Wessels, 2000). Experience has significantly decreased and

many engineers are nearing retirement. For these reasons, several aerospace companies have

begun to invest in knowledge management, which is the development of tools to encourage

collaboration and capture the tacit knowledge of employees.

A.2 People

The value of employees, however, is not measured simply by their knowledge, but by a variety

of factors that contribute innovation as well as experience. Based on the relevant literature and

interviews, five attributes were identified to describe organizational value and are discussed

below.

A.2.1 Proficiency

Product development in the aerospace industry requires significant technological knowledge to

remain proficient. Thus, it is not only important to initially select competent employees, but to

provide training to maintain their skills and knowledge. The Air Force (1996) expands this

sentiment to include quality, stating that “education and training are essential to implementing

quality.” The product development teams visited all had high levels of proficiency and usually

years of experience. The one exception mentioned a few times was that design engineers “do not

have insight on cost savings and may miss the big picture.” This corresponds with earlier

research, which identified a lack of emphasis on cost savings at the detailed level of process.

A.2.2 Diversity

“I’m not talking about trying to cultivate generalists… To help engineers develop

expertise in their core field, we need to provide them with diverse experience in that

sector and in peripheral sectors.” – Vice President of Research and Development34

34 Quotation is from Sobek (2000).

113

A number of program managers and industry experts have stressed the importance of diversity.

Rosenau (2000) and Trott (1998) include a “diverse range of skills” as a necessary characteristic

of employees. In light of this, the programs visited made determined efforts to get the “best

people with diverse experience.” Diversity serves not only as a source of new ideas, but more

importantly it increases cross-functional cooperation. For example, technology gatekeepers,

described by Allen (1977), have led to better product performance due to their extensive

communication networks. In industry, this trait was observed in design engineers, who generally

maintain good contacts for help in answering design, analysis, and manufacturing questions.

In terms of achieving a balance between proficiency and diversity, Iansiti (1998) conducted a

study in computer mainframe development. He found that, “by and large, projects staffed

mainly by members with more than 2 full generations of experience did not perform as well as

those with some lesser amount of experience.” Thus, he concluded that some diversity is

necessary at the expense of increased depth.

A.2.3 Empowerment

“Never tell people how to do things. Tell them what to do and they will surprise you

with their ingenuity.” -General George S. Patton, Jr. U.S. Army

As discussed earlier, empowerment is one of the tenets of lean theory. The Lean Aerospace

Initiative (1999) and Trott (1998), among others, have emphasized its importance. In the

programs visited, this was usually evident from the delegation of responsibility, accountability,

and authority (RAA) to the employees. Responsibility represents the assignment of a specific

task, accountability is ensuring the quality of the task, and authority is the right of an individual

to take the necessary actions required to complete the task. In many instances, organizational

empowerment was successful. However, several engineers mentioned the loss of mentorship,

which is due to a combination of increased empowerment and downsizing in the industry.

A.2.4 Mentorship

Even as empowerment increases in the aerospace industry, mentorship is quickly disappearing.

These two attributes, however, should not be considered opposites. The best example of their

synchronous implementation can be found at Toyota. Toyota traditionally relies on its employee

114

base to anticipate and solve most problems. However, this process does not happen alone.

Everyone at Toyota has a sempai (or mentor) who is not their boss (Sobek, 2000). Sobek writes

that supervisors actively train their engineers regarding many technical and non-technical issues.

Supervisors are “working team leaders,” which maintains employee empowerment but provides

help as necessary. Unfortunately, this type of mentorship is costly, and even in the model

programs visited, managers felt that the money is simply not available.

A.2.5 Leadership

The final component of organizational value is providing the necessary leadership in key

positions. At Toyota, the chief engineer is the integration specialist and “totally responsible for

the vehicle program (concept, targets, schedule, budget, coordination, and key design decisions)”

(Sobek, 2000). Similarly, the U.S. aerospace industry requires a program manager who is

administratively and technically skillful and keeps a high level of communication among team

members. In addition to these positions, many engineers actually consider design engineers “to

add the most value.” Since their position must integrate many sources of information into a

specific design, it requires a great deal of talent, experience, and authority. Finally, it is

important to stress that “establishing a strong quality focus requires substantial time and effort

from the leadership team” (Air Force, 1996).

A.3 Tools

Several decades ago, lean began with the use of flexible tools in the Toyota Production System

(Womack and Jones, 1990). In the last few years, a similar transformation is being made in

product development. Software and information technology tools are providing significant leaps

in productivity. For example, the following description of the Boeing 777 program led to a “60

to 90% reduction in rework” from previous airplanes (Condit, 1996).

The 777 was the first Boeing jetliner designed completely on computers…With the use of

interactive graphics, the design teams were able to concurrently release structure,

systems, payloads, and other design features of the aircraft with minimal interference and

related problems. (Condit, 1996)

115

Software tools were also used for testing, where they helped conduct thousands of test hours

prior to the rollout of the first 777, and similar technology was used on the two other successful

programs visited. In each case, few expenses were spared to incorporate modern tools, which are

described in this section. This commitment, however, does not necessarily extend beyond these

select programs, and industry managers have suggested that many programs have not yet applied

the new tools that are available.

A.3.1 Information Gathering Tools

“Sometimes the telephone number of the right person to speak with is the most valuable

piece of information you can give out.” – Design Engineer, Site B

Although direct communication is probably the most effective means for gathering information,

the size and complexity of product development requires a host of software tools to facilitate this

means. These tools include product data management systems, information archives, and

communication tools. Their objective is to efficiently provide the right information at the right

time. This is generally accomplished via documenting information in archives and enhancing

communication among team members.

Industry has had some success documenting information in three areas: issue tracking,

engineering skill management, and knowledge retention (Wessels, 2000). Issue tracking

involves linking documents to websites for quicker access, and all of the companies observed

have integrated this capability to some extent. Skill management was less common and involves

the documentation of skills in an effort to retain and promote the best people. Finally,

knowledge retention was the least common, as it employs video and online documentation to

describe detailed designs, processes, and other useful knowledge. In each of these cases, once

the necessary information is documented, it may be retrieved via search engines or hierarchical

structures that provide easy access. This efficient access of information has been employed in

other industries, where, for example, a 75% reduction in cycle time was achieved in automobile

stress analysis (Hammersley, 1999).

Despite the increasing use of documentation to capture knowledge, collaboration remains a more

effective means for transferring knowledge. Miles (2000) suggests that “it is now apparent that

effective knowledge management depends heavily on a company’s ability to collaborate, both

116

inside and outside the company.” Burke and Bolf (1986) found that “from a list of 15 sources of

learning, managers most value their peers, their immediate supervisor, other supervisors, and

external publications,” which is inline with related research (Rulke et al, 2000). Finally, Argote

and Ingram (2000) have shown that moving technology and tasks is “more effective when

accompanied by moving people because people are capable of adapting the tools or technology

to the new context.” Thus, an emphasis should be placed on facilitating collaboration rather than

solely relying on documentation to achieve effective knowledge management.

Given the importance of collaboration, many companies have implemented software tools that

assist with communication. For example, one site has introduced virtual collaboration rooms,

where engineers, customers, and suppliers can maintain discussions in real time. Several

managers believe that this is the direction of product development, despite the appearance of

several challenges. For example, some devices offer the capability of sending and receiving

messages from anywhere (including during meetings), creating interference in the working

environment. Similarly, many product development personnel have characterized email as a

constant distraction.

One tool that combines the strengths of documentation and collaboration is the visual

information pull system (VIPS). It was developed by Aerojet to introduce the lean principle of

pull to product development. VIPS is a web-based system that is used to request the completion

of tasks and then tracks their progress. It increases transparency (providing the entire team with

access to the progress of ongoing tasks) and is used to send messages to team members

(facilitating communication). Another advantage of VIPS is its emphasis on specific tasks. This

perspective allows for the introduction of techniques to measure value. For instance, in addition

to schedule-related data, other measures may be kept such as cost and balanced scorecard data.

Thus, tasks may be more directly analyzed for value adding or enabling efforts, as described in

the previous section.

A.3.2 Knowledge Application Tools

During visits, engineers and managers repeatedly characterized computer aided design (CAD)

software as “the single most significant contribution” to increased productivity. The strength of

CAD tools lies in their ability to simplify and automate much of the process. Furthermore, the

117

tools provide a visual aid that increases communication. For instance, meetings were observed

where the design was displayed to several team members, who would discuss problems and

suggest changes. This type of collaboration increases understanding, reduces rework, and is

fundamentally changing product development as it becomes more common (see Section 3.4.2).

Similarly, those familiar with manufacturing have credited software technology for reducing

manufacture and assembly time. Software applications have led to increased design for

manufacture (DFM). DFM is “aimed at reducing manufacturing costs while simultaneously

improving (or not compromising) product quality, development time, and development cost”

(Ulrich and Eppinger, 1995). For instance, some tools allow manufacturing to be simulated,

testing for accuracy before actual production. Likewise, other tools allow the assembly to be

simulated to ensure that workers can access all necessary areas of the product. This simulation is

exported to the assembly line to facilitate understanding, while correspondingly helping to

standardize the process. Similarly, other new tools are constantly being introduced to the

product development process. For example, over 35 different stress analysis software packages

are available, with each having its strengths and weaknesses (Hammersley et al, 1999).

118

Appendix B: Case Studies of Successful Team Environments

Brief case studies were conducted on the following three teams in order to pool characteristics of

successful team environments. The following teams have had notable success, and thus serve as

model environments.

B.1 “Twelve Days of August,” F-18E/F, Boeing

The first case study is from the F/A-18E/F aircraft development program, where in August of

1991, the program encountered a significant challenge. During the previous nine months,

Northrop, General Electric, and the Navy had been working to define the configuration and high-

level requirements for the E/F. The work, however, had been largely unsuccessful and the result

was “a weapon system that was over weight and over cost” (Springsteen, 1999). To address this

problem, a twelve-day meeting (later called the “Twelve Days of August”) was convened to

create a set of requirements that would not exceed the weight and cost budgets. In other words,

the objective was to accomplish in twelve days what had proved unworkable in nine months.

Many of the problems were the result of a lack of cooperation across functional groups. Each

group desired the best performance, regardless of the impact on the entire aircraft. For this

reason, it was decided to bring together all of the people who were knowledgeable to define the

configuration and requirements (Springsteen, 1999). Over 40 people attended the event,

gathering as a group each morning and evening, and working in functional teams throughout the

remainder of the day. “Over the twelve days they had to trade off weight, fuel, capacity, volume,

materials, the size of the radar cross-section, and cost. Operational analysis was going on

throughout all of this in order to understand what was being gained at a system level with the

changes that the teams were making” (Springsteen, 1999).

The result of this intense effort was a configuration and set of requirements that led to the

production of the F/A-18E/F aircraft. This aircraft won the Collier Trophy and was produced

below cost, on-schedule, and with comparatively superior performance (Cool, 2001). When

interviewed, many participants mentioned that the success of the “Twelve Days of August” was

achieved by bringing together the right people in a distraction free environment.

119

B.2 Developing New Products Team, Jet Propulsion Laboratory, NASA

The second case study is from the NASA Jet Propulsion Laboratory, which has often been

considered a world-class designer of unique spacecraft. A problem encountered by engineers at

JPL (and similar to the F/A-18E/F program) is the difficulty in creating the configuration, cost

estimates, and requirements. This process may require as much as two years, which adds

considerable cost to the project. To reduce the cycle time, JPL created the Developing New

Products (DNP) team.

The mission of DNP is to “(1) provide an integrated set of people, processes, and tools which

will enable JPL to rapidly engineer highly advanced space projects, and (2) maintain risk, yet

deliver spacecraft in 1/2 the time and 2/3 of the cost for missions comparable to pathfinder”

(Waltham, 2000). To achieve this goal, DNP uses a common area equipped with several new

software tools that engineers can use to quickly obtain spacecraft configurations, cost estimates

and requirements. The area is isolated from other team members and offers few distractions.

The result is akin to continuous flow, and one successful application reduced cycle time from

two years to two months (a 92% reduction). Although other implementations have had mixed

success, the DNP group has effectively applied several changes to promote communication.

B.3 Mission Control Center, Johnson Space Center, NASA

The final case study was conducted at the Mission Control Center (MCC) of Johnson Space

Center. The MCC (including the old and new versions) have managed numerous missions,

including Mercury, Gemini, Apollo, the Space Shuttle, and the International Space Station. In

regards to mission operations, it is considered a world-class location.

Although the MCC seems unrelated to product development, the reality is that they have much in

common. Both product development activities and the MCC are focused on problem solving.

As each group encounters a problem, resolution is sought via a specific procedure, which

includes design, analysis, and testing activities. The difference between the groups is that the

MCC is faced with considerable time pressure. Problems during space missions often require

120

solutions in seconds or minutes, rather than the weeks and months of product development. To

accommodate this emphasis on time, a unique environment has been created.

The environment of the MCC emphasizes rapid communication between knowledgeable

personnel. Over 40 people can occupy the MCC, each assigned to a computer terminal where

they monitor various functions of the mission. These engineers and managers also have separate

offices, thus keeping the MCC clean and orderly. Below the desks, a few manuals are provided,

although the majority of resources are located elsewhere. Given the complexity of most

missions, many of the personnel in the MCC have support teams that are found in similar rooms.

If a problem is encountered, the manager or engineer can direct the problem to their team to

provide a timely solution.

The result of the MCC has been considerable success for many years. For example, many

computer glitches have been quickly fixed on early and recent missions. Extra-vehicular space

walks have been guided by the center, and perhaps the best example is Apollo 13. Most people

are familiar with the timely creation of solutions to fix the series of critical problems that

occurred during that mission. In each case, the procedure for resolving the situation is the same:

bring the right people together, provide them with the right information, and allow them to work

in a distraction free environment.

121

Appendix C: Pilot Study of Academic Research

As a pilot study for quantifying value, six graduate students were selected to participate in a case

study involving value in the development of their Masters theses. Surveys were employed to

measure value, which emphasized obtaining initial results that could be analyzed.

C.1 Methodology of Academic Case Study

Importance was placed on using value attributes to gauge student research, since this was

considered an unproven approach for measuring value. However, the procedure for this method

was modified slightly from the industry studies. Rather than the value attributes previously

shown, a new set of attributes of value was created. These attributes include problem definition,

background, discussion, hypothesis, case study, results, industry knowledge gain, advisor

knowledge gain, student satisfaction and student knowledge gain. For each of these, a simple

maturity matrix was created that ranked the tasks from -3 to 3 (more recently defined as 1-5).

Over six weeks, students completed surveys on the value of each task they completed. Once

familiar with the surveys, students typically completed them within 90 seconds. The surveys

resulted in the development of six extensive sets of data, including over 100 tasks. A small

portion of one of these is shown in Figure 1. In addition to the attributes, data on the type of

task, documentation, and time was also collected.

Once the data had been collected, it was analyzed for various characteristics. Three significant

results were discovered that are discussed in the following subsections. First, the data revealed

more precisely how different types of tasks contribute to research. Second, the data could be

used to compare different projects and was especially helpful in illustrating clear differences in

project completion. Finally, the measure for value of tasks was compared against the time spent.

This comparison indicated which tasks provided the most return for the investment.

122

Figure C.1: Partial Data Set of Student Research

C.2 Task Value

The initial emphasis can be placed on the value attributes and their evolution through the tasks of

the research process. For example, Figure 2 shows student research at MIT progressing with

time, as portrayed by four types of value. Notice how value is characterized by gradual upward

progress with occasional jumps and plateaus. The objective is to remove as many of the plateaus

as possible. In this example, from 80 to 140 hours, there is a minimal amount of value added to

all four perspectives. This area was explored in more detail. In this case, the plateau was a

combination of three tasks: a work plan to organize the research, several unsuccessful attempts to

phone members of industry, and an unsuccessful literature review. In contrast, a site visit near

the 50th hour proved highly valuable. The student remarked that it sparked the next several

months of research.

123

0

10

20

30

40

50

60

0 50 100 150 200

Hours

Val

ue

Product ValueStudent Value

Advisor ValueLAI Value

Figure C.2: Cumulative Value of Student Research

In a similar fashion, different research projects may also be compared. For example, one

essential component of research is a case study. Despite this importance, students have markedly

different success in conducting one. For example, Figure 3 shows the success of each student in

obtaining one. Three of the students did not make any progress during the six weeks of this

study. The other three were making steady progress until of the 70th hour, when they diverged.

From a project management standpoint, this is valuable information that quickly illustrates where

potential problems might lie.

0

510

15

20

25

3035

40

45

0 50 100 150 200

Hours

Val

ue

LindberghDouglas

Armstrongvon BraunEarhart

Trippe

Figure C.3: Comparison of Research Case Studies

124

C.3 Time versus Task Value

Another comparison is the amount of time spent on different activities versus the value that they

create. Figure 4 depicts this association between time and three types of values. One immediate

observation is that focused meetings provide a great deal of value, although they do not take up

much time. By spending time as a team and working on a specific problem, a great deal can be

accomplished. Another insight is that presentations require a large amount of time to create, yet

only add value during the actual presentation. In other words, the set-up time is necessary, but

non-value-added. These insights are not new to research, but this structured methodology lends

them new credence.

0%10%20%30%40%

50%

Literat

ure Re

view

Pres

enta

tion

Meetin

g

Site

Visi

t

Model

Focu

sed Mee

ting

Time

Enterprise ValueStudent Value

Advisor Value

Figure C.4: Activity Value Summary

C.4 Results of the Pilot Study

This case study has surfaced several interesting phenomena. Specifically, tasks have been

highlighted that are potentially non-value-added, such as set-up time for presentations. Another

insight is that the progress on a research project can be clearly indicated via indirect measures of

research value. According to the data, one student can be progressing steadily, while another

might be at a standstill. Further research can determine what corrective action is necessary, but

the objective of the study has been accomplished.

125

Appendix D: Research Surveys and Definitions

D.1 Informed Consent for Surveys

This survey is designed to characterize three techniques for measuring value in the ProductDevelopment process. This study is part of an on-going research project by a consortiuminvolving the U.S. Air Force, a number of firms in the defense aerospace sector, and theMassachusetts Institute of Technology. The research projects focus on the investigation of theapplication of "Lean" practices in the defense aerospace industry.

Your cooperation is vital to the success of this study! Please answer the questions as they applyto you. Answering of the questions is voluntary. You are not obligated to answer any question. Ifyou are uncomfortable with any question, or feel in any way coerced or pressured intoparticipating in the survey or any part of it, you may decline to answer any or all questions. Yourdecision to decline to answer a question will be treated with the same confidentiality as positiveanswers.

Please be accurate in your responses. We understand that you may have concerns aboutconfidentiality. The survey is intended to be anonymous and several measures will be taken toensure that your responses will remain confidential. Only the researchers named below will haveaccess to the information requested in this survey. All analyses and reviews of the data will bepresented in the form of aggregated statistics. No individuals or individual programs will beidentified in the analysis, reviews, or reporting of the responses. We understand that the successof any research depends upon the quality of the information on which it is based, and we takeseriously our responsibility to ensure that any information you entrust to us will be protected.

Value in Product Development TeamJim Chase

Professor John DeystProfessor Ed GreitzerDr. Hugh McManus

Lean Aerospace InitiativeMIT Room 41-205

77 Massachusetts Ave.Cambridge, MA 02139

Fax: 617-258-7845

Thank you for your participation in this research!

126

D.2 Task Survey for Measuring Value (Industry)

Task Survey MIT Research Study

All data is confidential (click here for more info).

Name or initials:

Task Name (or nearest task): [selection of tasks from WBS]

(If task is unique, specify task name:)

Task contributes to (click here for definitions):

Functional performance of end product 5 4 3 2 1 N/A

Definition of processes to deliver product 5 4 3 2 1 N/A

Form of final output 5 4 3 2 1 N/A

Reduction of risks and uncertainties 5 4 3 2 1 N/A

Improvement of tools, processes, skills, etc. 5 4 3 2 1 N/A

Cost and/or schedule savings 5 4 3 2 1 N/A

Enabling other tasks 5 4 3 2 1 N/A

Facilitating communication 5 4 3 2 1 N/A

Employee job satisfaction 5 4 3 2 1 N/A

Other (describe in comments) 5 4 3 2 1 N/A

Direct effort spent on task completion: Hours

Comments:

Submit

Figure D.1: Online Task Survey for Measuring Value (Industry)

127

D.3 Original Value Attribute Definitions used in Industry Task Surveys35

V1: Functional Performance of End ProductThe functional performance of the end product to be delivered to the customer Task directly affects the functionality of the end product delivered to the customer. A high scoremeans direct specification of function, or direct specification of form that affects function, e.g.requirements specification, design decisions, or specification of parts, major dimensions,materials, etc. Lower scores might include tasks with minor impact on form and function (e.g.specifying detail dimensions). A "one" score might be used for processes which onlyoccasionally affect form and function (e.g. analyses which may turn up problems but usually donot).

V2: Definition of Processes to Deliver ProductThe definition of processes necessary to deliver the end product to the customer Task directly affects the processes necessary to deliver the end product to the customer. A highscore means direct specification of manufacturing, test, certification, or other downstreamprocesses necessary to deliver the product and have it accepted by the customer. Lower scoresmight include tasks with minor impact these plans or processes; a "one" score might indicateonly a chance of affecting these plans and processes.

V3: Form of Final OutputThe form of the output of this project (e.g. report, build-to-package, etc.) Task directly contributes to the document or information package that will form the output to thecustomer. High scores would include direct contribution to the deliverable documents, e.g.drawings called for in the build-to package. Lower scores might be used for intermediatedocumentation (e.g. internal reports) some of which may form part of the deliverabledocumentation, or which might be used directly to prepare it. A "one" might indicatedocumentation that has only a chance of inclusion in any final product.

V4: Reduction of Risks and UncertaintiesThe reduction of risks and uncertainties Task contributes to eliminating uncertainty in the design or reduces the risk of technical failureor program (cost and schedule) problems. High scores would include direct elimination ofuncertainties (e.g. design decisions that eliminate ambiguities in the design) or direct ruling outof risk factors (e.g. analyses that assure performance and/or rule out suspected failure modes), orplans to handle known risk factors. Lower scores might be used for tasks that address lessimportant risks or address only pieces of a problem (e.g. analyses of non-critical components,partial analyses). A "one" might indicate work that has only a chance of impacting program riskor uncertainty.

35 Originally contributed by McManus (2000b).

128

V5: Improvement of Tools, Processes, Skills, Etc.The improvement of tools, processes, technologies or skills relevant to E1-E4 Task contributes to the skill base necessary to do future work, but improving the tools, processesor technologies applied to design processes, and/or the skills of the engineers and others that dothe work. A high score might indicate direct work on development of design tools, training, orcritical technology. A lower score might be used for incremental improvements in methods, orimportant work-experience gained. A "one" might indicate incidental (but not trivial) gains inknowledge or work experience.

V6: Cost and/or Schedule Savings Task saves money and/or cuts schedule time. A high score would indicate that the task directlyresulted in major cost or time savings. A lower score might indicate minor savings, or savings asa byproduct rather than direct result of the task; a "one" might indicate incidental savings, or onlya chance of savings.

V7: Enabling Other TasksEnabling other tasks (e.g. task is required for other tasks to proceed) Task is necessary for other tasks to proceed, even if it does not itself directly contribute to theabove categories of value. Examples include gathering necessary information, getting approvals,set up of models or analyses, meetings to initiate other tasks, etc. A high score would indicatethe task is a critical prerequisite to a major value added task. Lower scores would indicate lowerlevels of criticality (e.g. following tasks could proceed with limitations without this task) oruncertainty (this task is sometimes, but not always, necessary)

V8: Facilitating CommunicationFacilitating necessary communication between tasks and/or employees Task directly aids necessary communication. A high score would indicate direct contribution tofree flow of critical information, e.g. setting up information systems, critical kick-off or othermeetings, communication of critical information from/to customers, etc. Lower scores wouldindicate lower levels of criticality or bandwidth; a "one" might indicate incidental contribution tocommunication.

V9: Employee Job SatisfactionThe employee's own job satisfaction Task is interesting, fun to do, results in increases in skills or positive experience, or otherwisecontributes to job satisfaction. This is necessarily highly subjective. A high score indicatesenjoyment of the task - a good reason to come to work. Lower scores indicate routine work; a"one" or "N/A" score might indicate an undesirable or unpleasant task.

V10: OtherAddresses other aspects of value not covered above (specify briefly in comments) Task performs a necessary or valuable function not covered in the above categories. Examplesmight include contributions to safety, work environment, or environmental impact reduction;satisfying of regulatory or contractual requirements, the following of existing processes, or otherneeds we haven't thought of.

129

D.4 Task Survey for Measuring Value (Academia)

Task Survey MIT Research Study

All data is confidential (click here for more info).

Name or initials:

Task Name:

Type of Task: [Lit. Review, Site Visit, Meeting, etc.]

Task contributes to (click here for definitions):

Problem Definition 5 4 3 2 1 N/A

Background 5 4 3 2 1 N/A

Discussion 5 4 3 2 1 N/A

Framework or Hypothesis 5 4 3 2 1 N/A

Case Study or Experiment 5 4 3 2 1 N/A

Contribution to Results 5 4 3 2 1 N/A

Advisor Knowledge 5 4 3 2 1 N/A

Industry Knowledge 5 4 3 2 1 N/A

Student Satisfaction 5 4 3 2 1 N/A

Student Knowledge 5 4 3 2 1 N/A

Direct effort spent on task completion: Hours

Comments:

Submit

Figure D.2: Online Task Survey for Measuring Value (Academia)

130

D.5 Survey for Communication in the Aerospace Industry

Communication in the Aerospace Industry MIT Research Study

All data is confidential (click here for more info).

Name (optional):

Position/Title:

Company Name:

Program Area: [Development, Manufacturing, Support, etc.]

On average, how many hours do you work each week? Hours

Please estimate the following information (leave blank if not applicable):

√ Level of Effectiveness √

(1 = not effective, 2 = effective, 3 = very effective)

Technical Work Process Work Team Building

Business Use 1 2 3 1 2 3 1 2 3

Face-to-Face Hrs/wk O O O O O O O O O

Meeting (w/2-5 people) Hrs/wk O O O O O O O O O

Meeting (w/6+ people) Hrs/wk O O O O O O O O O

Telephone Hrs/wk O O O O O O O O O

Teleconference Hrs/wk O O O O O O O O O

Voicemail Hrs/wk O O O O O O O O O

(1 = not effective, 2 = effective, 3 = very effective)

Technical Work Process Work Team Building

Business Use 1 2 3 1 2 3 1 2 3

Instant Messenger Hrs/wk O O O O O O O O O

Memos Hrs/wk O O O O O O O O O

Email Hrs/wk O O O O O O O O O

Mail Hrs/wk O O O O O O O O O

Reading Unpublished Reports Hrs/wk O O O O O O O O O

Reading Published Literature Hrs/wk O O O O O O O O O

Browsing the Web Hrs/wk O O O O O O O O O

Network Other than Web Hrs/wk O O O O O O O O O

On average, how many hours per week do you spend on non-communication-intensive

tasks (or those not listed above)? Hours

Comments:

Submit

Figure D.3: Online Survey for Communication in the Aerospace Industry

131

D.6 Definitions for Communication Survey

Technical Work- This aspect of work is the primary function of a job, as outlined by the jobdescription. Each method of communication described below can contribute (effectively or not)to job-related activities. "Not effective" means that this form of communication does noteffectively contribute to completing your job. "Effective" means that this contributes positivelyto completing your job. And, "very effective" means that this form of communication is criticalto the success of your job.

Process Work- This aspect of work relates to the process side of a job. Typically, this consistsof suggestions or mandated changes in how the job is accomplished. For example, a company-wide initiative to change software/hardware applications would fall under this category. Whattypes of communication are effective in contributing to this process? "Not effective" means thatthis form of communication is not helpful or effective in implementing process change."Effective" means this is helpful. And, "very effective" means this form of communication iscritical.

Team Building- This aspect of work relates to the social interaction necessary for a goodworking environment. It is typically very important to be able to communicate effectively withfellow colleagues. What types of communication contribute to this in your environment? "Noteffective" means that this form of communication is ineffective or damaging to building goodteam relationships. "Effective" means this contributes positively, and "very effective" means thisis critical for positive social interaction.

Face-to-Face- This type of communication occurs directly between people and occurs in 2-person meetings or in the daily on-the-job interactions.

Meeting (w/2-5 people)- This communication occurs directly in meetings involving 2 to 5people. These are typically focused meetings that cover a specific subject.

Meeting (w/6+ people)- This form of communication occurs in larger meetings of 6 or moremembers. Includes team meetings, program meetings, and employee meetings.

Telephone- This is communication that involves use of the phone for direct 1-to-1conversations.

Teleconference- This form of communication involves the use of the phone for discussionbetween more than two parties. Often, this might be in concert with a meeting as describedabove. In which case, it is considered a teleconference if the primary discussion occurs over thephone line.

Voicemail- This form of communication is the sending and receiving of voicemail or machinemessages. This includes dialing into the system, sending, and receiving.

Instant Messenger- This type of communication involves the immediate transmission andreception of electronic text. Currently, it is primarily used in personal applications (such as chatrooms), but it can have business applications. Please evaluate it only for business purposes.

Memos- These are common intra-office memos exchanged in the work environment.

132

Email- This form of communication is the transmission and reception of electronic messages.Common applications include Eudora, Claris Email, Entourage, and Outlook. Some of these(such as Eudora 5.0 include time statistics).

Mail- This type of communication is characterized by mail from within and outside theorganization. This would not include memos (previously mentioned) or reports that are sent viathe mail.

Reading Reports- This type of communication includes the time necessary to read reports orpapers. This could include a variety of documents, typically considered longer than a memo, butshorter than a book.

Reading Books- This communication consists of the knowledge obtained by reading business-related books during working hours.

Browsing the Web- This type of communication consists of using network browsers (usuallyNetscape & Explorer) to browse the World Wide Web.

Network other than Web- This type of communication consists of applications thatcommunicate with other servers or computers. For example, ERP or more specific applications,such as Configuration Management System (CMS) or the Visual Information Pull System(VIPS), are applications that use network communication to enable job-related activities.

133

D.7 Technical Uncertainty Survey

Technical Uncertainty Survey MIT Research Study

All data is confidential (click here for more info).

Name or initials:

Task Name (or nearest task): [selection of tasks from WBS]

(If task is unique, specify task name:)

Please estimate current TPMs shown below (and normalize as appropriate):

[Technical Performance Measure 1] Mean: [units]

Minimum: [units]

Maximum: [units]

[Technical Performance Measure 2] Mean: [units]

Minimum: [units]

Maximum: [units]

[Technical Performance Measure 3] Mean: [units]

Minimum: [units]

Maximum: [units]

Comments:

Submit

Figure D.4: Online Survey for Measuring Technical Uncertainty