2
Optimal Scheduling of Design Reviews in Product
Development
by
Alberto J. Cividanes
S.B. Mechanical Engineering
Massachusetts Institute of Technology, 2000
SUBMITTED TO THE DEPARTMENT OF MECHANICAL ENGINEERING IN PARTIAL
FULLFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF
MASTER OF SCIENCE IN MECHANICAL ENGINEERING
AT THE
OF TECHNOLOGY
INSTITUTE
MASSACHUSETTS
June 2002
@2002 Massachusetts Institute of Technology. All Rights Reserved.
Signature of Author........................
Departm nt of Mechanical Engineering
May 10, 2002
Certified by.........................................
Steven D. Eppinger
General Motors LFM Professor of Management Science and Engineering Systems
Thesis Supervisor
Certified by.........................................
Ali A. Yassine
Research Scientist
Thesis Supervisor
A ccepted by ................................................
3A
1ACHU
sT INSTITUTE
OF TECHNOLOGY
OCT 2 52
LIBRARIESj
.......................................
Ain. A. Sonin
Professor of Mechanical Engineering
Chairman, Committee for Graduate Students
2
Optimal Scheduling of Design Reviews in Product
Development
by
Alberto J. Cividanes
Submitted to the Department of Mechanical Engineering on May 10, 2002
in partial fulfillment of the requirements for the degree of
Master of Science in Mechanical Engineering
Abstract
Technology companies are facing the pressure of today's competitive market, in
which the introduction of new products faster than the competition is crucial for success.
Realizing that the processes they follow in developing their products are a source of
competitive advantage, companies are focusing on the design and effective management
of product development processes. Perhaps the most widely employed process today by
companies developing new products is the stage-gate or phased development process.
This process divides the development effort into distinct time-sequenced stages separated
by management decision gates. When all requirements in a gate review at the end of each
stage are not successfully met and the gatekeepers decide to reschedule the review to give
the team more time to improve their deliverables, the product development project can be
significantly delayed. These delays can have devastating consequences for a company, as
it faces the risk that other firms will deliver competing products much faster and get a
first-mover advantage in a given market.
The Design Structure Matrix has been employed to analyze the impact that the
location of gate reviews can have in the duration of a product development process. A
simulation model has been used to predict the development time with different locations
of the gate review in a process. In general, it is recommended to place the gate review
after the iterations are finished, as it increases the probability of successfully meeting all
the requirements of a gate review at the end of a design stage in a timely fashion. A
concept described as a stage buffer has also been introduced. By placing a buffer at the
end of a stage, a gate review can be scheduled in such a manner that will allow the
product development team to complete their assigned tasks and perform the necessary
iterations on time. Thus, the chances of advancing to the next stage of the process
without delaying the project can be significantly increased. These concepts have been
demonstrated by a real world case study from the automotive industry.
Thesis Supervisor: Steven D. Eppinger
Title: General Motors LFM Professor of Management Science and Engineering Systems
Thesis Supervisor: Ali A. Yassine
Title: Research Scientist
3
4
Acknowledgements
One of the most difficult tasks of writing this thesis was to enumerate all the
people that have helped with my research. First, I wish to thank my family, who
supported me and provided me with the most basic tools to succeed in life.
I would like to thank the faculty of the MIT Center for Innovation in Product
Development for their constant guidance during the past two years. I would like to thank
Dr. Ali Yassine, for supervising me throughout the process of writing this thesis, and Dr.
Bill Finch for making possible the project with General Motors. Special thanks also to
Prof. Steven Eppinger and Dr. Daniel Whitney, for their continuous support and technical
guidance. Also, I want to recognize the following alumni who contributed to my research
with their knowledge of DSM methods: Qi Dong, Cory Welch, and Tyson Browning.
Special thanks also go to the MIT Center for Innovation in Product Development and the
GEM Consortium for their financial support during the past two academic years.
Secondly, I wish to thank the personnel at General Motors R&D for their
continuous support over the summer: David Chang, Bob Lust, and especially the "DSM
Team" formed by Joe Donndelinger, Datta Kulkarni, and Sandy Elnick. Not only they
offered their professional help and guidance with the project, but also their friendship. I
also appreciate the financial support provided by General Motors during the summer of
2001.
I cannot finish this section without mentioning all my friends, especially who
those who spent with me all the long hours in the office: Fredrik, Gennadiy, Gaurav,
Jagmeet, and Peng. I hope you enjoy this thesis.
5
6
Table of Contents
INTRODUCTION...........................................................................................................13
1.1
1.2
1.3
M OTIVATION ...................................................................................................
THESIS O BJECTIVES..........................................................................................
THEsis O VERVIEW .........................................................................................
13
14
15
PROCESS MODELING USING THE DESIGN STRUCTURE MATRIX..........17
INTRODUCTION TO D SM .................................................................................
2.1
2.1.1
2.1.2
2.1.3
2.2
17
The Design Structure Matrix as a process modeling tool.....................17
B uilding a D SM ......................................................................................
22
Partitioningand tearing........................................................................
22
RELATED DSM WORK ON PRODUCT DEVELOPMENT PROCESSES ...........
USING SIMULATIONS WITH DSM MODELS ..........................................................
25
2.3
2.4
CHAPTER SUM MARY .....................................................................................
31
28
IMPACT OF GATE REVIEWS IN PRODUCT DEVELOPMENT PROCESSES.33
3.1
ROLE OF GATE REVIEWS AND PHASES IN A PROCESS ........................................
3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
3.2
3.3
33
Stage-gate product development processes...........................................
Stages ....................................................................................................
Gate reviews ..........................................................................................
Technically orienteddesign reviews .....................................................
Related work on scheduling of reviews .................................................
33
. 36
36
39
40
CURRENT PROBLEMS WITH GATE REVIEWS ......................................................
43
USING DSM TO DETERMINE GATE REVIEW LOCATION AND SCHEDULING........... 48
3.3.1
3.3.2
Using DSM to determine gate review location ...................
Using buffers in the scheduling of design reviews .................................
3.4
CHAPTER SUM M ARY .......................................................................................
48
61
65
CASE STUDY: A STAGE-GATE PRODUCT DEVELOPMENT PROCESS AT
GENERAL MOTORS ................................................................................................
67
4.1
AN OVERVIEW OF THE PRODUCT PORTFOLIO PROCESS .....................................
4.1.1
4.1.2
4.1.3
4.2
METHODOLOGY................................................................................................72
4.3
D SM AN ALYSIS .................................................................................................
4.3.1
4.3.2
4.4
4.5
The Task-based Design Structure Matrix...............................................
Partitioningand Tearing........................................................................
SIM ULATION ANALYSIS..................................................................................
4.4.1
4.4.2
4.4.3
4.4.4
67
Purpose of the study ..............................................................................
67
Overview of the ProductPortfolio and Concept Development Processes 68
Structure of the Concept Development Team........................................
71
Sim ulation Framework..........................................................................
Simulation Results - Concept Development Process............................
Simulation Results - Alternative Phases to the Process .......................
Sim ulation Lim itations..........................................................................
CHAPTER SUMM ARY .......................................................................................
74
74
76
84
84
85
90
93
95
DSM DEPLOYMENT EXPERIENCES.......................................................................97
7
5.1
5.2
5.3
5.4
5.5
DEPLOYING DSM METHODS AT A CORPORATE PARTNER....................................
FORMING THE DSM TEAM AT GENERAL MOTORS ............................................
OBSERVATIONS ON DSM TEAM'S INVOLVEMENT ............................................
OBSERVATIONS ON CDP TEAM MEMBERS' INVOLVEMENT ..............................
C HAPTER SUM M ARY ........................................................................................
97
99
100
103
107
CONCLUSIO NS............................................................................................................109
REFERENCES..............................................................................................................111
APPENDIX A - STANDARDIZED DATA COLLECTION TOOL FOR BUILDING
DSM M ODELS..............................................................................................................117
A .1
O VER V IEW .......................................................................................................
A .2
INTERVIEW SHEET ............................................................................................
117
119
APPENDIX B - DSM MODELS USED IN CASE STUDY.................125
B.1
CONCEPT DEVELOPMENT PROCESS ..................................................................
B .2
A LTERNATIVE PHASES .....................................................................................
125
130
APPENDIX C - LIST OF TASKS IN DSM MODEL................................................135
C. 1
DSM TASKS WITH INPUT AND OUTPUT RELATIONSHIPS ..................................
135
C .2
D SM T ASK KEY ...............................................................................................
139
8
List of Figures
Figure 2.1: Example of a binary Design Structure Matrix..........................................18
Figure 2.2: Three possible sequences for design tasks. (a) Dependent tasks, (b)
Independent tasks, and (c) Interdependent tasks...................................................
19
Figure 2.3: Design Structure Matrix showing different kinds of dependencies...........20
Figure 2.4: Network diagram representation of a DSM...............................................21
Figure 2.5: Partitioned D SM .......................................................................................
23
Figure 2.6: Triangular distribution of task duration.....................................................29
Figure 3.1: Structure of a stage-gate product development process. ...........................
34
Figure 3.2: Example of a typical stage-gate process...................................................
35
Figure 3.3: The coupled tasks and serial process with a design review (DR)..............42
Figure 3.4: Stage-gate process featuring inter-phase iterations. ..................................
46
Figure 3.5: DSM illustrating a gate review located in the middle of an iteration block.. 47
Figure 3.6: Gate review located at the beginning of the project (Case 1)....................50
Figure 3.7: Gate review located after Task 1(Case 2).................................................50
Figure 3.8: Gate review located after Task 2 (Case 3).................................................50
Figure 3.9: Gate review located after Task 3 (Case 4).................................................51
Figure 3.10: Gate review located after Task 4 (Case 5)...............................................51
Figure 3.11: Gate review located after Task 5 (Case 6)...............................................51
Figure 3.12: Gate review located after Task 6 (Case 7)...............................................52
Figure 3.13: Gate review located after Task 7 (Case 8)...............................................52
Figure 3.14: Gate review located after Task 8 (Case 9)...............................................52
Figure 3.15: Gate review located after Task 9 (Case 10)............................................53
Figure 3.16: Gate review located at the end of the project (Case 11)..........................53
Figure 3.17: Mean durations for sensitivity analysis (Rework probabilities)..............58
Figure 3.18: Mean durations for sensitivity analysis (Rework impacts)......................59
Figure 3.19: DSM example with stage buffer. .................................................................
64
Figure 4.1: The product portfolio process and concept development process.............70
Figure 4.2: The non-partitioned 120-task Concept Development Process DSM matrix. 76
Figure 4.3: DSM graphic representation after the initial partitioning algorithm. ......
77
Figure 4.4: The graphic representation of the final re-partitioned DSM model.......78
9
Figure 4.5: Areas od coupled tasks within sub-teams in Concept Development......79
Figure 4.6: Task interdependencies at the end of Phase I.............................................80
Figure 4.7: Architecture Selection Block at the end of Phase 1....................................81
Figure 4.8: Iterations at the end of Phase 2 and most of Phase 3.................................82
Figure 4.9: The Open Issues Block, the CAD Models Development Block, the
Performance Assessment and Balancing Block, and the Business Case Block........82
Figure 4.10: Dynmics of the process in the third category of iteration blocks. ...........
84
Figure 4.11: Case 3 DSM simulation showing that Phase 2 is fully expanded while
Phases 1 and 3 are modeled as a single row..........................................................
89
Figure 4.12: DSM used for Case 5 of the simulation showing the large iteration block is
fully expanded while tasks occurring before and after are modeled as a single row.90
Figure 4.13: Alternative phases suggested for Concept Development Process. .......... 91
Figure B.1: DSM simulation case 1: Phase 1, with Phases 2 and 3 collapsed.......125
Figure B.2: DSM simulation case 2: Phases 2 and 3, with Phase 1 collapsed.......126
Figure B.3: DSM simulation case 3: Phase 2, with Phases 1 and 3 collapsed.......127
Figure B.4: DSM simulation case 4: Phase 3, with Phases 1 and 2 collapsed.......128
Figure B.5: DSM simulation case 5: Large iteration block with other tasks collapsed. 129
Figure B.6: Alternative phases simulation: Phase A, with Phases B, C, and D collapsed.
.................................................................................................................................
1 30
Figure B.7: Alternative phases simulation: Phase B, with Phases A, C, and D collapse
.................................................................................................................................
13 1
Figure B.8: Alternative phases simulation: Phase C, with Phases A, B, and D collapsed.
.................................................................................................................................
13 2
Figure B.9: Alternative phases simulation: Phase D, with Phases A, B, and C collapsed.
.................................................................................................................................
13 3
10
List of Tables
Table 3.1: Simulation results for gate location example...............................................55
Table 3.2: Sensitivity analysis results by varying rework probabilities........................57
Table 3.3: Sensitivity analysis results by varying rework impacts. ..............................
59
Table 4.1: Simulation durations for the full DSM model and base case............86
Table 4.2: Standard durations for each of the collapsed CDP phases..........................87
Table 4.3: Simulation mean durations for the benchmark and five case models.........88
Table 4.4: Simulation mean durations for the alternative CDP phases DSM ..............
92
Table 4.5: Standard durations for collapsed alternative CDP phases. .........................
92
Table 4.6: Simulation mean durations for the alternative phase DSM models.......93
Table C.1: DSM tasks with input and output relations. ................................................
138
Table C.2: D SM task key. .............................................................................................
14 1
11
12
Chapter 1
Introduction
1.1
Motivation
Technology companies are facing the pressure of today's competitive market, in
which the introduction of new products faster than the competition is crucial for success.
Realizing that the processes they follow in developing their products are a source of
competitive advantage, companies are focusing on the design and effective management
of product development processes.
The author spent the summer of 2001 at General Motors conducting a case study
with a team of R&D researchers in which a front-end product development process used
to develop new vehicles was modeled and analyzed using the Design Structure Matrix
(DSM). Two projects were studied, one for the development of the new Buick Bengal
and another for a new version of the Cadillac DeVille, in order to identify areas for
process improvement.
After talking to some of the experts involved in the process, it
became evident that the way the process was executed differed significantly from the way
it was supposed to.
Building a DSM model of the process the way it was actually
executed enabled the team of researchers to identify a number of iterations in the process
that were not originally planned, and to find a very astounding result: activities belonging
to the second stage of the process required information from activities that would not get
started until the third stage in order to be completed successfully. This finding caught the
attention of the key people involved in the project, as in reality that particular gate review
13
had been rescheduled officially three times, delaying the program several months behind
schedule.
The findings of this study at General Motors led to an interest on how the location
of a gate review in a stage-gate product development process can have major impact on
the development time of a new product. As it was the case at General Motors, when all
requirements in a gate review are not successfully met and the gatekeepers decide to
reschedule the review to give the team more time to improve and finish their deliverables,
the product development project can be significantly delayed. These delays, which can
be in the order of several months, can have devastating consequences for a company, as it
faces the risk that other firms will deliver competing products much faster and get a firstmover advantage in a given market.
This thesis uses the Design Structure Matrix (DSM) to explore how the location
of a gate review can affect a product development process.
Also, a case study is
presented in detail in which the development of two new vehicles was modeled using the
DSM.
Thesis Objectives
1.2
The objectives of this thesis are summarized as follows:
1.
Present a review of stage-gate product development processes and the DSM
method.
2. Introduce a method to align gate reviews with the structure of a product
development process as it is executed by using the DSM, and explore the impact
that their location can have on the process duration.
3. Present a case study of a front-end product development process at an automotive
company in which the process was modeled using a DSM.
14
4. Document observations and learning experiences from a DSM deployment
exercise at a corporate sponsor.
5. Provide a standard set of questions for collecting data in a DSM study.
1.3
Thesis Overview
The rest of the thesis is organized as follows:
Chapter 2 explains the Design Structure Matrix (DSM) method and how it can be
used as a tool for analyzing product development processes.
Previous work done by
other researchers using this method is presented.
Chapter 3 introduces the stage-gate product development process and presents the
concept of gate reviews as a quality control check in product development projects. The
impact that the location of these gate reviews can have in the duration of the project is
explored using the DSM methodology.
Chapter 4 presents a case study conducted at General Motors, in which a front-end
stage-gate product development process was modeled with a task-based Design Structure
Matrix. The development efforts of two new vehicles, the Buick Bengal and the Cadillac
DeVille, were selected for the study. The DSM and simulation analyses are discussed in
detail, and the results are presented at the end of the chapter.
Chapter 5 discusses the deployment experiences of DSM methods at General Motors
R&D. Observations on the data collection process, as well as on the process of building
and validating the DSM model are presented. Documentation of these experiences might
provide some useful insights for future deployment exercises of DSM methods from
academia to industry.
15
Chapter 6 concludes the research findings in this thesis. Possible future research
directions are proposed, including the role of gate review locations in quality vs. cycle
time tradeoffs in new product development.
16
Chapter 2
Process Modeling Using the Design Structure Matrix
This chapter introduces the Design Structure Matrix (DSM) methodology as a project
management tool. Previous work done by other researchers using this method is also
presented, with applications for analyzing product development processes. The chapter
concludes by discussing simulation applications that have been developed to expand
DSM analysis.
2.1
Introduction to DSM
2.1.1
The Design Structure Matrix as a process modeling tool
The Design Structure Matrix (DSM) is a useful tool for representing and analyzing
the important relations in a complex system such as a design project.
Originally
developed by Steward for the analysis of design descriptions [52], the DSM is not just a
process model for project management, but also a general framework for analyzing and
improving the engineering process.
The purpose of applying the DSM method to a
design project is to understand the information flow and communication in the design
process, and hence to seek improvements based on better understanding of the system.
Browning identifies two main categories of DSMs: static and time-based [7]. A
static DSM represents system elements that exist simultaneously, such as groups in an
organization or components of a product architecture.
This kind of DSM is usually
analyzed with clustering algorithms. Time-based DSMs, on the contrary, indicate a flow
through time by the ordering of its rows and columns. This kind of DSM is typically
analyzed using sequencing algorithms.
17
One particular type of time-based DSM is the activity-based or task-based DSM.
It is used for modeling processes and activity networks based on activities and their
information flow and other dependencies. An activity-based DSM provides a concise,
visual format for understanding and analyzing the issues in a product development
process.
Since it is time-based, it is especially useful for highlighting iteration and
coupled activities.
This is a major capability of the DSM method that traditional
PERT/CPM (Project Evaluation and Review Technique/Critical Path Method) cannot
deliver.
An example of a binary DSM is shown in Figure 2.1. A DSM is a square matrix,
in which the rows and columns represent the same activities of a process in the same
order.
A B
C D
J
1
1
C
11
D
E
I
1
A
B
E F G H
1
1
1
1
1
F
1
G
1
H
1 1
_1
1
1 1
I
J
1
1
Figure 2.1: Example of a binary Design Structure Matrix.
Each entry in the DSM (marked by a "1" in this example) indicates that the element in
the corresponding column provides inputs to the element in the corresponding row.
Thus, marks along a row indicate the inputs that the activity is receiving, and marks along
a column indicates the outputs that an activity is providing to other activities in the
18
process. For example, in Figure 2.1, a "1" exists in row H, column D. Therefore, H
needs information from D, i.e., D-4H.
In general, there are three ways in which information flow can occur between two
tasks in a design process. Two tasks can be said to be dependent, or in series, if their
dependency imposes a sequential order in which the tasks must be completed. Tasks can
be independent, or occur in parallel, if no information is exchanged between them. The
third possible sequence for two tasks is to be interdependent, or coupled. In this case, the
tasks are mutually dependent, and each requires the output of the other in order to be
completed. Coupled activities must be executed simultaneously with continuous
exchanges of information, or must be carried out in an iterative fashion. Figure 2.2
illustrates these three possible sequences.
BL___
A__i
(b)
(a)
(c)
Figure 2.2: Three possible sequences for design tasks. (a) Dependent tasks, (b)
Independent tasks, and (c) Interdependent tasks.
19
A DSM is built in a way that allows any task to be coupled with any other task in
the process. Thus, it is very easy to identify whether two tasks are dependent (series),
independent (parallel), or interdependent (coupled).
Figure 2.3 shows the same DSM
presented in Figure 2.1, illustrating the type of sequence between some of the tasks.
A B C D E F G H
AM
B
J
I111111
1
Coupled Tasks
1
C
11 1
D
E
I
1
1
1
_1
F
G
1
H
1 1
J
1
_
_
1
_1
1
Sequential Tasks
1 1
1
Parallel Tasks
Figure 2.3: Design Structure Matrix showing different kinds of dependencies.
The matrix entries above and below the diagonal have different significance. A
through J are the tasks in the process that need to be completed in that specified order.
The entries below the diagonal show upstream tasks feeding information to downstream
tasks. For example, in Figure 2.3, there is a dependency in row G, column E, which
means that task E provides inputs to task G. Since E is finished before G, as long as task
G asks, information from E is ready and available. On the other hand, entries above the
matrix diagonal have different effects.
An entry above the diagonal shows upstream
tasks requesting information from downstream tasks.
For example, in Figure 2.3, a
dependency exists in row F, column H, meaning F needs inputs from H. However, since
H is not finished before F, F has to make an estimate on H. When H is finished later on,
20
the initial assumptions made about H have to be compared to the end result. If the initial
assumptions on H are very different from the end results, task F has to be reworked, and
the new result of H has to be checked against the new assumed H until the assumptions
and the results become close enough. Figure 2.4 shows a network diagram representation
of the same process depicted in the DSM in Figure 2.3. As it can be seen, it becomes
very difficult to keep track of interdependencies among tasks in this type of graphical
representation. From Figure 2.4, it is not easy to identify feedback loops in the system,
even though this is a small example of only ten tasks involved in the process. This
example illustrates the usefulness of the DSM method for highlighting iteration in a
process.
A
B
C
E
DJ
G
H
F
Figure 2.4: Network diagram representation of a DSM.
21
2.1.2
Building a DSM
Modeling a process with a Design Structure Matrix requires two representation steps,
followed by an integration analysis.
activities.
The first step is to decompose the process into
Immediately following this step, the information flows among the different
activities must be identified by capturing their respective interdependencies. The third
step is then to arrange the activities into a logical sequential order in a DSM.
The DSM is built by finding persons knowledgeable about each activity and eliciting
their expert opinions about their respective inputs and outputs. It is imperative that the
process modeler must determine the boundary of the process to be modeled and how the
process will be decomposed. A general guideline is to model a process to the level of
detail to which one desires to understand and control the process.
2.1.3
Partitioning and tearing
The presence of iterations is very common in product development projects.
Design iterations require close communications between various parties involved and
usually slow down the progress of the design process. Iterations usually generate
unplanned rework, and create activities requiring additional time such as negotiations,
meetings, etc.
Thus, a common strategy to speed up the design process is to try to
reduce the number of iterations involved and make them faster.
Since the entries above the diagonal in a DSM are potentials for design iterations,
one approach to speed up the product development process is to try to reduce the amount
of entries in the feedback region of the matrix. A common form of DSM analysis that
addresses this issue is called partitioning.This is the process of rearranging the order of
the activities in the process in order to reduce the number of elements above the diagonal
22
or move them closer to the diagonal. The closer a feedback mark is to the diagonal, the
fewer activities are involved in the design iteration, and hence the faster the iteration will
be.
Figure 2.5 shows the same matrix in Figure 2.1 and Figure 2.3 after partitioning.
The sequence of the process activities has changed, and as a result, fewer elements are
above the diagonal. The new rearranged sequence given by the partitioning algorithm is
the most efficient way is to complete tasks A through J.
I
A B C D E G F H J
I
A
I
I
D
E
1
G
F
1"
H
1
J
A
1
1
1
1i;
1
1
Figure 2.5: Partitioned DSM.
However, several feedback marks cannot be moved below diagonal no matter
how the order of rows and columns are rearranged. These feedback marks above the
diagonal create iteration loops in the process. In Figure 2.5, the shaded areas represent
three small iteration blocks that are still present in the system after the partitioning.
Iteration blocks in a DSM can be classified as either planned or unplanned. Since the
design process is inherently iterative by nature, a number of iterations are purposely
planned in a process to improve the quality of the design. These iterations are necessary
23
in a product development process, and are encouraged as long as they are carefully
planned and managed. On the contrary, unplanned iterations should be eliminated from a
design process. These often occur due poor communication among project members, and
to a lack of understanding of the dependencies among activities. Unplanned iterations are
a major source of rework in a process, and can have a negative impact in its duration.
The DSM, however, can be very helpful in identifying unplanned iteration blocks.
Partitioning a DSM orders the tasks as much as possible according to the
sequential dependencies of the tasks. The analysis of a partitioned DSM reveals which
tasks are sequential, which are parallel, and which are coupled. A block with above
diagonal marks identifies a group of coupled tasks that include the cyclic information
flows. A rearranged DSM can prescribe an improved process architecture, such that
information is created at the right time and unintentional iteration is minimized.
There is another strategy called "tearing" to decompose blocks in a DSM, which
can be implemented after the partitioning analysis is performed. A large, loosely coupled
group of tasks can sometimes be split up into two or more smaller, more tightly coupled
groups by removing a single task dependency (one mark in the matrix).
Steward
suggested the tearing method to minimize the iteration time of an iteration loop [52].
Steward defines tearing as to choose the marks so that if they were removed from the
loop and the variables in the loop were re-ordered by partitioning, no marks would appear
above the diagonal. This means having made these estimates, no additional estimates
need to be made. Tearing is also a way to find out the critical-to-speed elements in the
system.
Gebala and Eppinger proposed an algorithm that reduces the number of removed
tasks [23]. The tearing algorithm to minimize the number of tears is as follows:
24
1)
Schedule the tasks with a minimum number of input streams (initially there
will be none). These tasks have the minimum number of row elements in a
DSM. If there is more than one such task, select the one with the maximum
number of output streams. These tasks have the maximum number of column
marks. If this step fails to identify a unique task, compare the number of steps
required to reach all the other tasks under consideration. Select the task that
requires the maximum number of steps. If the lists are of equal length, the
choice is irrelevant.
2)
Remove the scheduled task from consideration and repeat step 1 until all tasks
have been scheduled.
2.2
Related DSM work on product development processes
Additional research has been developed to explore the applications of DSM
methods to product development from new angles. Besides using the binary DSM, many
researchers have explored assigning numerical values to the DSM off-diagonal entries to
indicate the strength of dependencies. In this way, instead of considering all the relations
with equal importance, one may ignore those less critical relations and only include the
important relations in an iteration loop. By doing so, the size of an iteration loop may
decrease, and the development project can go through faster. A good example of this
method is illustrated by McCord and Eppinger [32].
25
Pimmler and Eppinger not only assigned the dependency level to the interactions,
but also categorized the interaction in order to present more details of the design process
[40]. They also first used the DSM to decompose design teams.
Eppinger et al. present the decoupling and add-coupling of task dependencies in a
product development process [20]. In most design projects, there is always a trade-off
between the quality of the design and the speed of the design. De-coupling is a method to
remove some of the dependencies between tasks so that the iteration loops will be
smaller. However, since some of the information transfer is missing, the quality of the
design might be hurt. Add-coupling, on the other hand, is to add information transfer
among tasks to enlarge the iteration loop. The result is an increased design quality.
Concurrent engineering is an example of add-couplings.
McCord and Eppinger used DSM methods to study the integration problem in
systems [32].
They used a team-based DSM to analyze an automobile engine
development organization.
Smith and Eppinger [50] first evaluated the convergence of the design iterations.
They have provided sequential, parallel, and hybrid iteration models that analyze project
cycle time and highlight which activities contribute the most to delaying design
convergence.
Krishnan et al. developed a framework for overlapped sequential tasks [30]. They
explained appropriate overlapping strategies based on upstream information evolution
and downstream iteration sensitivity.
Carrascosa et al. [9] used DSM to develop a model to estimate the probability of
completing a product development project over time, where the model uses the concepts
of Probability of Change and Impact. The model incorporates a stochastic element that
26
represents the likelihood of changes resulting in task iterations. In such a model, most
parameters have a default value representing the best guess or the default solution. The
probability of change of a parameter represents the likelihood of the default value
changing over time. Similarly, the impact quantifies the effect of a change on the task
receiving the information.
The model, however, has some limitations, as it does not
consider learning effects. Another limitation is that there is no control present in the
evolution of the product development process. Lastly, the number of tasks that the model
can handle is very limited due to computational limitations.
Browning has used Design Structure Matrices to address product development
cycle time reduction challenges [6]. He highlights the two greatest advantages of DSM
capabilities to manage projects for reduced schedule risk and shorter cycle time: 1)
Concise representation of complex processes, providing a systems view, and 2) Clear
rendering of potential iteration in such processes. These advantages can help project
managers minimize cycle time by identifying and classifying iterations as intentional or
unintentional, minimizing unintentional iterations, and properly managing intentional
iterations to make them faster and fewer.
Yassine et al. provide a method for quantifying the off-diagonal dependencies
based on information variability and sensitivity [62].
Eppinger et al. used the DSM method to identify patterns of product development
interactions in three different domains: development organization, product architecture,
and product development process [18].
Most recently, Dong and Whitney devised a technique to obtain a Design
Structure Matrix (DSM) from a Design Matrix (DM) used in Axiomatic Design [16].
This technique allows obtaining the design information flow pattern at an early stage of
27
the design, and applying the DSM system analysis and project management techniques at
a time when the most important decisions about the design and the system are made. The
second significance of this technique is that the resulting DSM gives a design process
driven by the functional requirements, since the DSM is converted from the DM, which
captures the requirements flow-down information.
Therefore, the resulting process
captures the underlying structure of the design problem rather than capturing the as-is
process like the traditional DSM method does. Third, this technique can be used to
manage requirements flow down and capture system level design knowledge.
2.3
Using simulations with DSM models
Several researchers have extended DSM analysis methods with simulation models
primarily to predict product development time. Browning developed a DSM simulation
model that integrates project cost, schedule and performance [8]. Unlike previous models,
Browning's model treats rework probability and rework impact separately, treats task
durations as random variables, and applies a learning curve to the duration of reworked
tasks. The model assigns both rework probabilities and rework impacts to each instance
where interdependence between design activities was identified.
Thus, the rework
probability associated with two tasks is the chance that one of the tasks will need to be
reworked upon completion of the task providing the input information. Although rework
may be required of a design task, rework of the entire design task may not be necessary.
The rework impact percentage provides the fraction of original task duration that would
be required in the event that rework was required.
28
The model also treats design task durations as random variables with triangular
distributions for mathematical convenience. Estimates of the most likely value (MILV),
best-case value (BCV), and worst-case value (WCV) provide the endpoints of the
triangular distribution. Figure 2.6 illustrates the probability distribution function of the
design task duration as modeled by Browning.
BCV
MLV
WCV
Design Task Duration
Figure 2.6: Triangular distribution of task duration.
With probabilistic task rework and randomly distributed task durations, output
project duration will be a continuous random variable. The stochastic, simulation model
generates distributions of possible cost, schedule, and performance outcomes.
Welch extended the scheduling portion of Browning's simulation model to permit
partial overlapping of interdependent tasks, thus allowing concurrent development to be
modeled [57].
The primary reason was that the algorithm developed by Browning
required that a downstream task could not begin until the upstream task on which it is
dependent is 100% completed. Browning's algorithm permits activities to be performed
29
in parallel only if the downstream task does not rely on the upstream task for any
information (i.e., no task interdependence). In reality, more and more programs are
designed as concurrent engineering programs. That is, activities dependent on one
another proceed, at least to some extent, in parallel and extract information as they
progress. While a design task may require information from another upstream design
task, it is not always the case that 100% of the upstream task must be completed before
the downstream task may commence. To account for a degree of overlap between tasks
that were interdependent, an additional matrix was created.
Welch also modified Browning's algorithm to apply a learning curve to the
rework probabilities rather than to the task durations.
This way, the modeling of
"learning-by-doing" has been revised to permit rework probabilities to be dynamic rather
than static. Browning's algorithm assumed that the likelihood of reworking a design task
would be constant regardless of the number of iterations of that design task. However, the
case study presented by Welch indicated that the likelihood of reworking a design task
should indeed be reduced with iteration of the design task.
Cho developed an integrated project management framework for complex
engineering projects [10]. The integrated method he created streamlines project planning
and control using three modules: structuring, modeling, and scheduling. The structuring
module uses the DSM method to structure the information flows among tasks and
identify the feedback loops in the project. A critical dependency path is determined by
classifying the various types of information dependencies, and redundant constraints are
removed for modeling and scheduling analyses. In the modeling module, a generalized
process model predicts complex behaviors of iterative processes using advanced
simulation techniques. The model computes the probability distribution of lead time and
30
identifies critical paths in a resource-constrained project. Results from both modules are
then used to develop a network-based schedule in the form of a PERT or Gantt chart in
the scheduling module of the framework. Project managers can use this schedule as a
basis for monitoring and control of projects.
2.4
Chapter Summary
The Design Structure Matrix (DSM) has been introduced in this chapter as a
useful tool for representing and analyzing the important relations in a complex system
such as a design project. The DSM method can be applied to a design project in order to
understand the information flow and communication in the design process, and hence
seek improvements based on better understanding of the system. A literature review has
been presented describing the previous research that has been conducted applying the
DSM to product development processes.
The chapter concludes by discussing the
simulation models that have been developed that use the DSM as a basis for modeling a
design process.
31
32
Chapter 3
Impact of Gate Reviews in Product Development
Processes
The stage-gate product development process is introduced in this chapter, along with
the concept of gate reviews. The role that gate reviews play in a process and the impact
that their location can have on the overall duration of the process are explored using the
Design Structure Matrix.
3.1
Role of gate reviews and phases in a process
3.1.1
Stage-gate product development processes
A product development process can be defined as a disciplined and defined set of
tasks, steps, and phases that describe the normal means by which a company repetitively
converts embryonic ideas into salable products or services [41]. Different development
processes have been employed by companies in response to the increased pressure that
they receive to deliver new products to market at a faster pace. Some of the most
common types of processes include the waterfall or stage-gate process, the spiral process,
the design to schedule/budget process, and the evolutionary delivery process [54].
Perhaps the most widely employed process today by companies developing new
products is the stage-gate, also known as phased development process. Popularized by
Cooper [13] in recent years, the stage-gate process divides the development effort into
distinct time-sequenced stages separated by management decision gates. In each stage,
multifunctional teams must successfully complete a prescribed set of related crossfunctional tasks prior to obtaining management approval to proceed to the next stage of
33
product development.
Figure 3.1 shows a graphical representation of the general
structure of a stage-gate process. It shows how each stage of the process is followed by a
gate review, where decisions are made whether to proceed or not to the following stage.
Stage/
Phase N
Stage/
Phase 2
Stage/
PhaseI
Decision
Point I
Decision
Point N-1
Figure 3.1: Structure of a stage-gate product development process.
Most firms that have adopted stage-gate processes have typically moved to these
from more sequential phase review processes, which are characterized by the lack of
interaction among different functions. This kind of phase review process is a staged
product development process in which one function completes a set of tasks, and then
passes the information they generated sequentially to another function that in turn
completes the next set of tasks and passes everything along to the next function. In these
types of product development processes, which are also referred to as baton-passing
processes, multifunctional teamwork is largely absent. Thus, most firms have found more
effective
to move
away from
these processes
to stage-gate
processes
using
multifunctional teams [41].
The framework of the stage-gate process includes workflow and decision-flow
paths and defines the supporting systems and practices necessary to ensure the process's
ongoing smooth operation. These processes have a great deal of appeal to management,
34
because basically they restrict investment in the next stage until management is
comfortable with the outcome of the current stage. The gate can be an effective tool for
controlling product quality and development expense [35].
Stage-gate processes also
focus attention on the quality of execution, and ensure that no critical steps of the process
are omitted [42].
Figure 3.2 shows an example of a typical stage-gate process consisting of six
stages. The first stage consists of product planning, which typically has a very strong
presence of marketing and the project management team. Concept design is the second
stage, followed by a System-level design stage in which all the marketing needs are
translated into engineering specifications. In the fourth stage, detailed engineering design
of the product is performed. Once all the requirements for this stage are satisfied, the
product is ready for testing. The final stage then becomes the release of the product.
Product
planning
Concept
design
System-level
design
Detailed
design
testing
Product
release
Figure 3.2: Example of a typical stage-gate process.
35
3.1.2
Stages
In the stages, members involved on the project team undertake key tasks to gather
information needed to advance the project to the next gate or decision point. Each stage
contains a set of prescribed and concurrent activities. It is important to remember that the
majority of the activities during a stage are executed in parallel, and not only in sequence.
Another important aspect of stages is that they are cross-functional [42]. Thus, there is
no function specific stage, but rather, each stage consists of a set of parallel activities
undertaken by people from different functional areas in the company, working together as
a team and led by a project team leader.
3.1.3
Gate reviews
The gate is a point at which a management decision is made to allow the product
development project to proceed to the next stage, to recycle back into the current stage to
better complete some of the tasks, or to terminate. This type of review is referred to as a
stage-gate review, phase-gate review, phase review or phase approval. The term "gate"
implies that the project must go through this step in order to continue on. The number of
gates varies by company. At these decision points located between stages, the decisionmakers, also called gatekeepers, can choose to Go, Kill, Hold, or Recycle the project. The
gatekeepers are typically a group of managers who serve as advisors, decision-makers
and investors in the process. Using established business criteria, this multifunctional
group reviews new product opportunities and project progress, and allocates resources
accordingly at each gate. This group is also commonly called a "Product Approval
Committee" or "Portfolio Management Team" [41]. The management team that conducts
these reviews usually stays constant across all projects to bring consistency to the review
36
process and to maintain a comparative perspective among projects so that they better
recognize the good projects and the projects that are in trouble. This team might be one
and the same as a products committee or a product development steering team that
manages the development pipeline, screens projects, and establishes project priorities.
Effective gates are central to the success of a fast-paced, new product
development process as they serve as "quality control" control checks.
At a gate, the
previous stage is reviewed and it is checked whether it has been executed in a quality
fashion. It also allows the evaluation of the performance of the project team, and the
attractiveness of the project from an economic and business standpoint.
By making
Go/Kill decisions at a gate review, gatekeepers can prioritize projects and filter those that
do not look promising. Finally, gates are also resource allocation decision meetings.
These meetings are generally staffed by senior managers from different functions, who
own the resources the project leader and team require for the next stage.
Cooper [12] describes the common format that gates have:
" Deliverables:
These are the inputs into the gate review - what the project
team delivers to the meeting. These are the results of the actions taken in the
previous stage, and are based on a standard menu of deliverables for each
phase.
" Criteria: These are the questions or metrics by which the project is evaluated
in order to make the Go/Kill and prioritization decision.
"
Outputs: These are the results of the gate review - a decision about the
project (Go/Kill/Hold/Recycle). An action plan is usually approved, and the
dates and deliverables for the next gate are agreed upon.
37
Cooper [41] considers three kinds of gate reviews, which can be implemented
depending on the maturity of the process. A "Rigid Gate" is a review point in a stagegate process at which all the prior stage's work and deliverables must be complete before
work in the next stage can commence.
On the other hand, a "Flexible Gate" is a
permissive or permeable gate in a stage-gate process that is less rigid than the traditional
"go-stop-recycle" gate. These gates are useful in shortening time-to-market. A permissive
gate is one where the next stage is authorized although some work in the almostcompleted stage has not yet been finished. A permeable gate is one where some work in a
subsequent stage is authorized before a substantial amount of work in the prior stage is
completed. The third type of gate review is the "Fuzzy Gates". Fuzzy gates are
conditional or situational, rather than full "go" decisions. Their purpose is to try to
balance timely decisions and risk management. Conditional go decisions are "go,"
subject to a task being successfully completed by a future, but specified, date. Situational
gates have some criteria that must be met for all projects, and others that are only
required for some projects.
When companies start with an ill-defined process or lack any type of stage-gate
reviews, "hard" stage-gates or "rigid gates" are usually established. This means that the
review must be successfully conducted before the program proceeds. When a welldisciplined development process is in place and development personnel are used to stagegate reviews, the organization is positioned to move to "soft" stage-gates. Soft stage-gate
reviews allow the project to proceed in parallel with conducting the review, thereby
reducing time-to-market. In other words, there are no "hard" stops while the team
prepares for and conducts the review. For newly established stage-gate processes, a
pilot gate meeting is usually organized. This is a trial, informal gate meeting usually held
38
at the launch of a stage-gate process to test the design of the process and familiarize
participants with the stage-gate process.
3.1.4
Technically oriented design reviews
Another kind of review that is held throughout a product development process is
the technically oriented design review [35]. There are typically several types of design
reviews that occur at different points in the new product development process. These
design reviews are placed at a point in the process where there has been development of
some aspect of the product or process design that should be assessed before the project
continues based on those technical decisions. These reviews are intended to provide an
independent assessment of either the documented requirements for the new product, the
concept of the new product, the design of the new product, the process design to
manufacture and support the new product, or the readiness to put the new product into
production. These design reviews are not only a method to help verify the design of the
product, but also a means to reduce the risk associated with the new product.
Development personnel should learn to value design reviews as a means to reduce
program risks and increase program success. Design reviews are conducted with a design
review team composed of experienced, senior-level personnel who understand the
technology involved in the program and its associated technical risks. These personnel
should not be directly involved in the program in order to provide an objective
perspective on the program. Design review team members are chosen to match their skills
and expertise to the requirements of the project. The team is multi-functional to address
all the subject matter and issues covered during the review. The team may stay in place
39
for the project or new personnel may be added and existing design review team members
dropped as the project evolves in its development cycle.
Design reviews, while technically focused, are not limited to just the design of the
product. They must address all the life cycle requirements of the product as well as the
program requirements such as cost, schedule and risk.
3.1.5
Related work on scheduling of reviews
Ha and Porteus developed and EOQ-like model to determine an optimal review
policy in concurrent design for manufacturability [26].
The model, which seeks the
timing of the progress reviews to minimize the total expected project completion time,
has the following tradeoffs:
completion
time
by
Reviewing too infrequently can increase the project
preventing
process
design
work from
being
conducted
simultaneously with product design work and increasing the changes that extensive
product redesign work must be conducted, whereas reviewing too frequently can cause
too much time to be spent on the reviews that would otherwise be required. In their
study, it was found that frequent reviews have two benefits: (1) (Parallel development)
manufacturing process designers receive sufficient information about the design to enable
them to work in parallel with the product designers, (2) (Quality control) flaws in the
design are discovered soon after they are introduced, saving the time and resources
required for redesign later. The disadvantages of frequent reviews is that each review
requires setup/penalty time that otherwise would not be required.
In the formulation of their model, Ha and Porteus postulate that each time a
review takes place, a certain amount of "setup" time is required. This setup time consists
of ordinary setup time plus penalty time. The ordinary setup time consists of the time to
40
get organized for the review, construct prototypes if necessary, prepare documents and
communication material, coordinate meetings, travel, and account for lost productivity
due to refocusing on new tasks. The penalty time consists of the additional time required
to carry out the review and conduct redesign work, if any, due to carrying out the review
at that time. Unfortunately, the model does not encompass a broad range of concurrent
design issues.
Ahmadi and Wang [1] developed a model extending the line of study started by
Ha and Porteus.
In their model, they describe how design reviews and engineering
resources can be scheduled as the control mechanisms to operationally manage
development risk. They have found that companies that focus on the performance cost
dimensions of the development risk typically conduct many design reviews with various
layers of management involvement. These reviews try to minimize development risks at
the expense of additional overhead and increased project lead-time.
However, an
inappropriate scheduling of management involvement, as well as both under- and overspecifications of product development risk, typically results in extended project
completion time. Thus, the key challenge faced by their model is to schedule an ideal
level of management control by allocating appropriate engineering resource and choosing
the optimal review frequency and review acceptance levels at each design stage.
In the formulation of their model, Ahmadi and Wang assume that a design review
could be placed only at the end of a design stage, and evaluates only design stages that
follow the last review. They also define process confidence as a measure of design
conformance quality and the perceived engineering reliability of the product to be
designed. Stage confidence is also defined for each design stage, as a measure of the
41
degree of compatibility and closeness of the design to its target specifications at that
stage.
Mori et al. [34] combined DSM and graph theory to propose an approach
for
modeling and planning design processes as well as strategic scheduling of design
reviews. Initially, a DSM process model that represents task dependencies provides the
input for the optimization of the design process leading to a graph-based process model.
The DSM is decomposed into blocks for simplification of the process. However, it can
often occur that a block is too large and involves numerous tasks within a DSM. For
example, the algorithm cannot decompose the process further because the internal tasks
within the block are coupled too tightly. Thus, they propose one approach to deal with
such a large block by reorganizing the information flows within the coupled tasks by
strategically
scheduling design reviews. Figure 3.3
illustrates this concept of
decomposition of a block by strategic scheduling of design reviews:
A
B
(a)
DR
(A , B )
A
B
l.........................
(b)
Figure 3.3: The coupled tasks and serial process with a design review (DR).
Consider an example of coupled tasks, as shown in Figure 3.3 (a). The execution
of task A requires the output of task B, while task B requires the output of task A. The
42
coupled tasks either must be completed simultaneously with continual exchanges of
information or must be carried out in an iterative manner. Figure 3.3 (b) shows the
serialized process with the addition of a design review. A design review discusses the
interface between task A and task B leading to an agreement on the required information
for the process coordination.
Based on the agreement, the team performs task A in
advance, and then passes the output of task A as an input to task B. To check the
compatibility, there is a weak dependency from task B to task A. Basically, the idea is to
replace a strong dependency from task B to task A by a weak dependency and a design
review that supplements the required information. This step reorganized the information
flows among tasks and reduces iterations.
Although a design review facilitates sharing of information across the different teams,
frequent meetings are time consuming. Therefore, one needs to reduce the number of the
design reviews as well as the number of iterations. The algorithm developed by Mori et
al. strategically schedules the timing of design reviews and minimizes the number of
reviews held.
3.2
Current problems with gate reviews
Although stage-gate product development processes have proved to be very
effective for companies to develop new products and bring them to market, it is important
to understand why sometimes a project does not meet successfully all the requirements
established at a gate review and necessary to advance to the next stage.
The most common problem why projects fail at a gate review is the lack of
information or time to meet all the requirements. This problem is created by the structure
43
of the product development process, due to a bad choice for the location of a gate review.
Processes are generally designed and gates scheduled based on estimates of how long the
project is expected to last, and on the company's desired timing for launching the product
to market.
However, at the operational level the project might sometimes be run very
differently from the way it is supposed to be. Engineers and other project team members
usually face a number of unexpected hurdles that might not allow them to follow the
process exactly the way it was designed.
For example, when a process is newly
implemented, a few projects might be required to go through the process in order to get
the optimal process working.
It is only through real experiences in real product
development processes that a project management team can maximize the efficiency of
the process. Newly implemented processes typically also face the challenge of a lack of
understanding by project team members of the process itself, and the deliverables for
which they are responsible. This lack of familiarity with the process can have negative
consequences on the overall duration of the project.
Another common issue that product development teams face is that when stagegate processes are designed, these might not be aligned with the resource capabilities of
the company, which in many cases can be easily overestimated. Some examples of this
kind that can create unplanned rework in the project include the lack of availability or
accessibility of carryover CAD data, or the lack of availability of designers to be assigned
to work with engineers.
There are several other sources of rework in a product development process that
are not accounted for in the design of a stage-gate process. Some of them are potential
conflicts with the suppliers.
Problems range from suppliers going out of business to
44
suppliers informing the group that they cannot complete the part as specified. In some
cases, the purchasing organization is able to develop a fast workaround, while in others,
the product is held up for redesign and testing. In other cases, major problems can be
faced when a major functional activity is not fully integrated with the rest of the product
development team due to internal conflicts within the organization.
Constant
organizational changes inside the company can also be a source of unplanned rework.
Last minute decisions taken by high-level management regarding the direction of the
product can be another example of the numerous unexpected problems that a product
development team can face. In the automotive industry, this can translate to a sudden
change in architecture selection in the middle of the development process. Lastly, when
an innovative major technology that was supposed to be introduced in a new product is
not ready for implementation can significantly affect of developing that product.
When all gate requirements are not successfully met and the gatekeepers decide to
reschedule the gate review to give the team more time to improve and finish their
deliverables, the product development project can be significantly delayed. These delays,
which can be in the order of several months, can have devastating consequences for a
company, as it faces the risk that other firms will deliver competing products much faster
and get a first-mover advantage in a given market.
Thus, it is desired that inter-phase
iterations be minimized to increase the probabilities of meeting successfully all the
requirements of a gate review. Figure 3.4 shows a schematic of a stage-gate process
allowing inter-phase iterations.
The dotted arrows represent this kind of inter-phase
iterations, which occurs when all the requirements in a gate review are not successfully
met because tasks in one stage require information from tasks in the subsequent stage.
The spiral arrows represent intra-phase iterations, which are expected to occur within
45
each stage and in most cases are necessary to effectively satisfy all the requirements at
the end of the stage.
Phase gates
Stage/
Phase
e
iAtStage/
:...........
Phase 2
Stage/
Phase N
--------
Inter-phase
iterations
Intra-phase
iterations
Figure 3.4: Stage-gate process featuring inter-phase iterations.
A Design Structure Matrix of a product development project can be very useful in
helping identify the location of a gate review with respect to the iteration loops in the
process.
By developing a DSM at the operational or "as-is" level of the project,
unintentional iterations can be easily identified.
This DSM can show any potential
differences between the way a project is executed in reality and the way that it was
originally designed to be. A DSM allows identifying the natural structure of a process as
it is actually executed, and evaluating the validity of the location of a gate. Figure 3.5
46
shows an example in which a DSM captures a gate review in the middle of an iteration
block due to unplanned iterations.
lu
IA
A
B
D
C D
E
W G
F
H
I
19
B
C
E11
1
F
GATE REVIEW
1
1
G
1
11
1 ~1
!1:
1
H
B
I
11
1
1
Figure 3.5: DSM illustrating a gate review located in the middle of an iteration block.
When gate reviews are not successfully satisfied in their entirety, it is believed
that the reason will be one of the following: (1) there is a shortage of information and
many assumptions have to be made and used as placeholders until the required data is
available, (2) there is a shortage of time to finish the deliverables, or (3) there is a
shortage of both information required and time necessary to complete the tasks.
At times, a product development team cannot succeed at the gate review because
team members were missing important information to complete their tasks in a proper
47
manner.
In many cases, this information must be provided by tasks that are initiated
after the gate review, at the subsequent stage. Thus, assumptions have to be made, often
leading to not meeting successfully the requirements of the gate review and thus delaying
the overall product development process if the gatekeepers determine that the review
should be rescheduled for a later date. This situation can occur even when the team has
ample time prior to the gate review to work on their deliverables.
On many occasions, a product development team runs out of time to finish all the
deliverables required to successfully "pass" a gate review. This can happen even though
the team members have access to all the information that they require to finish their tasks.
When the project does not face any special circumstances outside of the control of the
members of the team, a possible reason for such a situation is that the gate review for that
stage was scheduled at a date earlier than what would have been necessary to properly
complete all the tasks. Given the complexity of new product development projects, very
often a shortage of both time and information can harm the project at the end of a stage.
3.3
Using DSM to determine gate review location and scheduling
3.3.1
Using DSM to determine gate review location
In this section the Design Structure Matrix method is used to analyze the effect
that the location of a gate can have on the overall duration of the project. It is suggested
that the first step is to construct a DSM of the product development process based on
interviews with the team members involved in the project to identify the proper tasks in
the process and their respective interdependencies. This DSM model will highlight any
48
possible discrepancies between the way the process was designed and the way that it is
actually executed.
A DSM analysis using the partitioning algorithm should then be
performed to obtain the best possible sequence in which the tasks should be performed to
minimize iterations. Even after performing the partitioning, a case might be given in
which the gate review is located in the middle of an iteration block as in the example
presented in Figure 3.5. Such a block has the presence of an inter-phase iteration, in
which team members require information from tasks performed at a subsequent stage in
order to properly complete their tasks. Given that this information is not available prior
to the gate review, the chances of not "passing" the gate review successfully can increase
dramatically. Basically, the probability of not "passing" the gate review can be defined
to be equal to the rework probability associated with a feedback mark across the stages.
Given that this kind of iteration is unplanned, a DSM proves to be a very powerful tool
that allows the project management team to see what is really happening in the project
and identify such irregularities that might be causing failure at the gate review.
An example is presented to study the impact of gate reviews, found within an
iteration block, on the duration of a project.
The example shows a simple process
consisting of ten activities and a few iteration blocks in the system.
The method
employed is to place a gate review after each task (one at a time), and use the scheduling
portion of the simulation model developed by Browning [8] to predict the duration of the
process. Figures 3.6 through 3.16 show the DSM of the process, with a different location
of the gate review in each case.
49
GR 1
2
3
4
5
6
7
8
9 10
Gate Review
...............
................
................
...............
................
................
................
................
................
1 ...............
x
...............
................
..........
................................
.
...............
................
.....
2 ...............
x ...
...............
...............
...............
................
...............
...........
3 ................
x
x
...............
............... . ................
................
4 ...............
..........
................
...............
........
................
....
........
..... .......
...............
5 ...............
x
X:
.............
.................
x
x
6 ...............
x ....
.....
.........
................
................
...........
................
.................
7 ................
x x
.......
........
................
................
................
8
x
x
x
..............
................
................
................
9
10
.................
x
x
x
...................
...............
.............
................
...............
................
................
................
................
x
x
x
Figure 3.6: Gate review located at the beginning of the project (Case 1).
I
GR 2
3
4
5
6
7
8
9 10
I
Gate Review
........
.......
................
...............
................
.......
.......
.................
................
................
2 ........ x
................
...........
................
...............
.........
.....
3 ...............
...
....
...........
. ..........
...............
...............
4 ...............
x ..
x
x ................
.............
..........
......
........
................
.........
.....
..............
5 . . .x. . . . . . . . . . . . . . . . . . . . .
x
x ..
6 ...............
x
............
........
......
...............
..............
...............
................
...............
...............
7 ...............
x
.............
...............
...............
...............
..........
....
...............
..........
8 ...............
x
x
x
...............
.................
................
X
9 ...............
x ...............
x ..............
.................
...............
........
.....
.................
................
..................
10
x
x
x
Figure 3.7: Gate review located after Task I (Case 2).
1 2 GR 3 4 5 6 7 8 9 10
.....
.......
............. .
...............
. .....
. ........
2
-----------------------Gate Review ..
...........
.
...............
.........
....
..
..........
................
.
....
................
..........
x
3
x x
..........
...............
4 ...............
x ................
x
x ...............
..............
................
................
...............
...............
5 x ..............
x
.........
x
x
6 ......
............
.......
...............
................
.............
..........
....
.............
........
...............
V
i
V
i
7 ...............
x....
..........
.....
......
.............
.............
.........
..............
................
a ...............
x
x I
x
...............
...............
................
9 ......
X:
I................
x .. .......
x
..............
.........
....
......
............
................
....
...
10
x
Figure 3.8: Gate review located after Task 2 (Case 3).
50
1
2
3 GR 4
5
6
7
8
9 10
1
................
................
2 ................
x
3 ................
x
x
...............
Gate Review ................
x
xixL
...............
...............
...............
................
:x
4 ................
x ix
x ................
...............
...............
..........
..........
5 ................
x ..........x
:x
.X
x ...............
6 ................
................
.....
........ ..............
...............
...............
................
7 ................
X:
x
x ...............
.................
..........
...................
..............
...............
................
................
8
X:
x
x
!x
9 ................
X: ...............
...............
................
..............
.:x
.................
................
................
x
................
...............
................
................
...............
................
10
:x
:x
Figure 3.9: Gate review located after Task 3 (Case 4).
1
2 3
4 GR 5 6
7 8
9 10
.................
.................
2 ..................
X
3 ................
x
x x
................
X: ................
x
x
................
.................
Gati
................
................
................
.....
..... ................
................
................
.................
5 .................
X: ..
X:
x
X
..............
6 ................
...............
................
.:x
................
.................
................
.................
.....
..........
.................
7 .................
.......
................
.............
.......
.
.................
............
................
................. ................
:x
X!
8 .................
................. x
:x
9 .................
:x
.................
.................
................
.................
.................
:x
................
10
.................
........
........
x
x
Figure 3.10: Gate review located after Task 4 (Case 5).
1
2 3
4 5 GR 6
7 8 9 10
.................
..................................
................
2 ...........
X.....
.....
.
..........
3 ................
x
.................
4 ................
X ................
x
x
...........
......
.........
5 .........
X......
. x
................
Gate Review ................
X .................
x ............
x ...
x ..................
x
.................
6 .........
x ................
x ............
x .......
x..........
x
....
................
....
..............
....
............
........
......
................
7 ................
x
................
................
................
................
.........
.. x x
8 ................
x
x
x
....
...........
...........
9 ................
X ................
:
x
x
.................
.................
...............
:
...............
.............
! ..
................
.................
101
ix i
Figure 3.11: Gate review located after Task 5 (Case 6).
51
1
2
3
4
5
6 GR 7
8
9 10
1
.............
...............
................
................
...............
2 ...............
x
...............
.. . .................
3 ...............
x
x
................
4
5
x
x
x
...............
................
......
..
x
x
6
................
x ..........
x
Gate Review ...............
x
I
x .....
x ...............
x ...............
x ................
x ..........
................
7 ...............
x
x
X: ................
x
...............
...............
...............
8 ...............
x
x
x
...............
..........
9 ...............
x
x
x
................
10
x
x
x
................
................
...............
..............
.............
................
................
...............
......
................
........
................
Figure 3.12: Gate review located after Task 6 (Case 7).
2
1
1
3
4
5
6
7 GR 8
9 10
.................
..............
................
................
................ ................
2 ........
3 ................
-771 ...........
....
.............
4 ................
x ...............
x
................
. . .x. . . . m
................
..............
5 ............
XE
x ...
................
6 ................
x
x
.
...............
...............
.....
....
..........
..................
.........
:x
X:
7 ................
.....
...............
...............
.....
................
Gate Review ................
:x
X:x
X ...............
................................
................
...............
...............
8 ................
X::
..x
............
................
X
Xx
x:x
... .............
................
9 ................
x ....
x
x ..
................
............
...............
.....
...........
.........
...............
.................
10
x
x
X:
Figure 3.13: Gate review located after Task 7 (Case 8).
1
2 3
4
5
6
7
8 GR 9 10
........
................
.................
.................
................
.................
2 ........
........
................
...............
3 ................
x
x
...............
...x
.....
4 ................
x
X ...............
x
. . . x. . . . . ..............
................
................
................
5 . . . X:
x
x
. . . . . . ................
1
x
6
7
8
x
x
x
x
x
...............................
........
................
.................
................
X:
x
...............
..............
................
...............
........
...
x
...............
X;
7
.:x
................
:x
.................
................
B*
x . . . x. . . . . ..................
Gate Review . . . x. . . . . . . .x. . . . . . . . .x. . . . ..
x
x ...............
x ................
.............
..............
9 . . . x. . . . . . . . . . . . . . . . . . . . . .............
x
x
x
. . . . . . . . ...............
...............
................
..................
10
x
x
x
Figure 3.14: Gate review located after Task 8 (Case 9).
52
1
4 5 6
2 3
7 8 9 GRIO
1
2 X
4
xx
X
3
x
X
5X
X
x
6
7
8
x
x
xi
X
x
X
x
_
x
X
x
x
x xM
x
9 X
Gate Review X
101
x
xx
x x
x x
x
x
x
x
I
xx
Figure 3.15: Gate review located after Task 9 (Case 10).
2 3 4 5 6
2 X
3
4
X
7
X
x
x
X
9 10GR
8
x
5X
6 .
7
x
x
x
8
X
9 X
X
10
Gate Review X
X
x
X
x
X X.X.XXX.X
Figure 3.16: Gate review located at the end of the project (Case 11).
The first assumption made when applying this method is that in case a gate review
is placed inside an iteration block, the iteration will be allowed to take place as many
times as necessary.
In other words, the gatekeepers will not kill the program at the
review if the requirements are not met. Instead, the gate review will be rescheduled and
53
the team will be given more time to continue working on their tasks until these
requirements are satisfied. In Figures 3.7 through 3.15, the highlighted gray regions
denominate the inter-phase iteration zone of the DSM. If a mark is placed in this region,
then the gate review is located inside an iteration block. A second assumption made is
that a gate review is another source of rework generation in case additional time is
allowed to finish the tasks of a particular stage. If the gatekeepers allow a stage to be
revisited and delay the project by allocating more time to these tasks and rescheduling the
review, then there is a probability that they will require additional changes from some of
the other tasks involved. Thus, whenever there is at least one mark in the inter-phase
iteration zone, additional feedback marks are placed along the column of the gate review
in the DSM up to the first task in the iteration loop. These additional dependencies can be
observed in Figures 3.9 through 3.15, and are depicted by a small "x".
Another
assumption made is that all the tasks in a stage must report a deliverable at the gate
review. These can be seen in each of the DSMs, where the row modeling the gate review
has inputs from all the tasks preceding it. When the gate review is placed inside an
iteration block, the mark representing the deliverable from the task with the missing
information is highlighted in "bold".
Each of the DSMs illustrated in Figures 3.6 through 3.16 were simulated using
Browning's model for predicting the project duration [8]. The simulations used simple
values for task durations: 1, 2, and 3 days for the best-case value (BCV), most likely
value (MLV), and worst-case value (WCV), respectively, and 1 day for each value for the
gate review. The rework probability for all tasks was modeled as 50%, while the rework
impact was modeled at 100%. In each case, the learning curve factor used as an input
was 50%. Also, no overlapping was allowed between tasks, and each simulation was
54
assigned 1,000 runs. Table 3.1 shows the mean duration and standard deviation for each
of the cases obtained from the simulations.
Case
Mean
(days)
S.D.
(days)
1
2
3
4
5
6
7
8
9
24.13
24.19
24.14
26.81
27.93
29.54
30.91
32.34
33.94
2.16
2.12
2.27
3.14
3.75
4.25
5.14
5.87
6.47
10
34.95
6.99
11
24.25
2.26
Table 3.1: Simulation results for gate location example.
From Table 3.1, it can be seen that the further down a gate review is placed in an
iteration loop, the longer the project duration is due to rework. This can be observed by
noticing how the mean duration steadily increases between cases 4 to 10, and then drops
sharply in case 11. In the model, the gate review is located within an iteration block in
cases 4 through 10. In each of these cases, additional feedback marks are placed in the
model due to the extra rework that the rescheduling of the gate generates. The further
down in the block the gate is, the more feedback marks the model has, and consequently,
the longer the duration. In case 11, however, the gate review is located outside the
iteration block. Thus, all these additional marks are eliminated, as there is no need to
reschedule the gate. In reality, the further down a gate review is in an iteration block, the
55
greater the number of tasks that need to be reworked. Thus, more time is required to
finish all these tasks properly. This can translate into the fact that a longer period of time
is required before the new gate can be scheduled.
Not only the duration values increase, but also the standard deviations. T-tests
have been performed between all the eleven cases in order to test the means for statistical
significance. All tests, with the exception of those involving cases 1, 2, 3, and 11 among
themselves, gave results of p<0.05. This means that the differences between the tested
cases with p<0.05 are statistically significant. The tests that did not give a significant
difference can be explained by the fact that in cases 1, 2, 3, and l Ithe gate review is
located outside the iteration blocks. In the same fashion, F-tests were performed to test
the variances for statistical significance. Results for the F-tests were similar as those for
the t-tests.
A sensitivity analysis was performed by varying both rework probabilities and
rework impacts in order to test the robustness of the results presented in Table 3.1. These
two parameters have each been classified into three main categories: low, medium, and
high. Low rework probabilities and impacts range from 0% to 30%, medium from 40%
to 60%, and high from 70% to 100%.
First, a sensitivity analysis was performed by varying the rework probabilities
across the three categories while keeping all the other parameters as they were used in the
example. Thus, each of the eleven cases presented between Figures 3.6 through 3.16 was
simulated using the following values for task durations: 1, 2, and 3 days for the best-case
value (BCV), most likely value (MLV), and worst-case value (WCV), respectively, and 1
day for each value for the gate review. In all cases, the rework impact was modeled at
100%, while the learning curve factor used as an input was 50%. Also, no overlapping
56
was allowed between tasks, and each simulation was assigned 1,000 runs. The rework
probability used from the low region was 20%, the medium one was 50%, and the value
used to model the high rework probability was 80%. It should be noted that results for
the medium region are equal to the results from the example presented in Table 3.1, as
they both use a rework probability of 50%. Table 3.2 summarizes the mean duration and
standard deviation for each of the cases obtained from the simulations in this sensitivity
analysis. Figure 3.17 illustrates a graph of the mean duration of the process for each
different location of the gate review.
Case 1
Case 2
Case 3
Case 4
Case 5
Case 6
Case 7
Case 8
Case 9
Case 10
Case 11
HIGH
MEDIUM
LOW
S.D. (days)
(days)
(days)
Mean
S.D.
(days)
(days)
Mean
Mean (days) S.D.
33.43
6.61
2.28
26.09
4.54
22.19
6.77
4.13
33.24
2.32
26.09
22.27
4.44
33.44
6.65
22.40
2.56
26.32
7.90
38.59
5.27
27.89
2.56
22.79
12.23
50.06
31.62
7.53
2.80
22.85
9.22
58.46
14.56
23.83
3.34
35.50
17.04
71.99
40.61
11.22
3.75
24.48
84.63
20.28
4.49
47.45
14.18
25.21
20.92
16.22
96.43
53.07
25.82
4.94
23.49
17.51
106.70
58.58
26.24
5.05
6.84
33.48
4.47
26.06
2.27
22.22
Table 3.2: Sensitivity analysis results by varying rework probabilities.
57
120
100
w
80-
cc
r
0
60-
cc
S40
20
0
1
2
3
4
5
6
7
8
9
10
11
12
Gate location
-4-LOW --
MEDIUM -A-
HIGH
Figure 3.17: Mean durations for sensitivity analysis (Rework probabilities).
For each case, t-tests were performed across low, medium and high rework
probabilities to test the means for statistical significance.
All results were significant
(p<0.05), meaning that for each case, the rework probability values used had a direct
impact on the overall duration of the process. F-tests were also performed to test the
variances for statistical significance, and all the results were also significant.
Another sensitivity analysis was performed by varying the rework impact values
across the three categories. The values used in the simulation were the same as before,
keeping in mind that the rework probability was kept constant at 50% in all cases. The
rework impact used from the low region was 20%, the medium one was 50%, and the
value used to model the high rework impact was 100%. In this case, it should be noted
that results for the high region are equal to the results from the example presented in
58
Table 3.1, as they both use a rework impact of 100%. Table 3.3 summarizes the mean
duration and standard deviation for each of the cases obtained from the simulations in this
sensitivity analysis. Figure 3.18 shows a graph of the mean duration of the process for
each different location of the gate review.
HIGH
MEDIUM
LOW
Mean (days) S.D. (days Mean (days) S.D. (days) Mean (days) S.D. (days)
Case 1
Case 2
Case 3
Case 4
Case 5
Case 6
Case 7
Case 8
Case 9
Case 10
Case 11
4.54
4.13
4.44
5.27
7.53
9.22
11.22
14.18
16.22
17.51
4.47
26.09
26.09
26.32
27.89
31.62
35.50
40.61
47.45
53.07
58.58
26.06
2.79
2.84
2.76
3.02
4.41
5.68
7.59
8.61
10.50
11.53
2.62
23.82
23.72
23.70
24.67
26.87
29.87
34.11
36.84
41.98
45.24
23.68
1.69
1.67
1.66
1.91
2.65
3.14
4.12
4.66
5.30
5.85
1.73
22.18
22.30
22.23
22.97
23.80
25.46
27.50
29.36
31.50
33.10
22.33
Table 3.3: Sensitivity analysis results by varying rework impacts.
7060 50
-
A
- 40 0-Q
3020
-
10
-
0
0
1
2
3
4
5
6
8
7
9
10
11
12
Gate location
+
LOW --
MEDIUM
A
HIGH
Figure 3.18: Mean durations for sensitivity analysis (Rework impacts).
59
As in the sensitivity analysis in which the rework probabilities were varied, t-tests
were also performed to test the means for statistical significance.
The results were
similar and they were all significant, as they all had p<0.05. Thus, values of rework
impact also can have a direct impact on the duration of the process. In a similar manner,
F-tests were conducted to test the variances for statistical significance.
Again, all the
tests gave significant results.
A number of valuable insights can be obtained from the results of this example
and the sensitivity analyses. By observing the graphs in Figures 3.17 and 3.18, it can be
observed that regardless of the values used for rework probabilities and rework impacts,
the location of a gate review within an iteration block has the most determinant effect in
delaying a process. The further down a gate review is placed in an iteration loop, the
longer the project duration is due to rework. Not only the duration values increase, but
also the standard deviations.
Nevertheless, it should be remembered that rework
probability and rework impact values also have a significant impact on the duration as
suggested by the t-tests.
When comparing low rework probability and impact values, it has been found that
the concept of rework impact has a much stronger effect in increasing the duration of the
process. Thus, when there are very low probabilities of rework, it can be safe to schedule
a gate review inside an iteration block if necessary to accelerate the process. This is
because the probabilities of having inter-phase iterations are very low. Such a case is the
only time when it is acceptable to place a gate review inside an iteration block.
However, for medium and high rework probabilities and impact values, the
opposite is true. As the gate review is moved further down in the iteration block, the
values used for rework probabilities can drive the project to have a much longer duration.
60
When a gate review is placed outside of an iteration block, rework probabilities
have a stronger impact on the duration of the process than the values for rework impact.
Even though this is a simple example with only a few tasks, it shows the negative
impact that the allowance of inter-phase iterations can have in the duration of a product
development process.
The methodology employed for this analysis can be performed
systematically across larger and more complex processes.
3.3.2
Using buffers in the scheduling of design reviews
The preceding section addressed the issue of where in the project should the gate
review be located, but does not address the problem of when should it be scheduled. By
removing a gate review from an iteration block and allowing the iteration to be completed
before the review, the project management team solves the issue of facing a shortage of
information in a stage necessary to satisfy all the requirements. However, even when all
the necessary information is available, the product development team can still run out of
time to successfully finish all the deliverables for approval at the gate review and thus
proceed to the next stage. Hence, product development time is often the primary concern
in project planning and execution.
Ulrich and Eppinger [53] provide a set of guidelines for accelerating product
development projects. This set of guidelines applies to the product development project
as a whole:
*
Start the project early - Delays at the beginning of a project cost exactly as
much time as similar delays during production ramp-up. Thus, the easiest
way to complete a project sooner is to start it early.
61
* Manage the project scope - There is a natural tendency to add additional
features and capabilities to the product as development progresses.
In
time-sensitive contexts, this tendency might lead the company to have an
elegant product without a market. Disciplined organizations must be able
to "freeze the design" and leave incremental improvements for the next
generation of the product.
" Facilitate the exchange of essential information - A DSM illustrates that a
tremendous amount of information must be transferred within a product
development team. Large teams may require more structure to promote
rapid and frequent information exchange.
Another recommendation that they make focuses on those tasks in the critical path
of the project. It consists of aggregating safety times as proposed by the critical chain
methodology developed by Goldratt [24]. Generally, the estimated duration of each task
in a product development project includes some amount of "safety time". This time takes
into account the unpredictable delays that occur during the execution of each task, which
may include waiting for information and approvals, interruptions from other tasks or
projects, and tasks being more difficult than anticipated.
According to Goldratt [24],
built-in safety times typically double the nominal duration of tasks. Even though safety
time is added to the expected task duration in order to account for random delays, these
estimates can quickly become the time targets during the execution of the tasks. This
implies that tasks are rarely completed early and in many cases overrun. The critical
chain method suggests removing the safety time for each task along the critical path and
aggregating all of them into a single project buffer placed at the end of the project
62
schedule. Since the need to extend task duration occurs in a somewhat random manner,
only some of the tasks will actually need to utilize time from the project buffer. Thus, a
single project buffer can be smaller than the sum of the safety times that would be
included in each estimate of task duration.
In addition, another advantage is that if
necessary, a particular task could use more time from the project buffer than what it
would have allocated in the individual safety time, without delaying the project.
The principal ideas from the critical chain method developed by Goldratt could be
applied to a DSM model to schedule a gate review at the end of a stage in a product
development process.
By introducing the concept of a stage buffer analogous to the
project buffer in the critical chain, a gate review can be scheduled in such a way to allow
the product development finish all their deliverables on time and satisfy the requirements
of the review. Such buffer would be placed at the end of the stage, and would allow the
project team to finish iterations completely before the gate review. The size of such a
stage buffer would be calculated in the following manner:
Stage buffer size = E(nominal duration of all tasks)(desired %of each task)
+ E(duration of iteration block)(maximum # of iterations allowed)(probability of rework)
The first term in the equation is analogous to adding the individual safety times
for each task in the critical chain method. The second term, on the other hand, allows
time for iterations to be completed as necessary. It is up to the project management team
and the experts in the process to estimate what is an appropriate number of iterations that
should be allowed, as well as the probabilities that feedback dependencies will trigger
rework in the project.
The DSM again will be crucial in determining the iteration
63
structure and amount of information exchange in the project.
Figure 3.19 shows an
example of a DSM with a stage buffer modeled before the gate review. Note that this is
the same DSM that was presented in Figure 3.16, with the addition of the buffer.
1
2
3
4
5
6
7
8
9 10 B GR
1
2 X
3
4
X
X
7
8
9
10
.......
X
X
X
X
XI
Buffer
Gate Review XXX
XXX
X
X
X
X
X
X
X
XXX
Figure 3.19: DSM example with stage buffer.
The size of the buffer for the example in Figure 3.19 can be calculated very
easily. Using similar values as in the example presented in the previous section, the most
likely duration of each task is 2 days and the probabilities of rework will be modeled at
50%. It is up to the project manager to determine the maximum number of iterations that
will be allowed, as well as the percentage of the individual task durations that want to be
added into the buffer. For the purposes of this example, only 2 iterations will be allowed,
and 75% of the nominal duration of each task in the process will be added to the buffer.
It should also be noted that given that the small three iteration blocks in the DSM overlap
each other, they can be considered to be a single larger iteration block as denoted by the
64
dotted lines. Given that there are 8 tasks in the block, the likely duration of each block
will be 16 days. Thus, the size of the buffer can be calculated as follows:
Stage buffer size= (10 tasks)(2 days per task)(0.75) + (16 days)(2)(0.50) = 31 days
Even though this is a simple example, it illustrates how manager can estimate the
size of a buffer for a given stage in a product development process. It is believed that the
introduction of the stage buffer concept contributes to help managers determine a
scheduling strategy for gate reviews in a process that would increase the probabilities of
advancing to the next stage without the need of rescheduling reviews.
3.4
Chapter Summary
The stage-gate product development process has been introduced in this chapter,
along with the concept of gate reviews. The DSM method in combination with existing
simulation models have been used to investigate the effect that the location of gate
reviews can have in the overall duration of a product development process.
The proposed methodology presented in this chapter to address the issues of gate
review location and scheduling can be summarized as follows:
1.
Create a DSM of the process as it is actually executed and compare it to
way the process was originally supposed to be in order to identify any
potential differences. The information required to build the DSM, such as
the tasks and the appropriate interdependencies, can be obtained by talking
65
directly to experts involved in the process.
Gate reviews should be
modeled as independent tasks in the process.
2. Perform the appropriate partitioning and tearing DSM analyses.
3. Identify the location of the gate review and move it accordingly to align it
with the natural structure of the process. If the gate is located inside an
iteration block, it is recommended that the stage-gate structure of the
process be redefined in order to eliminate inter-phase iterations.
4. Calculate the stage buffer size for each stage and determine the dates for
when the gate reviews will take place.
66
Chapter 4
Case Study: A Stage-Gate Product Development
Process at General Motors
Chapter 4 presents a case study conducted at General Motors during the summer of
2001, in which a stage-gate product development process was modeled with a task-based
Design Structure Matrix (DSM). The procedures and analysis are described in detail in
this chapter.
4.1
An overview of the product portfolio process
4.1.1
Purpose of the study
General Motors has implemented a product portfolio process (PPP) to create and
evaluate proposals for new product entries. The PPP is relatively new, so there is ample
opportunity to increase its operational efficiency. A task-based Design Structure Matrix
has been used to model a specific portion of this process, the concept development
process (CDP), and thus identify areas for process improvement. The ultimate goal of
these process enhancements is to reduce the total duration of the process, and thus help
the company increase the speed at which it brings new products to market.
In order to capture the full spectrum of challenges faced in the CDP, two different
types of program teams were selected for the study. One of the teams selected was
designing the Buick Bengal and faced all of the challenges associated with the design of
an entirely new vehicle. The second team was developing a new version of the Cadillac
DeVille, which has been an icon of the automotive history in the United States. Even
though the new DeVille was largely based on its predecessor, the DeVille team still faced
67
many of the challenges of a new product development project, especially due to the
implementation of several advanced technologies.
The purposes of this study can be summarized as follows:
1. To develop a model of General Motors' CDP as it is currently
practiced using the Design Structure Matrix methodology.
2. To identify opportunities to increase the efficiency and productivity of
the CDP using this process model.
3. To identify opportunities for development of future CDP enablers,
such as math-based design representation and engineering analysis
tools, information management systems, and workflow management
methods and tools.
The development of a formal, operating-level CDP model would also provide a
valuable baseline for subsequent R&D research projects at General Motors. This is an
important consideration given the R&D Center's relatively low working level of
knowledge of the CDP and the PPP in general.
4.1.2
Overview of the Product Portfolio and Concept Development Processes
General Motors has developed and implemented a product portfolio process (PPP),
a multi-phase formalized process for generating new vehicle design concepts and
subsequently assessing their viability from a cross-functional perspective. This process
consists of four distinct stages: Envision, Ideate, Define, and Develop (Figure 4.1). The
first three stages occur continuously throughout the year.
Designers, marketing
representatives, and portfolio planners continuously generate new concepts and ideas, and
select the most promising ones for a more thorough engineering feasibility evaluation.
This study focuses on the fourth and final stage, the concept development process
(CDP). The CDP is analogous to the front-end process, or concept development phase,
68
of the generic product development process described by Ulrich and Eppinger [53]. The
CDP is a structured phase-gate product development process in which a fully crossfunctional product development team rigorously evaluates a vehicle concept's viability.
Throughout the three phases of this process, a concept begins as an idea and matures to a
preliminary design for a vehicle that could be produced and incorporated into General
Motors' product portfolio.
Thus, the process encompasses a broad scope of activities,
including determining the marketing requirements for the vehicle, determining a
manufacturing strategy, designing the vehicle's appearance, assessing the engineering
design feasibility, and developing a business case to assess the vehicle's financial
viability. At the end of the process, all the findings are presented to a decision board,
which will ultimately decide whether or not the vehicle will be incorporated into General
Motors' product portfolio. If so, then a full vehicle development program is initiated to
design the vehicle and bring it to production. If not, the results of the study are bookshelved for future consideration and use. This illustrates the benefits of executing the
CDP, as potential impasses in the development of the vehicle may be determined at a
very early stage before significant investments of human resources and capital have been
made.
69
-
-
-
-.
-
-
-
-
Concept Development Process
Figure 4.1: The product portfolio process and concept development process.
The first phase of the CDP is focused on selection of a vehicle architecture. This
phase is conducted primarily by the concept leadership team with support from finance
and the performance development engineer. There is a particularly strong presence of
marketing and planning during this phase as the marketing requirements that will guide
the remainder of the process are being defined.
The initial development of the
manufacturing strategy is also prominent in this phase. This phase concludes once the
vehicle architecture has been selected. In the second phase of the CDP, design and
development engineers become actively involved.
Efforts in this phase are directed
towards identifying the major technical challenges for the concept and conducting
preliminary investigations of them. Finally, the third phase of the CDP is focused on
total integration of the vehicle and on finalizing the business case to be presented before
the strategy board.
70
4.1.3
Structure of the Concept Development Team
A concept development team is a matrixed, fully cross-functional team staffed
primarily by engineers with additional representatives from design studios and finance.
The leaders of the team are the vehicle concept manager, who is responsible for keeping
the process and the team on track, a portfolio planner, a brand manager, a vehicle
integration engineer, and a manufacturing integration engineer.
The engineers on the concept development team are divided into two primary
groups: design engineers and development engineers. There are several design engineers
on each concept development team whose roles are heavily oriented toward selection and
packaging of vehicle subsystems.
The design engineers are also responsible for
maintaining lists of open issues for their subsystems and for delivering progress reports in
weekly team meetings that address open issues considered critical for successful
completion of the concept development process.
The development engineers are represented at the highest level by a performance
development engineer whose role is to assess the functional performance of the vehicle
relative to its performance targets and to enlist the services of additional development
engineers as needed throughout the course of the CDP. The performance development
engineer is supported by development engineers from a variety of engineering disciplines
such as safety, noise & vibration, vehicle dynamics, performance & fuel economy,
HVAC, quality, and mass. They provide increasing support to the team and become
more visibly involved in the weekly team meetings as the CDP progresses and as issues
related to their specific discipline arise.
71
4.2
Methodology
A series of individual interviews were conducted with members of the concept
development teams to obtain the necessary information required to build the DSM model.
Members of both the DeVille and Bengal teams were interviewed. Each interview lasted
approximately one hour, and there were typically two members of the R&D DSM Team
acting as interviewers. A standard interview template (See Appendix A) was developed
as a guide for the different interviewers to provide consistent information to build the
model.
The vehicle concept manager for both of the programs selected for study proposed a
preliminary list of interviewees at the beginning of the study and more were added to the
list as their roles were discussed in some of the interviews. The process of scheduling the
interviews lasted between one and two weeks. In general, most of the team members
were very receptive to the idea of collaborating with the DSM project. In order to setup
the interviews, an initial approach was made through electronic mail. The response rate
to this approach was relatively low, so another round of telephone calls followed. One
round of phone calls was sufficient to schedule an interview date with most members. A
few team members initially were reluctant to be interviewed, but after talking to their
colleagues who had been interviewed and understanding the value of the DSM project
acceded to grant us an interview.
Interviews
typically
lasted
approximately
one
hour.
Even
though
total
confidentiality was guaranteed at the interviews, there were two persons who preferred
not to be tape-recorded.
In general, interviewees found that it was very difficult to
identify a discrete set of work tasks that they performed during the CDP. This may have
been because of the relative newness of the CDP or because these phases had been
72
designed on a deliverables basis rather than on a work-task basis. The DSM Team found
it helpful with many interviewees to initiate the conversation using charts of expected
deliverables that were available for most functions.
It was found that one hour was enough time to collect information describing the
interviewee's tasks, to identify the corresponding tasks that provide input information or
receive output information, and in some cases, the time durations of the interviewee's
tasks. Therefore, the remainder of the data required for the DSM simulations, such as
rework probabilities and impact of rework, was collected after the first round of
interviews was complete and after a draft process model had been constructed.
At this
point, the DSM Team collected the remaining data either through a second, usually
shorter, interview or via electronic mail. The interviewees found it quite difficult to
quantify this numerical data. This may be due to a general bias among the interviewees
towards conservative estimates for process parameters or it may be due to the highly
parallel, concurrent, and continuous nature of the work performed during the CDP.
Once all the interviews were finished, a master task-based DSM of the process was
developed based on the information from both the Bengal and DeVille teams. Appendix
C contains a list of all the tasks in the DSM along with their input/output relationships.
Upon completion, the DSM model was iteratively refined through a series of
reviews with the interviewees. The numerical data required for the simulation analysis
was also collected at this point. The final version of the DSM model was then reviewed
and validated with the process owner for the PPP and with the vehicle concept manager
for the Bengal and DeVille teams.
The final steps of this study consisted of performing the appropriate DSM analysis
by applying the partitioning algorithm and tearing analysis. Once the structure of the
73
Design Structure Matrix was analyzed, numerical simulations were performed to
understand the impact that each phase has on the overall process duration using the
simulation model developed by Welch [57].
4.3
DSM Analysis
4.3.1
The Task-based Design Structure Matrix
The final version of the non-partitioned DSM model contained a total of 120 tasks
(Appendix C) from 19 different functions (Figure 4.2). In Phase 1, the model had 39
tasks. These tasks for the most part depict a serial flow of information. During this
phase strategies are developed for system engineering, manufacturing, and part sharing in
the body system. This phase shows the strong presence of the marketing and planning
functions. Efforts in this phase are geared toward selecting a vehicle architecture; at the
end of this phase one of the company's existing architectures is selected for the new
vehicle. This selection is then presented for endorsement at the gate review of Phase 1; if
accepted, the team is authorized proceed to the next phase of the CDP.
The DSM model captured the most tasks in the second phase - a total of 52 from all
19 functions. The design engineers become heavily involved once the architecture has
been selected and the vehicle's bill of material and CAD/CAE models are being
developed.
In the DSM model, this phase appears to have two parts. The first part
represents highly independent and parallel activities, as the design engineers work in
parallel on their respective vehicle subsystems.
The second part consists of highly
coupled (interdependent) and highly iterative tasks. During this phase major technical
challenges are identified and initial investigations are conducted. Efforts in this phase
begin to focus on total vehicle integration.
74
The third and final phase had 29 tasks.
The DSM model shows that there is
feedback from some of these tasks to some of the tasks started in the later part of Phase 2.
The tasks involve balancing functional targets, developing a complete, integrated vehicle
concept model, and finalizing the business case. Efforts in this phase are aimed toward
finalizing the total integration of the vehicle and preparing to present the concept to the
decision board.
A total of 430 marks representing dependencies among different functions were
identified in the DSM. With 120 tasks in the model, this gives an average of 3.6 inputs
per task. This value is considered to be low; Whitney has found that a typical DSM
model of a mature process has an average of 6 inputs per task [58]. This suggests that
some dependencies might have been left out of the model. Possible reasons are that the
DSM Team was not able to interview members from one major functional area, or it may
also be due to the relatively newness of the CDP. Because this DSM model was built
based on data collected by interviewing the people executing the CDP, it may be that
some dependencies may not have been discussed in the interviews since the interviewees
are still familiarizing themselves with the process.
75
Figure 4.2: The non-partitioned 120-task Concept Development Process DSM matrix.
4.3.2
Partitioning and Tearing
The partitioning algorithm was applied to the DSM to re-sequence the order of the
tasks, in order to reduce the iterations in the system and optimize the efficiency of the
information flow. The initial partitioning of the matrix revealed one large iterative block
(Figure 4.3).
This large iteration block was partly created due to three particular
feedback marks providing information from each gate review to an early planning task
that consisted of updating the timing schedule of the program. The team understood that
this feedback is necessary in a typical design process and does not provide a real insight
into what kind of problems are being raised in the process due to unwanted rework.
Thus, a "tearing" analysis was performed by suppressing these three marks in the model
76
and re-partitioning the DSM.
Figure 4.3 shows an approximate location of the three
feedback marks that were removed to perform the "tearing" analysis.
Torn marks
Figure 4.3: DSM graphic representation after the initial partitioning algorithm.
This re-partitioning produced a more insightful model with several sets of lower
triangular feedback loops within Phases 1 and 2 and larger feedback loops between
Phases 2 and 3 (Figure 4.4).
77
Figure 4.4: The graphic representation of the final re-partitioned DSM model.
The iteration blocks present in the re-partitioned DSM represent real feedback in
the CDP that were classified into three main categories. The first category, identified in
Figure 4.5, consists of small iteration blocks created by coupled tasks that are performed
by individuals or sub-teams within the concept development team. This kind of block is
natural and is expected to appear in a product development process like the CDP.
78
Figure 4.5: Areas of coupled tasks within sub-teams in Concept Development.
For marketing, the coupled tasks consist of determining the vehicle's feature
content and providing a revenue estimate.
The design engineer responsible for the
underhood compartment and the powertrain systems engineer have two interdependent
tasks: creating a technical specifications document and developing the CAD model for
the powertrain and for the underhood compartment. Within vehicle concept engineering
there are two coupled tasks: packaging vehicle occupants and packaging the vehicle's
structural members.
Two sets of tasks are coupled for the body structure and metal
fabricating functions: (1)
developing the body bill of material and identifying the
technical challenges for the body system and (2) developing preliminary die designs and
sizes and providing die investment estimates.
79
Figure 4.6: Task interdependencies at the end of Phase 1.
The second category is shown in Figure 4.6, and occurs at the end of Phase 1. This
is a set of interdependent tasks involved in the selection of a vehicle architecture. This
set of tasks has collectively been named the Architecture Selection Block.
Figure 4.7 highlights the key activities involved in selection of an architecture.
Some of the functions with significant involvement in this decision include the vehicle
integration engineer, the performance development engineer, body engineering, portfolio
planning, and the management team who will ultimately endorse the architecture
selection.
80
Establish Body Part
Sharing Strategy
Determine Product
Content
....
......
.....
I
--1---Recommend Final
Architecture
74
Review Phase 1/ Approve
Final Architecture
Provide Alternative Architecture and
Configuration Trade-Offs With
Assessments
Figure 4.7: Architecture Selection Block at the end of Phase 1.
The third category of iterations occurs during the later part of Phase 2 and most of
Phase 3, as illustrated in Figure 4.8. Four major iteration blocks have been identified in
this category: the Open Issues Block, the CAD Models Development Block, the
Performance Assessment and Balancing Block, and the Business Case Block (Figure
4.9). From the Open Issues Block, it can be seen that the vehicle integration engineer is
the liaison between the various design engineers, as he tracks the total vehicle issues and
provides feedback to the design engineers. It can also be observed in Figure 4.9 that the
vehicle integration engineer plays a fundamental role in the total integration of the
vehicle, as his task of tracking total vehicle issues is part of the Open Issues Block and
the other major blocks in the system.
81
Figure 4.8: Iterations at the end of Phase 2 and most part of Phase 3.
Open Issues Block
Performance Assessment
and Balancing Bloc
Track Total Vehicle Issues
(Vehicle
Integration
_
Develop Integrated
Concept Vehicle Model
(Packaging Engineering)
. . .
Engineering)
Update Financial
Assessment and Finalize
Business Case (Finance)
CAD Models
Development
BloCk
Review Phase 2 Deliverables
(Program Management Team)
Business Case Block
Assess Risks in Performance
Requirements (Systems Engineering)
Figure 4.9: The Open Issues Block, the CAD Models Development Block, the
Performance Assessment and Balancing Block, and the Business Case Block.
82
Another noteworthy point is that in the DSM model Phase 3 appears to be simply a
continuation of Phase 2, and no clear distinction is seen between Phases 2 and 3 as there
was between Phases 1 and 2. This is shown by the placement of Phase 2 gate review,
which occurs in the middle of the CAD Models Development Block, the Performance
Assessment and Balancing Block, and the Business Case Block. These three blocks all
provide feedback from tasks in Phase 3 to tasks in Phase 2. Thus, the review at the end
of Phase 2 functions as a status review rather than as a true gate review. This is a critical
finding from the DSM analysis; it indicates that the Phase 2 gate review is not properly
aligned with the natural structure of the process. Since the tasks required to pass this gate
require feedback from tasks occurring in the next phase, the probability of successfully
passing this gate review is low. This leads to frequent repetition of this gate review and
significantly longer overall process duration.
This observation was confirmed by reviewing the revisions to the timing plans of
the programs under study. For one team, the Phase 2 gate has been officially scheduled
three times, delaying the program several months behind schedule.
Figure 4.10 shows some of the dynamics within the CDP at this stage. This closeup highlights how the different design engineers simultaneously receive inputs from
performance development, systems engineering, and manufacturing, while they feed back
to those functions that play an integration role such as the vehicle concept engineer and
the vehicle integration engineer. It can also be seen in Figure 4.9 that the CAD Models
Development Block is just a subset of the larger block labeled Performance Assessment
and Balancing Block. It can also be observed that the development of the business case
is the last major iterative process in the CDP, as depicted by the Business Case block.
83
Track Total Vehicle
Issues (TVIE)
I
UN
IL'
w
I
-I
1 T -T-1
Feedback
Provided by
Different
11
Engineering
Compartments
1U1
1.
1
1i
±
I L- I
1J1ll
Input from Systems
Input from Performance
Development to Different
Compartments
Engineering to
Different
Compartments
Input from Manufacturing
to Different
Compartments
I
S
0
Figure 4.10: Dynamics of the process in the third category of iteration blocks.
4.4
Simulation Analysis
4.4.1
Simulation Framework
Given the newness and the relatively high rate of evolution of the CDP, there is too
much uncertainty in the quantitative data collected to assure robustness of the simulation
results. In view of this challenge, the author and the GM R&D members of the DSM
project team have jointly developed the following framework for creating meaningful
recommendations.
The simulation approach features a block-by-block analysis. In this analysis, a set of
tasks is grouped into a block and the rest of the process is aggregated into a single row
with the corresponding inputs and outputs. If the aggregated rows use the task durations
to be planned or the standard ones, the simulation output of the process duration will give
84
an estimate of the relative influence of the tasks in the block on the duration of the entire
process.
Block-by-block or regrouped block analyses can be performed to identify
opportunities for efficient means to improve the total process duration. It is difficult to
capture the probability or impact of rework in this setup. Thus, analyzing more than one
block at a time and using aggregated rows in the place of rest of the process as
appropriate could further expand this approach.
Here a block may consist of an
individual iteration block or of an entire set of tasks between two gate-reviews.
4.4.2
Simulation Results - Concept Development Process
Simulating the partitioned DSM using the data that was collected during the
interviewing process was the first step of the simulation analysis. The simulation model
developed by Welch [57] was used to perform this analysis. Rework probabilities, rework
impacts and overlapping percentages were used to build a Probability Matrix, an Impact
Matrix, and an Overlap Matrix, respectively. Three values of task durations, measured in
days, were assigned to each task as provided by the interviewees.
These values
represented the estimated minimum time to complete the task, the most likely time, and
the maximum time. Triangular distributions were used for the simulation. Finally, for
each task the learning curve was also used to estimate the percentage reduction in the
rework probability for each iteration of a task.
The partitioned DSM model was simulated a total of six times under different
conditions (see Appendix B). First, the entire process was simulated as a base case
(without rework) and as a full model (including all rework probabilities and impacts).
These results were used as a baseline to measure the other simulation results in the block85
by-block analysis. Following this simulation, the block-by-block analysis was performed
focusing on the sets of tasks grouped into each block with the rest of the process
contracted into individual rows with appropriate inputs and outputs.
To allocate expected durations to the contracted blocks, a series of simulations were
run prior to the block-by-block analysis. First, Phase 1 was simulated by itself both as a
full model and a base case to estimate its duration. After that, Phases 1 and 2 were
simulated to estimate the duration of both together. Since the duration of Phase 1 alone
had been estimated through the previous simulation, the duration of Phase 2 alone was
estimated by subtracting the duration of Phase 1 from the combined duration of Phases 1
and 2. Similarly, the duration for Phase 3 was obtained by simulating the entire process
and subtracting the first two phases.
Table 4.1 summarizes the results of these
simulations.
Concept Development Process
Phases
Phase 1
Phases l and 2
Phases 1, 2 and 3
Full model
Mean
S.D.
(days)
(days)
165
19
342
20
558
34
Base case
Mean
S.D.
(days) (days)
121
10
298
14
434
17
Table 4.1: Simulation durations for the full DSM model and base case.
Table 4.2 shows the durations that were used for each of the three phases when they
were collapsed into single rows in the block-by-block analysis.
These values are
extremely large when compared to actual durations of the three phases of the CDP. This
discrepancy occurs partly because the DSM model assumes full completion of these tasks
within each phase, but in reality, there are many tasks that begin in one phase of the CDP
86
but are not completed before the gate review. This supports what was learned from
weekly team observations. Another important observation is that, as discussed earlier,
there was a general bias among the interviewees towards conservative estimates for
process parameters such as task durations.
Finally, it is interesting to note that even
though Phase 3 was designed to last longer than the other two phases, in reality it was
found that Phase 2 is the longest one in the process.
Collapsed CDP Phase
Phase 1
Phase 2
Phase 3
Duration (days)
121
177
136
Table 4.2: Standard durations for each of the collapsed CDP phases.
Having determined the durations of each phase individually, the block-by-block
analysis could be started. By allocating the task durations in Table 4.2 to the contracted
rows, the estimates of process duration generated through simulation will provide
estimates of each block's influence on the duration of the entire process. Simulations
were conducted following this block-by-block analysis model, considering one phase at a
time.
Another simulation was performed keeping Phases 2 and 3 as one block and
contracting Phase 1. Similarly, simulations were performed keeping the tasks in the large
iteration block and contracting the rest of the process.
In each case, mean process
durations and standard deviations were recorded for the entire process (Table 4.3).
87
Benchmark
Case 1
Case 2
Case 3
Case 4
Case 5
Entire Process
Phase 1 full (2 and 3 collapsed)
Phases 2 and 3 full (1 collapsed)
Phase 2 full ( 1 and 3 collapsed)
Phase 3 full (1 and 2 collapsed)
Large block full (Rest of process collapsed)
Full model
Mean
S.D.
Base case
Mean
S.D.
(days)
(days)
(days)
(days)
558.04
475.58
538.20
523.19
500.19
539.04
34.42
19.04
30.80
87.01
24.17
32.36
434.34
431.52
444.38
439.62
487.95
439.35
17.26
10.10
15.18
11.40
14.72
6.97
Table 4.3: Simulation mean durations for the benchmark and five case models.
From the results of simulating the entire process and comparing the full model to the
base case, it was determined that approximately 22% of the overall duration was due to
rework in the system. By observing the results from cases 1 and 4, it can be observed
that Phases 1 and 3 have the least impact on the overall process duration. Similarly from
the results of case 3 shown in Figure 4.11, it is seen that Phase 2 has the greatest impact
on the overall process duration. Its unusually large standard deviation indicates that it is
the main source of variation in overall process duration. This seems to stem from the
lack of clear distinction between Phases 2 and 3 discussed earlier.
88
Figure 4.11: Case 3 DSM simulation showing that Phase 2 is fully expanded while
Phases 1 and 3 are modeled as a single row.
Results of case 5 show the huge impact that the large iteration block has on overall
process duration (Figure 4.12). Its standard deviation (32.36 days) is also very large,
equaling that of the simulation of the entire process. However, it is much smaller than
the standard deviation for Case 3 because all of the feedback is modeled within the
expanded block; thus the feedback across phases is not captured as strongly as in Case 3.
89
1
0
1 LM I
I
i I i I
t7t
U 4
04
I
I I
Figure 4.12: DSM used for Case 5 of the simulation showing the large iteration block is
fully expanded while tasks occurring before and after are modeled as a single row.
4.4.3
Simulation Results - Alternative Phases to the Process
After conducting a block-by-block analysis of the CDP and recognizing the impact
that each phase or block has on the overall process duration, the team was able to propose
an alternative phase-gate structure for the process. Instead of the three current phases, the
DSM team suggests four alternative phases that match the natural structure of the process
(Figure 4.13). Phase A would be the same Phase 1, with no changes to the existing tasks.
Phase 2 has been restructured to remove the gate review from the middle of the large
iteration block and to create a more real distinction between the later phases of CDP. The
proposed Phase B begins immediately after Phase 1 and ends at the beginning of the large
90
iteration block. The proposed Phase C encompasses the large iteration block, the only
change being that the gate reviews now occur at the beginning and end of this block
rather than in the middle of it. Finally, the proposed Phase D contains all of the tasks
previously in Phase 3 that were not part of the large iteration block.
Figure 4.13: Alternative phases suggested for Concept Development Process.
A similar block-by-block analysis was performed on these alternative phases by
simulating one phase at a time and contracting the others into a single row each, while
adding their appropriate inputs and outputs. These simulations were also run as full
models, with rework probabilities and impacts, as well as a base case, with feedback
marks removed.
91
To allocate standard or expected durations to the contracted blocks, a series of
simulations were performed prior to the block-by-block analysis. Basically, the same
method that was followed in the previous simulation analysis for the original phases was
used to determine the durations of the four alternative phases. Table 4.4 shows the
results of this portion of the simulation analysis, while Table 4.5 shows the standard
durations assigned to each of the four phases.
Alternative CDP Phases
Phase A
Phases A and B
Phases A, B and C
Phases A, B, C and D
Full model
Mean
S.D.
(days)
(days)
164.68
18.64
263.27
19.64
33.53
518.41
33.83
557.42
Base case
Mean
S.D.
(days)
(days)
9.72
120.71
13.69
226.80
15.48
374.83
16.80
434.45
Table 4.4: Simulation mean durations for the alternative CDP phases DSM.
Alternative CDP Phase
Phase A
Phase B
Phase C
Phase D
Duration (days)
121
106
148
59
Table 4.5: Standard durations for collapsed alternative CDP phases.
92
Full model
Alternative Phases
Entire Process
Phase A (B, C, D collapsed)
Phase B (A, C, D collapsed)
Phase C (A, B, D collapsed)
Phase D (A, B, C collapsed)
Mean
(days)
557.42
465.62
363.74
533.63
480.28
S.D.
(days)
33.83
15.36
10.06
28.62
8.86
Base case
Mean
(days)
434.45
424.85
358.19
440.23
480.28
S.D.
(days)
16.80
8.76
9.47
7.32
8.86
Table 4.6: Simulation mean durations for the alternative phase DSM models.
In the block-by-block analysis, it can be seen that the overall duration and standard
deviation were the same as before when the entire process was simulated (Table 4.6).
Similarly, it was found that 22% of the total time is due to rework. However, some
interesting differences were observed when simulating the different phases one at a time
with the others contracted. The removal of the gate review from the middle of the large
iteration block has substantially reduced the amount of variation that was previously
present in Phase 2. It can now be seen that the impact of the duration of Phase C (large
iteration block) on the overall process duration is significantly higher than the impact of
the other phases. Consequently, there is less variation in the duration of the other phases
because most of the rework in the system has been isolated in Phase C. This suggests
that tasks within this block can be targeted as the major source of opportunity for
reduction of the duration of the Concept Development.
4.4.4
Simulation Limitations
Given the relative newness and relatively high rate of evolution of Concept
Development Process, the simulations faced a variety of challenges. The first challenge
arose with the nature of some of the tasks in the CDP. Many of the tasks, such as those
93
related to project management or reporting, are of a continuous or ongoing nature. Initial
simulations indicated that these ongoing tasks seemed to drive much higher overall
process duration.
Given the lack of documentation on this issue in current DSM
literature, the DSM Team approached this challenge by setting the durations of these
tasks to zero days in order to explore their effect on overall process durations. This
would provide insight into the relative effects of these tasks on the total process duration;
however, there is no simple mechanism for measuring the impact of these tasks on the
robustness of the process in absolute terms.
Another major issue was obtaining useful numerical data from the interviewees; they
tended to provide conservative estimates of task durations, rework probabilities, impact
of rework, and learning curve and overlapping percentages. On many occasions,
interviewees had difficulty understanding these concepts. The degree by which estimated
process duration exceeded the planned and observed process duration suggests that many
of the estimated task durations and rework probabilities are potentially conservative.
These conservative estimates might have been due to the ongoing nature of some of the
CDP tasks, as it was very difficult to assign discrete values to them.
In the future,
interviewers should anticipate these issues and spend more time explaining the
interviewees the different parameters related to the DSM simulations prior to conducting
any interviews.
94
4.5
Chapter Summary
This chapter presents the results of a case study performed at General Motors, in
which a front-end product development process was modeled using the Design Structure
Matrix (DSM). Two projects were studied, one for the development of the new Buick
Bengal and another for a new version of the Cadillac DeVille, in order to identify areas
for process improvement. By talking to some of the experts involved in the process, a
DSM model of the process the way it was actually executed was built. By observing the
model, it became evident that the way the process was executed differed significantly
from the way it was supposed to. Such DSM enabled the team of researchers to identify
a number of iterations in the process that were not originally planned, and to find a very
astounding result: activities belonging to the second stage of the process required
information from activities that would not get started until the third stage in order to be
completed successfully. This finding caught the attention of the key people involved in
the project, as in reality that particular gate review had been rescheduled officially three
times, delaying the program several months behind schedule. A new stage-gate structure
was proposed, allowing iterations to occur only within a stage and avoiding inter-phase
iterations.
95
96
Chapter 5
DSM Deployment Experiences
This chapter presents a series of observations on the deployment process of DSM
tools and analysis techniques at General Motors. It focuses on all aspects of the process,
such as forming the team responsible for conducting the DSM study, all the challenges
that they had to face throughout the process, and the involvement of the product
development teams under study. Documentation of these experiences might provide
some useful insights for future deployment exercises of DSM methods from academia to
industry.
5.1
Deploying DSM methods at a corporate partner
Historically, a Design Structure Matrix (DSM) case study has been done by a
graduate student spending a summer with a corporate sponsor. It has been the norm that
the student is responsible for collecting the necessary data, building the DSM model, and
performing the appropriate analysis.
The student performs all these tasks mainly in
isolation and the only interaction with the program managers and the engineers is to
collect the appropriate data required to build the model and to validate it. Once the study
is finished, the student returns to MIT and the company retains no experience or
knowledge of the methodology used to perform the DSM study. Thus, the company does
not keep any trained personnel to perform future DSM studies of their own, limiting the
spread of DSM applications.
97
When the case study presented in this thesis was being developed, one of the main
objectives discussed was the deployment of DSM techniques and methods to the
corporate sponsor.
Thus, it was determined that one if its main goals would be to
increase knowledge and experience within General Motors (GM) in the application of
DSM tools and methods.
By having a team of researchers from GM's Research &
Development Center (GM R&D) working closely with the MIT student throughout the
entire project, from collecting the data to performing the DSM analysis, GM R&D would
benefit by keeping a set of trained DSM "experts" to perform subsequent DSM studies at
the company.
There were other benefits from the deployment of DSM tools and techniques to GM
R&D besides the training of their personnel. One of the main problems that GM R&D
faces when trying to collaborate with other units within GM is the low bandwidth of
communication between the operating units, which function as separate entities. In this
case, GM R&D was separated both physically and organizationally from the operating
unit responsible for executing the early phases of GM's product portfolio process (PPP).
By having the GM R&D members of the "DSM Team" involved in the data collection for
the DSM study, they were able to establish personal contacts that will facilitate
communication between the two groups for future projects, whether related to DSM or
not.
The deployment of DSM tools and techniques at GM R&D can be considered to be
successful. Not only does GM R&D have a group of trained researchers in the subject
matter, but they have also been able to generate interest in DSM among fellow
researchers.
Another success of this case study is the fact that as a result of it,
98
applications of DSM methods are being discussed for several projects underway or being
planned within GM R&D.
Forming the DSM Team at General Motors
5.2
The "DSM Team", composed of GM R&D researchers and myself, was selected with
the following criteria in mind:
1. The team should consist of members from both the MIT/CIPD and
from GM R&D to provide for transfer of DSM technology and for
growth of DSM application capability within GM R&D.
2. Team members should have a strong common interest in investigating
and in improving the early phases of the product development process.
3. The team should be highly cross-functional to provide a variety of
different perspectives on the process being studied.
4. The team should contain some members with prior experience in
applying either DSM or other process modeling techniques.
5.
Some team members should be familiar with the theory and
application of product development processes, through experience or
through first-hand research.
6. The team should contain some members with skills in relevant data
collection techniques, such as interviewing and observation.
The DSM Team was formed following these guidelines, composed of four members
with totally different backgrounds in order to bring diversity to the study. The DSM
Team leader from GM R&D was an engineer by training. He brought several years of
practical vehicle program experience to the DSM Team from previous assignments in
vehicle integration and chassis engineering. He also developed basic skills in process
modeling and simulation and in project management through previous assignments in
advanced engineering. Thus, his knowledge proved to be invaluable when understanding
the PPP and CDP at a functional level and the interactions among the different functions
99
in the vehicle program.
The second DSM Team member, with advanced degrees in
mathematics and an established history of contribution in the academic research realm,
also came to the DSM Team well versed in the theory and application of DSM process
modeling and simulation techniques.
The third member of the DSM Team, having
recently completed a Ph.D. in psychology, brought valuable skills in data collection
through both interviewing and observation and in analysis of group dynamics. She also
provided a valuable fresh-eyes perspective for the DSM Team since her observations and
insights were not colored by prior experiences with product development teams.
5.3
Observations on DSM Team's involvement
The GM R&D DSM Team members were involved in every aspect of the DSM
case study, from the selection of the product development teams for the study to
performing the analysis of the DSM model.
The DSM Team organized itself at the
beginning of the project by scheduling a weekly meeting to discuss the relevant issues for
that week. During the first meeting, I presented formal DSM training to bring the rest of
the DSM Team members to the same level of understanding of DSM applications and
analysis techniques. This training was complemented by individual reviews of relevant
DSM literature.
Once all of the DSM Team members had a good understanding of DSM methods,
their contribution began almost immediately. First, they recommended changes to the
data collection sheet in order to customize it to meet the specific details of this project.
Additionally, an entire section was added to gather data for another process improvement
100
project. This was seen as a very positive suggestion, as it increased the impact of the
DSM project through its support of other GM R&D projects.
The involvement of the GM R&D DSM Team members continued throughout the
data collection phase of the project. It was determined that for every interview, at least
one member from the DSM Team would accompany me. Throughout the data collection
phase, all of the DSM Team members became more effective interviewers as their
understanding of the Concept Development Process increased.
The prior practical
vehicle program experience possessed by one of the DSM Team members proved to be a
very valuable resource in team member interviews, as he was able to ask relevant
questions of very key points when needed.
Another contribution
of the GM R&D DSM Team
members
was the
implementation of an observation method in addition to team member interviewing for
data collection. Because these phases of the CDP had not been formally studied within
GM R&D, a direct observation method was used to complement the interviews and to
better understand information and work flows during these phases of the CDP. This
direct observation approach consisted of watching and noting what people do, how
members of the product development teams interact, and how the phases of the CDP
appear to proceed during the weekly product development team meetings.
Although the information gathered through direct observation was limited by the
observer's interpretation of the team's activities and interactions, the direct observation
and interviewing methods complemented each other and provided a more comprehensive
picture of the early phases of the PPP. This dual approach provided the DSM Team with
(1) additional insight into why information flows as it does and tasks endure as long as
they do during the phases of the CDP, (2) a means of validating the DSM process model
101
(ideally, the observed work flows would match those reported in the DSM interviews),
and (3) a mechanism for identifying and correcting any inconsistencies in the DSM
model.
Once all the data was collected, the GM R&D DSM Team members were also
involved in building the preliminary DSM process model.
The model was built
throughout a series of working sessions attended by the entire DSM Team. Because there
were at least two interviewers present at every interview, the DSM Team members shared
their notes from the interviews in order to determine all the tasks that should be included
in the model along with their corresponding interdependencies.
After the entire DSM
Team reached consensus and agreed on the preliminary DSM, the model was validated
by the appropriate interviewees.
The DSM Team met again to make the necessary
changes to the DSM process model and to discuss the results of the DSM tearing and
partitioning analyses.
Once the summer was over, the DSM Team members from GM R&D continued to
work on the project and to communicate with the MIT CIPD via telephone conferences.
Thus, the weekly DSM Team meetings were still held throughout the rest of the semester.
During this period, the DSM Team conducted a number of follow up interviews in order
to gather some of numerical data required for the simulations.
Again, the prior
experience of a GM R&D DSM Team member with process modeling and simulation
techniques proved to be very valuable when developing the framework for performing
the simulation analysis. However, all of the simulations were performed at MIT, so the
rest of the DSM Team did not get any practical experience in DSM simulation. Although
the GM R&D DSM Team understand what the simulation does and the inputs required,
this is aspect of the DSM deployment process could be improved in the future.
102
It can be concluded that the deployment of DSM methods at GM R&D was a
success. The value of DSM tools and methods to GM has been demonstrated by applying
them in the context of the company's internal processes. Also, the GM R&D DSM team
members have obtained practical experience in performing DSM related research and can
contribute in the future with new ideas and studies in the field. Finally, this project has
cultivated both capability and interest in the application of DSM methods at GM R&D.
Several follow-up projects in the application of DSM methods to other problems related
to product development are already under discussion.
5.4
Observations on CDP Team members' involvement
Another aspect of this DSM deployment experience from which lessons can be
learned is the involvement of the product development teams in the project. It should be
noted that the first challenge faced by the DSM Team was establishing the necessary
working relationships with project partners outside of the R&D Center. Given that the
R&D Center is organizationally separated from the operating unit responsible for
executing the CDP, it was very challenging to identify the appropriate people with
authority to select a program for the study. After a series of management reviews to
obtain full buy-in and support for the project, two product development teams were
selected for study.
A good relationship with the program manager of these two teams proved to be
key in the success of the study. First, he invited the DSM Team to attend both teams'
weekly "town hall" meetings.
Our purposes in attending were to get a first hand
understanding of the issues faced by the product development team to support our
103
interviews with the team members and to establish personal contacts with the team
members prior to our interviews. The program manager was key in pointing out a list of
team members who should be interviewed for the DSM study.
In general, most of the team members were very receptive to the idea of
collaborating with the DSM project. In order to setup the interviews, an initial approach
was made through electronic mail. The response rate to this approach was relatively low,
so another round of telephone calls had to follow.
One round of phone calls was
sufficient to schedule an interview date with most members. A few team members were
initially reluctant to be interviewed, but after talking to their colleagues who had been
interviewed and understanding the value of the DSM project agreed to grant us an
interview.
Unfortunately, one specific functional activity did not want to collaborate with the
DSM study. Even though they initially gave a verbal commitment to be interviewed,
they ignored our communications when trying to schedule an interview and when met
personally would offer a number of excuses for deferring the interview. However, this
activity's tasks and their interdependencies with other activities in the CDP were
identified through the interviews of other functions that either received information from
or provided information to them.
This kind of conflict is very typical in research
involving interviews like the DSM study. Most of the time, however, it has nothing to do
with the study itself and is due to organizational barriers within the teams that are often
observed in matrixed organizational structures.
All the team members interviewed expressed a genuine interest in the study
during their interviews.
They understood its value, and saw in the interviews an
opportunity to make suggestions on how their role in the CDP could be improved. Even
104
though total confidentiality was guaranteed at the interviews, there were two persons who
preferred not to be tape-recorded. Another interesting observation is that a number of
individuals from each team that had the same role in their respective teams asked if they
could be interviewed together. The reason for this request was that even though they
worked on different programs, they worked very closely together because they functioned
in the same role on each team. By having a combined interview, they argued that they
could provide a more complete picture of their role in the CDP. This is another example
of the impact of matrixed organizational structures on the execution of the process. From
the DSM Team's perspective, these group interviews were helpful as interviewees
provided a more complete description of their role in the CDP than if they were
interviewed separately. On several cases, one interviewee would correct the other one
when the information provided was not totally accurate, or when some details were
omitted. Thus, this kind of interview allowed the interviewers to verify instantly the
information that was being provided. On the other hand, this kind of interview limited
the interviewers to obtain information about a given function from a single interview.
The negative aspect of this is that in case the members from the two programs had very
different opinions about some of their tasks and their role in the CDP, this could be better
captured in individual interviews.
Interviews typically lasted approximately one hour.
In general, interviewees
found that it was very difficult to identify a discrete set of work tasks that they performed
during the CDP. This may have been because of the relative newness of the process or
because the CDP had been designed on a deliverables basis rather than on a work-task
basis.
The DSM Team found it helpful with many interviewees to initiate the
conversation using charts of expected deliverables that were available for most functions.
105
It was found that one hour was only enough time to collect information regarding the
interviewee's tasks, the corresponding tasks providing input information or receiving an
output, and in some cases, the time durations of the interviewee's tasks. Therefore, the
remainder of the data required for the DSM simulations, such as rework probabilities and
impact of rework, was collected after the first round of interviews was complete and after
a draft process model had been constructed.
At this point, the DSM Team collected the
remaining data either through a second, usually shorter interview or via electronic mail.
The interviewees found it quite difficult to provide the numerical data associated
with their work tasks. This was especially true for the numerical data collected after the
first interview: task overlapping percentages, rework probabilities, and impact of rework.
This may be due to the highly parallel, concurrent, and continuous nature of the work
performed in the CDP or to a general bias among the interviewees towards conservative
estimates for process parameters.
The scope of data collection extended beyond the members of the product
development teams. The DSM Team also obtained the support of the professionals in
charge of designing the early phases of the PPP and of verifying its operational
implementation. Thus, these individuals were also very helpful in validating the DSM
model.
However, they brought a different perspective, related to how Concept
Development in particular should be executed versus how it actually was. Nevertheless,
it was a very interesting exercise to review the DSM process model with them. The
program manager also provided a very valuable contribution in the validation of the
process model.
In conclusion, it should be observed that in this type of research it is vital to have
a good relationship with the program manager of the team being studied. It should also
106
be expected that not every team member would be as cooperative as required for this kind
of study.
Whether it is due to time constraints, concerns over confidentiality of
information, or organizational barriers within the corporate sponsor, many members of
the team resist being interviewed. Still, most individuals see the potential impact that this
kind of research can have on their role in the CDP, so they try to make this experience a
very positive one.
5.5
Chapter Summary
This chapter summarizes the different challenges that were faced during the
deployment process of DSM methods from MIT to General Motors R&D. Some of the
key lessons learned from this process to keep in mind for future exercises include that
part of the success of the study largely depends on the relationship of the researchers with
the program manager. It was also observed that dividing the data collection process into
two steps proved to be more efficient for developing the DSM model. Similarly, it was
found that previous documentation of the process and its tasks were very useful for the
interviewees in helping them define their tasks, and for the DSM researchers in helping
them build the DSM model and verify information provided at the interviews. Other
novelties introduced in the DSM study include the use of direct observation to understand
the process, and conducting combined interviews for data collection.
The deployment of DSM tools and analysis techniques to General Motors R&D
can be considered to be very successful. Not only were all the objectives of the study
accomplished, including training a team of GM R&D researchers on DSM methods, but
also enough interest has been generated on the topic to start planning new DSM studies
107
for the near future. However, providing GM researchers some practical training on how
to run the simulation models could still enhance this deployment process in the future.
108
Chapter 6
Conclusions
A method for analyzing the impact of the location of gate reviews on the overall
duration of stage-gate product development processes using the Design Structure Matrix
has been presented. By building a DSM model of a product development process as it is
actually executed, valuable insights can be obtained and unplanned iterations can be
identified.
After performing the traditional partitioning analysis, the placement of the
gate review can be aligned with the natural structure of the process in order to avoid
inter-phase iterations.
Existing simulation models can then be used to predict the
development time with different locations of the gate review.
In general, it is
recommended to place the gate review outside of an iteration block, as it increases the
probability of successfully meeting all the requirements of a gate review at the end of a
design stage in a timely manner. In this analysis, the DSM has proved to be a very
powerful tool in identifying the differences between the way a process is actually
executed and the way it is supposed to be.
A concept described as a stage buffer, based on Goldratt's critical chain
methodology, has also been introduced. By placing a buffer at the end of a stage, a gate
review can be scheduled in such a manner that will allow the product development team
to complete their assigned tasks and perform the necessary iterations on time. Thus, the
chances of advancing to the next stage of the process without delaying the project can be
significantly increased.
109
This thesis also presents in detail the results of a case study in which a front-end
product development process has been modeled at General Motors using the Design
Structure Matrix (DSM). In this study, an improper location of a gate review was found
to be the reason why the project had been delayed several months behind schedule. A
new stage-gate structure was proposed, allowing iterations to occur only within a stage
and avoiding inter-phase iterations.
Lessons learned of the deployment of the DSM
method from academia to industry have also been documented in detail, to be used as a
reference in future deployment exercises.
Future research in this topic could be performed by investigating quality vs.
development time tradeoffs when a gate review is located in the middle of an iteration
loop. Another direction of future research can consist of upgrading existing simulation
models to allow time buffers to be included.
110
References
[1] Ahmadi, R. and Wang, R.H., "Managing Development Risk in Product Design
Processes," Operations Research, Vol. 47, No. 2, pp. 235-246, March-April 1999.
[2] Bromberg, M.F., Modeling Design Rework in a Product Development Process,
Master's Thesis (ME/Mgt.), MIT, Cambridge, MA, 2000.
[3] Browning, T.R. and Eppinger, S.D., "Modeling the Impact of Process Architecture on
Cost and Schedule Risk in Product Development," MIT Sloan School of Management,
Cambridge, MA, Working Paper No. 4050, April 2000.
[4] Browning, T.R., "Categorization of Design Structure Matrix Applications for Project
Management, Organization Design, and Systems Engineering," IEEE Transactions on
Engineering Management, April 1999.
[5] Browning, T.R., "Designing System Development Projects for Organizational
Integration," John Wiley & Sons, Inc., Syst Eng 2, 1999, pp. 217-225.
[6] Browning, T.R. "Use of Dependency Structure Matrices for Product Development
Cycle Time Reduction," Proceedings of the Fifth ISPE International Conference on
Concurrent Engineering: Research and Applications, Tokyo, Japan, July 15-17, 1998, pp.
89-96.
[7] Browning, T.R., "Applying the Design Structure Matrix to System Decomposition
and Integration Problems: A Review and New Directions," IEEE Transactions on
Engineering Management, Vol. 48, No. 3, Aug. 2001 pp. 292-306.
[8] Browning, T.R., Modeling and Analyzing Cost, Schedule, and Performance in
Complex System Product Development, PhD Thesis (TMP), MIT, Cambridge, MA,
1999.
[9] Carrascosa, M. et al., "Using the Design Structure Matrix to Estimate Product
Development Time," Proceedings of the ASME Design Engineering Technical
Conferences (Design Automation Conference), Atlanta, GA, Sept. 13-16, 1998.
[10] Cho, S., An Integrated Method for Managing Complex Engineering Projects Using
the Design Structure Matrix and Advanced Simulation, MS Thesis (ME), MIT,
Cambridge, MA, 2001.
[11] Cho, S. and Eppinger, S.D., "Product Development Process Modeling Using
Advanced Simulation," Proceedings of the 13th International Conference on Design
Theory and Methodology (DTM 2001), September 9-12, 2001, Pittsburgh, PA.
111
[12] Cooper, R.G. "Doing It Right - Winning With New Products". July-August 2000.
< http://www.stage-gate.com/research.htm>
[13] Cooper, R.G., Winning at New Products,Addison-Wesley, Menlo Park, CA, 1986.
[14] Crow, K. Control the NPD Process With Stage Gates Reviews And
Design Reviews. April 20, 2002. <http://www.npd-solutions.com/reviews.html>
[15] Denker, S.P. et al., "Planning Concurrency and Managing Iteration in Projects,"
Center for Quality of Management Journal, Vol. 8, No. 2, Autumn 1999.
[16] Dong, Q. and Whitney, D.E., "Designing a Requirement Driven Product
Development Process," Proceedings of the 13th International Conference on Design
Theory and Methodology (DTM 2001), September 9-12, 2001, Pittsburgh, PA.
[17] Dong, Q., Representing Information Flow and Knowledge Management in Product
Design Using the Design Structure Matrix, MS Thesis (ME), MIT, Cambridge, MA,
1999.
[18] Eppinger, S.D. and Salminen, V., "Patterns of Product Development Interactions,"
International Conference on Engineering Design, Glasgow, Scotland, August 2001.
[19] Eppinger, S.D. and Whitney, D.E., "Organizing the Tasks in Complex Design
Projects," MIT Sloan School of Management, Cambridge, MA, Working Paper No. 3083,
October 1989.
[20] Eppinger, S.D. et al., "A Model-based Method for Organizing Tasks in Product
Development," Research in Engineering Design, Vol. 6, No. 1, pp. 1-13, 1994.
[21] Eppinger, S.D. et al., "Organizing the Tasks in Complex Design Projects," ASME
Conference on Design Theory and Methodology, Chicago, IL, September 1990, pp. 3946.
[22] Eppinger, S.D., "Innovation at the Speed of Information," Harvard Business Review,
Vol. 79, No. 1, pp. 149-158, January 2001.
[23] Gebala, D.A. and Eppinger S.D., "Methods for Analyzing Design Procedures,"
Proceedings of the ASME Third International Conference on Design Theory and
Methodology, 1991, pp. 227-233.
[24] Goldratt, E.M. CriticalChain, The North River Press, Great Barrington, MA, 1997.
[25] Goldt, S.C., Implementing Cycle Time Reduction in Product Development, Master's
Thesis (ME/Mgt.), MIT, Cambridge, MA, 1995.
112
[26] Ha, A.Y. and Porteus, E.L., "Optimal Timing of Reviews in Concurrent Design for
Manufacturability," Management Science, Vol. 41, No. 9, pp. 1431-1447, September
1995.
[27] Isaksson, 0. et al., "Evaluation of Design Process Alternatives Using Signal Flow
Graphs," Journal of Engineering Design, Vol. 11, No. 3, pp. 211-224, 2000.
[28] Joglekar, N. et al., "Performance of Coupled Product Development Activities with a
Deadline," Management Science, Vol. 47 (12), 2001.
[29] Krishnan, V. and Ulrich, K., "Product Development Decisions: A Review of the
Literature," The Wharton School, Philadelphia, PA, Working Paper, October 1998.
[30] Krishnan, V. et al., "A Model-Based Framework to Overlap Product Development
Activities," Management Science, Vol. 43, No. 4, April 1997.
[31] Kulkarni, D.M., "Controlling Rework in the Vehicle Development Process," General
Motors R&D Center Contract Report CR-99/01/ESL, April 1999.
[32] McCord, K.R. and Eppinger S.D., "Managing the Integration Problem in Concurrent
Engineering," MIT Sloan School of Management, Cambridge, MA, Working Paper No.
3594, 1993.
[33] Merkhofer, M.W., "Quantifying Judgmental Uncertainty: Methodology,
Experiences, and Insights," IEEE Transactions on Systems, Man, and Cybernetics, Vol.
SMC-17, No. 5, September - October 1987.
[34] Mori, T. et al., "Task Planning for Product Development by Strategic Scheduling of
Design Reviews," Proceedings of the ASME Design Engineering Technical Conferences,
Las Vegas, NV, Sept. 12-15, 1999.
[35] New Product Dynamics, Portland, OR. Stage Gate Process Versus Time to Market.
April 18, 2002. < http://www.newproductdynamics.com/stage-gate.htm>
[36] Okundaye, B.O., New Product Development in the North American Truck Industry:
An Empirical Investigation and Hypothesis, Master's Thesis (Mgt.), MIT, Cambridge,
MA, 1994.
[37] Oosterwal, D.P., Product Development: A Case Study of General Motors, Master's
Thesis (Mgt.), MIT, Cambridge, MA, 1993.
[38] Pahl, G. and Beitz, W., EngineeringDesign, Springer-Verlag, London, 1984.
[39] Patterson, S.P., Managing Variation During Pre-production Activities, Master's
Thesis (ME/Mgt.), MIT, Cambridge, MA, 1994.
113
[40] Pimmler, T. and Eppinger, S.D., "Integration Analysis of Product Decompositions,"
Proceedings of the ASME 6th International Conference on Design Theory and
Methodology, Minneapolis, MN, Sept. 1994.
[41] Product Development and Management Association. Glossary of New Product
Development Terms. August 12, 2001. <http://www.pdma.org/library/glossary.html>
[42] Product Development Institute Inc., Ancaster, Canada. Stage-Gate. April 20, 2002.
< http://prod-dev.com/stagegate.shtml>
[43] Raab, S.R., Project Management for New Product Development, Master's Thesis
(Mgt.), MIT, Cambridge, MA, 1992.
[44] Roemer, T.A. et al., "Structuring Product Development Processes," European
Journal of Operational Research, Vol. 130, pp. 539-558, 2001.
[45] Sabbaghian, N. et al., "Product Development Process Capture and Display Using
Web-Based Technologies," Proceedings of the IEEE International Conference on
Systems, Man, and Cybernetics, San Diego, CA, Oct. 11-14, 1998, pp. 2664-2669.
[46] Salwen, D.J., Investigating the Relevance of Deadlines for Product Development,
Master's Thesis (Mgt.), MIT, Cambridge, MA, 1993.
[47] Sequeira, M.W., Use of the Design Structure Matrix in the Improvement of an
Automobile Development Process, Master's Thesis (MSE/Mgt.), MIT, Cambridge, MA,
1991.
[48] Shephard, G. and Kirkwood, C., "Managing the Judgmental Probability Elicitation
Process: A Case Study of Analyst/Manager Interaction," IEEE Transactions on
Engineering Management, Vol. 41, No. 4, November 1994, pp. 414-425.
[49] Smith, P.G. and Reinertsen, D.G., "Shortening the Product Development Cycle,"
Research-Technology Management, May-June 1992, pp. 44-49.
[50] Smith, R. and Eppinger, S.D., "Identifying Controlling Features of Engineering
Design Iteration," MIT Sloan School of Management, Cambridge, MA, Working Paper
No. 3348, October 1991.
[51] Smith, R.P. and Eppinger, S.D., "Deciding Between Sequential and Parallel Tasks in
Engineering Design," Concurrent Engineering: Research and Applications, Vol. 6, pp.
15-25, 1998.
[52] Steward, D.V., "The Design Structure System: A Method for Managing the Design
of Complex Systems," IEEE Transactions on Engineering Management, Vol. 28, pp. 7174, 1981.
114
[53] Ulrich, K. and Eppinger, S., Product Design and Development, McGraw-Hill, Inc.,
New York, 1999.
[54] Unger, D., "Planning Design Iterations in Product Development," MIT CIPD Fall
Research Review, Cambridge, MA, November 2001.
[55] Ward, Allen et al., "Another Look at How Toyota Integrates Product Development,"
Harvard Business Review, pp. 36-49, July - August 1998.
[56] Ward, Allen et al., "The Second Toyota Paradox: How Delaying Decisions Can
Make Better Cars Faster," Sloan Management Review, Spring 1995, pp. 43-61.
[57] Welch, C.J., Application of the Design Structure Matrix: A Case Study in Process
Improvement Dynamics, Master's Thesis (ME/Mgt), MIT, Cambridge, MA, 2001.
[58] Whitney, D. MIT Center for Technology, Policy and Industrial Development,
Personal Interview. September 24, 2001.
[59] Yassine, A. and Browning, T.R., "Analyzing Multiple Product Development
Projects Based On Information and Resource Constraints," IEEE System, Man, and
Cybernetics - Part A: Systems and Humans, Mar. 2001.
[60] Yassine, A. et al., "Assessment of Rework Probabilities for Design Structure Matrix
Simulation in Product Development Management," Proceedings of the 13th International
Conference on Design Theory and Methodology (DTM 2001), Sept. 9-12, 2001,
Pittsburgh, PA.
[61] Yassine, A. et al., "DO-IT-RIGHT-FIRST-TIME (DRFT) Approach to Design
Structure Matrix (DSM) Restructuring," Proceedings of the 12th International
Conference on Design Theory and Methodology (DTM 2000), Sept. 10-13, 2000,
Baltimore, Maryland.
[62] Yassine, A. et al., "Engineering Design Management: An Information Structure
Approach," International Journal of Production Research, Vol. 37, No. 13, 1999, pp.
2957-2975.
115
116
Appendix A - Standardized Data Collection Tool for
Building DSM Models
A.1
Overview
Serving primarily as a data collection instrument, the interview template consists of four
sections:
1. Task related questions - In this section, a discrete task is identified and described
by the interviewee. Questions related to task duration are then asked, including a
range of duration (minimum, maximum, and most likely), and the identification of
sources that may cause variation to these durations.
Interestingly, duration
information was difficult to obtain from some interviewees because of their
uncertainty on accuracy of the value they could provide.
2. Inputs - The interviewee identifies a number of tasks that provide inputs to the
task being discussed. For each of these input tasks, there is a series of questions
designed to obtain data required to run the process simulation:
" Frequency: How often do you interact with the person providing this
input?
"
Overlapping:What percentage of the input task must be completed before
you can start your task?
*
Rework probability: What is the probability that rework will be needed for
this task due to a change in this input?
117
"
Impact of rework: What percentage of the task needs to be redone due to
this change?
" Learning curve: What percentage of the original task duration can be
salvaged to due to a learning curve?
3. Outputs - The interviewee is also asked to identify the tasks receiving the outputs
from the task being discussed, and to estimate percentage values of rework
probability and impact.
4. Resources related questions - These are questions related to how additional
resources could affect the total duration of the process. These questions were
prepared to collect information to support an upcoming workflow management /
scheduling project.
118
Resources:
Can this task be speeded up?
Yes
No
If so, how do the following influence task duration?
i) Add one person (with skill level similar to yours):
Decrease time to complete task by 50%
Decrease time to complete task by 25%
Decrease time to complete task by 10%
No change
Other (Please specify)
ii) Additional training
Decrease time to complete task by 50%
Decrease time to complete task by 25%
Decrease time to complete task by 10%
No change
Other (Please specify)
iii) Add specialized equipment (computing, visualization, test facilities, etc)
Decrease time to complete task by 50%
Decrease time to complete task by 25%
Decrease time to complete task by 10%
No change
Other (Please specify)
iv) Other (please specify)
122
Output:
#1
Who needs information produced in this task?
Name:
Title:
Tel:
Email:
What information is produced in this task?
Describe:
Written Documents
Spreadsheets
Physical Prototypes
Computer Models
Other
Rework probability:
What is the probability that rework will be needed for this task due to a change
in this input?:
Medium
Very High
Low
High
Very Low
Can you provide a probability estimate?. . . . . . . . . . . . . . . . . . . . . . .
Impact of rework:
What percentage of the work needs to be redone due to this change?:
AJI the task
Half the task
Most of the task
Less than half
Can you provide a percentage estimate? . . . . . . . . . . . . . . . . . . . . . . .
Output:
#2
Who needs information produced in this task?
Name:
Nime:
Email:
What information is produced in this task?
1Describe,
Rework probability:
What is the probability that rework will be needed for this task due to a change
in this input?:
Medium
Very High
Low
High
Very Low
Can you provide a probability estimate?. . . . . . . . . . . . . . . . . . . . . . .
All the task
Impact of rework:
What percentage of the work needs to be redone due to this change?:
Half the task
Most of the task
Less than half
Can you provide a percentage estimate? . . . . . . . . . . . . . . . . . . . . . . .
121
Input:
#1
W hat task provides input needed to complete this task? . . . . . . . . . . . . . . ITask name
W ho is responsible for providing this input? . . . . . . . . . . . . . . . . . . . . .'Name:
Title:
Tel:
Email:
Describe:
What type of input is required? :
Information
If this input is information, in what format is it needed?:
What is this input needed for?:
Frequency:
Start Task
Material
Spatial
Written Documents
Computer Models
Early Stages
Spreadsheets
Physical Prototype
Other
Late Stages
How often do you interact with the person providing this input?:
At the end to veril
Once
Daily
Bi-Weekly
Overlapping:
Energy
Can you start your task before this input is 100 0 complete?
Monthly
Yes
Weekly
Quarterly
Neve
No
If your answer was yes, can you provide an estimate of the percentage of the input
task that must be complete before you can start your task? . . . . . . . . . . . . . . . .
What is the probability that rework will be needed for this task due to a change
in this input?:
Very High
Medium
Rework probability:
High
Low
Very Lov
Can you provide a probability estimate? . . . . . . . . . . . . . . . . . . . . . . . . . .
Based on your experience in similar projects, how many times you see this happening?.
All the task
Impact of rework:
What percentage of the work needs to be redone due to this change?:
Half the task
Most of the task
Less than half
Can you provide a percentage estimate? . . . . . . . . . . . . . . . . . . . . . . . . .
Learning curve:
LC acts a as a multiplier to the rework impacts:
- If LC = 0, then 00/ of original task duration is required when performing the task in subsequent iterations
- If LC = 1, then 100% of original task duration is required
Can you provide a percentage estimate? . . . . . . . . . . . . . . . . . . . . . . . . .
Please provide an estimate of the percentage reduction in the rework probability
with each iteration of the task . . . . . . . . .
. . . . . . . . . . . . . . . . . . . ...
120
A.2
Interview Sheet
DSM Study Interview Sheet
Name:
Ilntervievei
Organization:
Date:
Title:
Email:
Tel:
Option:
Address:
On how many options have you worked before? . . . . . . . . . . . . . . . . .I
I -
Task name:
I
Description:
Estimated time to perform task:
(Days)
MIN
MOST LIKELY
What percentage of this time is spent working on this project? . . . . . . . . . . . . . . .
If you were to work full time on this project, how long would it take? . . . . . . . . . . . . .
Can you explain why does this task take you this amount of time, and what may cause variations in the time?
119
Comments:
123
124
Appendix B - DSM Models Used in Case Study
B.1
Concept Development Process
Figure B.1: DSM simulation case 1: Phasel, with Phases 2 and 3 collapsed.
125
4
i
4
4t
Figure B.2: DSM simulation case 2: Phases 2 and 3, with Phase 1 collapsed.
126
I
+-'4
SI I I I | | | I l
ii
I I
I
I
I
I I I
I
I
I
I I I
I I
I
I
I
I I I I
I I
zmiit|
~H~IL
I I
I
I I I
I
I I
E
I.W
I1
.1
i iH-!H
I
lii i !iii i !
Pq 1 1 1 N I I I I I I I I
I IQ I I M I I ! ! ! ! ! !
------
................
-H
I
-----
-
--
---i
+
1-
+
W
f
I
-- 4
-- I
Figure B.3: DSM simulation case 3: Phase 2, with Phases 1 and 3 collapsed.
127
.
.-.
..
.. .
-HI I
-it
U
U
-LI-v
Figure B.4: DSM simulation case 4: Phase 3, with Phases 1 and 2 collapsed.
128
Figure B.5: DSM simulation case 5: Large iteration block with other tasks collapsed.
129
U
B.2
Alternative Phases
Figure B.6: Alternative phases simulation: Phase A, with Phases B, C, and D collapsed.
130
mill
2
im
-0000-i
M
M
Figure B.7: Alternative phases simulation: Phase B, with Phases A, C, and D collapsed.
131
Figure B.8: Alternative phases simulation: Phase C, with Phases A, B, and D collapsed.
132
Figure B.9: Alternative phases simulation: Phase D, with Phases A, B, and C collapsed.
133
Appendix C - List of Tasks in DSM Model
C.1
DSM Tasks with Input and Output Relationships
Function
Task Number & Task Name
Marketing/Planning [11 Develop Marketing Requirements Summary
Phase Tasks Providing Tasks Receiving Outputs
Inputs
3, 5, 6, 7, 8, 10, 11, 12, 13, 14, 15, 16,18,
20,21, 22, 25, 30, 39,40, 41,42,43, 44
1
51,52,53,54
[2] Provide Preliminary 2-D Sketches
1
Planning
[4] Develop Timing Plan for Concept Development
Process
1
39, 91,118
39, 91,118
Planning
[3] Identify Target Vehicle Architectures
1
1
16, 18, 20, 22, 25, 29, 30, 37, 80, 81
Marketing
[5] Provide Competitive Data (1st Cut)
1
1
9
Marketing
[6] Identify Key Sales Volume Drivers
1
1
7
Marketing
[8] Provide List of Key Technologies Desired for
the Vehicle
[10] Identify Critical Product Characteristics
1
1
13, 36
1
1
11, 28, 40, 41,42, 43, 44,65,97,112
1
1
23
Marketing
[21] Understand Requirements for Underhood
Compartment
[7] Provide Initial Sales Volume Forecast
1
1, 6
14,18, 20, 35, 80,115
Systems
Engineering
[9] Conduct Benchmarking / Competitive
Assessment (2nd Cut)
1
5
97
Systems
Engineering
[11] Set High-Level Engineering Target
Parameters
1
1,10
12,19,25,28, 30, 51,52,53, 54, 65,97,
112
1
1,3
17,19,40, 41, 42,43,80,109
Design Studio
Systems
Engineering
Underhood
Vehicle Integration [16] Create Initial Bill of Material
Powertrain
Integration
[22] Evaluate Different Powertrain Options
Considered for the Vehicle
1
1, 3
34
Planning
[36] Create Offline Technology Development Plans
1
8
39,90
Quality
[12] Conduct Competitive Quality Assessments
1
1,11
15, 38
Marketing
[13] Develop Preliminary Vehicle Order Guide
1
1,8,14
14,17
Marketing
[14] Provide Revenue Estimate
1
1,7,13
13,35
Manufacturing
[18] Develop Initial Program Manufacturing
1
1, 3,7
19,30,37,39
Strategy
Body
[25] Understand Structural Requirements for Body
1
1, 3,11
26,27,37,71
Quality
[15] Set Vehicle Level Quality Targets
1
1, 12
38,55
Manufacturing
[19] Generate Plan Layouts and Evaluate
Manufacturing Feasibility
1
11,16,18
20, 37
Body
1
25
27, 31,56
Vehicle Concept
Engineering
[26] Identify Cross-Sections for Body Structural
Members
[30]Develop Initial Integrated Vehicle CAD Models
(for each architecture)
1
1, 3,11,18
28, 31, 32, 37
Performance
Development
[28] Develop Preliminary Balance of Physical
Parameters
1
10,11,30
29,49
135
Vehicle Integration [17] Develop Engineering Product Content Sheet
1
13,16,27
20, 33, 35,63,80,81,107,109,112
Manufacturing
1
1, 3, 7,17, 19
35, 89
Body
[20] Create Manufacturing Content Sheets and
Estimate Facilities Investment Levels
[27] Establish Body Part Commonality Strategy
1
25,26,37
17, 35, 56,76,77,80,81,98,109
Performance
Development
[29] Provide Alternative Architecture and
Configuration Trade-Offs With Assessments
1
3, 28, 38
37, 39
Planning
[33] Run Initial Workload Model
1
17
35
Finance
[35] Prepare Initial Financial/Business Assessment
1
7,14,17, 20, 27, 33
39, 89
Vehicle Integration [37] Recommend Final Architecture
1
3,18,19, 25, 29, 30, 39
27, 34,39,40,41,42,43,63,65
Quality
1
12,15, 37
29, 55
[38] Assess Risks and Balance Quality Targets at
Vehicle Level
Program
Management
Team
Chassis
[39] Review Phase 1
1
1, 4, 18, 29, 35, 36, 37
4, 37, 40,41,42,43
[40] Develop Chassis Bill of Material
2
1,10,16,37,39
45,51,73,87,92
Cockpit
[41] Develop Cockpit Bill of Material
2
1,10,16, 37, 39
46, 52, 73, 87, 92
Passenger
[42] Develop Passenger Compartment Bill of
Material
[43] Develop Underhood Compartment Bill of
Material
[44] Develop Powertrain Bill of Material
2
1,10,16, 37, 39
47, 53, 73, 87, 92
2
1,10,16, 37,39
48, 54, 73, 87, 92
2
1,10, 37
24, 34, 50, 54
Quality
[55] Allocate Vehicle Level Quality Targets
2
15, 38
87
Body
[56]
Develop Initial Finite Element Model for Body
Structure
2
26, 27
65, 71, 82, 84
Manufacturing
[63] Determine Manufacturing Requirements
2
17, 37
71, 93, 94, 95, 96,109
Underhood
[23] Summarize Vehicle Technical Requirements
for Underhood Compartment
[24] Summarize Powertrain Technical
Requirements for Underhood Compartment
[34] Design CAD for Powertrain
1
21, 24
24
1
23,44
23
1
22, 37, 44,54
54, 64, 70, 99
[54] Generate Packaging Layouts for Underhood
Compartment
[51] Generate Packaging Layouts for Chassis
Systems
2
2,11, 34, 43,44
34, 60, 69,103
2
2,11,40
57, 66,100
Cockpit
[52] Generate Packaging Layouts for Cockpit
2
2,11,41
58, 67,101
Passenger
[53] Generate Packaging Layouts for Passenger
Compartment
2
2, 11,42
59, 68, 102
Quality
[87] Assess Risks and Balance Quality Targets
2
40,41,42,43,55
65
Chassis
[57] Perform Physical Interference Assessment for
2
51
61, 62
Cockpit
Chassis Systems
[58] Perform Physical Interference Assessment for
2
52
32, 61, 62, 67
2
53
32, 61, 62, 68
2
54
61, 62
2
34
65
26, 30, 32
32
II
Underhood
Powertrain
Integration
Powertrain
Integration
Powertrain
Integration
Underhood
Chassis
Cockpit
Passenger
[59] Perform Physical Interference Assessment for
Passenger Compartment
Underhood
Powertrain
Integration
[60] Perform Physical Interference Assessment for
Underhood Compartment
[64] Provide Engine Data for Performance
Assessments
Vehicle Concept
Engineering
[31] Generate Packaging Layouts for Body
Structural Members
1
I
I
136
Vehicle Concept
Engineering
Design Studio
[321 Develop Occupant Packaging
1
30, 31, 58, 59
31, 67, 68,74, 84
[61] Create Initial Visual Surfaces
2
57,58,59,60
66,67,68,69,71,83,84,104,106
Vehicle Concept
Engineering
Chassis
[62] Develop Integrated Vehicle-Level Packaging
Layout and Physical Interference Model
[66] Identify Major Technical Challenges and
Conduct Quick Studies - Chassis
[67] Identify Major Technical Challenges and
Conduct Quick Studies - Cockpit
[68] Identify Major Technical Challenges and
Conduct Quick Studies - Passenger
[69] Identify Major Technical Challenges and
Conduct Quick Studies - Underhood Compartment
2
65, 82, 83, 84,112
2
58, 59, 57, 60
51, 61
73,93
2
32,52, 58, 61
73, 91, 94
2
32,53, 59, 61
73, 91, 95
2
54, 61
70, 73, 91, 96
[82] Assess Body Concept Compatibility with
Integrated Vehicle-Level Physical Interference
Model
[83] Generate Surface Limits for Bodyside
2
56, 62
106
2
61, 62
77, 84
[70] Identify Major Technical Challenges and
Conduct Quick Studies - Powertrain
2
34, 69
50, 91, 96, 99
[71] Identify Major Technical Challenges and
Conduct Quick Studies - Body
Die Manufacturing [76] Provide Die Investment Estimates
2
25, 56,61,63,77
73, 91,98
2
27, 77, 98
49, 77
Die Manufacturing [77] Determine Die Sizes and Designs
2
27, 76, 83, 98
71, 76, 78
Cockpit
Passenger
Underhood
Body
Vehicle Concept
Engineering
Powertrain
Integration
Body
Body
[98] Finalize Body Bill of Material
3
27, 71
73,77, 92,106
Powertrain
[50] Track Cost/Mass/Quality Status for Powertrain
2
44, 70
48, 99
Integration
System
2
28, 76
65, 92
2
77
89
[45] Track Cost/Mass/Quality Status for Chassis
Systems
[46] Track Cost/Mass/Quality Status for Cockpit
2
65,72,92,93
2
40, 72
I
41,72
[47] Track Cost/Mass/Quality Status for the
Passenger Compartment
[48] Track Cost/Mass/Quality Status for the
Underhood Compartment
[65] Conduct Performance Synthesis and Analysis
2
42, 72
65, 72, 92, 95
2
43,50, 72
65, 72,92, 96
2
10, 11, 37, 45, 46, 47, 48, 74, 90, 91, 93, 94, 95, 96,112
49, 56, 62, 64, 87
Vehicle Integration [72] Track Total Vehicle Issues
2
Vehicle Integration [73] Maintain Vehicle Mainstream Chart and
Update Engineering Product Content Sheet
2
45,46, 47,48, 79,93, 94, 45,46,47,48, 73, 79, 84, 85, 86, 90, 93,
94,95, 96,112
95, 96, 97, 112
40,41,42,43,66,67,68, 80, 81,88,89,110,107,109,117,119
69, 71, 72, 86, 98
[49] Track Cost/Mass/Quality Status for the Body
Structure
Die Manufacturing [78] Prepare Die Development Schedules
Body
Chassis
Cockpit
Passenger
Underhood
Performance
Development
2
32, 65
75, 90
2
74
91, 93, 94, 95, 96,118
[79] Conduct Financial Analyses for Alternative
Subsystem Designs
[80] Develop Subassembly Strategy
2
72
72, 89
2
3, 7,16,17, 27, 73
93, 94,95,96
[81] Determine Assembly Tool and Parts
Commonality Strategy
[84] Develop Integrated Vehicle-level CAD Model
2
3, 17, 27, 73
93, 94, 95, 96
2
32, 56, 61, 62, 72, 83, 93, 106, 110,112,116
94,95, 96,100,101,102,
[86] Provide Customer's Perspective in Design
Decisions
[88] Run Updated Workload Model
2
72
73
2
73
89
Systems
Engineering
Systems
[74] Check Current Status of Vehicle Relative to
Requirements
[75] Develop Action Plans to Address Functional
Engineering
Performance Issues
Finance
Manufacturing
Manufacturing
Vehicle Concept
Engineering
65, 72, 92, 94
103
Marketing
Planning
137
Finance
[89] Update Financial Assessment and Finalize
Business Case
[90] Update Offline Technology Development
Plans
[91] Review Phase 2
2
20, 35, 73, 78, 79, 88, 115 91, 115, 117, 118
2
36, 65, 72, 74
91, 117, 118, 119
2
4, 65, 66, 67, 68, 69, 70,
71, 75,89, 90
4,112
[92] Prepare Program Quality Target Matrix
3
105,120
Chassis
[93] Follow up and Maintain Open Issues - Chassis
3
Cockpit
[94] Follow up and Maintain Open Issues - Cockpit
3
Passenger
[95] Follow up and Maintain Open Issues Passenger Compartment
3
40,41,42,43,45,46,47,
48, 49, 98
45, 63, 65, 66, 72, 75, 80,
81
46, 63, 65, 67, 72, 75, 80,
81
47, 63, 65, 68, 72, 75, 80,
81
Underhood
[96] Follow up and Maintain Open Issues Underhood Compartment
[97] Provide Supporting Information for Trade-offs
3
3
48, 63,65,69,70,72,75, 72, 84,103
80, 81
9,10,11,112
72, 76
[99] Refine Powertrain CAD model
3
34, 44, 50, 70,103
103
Chassis
[100] Design Integrated Assembly CAD Model for
Chassis
3
51, 93
84, 116
Cockpit
[101] Design Integrated Assembly CAD Model for
Cockpit
[102] Design Integrated Assembly CAD Model for
Passenger Compartment
[103] Design Integrated Assembly CAD Model for
Underhood Compartment
[105] Allocate component-level Quality Targets
and Assess Risks
[106] Develop Body Concept Model
3
52,94
84,116
3
53, 95
84,116
3
54, 96, 99
84, 99,104,116
3
92
112
3
61,82, 84, 98
107,108,110,112,116
Performance
Development
Marketing
[112] Assess Risks in Performance Requirements
3
[115] Provide Final Sales Volume Forecast
3
10, 11, 17, 62, 65, 72, 84, 72, 97,118
91,105,106
7, 89
89
Marketing
[85] Conduct Marketing Clinics
2
72
Design Studio
[104] Update Mainstream Visual Surfaces
[107] Develop Manufacturing Plant Conveyor
3
61,103
111, 116
3
17,73,106
108
[120] Provide Transition to Program Quality
Manager
[108] Assess Body Assembly Feasibility
3
92
3
106,107
109
3
111, 118,119
3
84,100,101,102,103,
104,106
16, 17, 27, 63, 73,108
Design Studio
[116] Develop Final Integrated Assembly CAD
Model for Entire Vehicle
[109] Create Manufacturing Requirements
Agreements
[111] Create Physical/irtual Appearance Models
3
104,116
Manufacturing
[110] Develop Final Assembly Assessment
3
73,84,106,109
113
Manufacturing
[113] Develop Preliminary Workplace Visualization
3
110
114
Planning
Program
Management
Team
Quality
Systems
Engineering
Powertrain
Integration
Passenger
Underhood
Quality
Body
Manufacturing
Quality
Manufacturing
Vehicle Concept
Engineering
Manufacturing
Strategy
72, 84,100
72, 84,101
72, 84,102
110
Models
Manufacturing
[114] Develop Manufacturing Program Timing Plan
3
113
118
Program
Management
Team
Planning
[118] Review Phase 3
3
4,75,89,90,112,114,
115,116
4,117,119
[117] Develop Plan for Review Board
3
73, 89, 90,118
3
73, 70,116,118
Vehicle Integration [119] Provide Transition to Vehicle Program After
Concept Development
Table C.1: DSM tasks with input and output relations.
138
C.2
DSM Task Key
Task #
Task Name
Phase
Function
1
Develop Marketing Requirements Summary
1
Marketing/Planning
2
Provide Preliminary 2-D Sketches
1
Design Studio
3
Identify Target Vehicle Architectures
1
Planning
4
Develop Timing Plan for Concept Development Process
1
Planning
5
Provide Competitive Data (1st Cut)
1
Marketing
6
Identify Key Sales Volume Drivers
1
Marketing
7
Provide Initial Sales Volume Forecast
1
Marketing
8
Provide List of Key Technologies Desired for the Vehicle
1
Marketing
9
Conduct Benchmarking / Competitive Assessment (2nd Cut)
1
Systems Engineering
10
Identify Critical Product Characteristics
1
Systems Engineering
11
Set High-Level Engineering Target Parameters
1
Systems Engineering
12
Conduct Competitive Quality Assessments
1
Quality
13
Develop Preliminary Vehicle Order Guide
1
Marketing
14
Provide Revenue Estimate
1
Marketing
15
Set Vehicle Level Quality Targets
1
Quality
16
Create Initial Bill of Material
1
Vehicle Integration
17
Develop Engineering Product Content Sheet
1
Vehicle Integration
18
Develop Initial Program Manufacturing Strategy
1
Manufacturing
19
Generate Plan Layouts and Evaluate Manufacturing Feasibility
1
Manufacturing
20
Create Manufacturing Content Sheets and Estimate Facilities Investment Levels
1
Manufacturing
21
Understand Requirements for Underhood Compartment
1
Underhood
22
Evaluate Different Powertrain Options Considered for the Vehicle
1
Powertrain Integration
23
Summarize Vehicle Technical Requirements for Underhood Compartment
1
Underhood
24
Summarize Powertrain Technical Requirements for Underhood Compartment
1
Powertrain Integration
25
Understand Structural Requirements for Body
1
Body
26
Identify Cross-Sections for Body Structural Members
1
Body
27
Establish Body Part Commonality Strategy
1
Body
28
Develop Preliminary Balance of Physical Parameters
1
Performance Development
29
Provide Alternative Architecture and Configuration Trade-Offs With Assessments
1
Performance Development
30
Develop Initial Integrated Vehicle CAD Models (for each architecture)
1
Vehicle Concept Engineering
31
Generate Packaging Layouts for Body Structural Members
1
Vehicle Concept Engineering
32
Develop Occupant Packaging
1
Vehicle Concept Engineering
33
Run Initial Workload Model
1
Planning
34
Design CAD for Powertrain
1
Powertrain Integration
35
Prepare Initial Financial/Business Assessment
1
Finance
36
Create Offline Technology Development Plans
1
Planning
37
Recommend Final Architecture
1
Vehicle Integration
38
Assess Risks and Balance Quality Targets at Vehicle Level
1
Quality
39
Review Phase 1
1
Program Management Team
40
Develop Chassis Bill of Material
2
Chassis
41
Develop Cockpit Bill of Material
2
Cockpit
42
Develop Passenger Compartment Bill of Material
2
Passenger
139
Underhood
43
Develop Underhood Compartment Bill of Material
2
44
Develop Powertrain Bill of Material
2
Powertrain Integration
45
Track Cost/Mass/Quality Status for Chassis Systems
2
Chassis
46
Track Cost/Mass/Quality Status for Cockpit
2
Cockpit
47
Track Cost/Mass/Quality Status for the Passenger Compartment
2
Passenger
48
Track Cost/Mass/Quality Status for the Underhood Compartment
2
Underhood
49
Track Cost/Mass/Quality Status for the Body Structure
2
Body
50
Track Cost/Mass/Quality Status for Powertrain System
2
Powertrain Integration
51
Generate Packaging Layouts for Chassis Systems
2
Chassis
52
Generate Packaging Layouts for Cockpit
2
Cockpit
53
Generate Packaging Layouts for Passenger Compartment
2
Passenger
54
Generate Packaging Layouts for Underhood Compartment
2
Underhood
55
Allocate Vehicle Level Quality Targets
2
Quality
56
Develop Initial Finite Element Model for Body Structure
2
Body
57
Perform Physical Interference Assessment for Chassis Systems
2
Chassis
58
Perform Physical Interference Assessment for Cockpit
2
Cockpit
59
Perform Physical Interference Assessment for Passenger Compartment
2
Passenger
60
Perform Physical Interference Assessment for Underhood Compartment
2
Underhood
61
Create Initial Visual Surfaces
2
Design Studio
62
Develop Integrated Vehicle-Level Packaging Layout and Physical Interference Model
2
Vehicle Concept Engineering
63
Determine Manufacturing Requirements
2
Manufacturing
64
Provide Engine Data for Performance Assessments
2
Powertrain Integration
65
Conduct Performance Synthesis and Analysis in Quick Study Phase
2
Performance Development
66
Identify Major Technical Challenges and Conduct Quick Studies - Chassis
2
Chassis
67
Identify Major Technical Challenges and Conduct Quick Studies - Cockpit
2
Cockpit
68
Identify Major Technical Challenges and Conduct Quick Studies - Passenger/Rear
2
Passenger
69
Identify Major Technical Challenges and Conduct Quick Studies - Underhood Compartment
2
Underhood
70
Identify Major Technical Challenges and Conduct Quick Studies - Powertrain
2
Powertrain Integration
71
Identify Major Technical Challenges and Conduct Quick Studies - Body
2
Body
72
Track Total Vehicle Issues
2
Vehicle Integration
73
Maintain Vehicle Mainstream Chart and Update Engineering Product Content Sheet
2
Vehicle Integration
74
Check Current Status of Vehicle Relative to Requirements
2
Systems Engineering
75
Develop Action Plans to Address Functional Performance Issues
2
Systems Engineering
76
Provide Die Investment Estimates
2
Die Manufacturing
77
Determine Die Sizes and Designs
2
Die Manufacturing
78
Prepare Die Development Schedules
2
Die Manufacturing
79
Conduct Financial Analyses for Alternative Subsystem Designs
2
Finance
80
Develop Subassembly Strategy
2
Manufacturing
81
Determine Assembly Tool and Parts Commonality Strategy
2
Manufacturing
82
Assess Body Concept Compatibility with Integrated Vehicle-Level Physical Interference Model
2
Body
83
Generate Surface Limits for Bodyside
2
Vehicle Concept Engineering
84
Develop Integrated Vehicle-level CAD Model
2
Vehicle Concept Engineering
85
Conduct Marketing Clinics
2
Marketing
86
Provide Customer's Perspective in Design Decisions
2
Marketing
87
Assess Risks and Balance Quality Targets
2
Quality
88
Run Updated Workload Model
2
Planning
140
89
Update Financial Assessment and Finalize Business Case
2
Finance
90
Update Offline Technology Development Plans
2
Planning
91
Review Phase 2
2
Program Management Team
92
Prepare Program Quality Target Matrix
3
Quality
93
Follow up and Maintain Open Issues -Chassis
3
Chassis
94
Follow up and Maintain Open Issues -Cockpit
3
Cockpit
95
Follow up and Maintain Open Issues - Passenger/Rear
3
Passenger
96
Follow up and Maintain Open Issues - Underhood Compartment
3
Underhood
97
Provide Supporting Information for Trade-offs
3
Systems Engineering
98
Finalize Body Bill of Material
3
Body
99
Refine Powertrain CAD model
3
Powertrain Integration
100
Design Integrated Assembly CAD Model for Chassis
3
Chassis
101
Design Integrated Assembly CAD Model for Cockpit
3
Cockpit
102
Design Integrated Assembly CAD Model for Passenger Compartment
3
Passenger
103
Design Integrated Assembly CAD Model for Underhood Compartment
3
Underhood
104
Update Mainstream Visual Surfaces
3
Design Studio
105
Allocate component-level Quality Targets and Assess Risks
3
Quality
106
Develop Body Concept Model
3
Body
107
Develop Manufacturing Plant Conveyor Strategy
3
Manufacturing
108
Assess Body Assembly Feasibility
3
Manufacturing
109
Create Manufacturing Requirements Agreements
3
Manufacturing
Develop Final Assembly Assessment
3
Manufacturing
ill
Create PhysicalNirtual Appearance Models
3
Design Studio
112
Assess Risks in Performance Requirements
3
Performance Development
113
Develop Preliminary Workplace Visualization Models
3
Manufacturing
114
Develop Manufacturing Program Timing Plan
3
Manufacturing
115
Provide Final Sales Volume Forecast
3
Marketing
116
Develop Final Integrated Assembly CAD Model for Entire Vehicle
3
Vehicle Concept Engineering
117
Develop Plan for Review Board
3
Planning
118
Review Phase 3
3
Program Management Team
119
Provide Transition to Vehicle Program After Concept Development
3
Vehicle Integration
120
Provide Transition to Program Quality Manager
3
Quality
110
Table C.2: DSM task key.
141
142
143