Anda di halaman 1dari 25

Product development process modeling

Robert P Smith and Jeffrey A Morrow, Industrial Engineering, University of Washington, Seattle, WA 98195, USA In recent years an increasing amount of attention has been paid to the construction of process models for the product development process. Understanding and modeling a process is an important rst step in the construction of managerially useful decision aids. Product development is a complex process, and it is likely that many process models will be useful for making managerial decisions. This paper provides a summary of such work, and points out the strengths and weaknesses of the various modeling approaches. It also proposes a new set of criteria for evaluating product development models, with particular attention to their industrial relevance. 1999 Elsevier Science Ltd. All rights reserved Keywords: design models, modeling, product development, engineering design, design management

1 Ulrich, K T and Eppinger, S D Product design and development McGrawHill, New York (1995) 2 Susman, G I Integrating design and manufacturing for competitive advantage Oxford University Press, New York (1992) 3 Simon, H A The sciences of the articial MIT Press, Cambridge (1981) 4 Bucciarelli, L L Designing engineers MIT Press, Cambridge (1994) 5 Finger, S and Dixon, J R A review of research in mechanical engineering design Research in Engineering Design Vol 1 (1989) pp 5167; 121137 6 Pahl, G and Beitz, W Engineering design: a systematic approach Springer Verlag, New York (1988) 7 Suh, N P The principles of design Oxford University Press, New York (1990) 8 Wareld, J N A science of generic design: managing com-

roduct development is a critical function of technology-based rms. The success of product development efforts can determine the longterm viability of companies and economies1,2.

Product development of large-scale systems is a complex process; complex because of the range of technical issues that must be addressed, and complex because of the variety of people and organizational structures that must be employed over the life of a product development effort3,4. Product development involves many organizational units and engineering disciplines. Research on product development includes work from diverse areas of the engineering and management research communities. Engineering researchers have typically focused on formal structures involved in engineering design decisions59, while management research has concentrated on the myriad organizational issues involved in product development10. Both research traditions have value to the product development researcher. Product development is the process of converting needs into a technical and commercial solution11. Each product development process is unique,
0142-694X/99 $ - see front matter Design Studies 20 (1999) 237261 PII: S0142-694X(98)00018-0 1999 Elsevier Science Ltd All rights reserved Printed in Great Britain

237

DST: design studies (page 1

08-03-99 08:58:18

Rev 14.02x

zdst$$141h

but the processes share common features or elements. If we can understand what those processes have in common we may be able to guide the management of future product development processes. Like other processes, it is possible and useful to build quantiable models of the product development process. The goals of process modeling are several; they include learning about the process, and suggesting ways that a process can be controlled. There are a number of process models of product development, and there is a signicant amount of recent research activity in developing or improving process models. It is the aim of this paper to chronicle the published models, and to guide future model development. The existence of a number of divergent product development process models should not be surprisingproduct development is complex. In lieu of trying to unify the product development modeling literature we should explore the various advantages of each modeling approach. As researchers we should be attempting to improve decision making and building models that allow this; as practitioners we should determine which, if any, of the existing models serve our needs. There are important interactions between a models theoretical power and its practical value; neither can be neglected12. This paper is structured as follows. Section 1 suggests a set of criteria by which product development process models can be judged. Section 2 describes the existing models of product development and measures them against the criteria established in section 1. Section 3 gives an overall view of the state of product development process modeling. Section 4 serves as a summary.

plexity through systems design Iowa State University Press, Ames (1994) 9 Braha, D and Maimon, O The design process: properties, paradigms, and structure IEEE Transactions on Systems Man and Cybernetics, Part A: Systems and Humans Vol 27 No 2 (1997) pp 146166 10 Brown, S L and Eisenhardt, K M Product development: past research, present ndings, and future directions Academy of Management Review Vol 20 No 2 (1995) pp 343378 11 Whitney, D E Designing the design process Research in Engineering Design Vol 2 (1990) pp 313 12 Brady, T, Rush, H, Hobday, M, Davies, A, Probert, D and Banerjee, S Tools for technology management: an academic perspective Technovation Vol 17 No 8 (1997) pp 417426

Modeling criteria

There are a number of criteria by which the merit of proposed models of the product development process should be judged. This section will present those criteria, and show how they apply to the eld of product development process modeling. We take the ultimate goal of management science modeling of the product development process to be the creation of one or more predictive models that improve managerial decision making. If a model is to have useful predictive value, it must meet several criteria: it addresses an important managerial issue; the decision making is based on information that is available and accurate; the assumptions and simplications of the model are reasonable; and the model is computationally tractable. Each of these issues is discussed below.

238

Design Studies Vol 20 No 3 May 1999

DST: design studies (page 2

08-03-99 08:58:18

Rev 14.02x

zdst$$141h

The rst issue is whether the model addresses an important managerial issue. This is an inherently subjective judgment. The importance of product development would suggest that almost any realistic managerial decision involved in design management would be able to fulll this criterion. These decisions might involve task scheduling, resource allocation, product release, target specication, or many other managerial tasks related to product development. The second issue is whether the model relies on information that is readily available in a timely manner to support decision making. This is a somewhat difcult hurdle for many of the modeling methodologies, as the nature of mathematical modeling requires the use of precise data, while product development occurs in an environment of uncertainty and ambiguity. Nevertheless, there are a number of predictive data that are available early in the product development process, and these are the data that should be used in the construction of useful predictive models. Identifying which data these are is a thorny problem. The third issue involves the assumptions and simplications necessary for model construction and analysis. Modeling is a process of abstraction from the real world. Tractable mathematical functions can be constructed from a limited set of relationships (multiplication, exponentiation, Markov processes, and so forth). It is typically necessary to assume that reality ts one or more of these functional forms. Whether or not reality is well described by this abstracted form is another important subjective judgment that contributes strongly to the perceived merit of the modeling approach. The nal issue is computational tractability of the model. Often this is not a particularly important issue, as, due to the second issue discussed above, the size of reliable data sets is often not that large, and the power of even desktop computing enables the use and applicability of what were in previous decades considered relatively complex models. Once we have established the criteria by which models can be judged, we need to establish a world in which they can be judged. The rst level of validity is face validity. Face validity implies that the modeling topic, data, assumptions, and tractability seem reasonable to those who are familiar to the eld of product development management. All the models presented in this paper have this level of validity. The second level of validity is the application of the modeling framework to existing, but retrospective data sets gathered from industry. The best of the models described in the next section typically are able to demonstrate

Product development process modeling

239

DST: design studies (page 3

08-03-99 08:58:19

Rev 14.02x

zdst$$141h

their worth by application to these types of realistic data sets. (Note that the models are generally not being used to actually guide decision making, but rather to show that they could have guided decision making.) The third level of validity is the use of the model to guide decision making in an experimental environment. This type of environment is well-controlled and repeatable, so it is possible to demonstrate the effects of improving decision making. This type of demonstration is, however, difcult, as the types of problem likely to be encountered in experimental settings are often much simpler than those encountered in industrial environments. No model presented here attempts this level of validity, but it may prove an important avenue in the further development of product development process modeling. The fourth level of validity is the use of the model to guide decision making in the real world. This is a difcult case to make, as often there is no objective comparison between the changed and the unchanged situation, and the real data are confounded with many other effects that may affect the success of the decisions made by the model. None of the models in this paper attempts this level of validity, but it is included in this list as, arguably, the ultimate goal of this type of modeling approach. It has been argued that the process by which the experienced management scientist arrives at a model of the phenomenon he is studying is probably best described as intuitive13. If modeling is intuitive and artful, what advice do masters have for tyro modelers? Morris suggests that it is useful to approach modeling as a process of enrichment or elaboration. One starts from some analogy or association with well developed logical structures, and then engages in two sorts of looping or alternation procedures. The rst sort of alternation occurs between modication of a model and confrontation by data, with each test yielding new modication insight and each modication a new test. The second is alternation between exploration of the deductive tractability of the model and the assumptions that characterize it. Thus, if a model is tractable in the sense of permitting the attainment of the deductive goals, the analyst may seek further relaxation or complication of the assumptions. If the model is not tractable or cannot be solved, the analyst returns to strengthen or simplify the assumptions13. But complexity and extent are not ends in themselves for modelers. We seek deductive insight and leverage. For this the simpler a model is, subject to reproducing the behavior we observe in the world to a necessary level of precision, the better it is. For engineers perhaps Newtonian mechanics is the most universal world model and Newtonian mechanics is crystalline

13 Morris, W T On the art of modeling Management Science Vol 13 No 12 (1967) pp B707 B717

240

Design Studies Vol 20 No 3 May 1999

DST: design studies (page 4

08-03-99 08:58:19

Rev 14.02x

zdst$$141h

in simplicity, power, and generality. When we seek to nd the physics of some aspect of the world, we dream of nding models that give that kind of deductive leverage. If we seek application by others of models we produce, then we must prepare to meet their predictable resistance to taking action on the basis of models they have not personally generated14. We note tension between type 1 error, believing a models results when the model is wrong, and type 2 error, not believing that what a model indicates is correct when in fact it is. We believe that many academic modelers have attended more to avoiding type 1 error by focusing on model validity (typically associated with greater model complexity and hence opacity). This has caused a corresponding rise of type 2 error because academics fail to convince practitioners of their models realism; in a word their models lack credibility. We might associate greater credibility with an Occams Razor sort of simplicity and advocate that academics shift the balance of attention toward credibility to improve application likelihood. Others, in acknowledging this problem, believe that the solution lies in helping practitioners learn tools for rigorous development of their own models15. In an attempt to judge the utility of process modeling for manufacturing organizations, it has been observed that modeling has some, but limited, value16. The limitations arise from the modelers need to reduce the complex situation to a more structured form in order to have it t in the modeling framework, the lack of quantitative modeling approach, the obviousness of ndings that arise from a model, the difculty of capturing process steps that are often intuitive, and the lack of the ability of the model to be updated as the organizational situation changes. The Busby and Williams work was based on application of IDEF017; we will see in section 2 that there is a number of modeling structures that exist today that allow for greater quantitative information to be included in model construction. But with this exception the other criticisms are potentially valid for the modeling approaches that exist (obviousness of ndings, difculty of capturing intuitive steps in the process, difculty in updating the model continuously). Furthermore, none of the modeling research efforts undertaken (as described in section 2) has documented a rigorous application of the modeling approach to an organization in order to document its utility. This is a goal of demonstrative power to which the community of product development modeling researchers should aspire. Another aspect of the role of modeling in product development considers how engineering designers form models of the design artifact and its performance18. Their view, rather than sharing our focus of modeling the

14 De Geus, A P Modelling to predict or to learn? European Journal of Operational Research Vol 59 (1992) pp 15 15 Lane, D C Modelling as learning: a consultancy methodology for enhancing learning in management teams European Journal of Operational Research Vol 59 (1992) pp 6484 16 Busby, J S and Williams, G M The value and limitations of using process models to describe the manufacturing organization International Journal of Production Research Vol 31 No 9 (1993) pp 21792194 17 Ross, D T Structured analysis (SA): a language for communicating ideas IEEE Transactions on Software Engineering Vol SE-3 No 1 (1977) pp 1634 18 Subrahmanian, E, Konda, S L, Levy, S N, Reich, Y, Westerberg, A W and Monarch, I Equations arent enough: informal modeling in design Articial Intelligence for Engineering Design, Analysis and Manufacturing Vol 7 No 4 (1993) pp 257274

Product development process modeling

241

DST: design studies (page 5

08-03-99 08:58:19

Rev 14.02x

zdst$$141h

design process, considers the way that models of technical performance are used by designers. That type of model has its own measures of validity and utility that differ from those of process models. It is noted that informal models are used quite often in the design process, and design methodology researchers need to be aware of informality of design representations as they go about aiding the designer. In a comparison of modeling approaches used by engineering and architectural design researchers, it has been noted that engineering models of the design process are more structured and linear, while architectural models of the design process are more based on cognition and preconceptions19. This difference is probably due to the fact that engineering problems are generally more well-structured while architectural problems are generally ill-structured. This paper is focused on engineering design, so the models that we will see will tend to be highly structured, which leads to the ability to use mathematical techniques of varying stripes. This focus on underlying structure furthermore implies that the models consider the most structured parts of the engineering design process. The models are therefore biased toward the system level and detail design portions of the design process, and concentrate less on the conceptual, creative or otherwise unstructured aspects. Product development process models can be seen as a type of project management model. Project management models have use not only for controlling and evaluating projects, but also for developing common goals and understanding of tasks among the members of the project team20. We should therefore consider not only the direct benets of models (which are often difcult to determine) but also the indirect benets of model building. The utility of formal project management models was established in a survey of research and development project managers21. That survey suggested that managers were typically unwilling to use complex mathematical models, both because of the difculty in determining input data and because of the opacity of the algorithm employed. Recognizing that modeling and decision support software have improved signicantly since the survey was conducted, we still must consider those two criteria in determining the effectiveness of new modeling techniques.

19 Cross, N and Roozenburg, N Modelling the design process in engineering and architecture Journal of Engineering Design Vol 3 No 4 (1992) pp 325337 20 Graham, R J The role of network techniques in team building for project management. In Dean, B V (ed) Project management: methods and studies Elsevier, Amsterdam pp 163 171 (1985) 21 Liberatore, M J and Titus, G J The practice of management science in R and D project management Management Science Vol 29 No 8 (1983) pp 962974

A review of models

This section describes the recent models that have been presented in the literature. We will rst briey present some older models of product development, and then go into some details on a number of recent modeling efforts.

242

Design Studies Vol 20 No 3 May 1999

DST: design studies (page 6

08-03-99 08:58:19

Rev 14.02x

zdst$$141h

All of the models are based on the observation that design is composed of a number of tasks that have an underlying structure. This observation can be traced to some of the earliest and most inuential models of design decision making22,23. The structure that is posited within each model varies signicantly, but all of these models are based on the belief that a structure exists. Jones24 does an excellent job of reviewing the design models and methods that arose during the 1960s and previously. Those methods will not be further reviewed here. There are 35 methods reviewed in his treatise, particularly notable among those in relevance to this paper are the methods of Alexander23, Luckman25, Starr26, and Archer27. The ideas in those models have been incorporated into many of the more recent models that are described below.
22 Marples, D L The decisions of engineering design IRE Transactions on Engineering Management Vol EM-8 No 2 (1961) pp 5571 23 Alexander, C Notes on the synthesis of form Harvard University Press, Cambridge (1964) 24 Jones, J C Design methods: seeds of human futures Wiley Interscience, New York (1970) 25 Luckman, J An approach to the management of design Operational Research Quarterly Vol 18 No 4 (1967) pp 345358 26 Starr, M K Product design and decision theory Prentice Hall, New York (1963) 27 Archer, L B Systematic method for designers Council of Industrial Design, London (1965) 28 Evbuomwan, N F O, Sivaloganathan, S and Jebb, A A survey of design philosophies, models, methods and systems Proceedings of the Institution of Mechanical Engineers Vol 210 (1996) pp 301320 29 Platt, D G Building process models for design management Journal of Computing in Civil Engineering Vol 10 No 3 (1996) pp 194203 30 Ritchie, E Planning and control of R and D activities Operational Research Quarterly Vol 23 No 4 (1972) pp 477490 31 Dougherty, D M, Stephens, D B and Ezell, D E The lasting qualities of PERT: preferences and perceptions of R and D project managers R and D Management Vol 14 No 1 (1984) pp 4756

There is also a distinct stream of modeling research on engineering design methodology28,29. That work focuses on descriptive methodological and philosophical frameworks of the engineering design process. The focus in our paper is on quantitative, graphical, or otherwise formalizable predictive models, which constitute a distinct but related class of models. For many of the models presented below time is one of the dependent variables of interest. It is not surprising that this is so: product development lead time is one of the critical factors for success, many process choices affect lead time, and time is inherently quantiable. The progenitor of timebased project modeling is the PERT/CPM method, and this serves as a useful point of comparison for time-based product development modeling efforts. PERT-type models have been applied to engineering design, with varied success30,31. It is recognized that PERT has several limitations: the lack of the feedback and iteration that is common to the design process, and the difculty for managers to collect the data and understand the outputs of these types of model, particularly in their most complicated forms. Furthermore, it is also not clear that the primary behaviors that PERT is able to capture (stochastic activity duration, sequential activity relationships) are the behaviors that are most critical to engineering design management. For these reasons many process modelers seem to be leaving the PERT framework to establish models that better address other behaviors while trying to keep the models as simple as feasible. We have grouped the models into ve categories, depending on what each model attempts to accomplish. The ve categories are sequencing and scheduling models, decomposition models, stochastic lead time models, design review timing models, and parallelism models.

Product development process modeling

243

DST: design studies (page 7

08-03-99 08:58:19

Rev 14.02x

zdst$$141h

32 Steward, D V The design structure system: a method for managing the design of complex systems IEEE Transactions on Engineering Management Vol EM-28 No 3 (1981) pp 7174 33 Eppinger, S D, Whitney, D E, Smith, R P and Gebala, D A A model-based method for organizing tasks in product Research in development Engineering Design Vol 6 No 1 (1994) pp 113 34 Kusiak, A and Wang, J Efcient organizing of design activities International Journal of Production Research Vol 31 No 4 (1993) pp 753769 35 Eppinger, S D Modelbased approaches to managing concurrent engineering Journal of Engineering Design Vol 2 No 4 (1991) pp 283290 36 Rogers, J L Knowledgebased tool for decomposing complex design problems Journal of Computing in Civil Engineering Vol 4 No 4 (1990) pp 298312 37 Lewis, W P and Cangshan, L The timely allocation of resources in the concurrent design of new products Journal of Engineering Design Vol 8 No 1 (1997) pp 317

2.1

Sequencing and scheduling design tasks

A number of models have considered the problem of scheduling and sequencing design tasks. Product development is distinct from many project-like activities in that iteration and rework are commonplace. The presence of iteration leads to difculty in nding appropriate orderings.

2.1.1

Design structure matrix

One of the most important family of models is that based on the design structure matrix (DSM)3236 (see Figure 1). The DSM method assumes that each design task can be modeled as an information processing task, using and creating information. The output information from one task becomes the input information to another task. The input/output relationships may (in all likelihood) include cycles, which indicate the need for iteration. The DSM formulation is a matrix representation that includes these relationships. Tasks in the matrix may be resequenced, which helps identify cyclical and acyclical tasks. The researchers who have considered this modeling family observe that it is a feasible proposition to construct this type of matrix, even for relatively complex design processes with more than 100 tasks33. One limitation of the DSM is that it is relatively difcult for the uninitiated to understand37.

Figure 1 Design matrix33

structure

244

Design Studies Vol 20 No 3 May 1999

DST: design studies (page 8

08-03-99 08:58:19

Rev 14.02x

zdst$$141h

The basic assumptions of this model, that design tasks are predictable information processing tasks with identiable inputs and outputs is reasonable (except in the case of truly novel technologies). Finding groups of tasks that require cyclical ows of information (coupled tasks) is relatively easy once the matrix data exist. For these reasons the model seems to have signicant potential utility. The DSM method as originally proposed offers little advice about how to handle and schedule design tasks within the iterative groups. Newer variations have been proposed to address this shortcoming. The models that have been located within this subsection are those extensions to the DSM framework that consider sequencing and scheduling when only one task is occurring at a time. There are also sequencing and scheduling models that assume that parallelism may occur. Those models have been placed in section 2.5.

2.1.2

Feedbacks and crossovers

Two sequencing models based on the DSM are based on reducing the number of information feedbacks, information crossovers and length of iterative cycles38,39. These numbers are meaningful for sequential schedules of tasks. Feedbacks indicate a need for repetition, information crossovers indicate an opportunity for a loss of coordination information, and length of feedback cycles indicates a large amount of required rework. These are discrete optimization problems, and it is shown that genetic algorithms are useful at nding near-optimal solutions for large instances. These studies do not provide empirical justication of the utility of feedback, crossover and cycle length measures as critical measures of scheduling goodness, nor do they present empirical data that shows the utility of their method. These are potentially critical shortcomings in this modeling approach. Nevertheless, the optimization method is powerful, and could potentially be applied to other goodness functions.

38 McCulley, C and Bloebaum, C L A genetic tool for optimal design sequencing in complex engineering systems Structural Optimization Vol 12 No 23 (1996) pp 186201 39 Altus, S S, Kroo, I M and Gage, P J A genetic algorithm for scheduling and decomposition of multidisciplinary design problems Journal of Mechanical Design Vol 118 No 4 (1996) pp 486489 40 Smith, R P and Eppinger, S D A predictive model of sequential iteration in engineering design Management Science Vol 43 No 8 (1997) pp 11041120

2.1.3

Sequential iteration model

Another sequencing and scheduling model that is built on the framework of the DSM is the sequential iteration model40. In this model tasks are completed one at a time, with a probabilistic need for repetition of prior tasks (see Figure 2). Each task has a xed, deterministic duration. The expected duration of any given ordering of tasks can be calculated by nding the expected reward of a reward Markov chain. The ordering of the tasks can be manipulated to minimize the expected time. This is a combinatorial optimization problem and several heuristics exist for nding near-optimal orderings.

Product development process modeling

245

DST: design studies (page 9

08-03-99 08:58:19

Rev 14.02x

zdst$$141h

Figure 2 Reward ation model40

Markov

chain for sequential iter-

There are some useful outputs of this model, such as that it is valuable to complete shorter tasks before longer tasks and that it is desirable to lessen the number of large repeat probabilities that appear as feedbacks in the optimal ordering. The difculty with this model is in its assumptions. In order to keep nding the expected duration of a given ordering tractable, the model assumes that tasks have xed and constant durations, no matter how many times they are repeated. Also, repetition probabilities are assumed to be known, xed and constant, independent of the ordering of the tasks and of the number of times that any task has been completed. Some of the limitations of the sequential iteration model have been removed in an extension41. The extension allows for random duration of tasks as well as allows multiple tasks to be attempted simultaneously. The limitation of the extension is a corresponding decrease in the tractability of the model. While the original sequential iteration model could analyze processes with dozens or scores of tasks, the more recent version is restricted to no more than about 10 if exact solutions are to be obtained. Larger problems are approximately tractable using simulation, but the solutions are not as reliable.

2.1.4

Iterative cycle time estimation

41 Eppinger, S D, Nukala, M V and Whitney, D E Generalized models of design iteration using signal ow graphs Research in Engineering Design Vol 9 No 2 (1997) pp 112123 42 Belhe, U and Kusiak, A Modeling relationships among design activities Journal of Mechanical Design Vol 118 No 4 (1996) pp 454460

A further extension to the DSM framework is a model that includes probabilistic OR and XOR (exclusive OR) relationships between tasks42. For this model the probabilities of executing one or more of the OR/XOR paths are dependent on the iteration number, and these probabilities are xed in advance. The presented version of the model has the length of each task be xed and deterministic, and the length of each task does not change as the iteration process progresses. The model enables calculating the probability distribution of the total time required to complete the design process. Knowing this distribution is useful for monitoring progress, predicting due dates, and allocating task resources.

246

Design Studies Vol 20 No 3 May 1999

DST: design studies (page 10 )

08-03-99 08:58:19

Rev 14.02x

zdst$$141h

The difculties with this model are the assumptions and the availability of data. We must assume that task times and iteration probabilities are xed and known in advance, as is the task iteration structure. This requires signicant knowledge about the structure of the design process. Furthermore, there is no example presented based on empirical data. All of these sequencing and scheduling models attempt to address a signicant managerial problem that has important effects on design processes. They also, however, require strong assumptions in order to retain analytical tractability. The models in this section are interesting, but their utility for industrial practice remains to be demonstrated.

2.2

Decomposing large systems

One essential task within product development management is how large design projects should be split into smaller elements43,44. This decision is difcult, important, and amenable to formal analysis, and has therefore been the target of several models. Decomposition of large systems is useful either to allocate the work among multiple designers or design teams, or also to suggest a decomposition of the technical artifact that will minimize overlapping between subsystems. Decompositions therefore have the ability to speed the design process as well as create higher performance design outcomes. Formal decomposition methods trace their roots to Alexander23. Alexanders model uses interactions between design elements (described in matrix or graphical form) to determine appropriate subgroups of design elements. Designers are polled about where they believe the strongest interactions exist between pairs of tasks, and the method is able to use these interactions between design elements to suggest appropriate decouplings of the elements. A later paper45 applies the method to a building design problem, and compares the decompositions offered by the algorithm with those suggested by building designers. It is demonstrated that the method seems to do no worse in decomposing the problem than do the designers. This approach has been extended in several more recent modeling approaches.

43 Bird, S D and Kasper, G M Problem formalization techniques for collaborative systems IEEE Transactions on Systems, Man, and Cybernetics Vol 25 No 2 (1995) pp 231242 44 Rechtin, E and Maier, M W The art of systems architecting CRC Press, Boca Raton (1997) 45 Lewis, W P, Samuel, A E and Field, B W An example of the application of a systematic method to design Operational Research Quarterly Vol 24 No 2 (1973) pp 217233 46 Smith, R P and Eppinger, S D Identifying controlling features of engineering design iteration Management Science Vol 43 No 3 (1997) pp 276293

2.2.1

Work transformation matrix method

One method developed to accomplish decomposition is the work transformation matrix (WTM) method46. The WTM method is an extension to the DSM method presented earlier. In this model the off-diagonal DSM entries are replaced with rework factors, and the time for each task is estimated (see Figure 3). The rework factors indicate how much rework needs to be completed as a function of work completed in the previous iteration. The model assumes that the design process is iterative, and

Product development process modeling

247

DST: design studies (page 11 )

08-03-99 08:58:19

Rev 14.02x

zdst$$141h

Figure 3 Work ation Matrix46

transform-

iterative rework is created linearly, so that rework is a linear function of work in the immediately previous iteration. The total work completed during the process can be calculated by looking at the sum of the work done during every iteration. The output of this model is the total work completed. One illuminating observation is that the total work completed is a strong function of the eigenvalues and the eigenvectors of the matrix containing the rework quantities. By analogy to dynamic physical systems, the dynamic behavior of the process is strongly indicated by the eigenvectors associated with the largest eigenvalues of the matrix. The eigenvectors can therefore be used for decomposition of the problem into relatively unconnected groups of tasks. The original paper concerning the WTM model presents an application of the method to brake system design at General Motors. They present evidence that it is relatively straightforward to collect data from real engineering projects, and observe that the eigenvectors of the created WTM correspond well with known tightly coupled technical issues. They suggest that the method would be applicable in situations where the tightly coupled technical issues are not known in advance. The shortcomings in this model arise from the restrictive nature of the assumptions. It is difcult to justify the strict appropriateness of these assumptions (linear creation of rework, static measures of rework process), but the ability of the model to be applied to a real situation is encouraging.

47 Kusiak, A and Park, K Concurrent engineering: decomposition and scheduling of design activities International Journal of Production Research Vol 28 No 10 (1990) pp 1883 1900 48 Kusiak, A and Wang, J Decomposition of the design process Journal of Mechanical Design Vol 115 (1993) pp 687 695 49 Michelena, N F and Papalambros, P Y A hypergraph framework for optimal modelbased decomposition of design problems Computational Optimization and Applications Vol 8 No 2 (1997) pp 173196

2.2.2

Activity module decomposition model

Another model that describes the decomposition problem is based on the similarities between design process decomposition and cellular manufacturing systems4749 (see Figure 4). In this model the design activities are assumed to be similar to manufacturing jobs to be processed, and design

248

Design Studies Vol 20 No 3 May 1999

DST: design studies (page 12 )

08-03-99 08:58:19

Rev 14.02x

zdst$$141h

Figure 4 Activity module decomposition matrix47

resources (such as engineers) are assumed to be similar to manufacturing processing equipment. It is desirable to decompose the system into modules such that each module (manufacturing cell or design resource) is substantially decomposed from other modules. If we accept the analogy, then there are a number of results from cellular manufacturing that follow directly. For example, the cellular manufacturing optimization problem is known to be NP-hard, and there are a number of heuristics that provide useful decompositions. As we consider the applicability of this model, we must determine whether activities require sets of resources in the same way that manufacturing jobs require sets of machines, and whether the assignment of groups of design activities to engineering resources is analogous to the creation of manufacturing work cells. Because of the exibility of human resources, it is likely that the engineering design situation is likely to be more uid and less xed than the manufacturing equivalent, although the analogy does have some intellectual appeal. The model is applied to a problem involving the design of a helical compression spring48. It is shown that for an instance where the functional form of the governing design equations are available it is possible to identify decompositions that separate substantial sub-blocks of the underlying design problem. Whether these equations are available in many design situations and whether those situations are likely to exhibit the cellular structure are open questions.

Product development process modeling

249

DST: design studies (page 13 )

08-03-99 08:58:19

Rev 14.02x

zdst$$141h

2.2.3

Other decomposition models

Another decomposition model provides a novel interpretation of the DSM method described earlier50. This model incorporates both the DSM information concerning task precedence and cycles as well as activity resource incidence matrices. These two sets of matrix information are combined to offer suggestions about how a design organization should be decomposed, and which interactions between tasks and people are desirable. Unfortunately, the model is not highly formalized, and the recommendations of the model are not based on rigorous analysis. There is the kernel of a useful idea, that one needs to be aware of both interactions between tasks and between people when forming decompositions and assigning tasks, but the model does not attempt to do this in a formal way. A second extension to the DSM method attempts to divide design tasks into organizational units51. This method extends the DSM structure to include spatial, energy, information and material interactions between design elements. These interactions are used to identify clusters of design elements that should be addressed by organizational units. This model contains a considerable amount of structuring of design element interactions, but the clustering step remains informal.

Determining the effects of stochastic delays on product development lead time


Two effects that are potentially important to product development that are not captured in PERT/CPM models of product development are the need for iteration as well as the potential delays in product development because of queueing delays. The models in this subsection recognize that product development projects do not occur in isolation, but instead there are several simultaneous projects that are competing for the same limited resources. The limited availability of resources (typically design engineers) causes delay in the overall project that can adversely affect overall project lead time. The two models below address these issues.
50 Bolton, B Polyhedral dynamics applied to design and project management IEE Proceedings, Part A Vol 135 No 4 (1988) pp 241244 51 Pimmler, T U and Eppinger, S D Integration analysis of product decompositions ASME Design Theory and Methodology Conference ASME, Minneapolis (1994) 52 Taylor, B W and Moore, L J R and D project planning with Q-GERT network modeling and simulation Management Science Vol 26 No 1 (1980) pp 4459

2.3

2.3.1

Q-GERT model

The rst model is the Q-GERT model52. GERT is an extension to PERT that allows feedback and a more general analysis. Q-GERT is an extension to GERT that allows for queueing delays. Taylor and Moore have applied Q-GERT to product development. The model includes such features as probabilistic routing of tasks to servers, including probabilistic iteration; branching and joining of tasks; and multiple simultaneous projects within multiple development groups. There

250

Design Studies Vol 20 No 3 May 1999

DST: design studies (page 14 )

08-03-99 08:58:19

Rev 14.02x

zdst$$141h

are a known set of development projects with well-characterized probabilistic descriptions of task durations and outcomes. The Q-GERT methodology relies on simulation analysis to make observations about the expected throughput time and variance. Taylor and Moore apply the Q-GERT methodology to a set of development projects within an unnamed textile company. In practice it is difcult to imagine that the upcoming projects will be sufciently well understood that a probabilistic characterization will be accurate. Also, the reliance on simulation as the mode of analysis means that it is difcult to determine the functional relationship between variables. Every instance of the network requires a new simulation coding, which can become prohibitive for complex situations. They have identied an interesting problem, but their analytical method is limited in its ability to make useful insights.

2.3.2

Queueing network model

A more recent modeling effort has also focused on examining the effects of queueing delays on product development lead time53. This model applies more recent analytical results from queueing networks regarding Brownian approximations and fork-join networks to the problem of product development viewed as a queueing network. The outcomes of the model indicate the total capacity available for any given network structure, as well a cycle time of a given throughput rate and resource combination. In order for a queueing network model to be valid there are a number of assumptions that need to hold. First, there must be a sufcient number of similar projects such that a probabilistic description of them makes sense and data are available. Second, the network has to be assumed to be operating for a sufcient period of time that the steady-state probability description applies. Third, it must be assumed that there is no meta-level control of the network (such as engineers working overtime because they know that they have a large backlog of work). Each of these assumptions is troubling. In combination they may lead to signicant difculty in application of the model. The authors of this study state We found that the construction of the model itself, rather than being a burden, was probably the most directly useful part of our research53 (p 482). This is both good and bad news. There is utility in doing this type of modeling, but it really doesnt matter what type of modeling is done, as long as the participants and the modelers take sufcient effort to discuss the important issues.

Adler, P S, Mandelbaum, A, Nguyen, V and Schwerer, E From project to process management: an empirically-based framework for analyzing product development time Management Science Vol 41 No 3 (1996) pp 458484

53

Product development process modeling

251

DST: design studies (page 15 )

08-03-99 08:58:19

Rev 14.02x

zdst$$141h

2.4 Determining the timing of design reviews/product release


Another class of models concerns the timing of activities that are related to the design process, but are not design tasks themselves. These activities include design reviews and product release.

2.4.1

Timing of design reviews

The rst model in this vein is based on the concept of determining the timing of design reviews54. Design reviews are important milestones in the design process when participants exchange their partially completed ideas about the nal form of the artifact. Design reviews are valuable because they provide opportunities to exchange and critique ideas, but are potentially nonproductive because of the preparation time and other overhead. In their model Ha and Porteus assume that there are two types of design activities: product design activities and process design activities. Any given design activity may create a aw that will only be discovered at the time of the next design review. Flaws are corrected by some amount of rework. Also, each design review releases an amount of work from product design to process design. It is desirable to have design reviews close together so that aws are discovered rapidly and so that process designers are not starved of work. It is desirable to space design reviews apart so that the overhead of conducting the reviews is not increased. The model is stated such that an optimal balance can be found between these conicting interests. This model traces its antecedents to comparable ideas in the world of manufacturing quality control and inspection. The model is tractable for simple situations such as having stationary strategies and only two types of design task. Extensions are possible that reduce tractability. The observations about the inuences on design review frequency are insightful, but it is difcult to imagine a situation where the outcome of the model would be applied directly. The data are difcult to estimate for any specic instance, and some of the assumptions (for example, product reviews are the sole mechanism by which information is passed from one group to another, and are also the sole mechanism by which design errors are discovered) are not reective of design reality.

54 Ha, A Y and Porteus, E L Optimal timing of reviews in concurrent design for manufacturability Management Science Vol 41 No 9 (1995) pp 14311447 55 Koushik, M V and Mookerjee, V S Modeling coordination in software construction: an analytical approach Information Systems Research Vol 6 No 3 (1995) pp 220254

2.4.2

Module scheduling

A philosophically similar model arises in the consideration of software development55. This model considers the effects of coordination of modules in software development.

252

Design Studies Vol 20 No 3 May 1999

DST: design studies (page 16 )

08-03-99 08:58:19

Rev 14.02x

zdst$$141h

The number of developers needs to be chosen by the decision maker. Each developer works on a module of the software project. There is a xed total number of modules, and a coordination event occurs after some number of modules are completed, which is another decision variable. During and after a coordination event the participants communicate their results, the completed modules are integrated, rework occurs on incompatibilities, and further development work occurs on uncompleted modules. The total development time is xed in advance. In this model there is a number of phenomena explored. Analysis of the model is presented based on numerical results for examples concerning many identical modules. In addition they present simulation results for systems containing non-identical modules. The results concern phenomena such as the optimal team size as a function of time available and the optimal number of modules that should be completed before a coordination event as a function of the total number of modules. Again the observations of this type of model seem appropriate, but the difculty in obtaining specic data for any given project will limit the models direct applicability. The originators claim the results [of this model] should not be interpreted in a strict numeric senseIt is reasonable to use these results to predict the impact of changing a particular system parameter on the direction of an outcome variable55 (p 243).

2.4.3

Product release

A further model that addresses the scheduling of important milestones in the product development cycle is a model that examines the relationship between product performance, product release, and development56. This model examines the functional relationship between performance and prot as a function of product release timing. The model reasonably assumes that product performance is an increasing function of development time. The market performance of a product is a function of the product performance as well as what other competing products are already on the market at the time of product introduction. Product managers therefore have to determine when to release products such that their performance is high enough to satisfy customer expectations but the development cycle is quick enough that competitors do not ll the void rst.
56 Cohen, M A, Eliashberg, J and Ho, T-H New product development: the performance and time-to-market tradeoff Management Science Vol 42 No 2 (1996) pp 173186

The model is able to indicate optimal time-to-market and product performance goals, as well as showing other relationships, such as that strictly minimizing time-to-market does not lead to the long-term optimal product development strategy.

Product development process modeling

253

DST: design studies (page 17 )

08-03-99 08:58:19

Rev 14.02x

zdst$$141h

The model assumes that product performance has a CobbDouglas form of increase, similar to common assumptions in economics for production functions. The authors have validated this assumption based on existing data from consumer-oriented rms in two industries. The consumer demand model uses the logit model for its functional form, which is a common assumption in the marketing literature and has also received empirical support. The model has strong justication for its functional relationships, which increases the credibility of its results. It does, however, suffer from a common fault in product development process modeling in that the model relies on data that are not estimable in practice, and so the results of the model cannot be applied directly to enable a project manager to make product development decisions.

2.4.4

Stage targeting

A related model concerns how rms allocate development resources in sequential stages57. This model assumes that there is a limited set of resources (engineering professionals) who are useful to the development project. A set of rms must compete to employ these resources. Product development is a two stage process (research and development), and the rms decide how to allocate resources between these stages sequentially. Firms also decide how to set technical targets of each stage (increase the technical goals, possibly delaying product introduction, or lower the technical goals to increase the chances that you will be early to market). The results of the model indicate that there is advantage given to rms that are currently ahead of their competitors, and that these rms will try to increase the likelihood that they arrive rst to market. Laggard rms, by contrast, will raise their technical sights, hoping to be able to produce a better product, albeit one that does not reach the market early. The model developers illustrate how the effects described by the model have useful explicative power for competitive actions within the mainframe computer industry in the late 1980s. Although it is not possible to specically identify parameter values and functional forms, the effects and the directions of these major effects in the model are borne out in the empirical data.
57 Khanna, T and Iansiti, M Firm asymmetries and sequential R and D: theory and evidence from the mainframe computer industry Management Science Vol 43 No 4 (1997) pp 405421

This is the only model included in this survey that includes game-theoretic concepts. The bulk of product development process modelers do not include multiple rms to show how the decisions of one rm may affect the choices of another rm. Game-theoretic modeling is a potentially

254

Design Studies Vol 20 No 3 May 1999

DST: design studies (page 18 )

08-03-99 08:58:19

Rev 14.02x

zdst$$141h

fruitful area for product development, since many product development decisions are strongly inuenced by competitive actions.

2.5

Determining the amount of parallelism

One design management problem that has been attracting attention is the amount of parallelism that is appropriate during the design process. Recent wisdom indicates that parallelism or concurrency has signicant advantages over a purely sequential process58. The models described below indicate that there are valid reasons for maintaining some amount of sequential scheduling in the design process as a method to reduce costs and reduce the size and complexity of the organization required to support design activity.

2.5.1

Parallel scheduling

The rst model in this vein is one that examines the effects of parallel scheduling59. In this model there is a number of design tasks that need to be completed, and there is an explicit underlying order of the design tasks. There is also uncertainty surrounding design tasks, such that if one of the design tasks fails to be completed successfully it will have to be repeated, along with tasks that would naturally follow the failed task. The basic assumptions of this model are based on general beliefs about how design processes occur, rather than any specic observations. The advantage of doing tasks in parallel is that the design process can be completed more quickly. The advantage of doing tasks in series is that the number of tasks that will require repetition is lessened, and therefore the development cost is lessened. The goal of the model is to determine how much parallelism is desirable, and whether minimizing development time justies an increase in development cost. The model is presented in a general form, but the formal analysis is restricted to a more restricted version with identical tasks and limited task repetition. Because of the homogeneity of the developed model it is unlikely it could be applied to practical design projects. Applying the more general model would require more model development as well as the estimation of a large number of parameters concerning task cost, time and repetition probability.

58 Nevins, J L and Whitney, D E Concurrent design of products and processes: a strategy for the next generation in manufacturing McGraw Hill, New York (1989) 59 AitSahlia, F, Johnson, E and Will, P Is concurrent engineering always a sensible proposition? IEEE Transactions on Engineering Management Vol 42 No 2 (1995) pp 166170 60 Smith, R P and Eppinger, S D Deciding between sequential and concurrent tasks in engineering design Concurrent Engineering: Research and Applications Vol 6 No 1 (1998) pp 1525

2.5.2

WTM parallel/serial model

Another model that has addressed the issue of how much parallelism is desirable is the parallel-serial version of the WTM model60. The WTM model (as introduced in section 2.2 above) is extended to allow for sequential processing of iteratively coupled tasks. The tasks are grouped into sets. The initial set of tasks is worked on until no more iterative rework remains.

Product development process modeling

255

DST: design studies (page 19 )

08-03-99 08:58:19

Rev 14.02x

zdst$$141h

The subsequent set of tasks is then attempted, with iterative rework both for the later set as well as for earlier sets of tasks. The total development time and total amount of engineering effort can be calculated based on the WTM model framework. In addition to the WTM model assumptions, it must be assumed that there is no change in model parameters as a function of how the tasks are sequenced, and there is no change in the product that is produced by the design process as a function of how the tasks are sequenced. Both of these assumptions are strong and potentially problematic. The model has been applied to a computer workstation design problem. The data that are necessary to implement the model are shown to be possible to collect, and the outcome of the model seems to match many measures of credibility, such as primarily completing the product design and the general parameters of manufacturing process design before doing detailed process design work.

2.5.3

Stage overlapping

61 Krishnan, V, Eppinger, S D and Whitney, D E A modelbased framework to overlap product development activities Management Science Vol 43 No 4 (1997) pp 437451 62 Loch, C H and Terwiesch, C Communication and uncertainty in concurrent engineering Management Science (in press)

Two related models are concerned with the role of stage overlapping between nominally sequential design stages61,62 (see Figure 5). Increases in overlapping may arise from the early freezing of design parameters in an upstream stage. Increasing the amount of overlap has the potential to reduce the total time required to complete the design process. Increasing the overlap may also lead to premature choice of design alternatives and associated quality losses, or the creating of additional and expensive rework. These models are intended to illuminate this set of issues. The models results are based on reasonable functional forms of quality loss function and parameter change expressions. The models are able to calculate minimum development time policies for identiable data. They also illustrate how one should attempt to identify parameters that could

Figure 5 Task overlapping options61

256

Design Studies Vol 20 No 3 May 1999

DST: design studies (page 20 )

08-03-99 08:58:19

Rev 14.02x

zdst$$141h

and should be frozen early, in order to lessen development time without sacricing product quality. The models are illustrated with examples from the automotive and electronics industries. The data were collected in retrospect, but it is proposed that these data are typically available in many instances. The models that address the parallelism/sequencing issues arise in an important area of design process management. They indicate the likely truth that limitations to complete parallelism are appropriate, and have begun to construct useful decision aids that may have direct applicability for design management.

2.6

Other issues

The earliest attempts at process modeling did not focus on time as the most important process variable. They instead looked at various other formalizable aspects of the design artifact. This subsection is intended to examine several models that do not t into any clear category, except that none of them explicitly considers time as a process variable. One such modeling formalism is known as the AIDA (analysis of interconnected decision areas) model63,25,64. AIDA assumes that there is a number of subproblems within every design problem, and every subproblem has a variety of possible solutions (see Figure 6). Some of the subsolutions will be incompatible with solutions to other subproblems. If we know what these incompatibilities are, then it is possible to nd feasible sets of solution with no known incompatibilities. The AIDA formalism describes a useful set of knowledge concerning the design process, that many design subcomponent decisions are interrelated. However, the lack of application of these methods in the literature leads one to believe that there are difculties in its applicability. It is possible that the amount of predictive knowledge concerning whether certain subsolutions are incompatible exceeds the amount typically available at the time that decisions are made, or collecting this information is prohibitive. Alternatively, the interaction graph suggests that pairs of solutions may be incompatible, but in reality it may be triples of solutions that are incompatible, although any pair within the triple would be satisfactory. Other formalisms examine how the sequences of decisions alter the design space65,22,66. These models acknowledge that design is constituted of a number of decisions, and each decision alters the decision space available for future decisions (see Figure 7). These models seem a good way to describe design processes after they have occurred, but neither the authors

63 Harary, F, Jessop, W N, Stringer, J and Luckman, J An algorithm for project development Nature Vol 206 (1965) p 118 64 Blandford, S and Hope, R P Systematic methods for the problem solving process with particular reference to design IEE Proceedings, Part A Vol 132 No 4 (1985) pp 199212 65 Ramstro m, D and Rhenman, E A method of describing the development of an engineering project IEEE Transactions on Engineering Management EM- Vol 12 No 3 (1965) pp 79 86 66 Morgan, J A network approach Chartered Mechanical Engineer Vol 14 No 4 (1967) pp 170172

Product development process modeling

257

DST: design studies (page 21 )

08-03-99 08:58:19

Rev 14.02x

zdst$$141h

Figure graph25

AIDA

options

nor anyone else has attempted to use these models as predictive tools. There is a more recent study that applies the Marples approach to an industrial design problem67, but again this is used for retrospective description rather than as a predictive tool. A more recent process model of design that does not address time is a Petri net model68. This model describes information ows in engineering design using Petri nets. The advantages of Petri nets include their handling of concurrency and iterative ows. The disadvantages of Petri net descriptions include the lack of useful measures of time, and emphasis on feasibility as the output measure of interest. Additionally, there is no weighting to the connections; all connections are implied to be of the same importance. Furthermore, the complete structure of the project must be done in advance if the model is to have any useful predictive utility. The proposers have not applied the modeling technique to an industrial problem.

Tebay, R, Atherton, J and Wearne, S H Mechanical engineering design decisions: instances of practice compared with theory Proceedings of the Institution of Mechanical Engineers Vol 198B No 6 (1984) pp 8796 68 Bretschneider, F and Lagger, H Design-ow modeling and knowledge-based management Applied Articial Intelligence Vol 6 No 1 (1992) pp 4557

67

258

Design Studies Vol 20 No 3 May 1999

DST: design studies (page 22 )

08-03-99 08:58:19

Rev 14.02x

zdst$$141h

Figure 7 Design sequence chart67

Discussion

There is no reason to believe that the existing models are sufcient and cannot be superseded. It is the goal of this paper to identify the state of the modeling art and to suggest metrics by which modeling efforts can and should be judged. It remains the task of the community to nd those models that best fulll the needs of importance, rigor, tractability, and applicability. All of the models described in this paper meet the criterion of managerial importance of the underlying issue. The models focus on development lead time, development cost, product specications, and other criteria, all of which are indisputably of great signicance in the product development process. All of the models meet the criterion of rigor. These models are developed in an academic context and published in peer-reviewed outlets. The modeling process has therefore emphasized rigor (at the potential loss of applicability). Computational tractability is not that difcult a hurdle for these modeling efforts. The model developers pay differing amounts of attention to

Product development process modeling

259

DST: design studies (page 23 )

08-03-99 08:58:19

Rev 14.02x

zdst$$141h

tractability in the presentation of their model, but in general this is not a critical problem for this type of model. Although several of the models involve discrete optimization (and some are formally shown to be NPhard), data are sufciently difcult to come by that the run time is likely to be manageable for realistic problems. Furthermore, optimal solutions are not critical and heuristically good solutions will typically prove acceptable. If these models fail to be useful for large-scale systems, it is typically due to the lack of available data rather than due to computational tractability. Applicability is potentially the most signicant criterion; there are multiple ways that a model might fail to be applicable. A model will fail to be applicable if it is predicated on the availability of information that is not readily available. A model will fail to be applicable if the assumptions and simplications necessary for its construction do not match industrial practice. Each of the models presented fails to one degree or another along the applicability criterion. This is an area that future modelers should pay greater attention to if their work is to have practical signicance. Many of these models use iteration as a building block for mathematical formalism. Iteration is used for two reasons: it is ubiquitous in engineering practice, and the repetition leads to the type of patterned behavior that is amenable to mathematical structuring. Product development process modeling is in an earlier stage of development than modeling in other areas of management science. Product development is more difcult to model than production processes (the most common type of application in the operations community). Because of a greater amount of variety in engineering practice, because of the lower number of repetitions, and because of the high level of human intervention, it is difcult to imagine that product development modeling will reach the level of sophistication and application that can be achieved in production. Despite this shortcoming, there is the potential for great utility in product development modeling efforts. Because of the tremendous impact of design decisions, any attempt to improve decision making will have great benet for those rms who are successful. The efforts that have been made have created some potentially useful modeling frameworks. Because the instantiation of any model is process specic, there is not one version of any process model that applies to all product development processes. The modeling methods, however, are sufciently general that they can be applied to a wide variety of industrial situations.

260

Design Studies Vol 20 No 3 May 1999

DST: design studies (page 24 )

08-03-99 08:58:19

Rev 14.02x

zdst$$141h

These models are primarily developed in an academic context, rather than by those who are engaged in design activities. The standards for academic merit, such as mathematical elegance, worst-case computational tractability and empirically justied modeling assumptions, do not carry as much weight with designers and their managers, who are more interested in practical utility and relevance. The practical criterion is easier to state but harder to measure: is it useful? As we consider models from a utility point of view we are swayed most strongly by the application of the model to real problems. Unfortunately, often this type of application either is proprietary and therefore not presentable in the open literature, or comes only after the primary model has been developed and published, such that publication of the application is less likely in the academic press. Nevertheless, we suspect that most of these models have not been applied on real problems in a manner that enabled action by important decision makers. The methods described in this paper are associated with techniques that are amenable to computer analysis: mathematical algorithms and optimization. Since these models were developed for academic purposes no commercial software exists for most of the models, and that which does exist is relatively crude and user-unfriendly. This is a barrier to wider use that will need to be remedied if the models are to spread outside of the academic community.

Conclusion

The eld of product development process modeling is reaching a greater degree of maturity. There are a number of models that focus on many interesting and important process issues such as lead time, task scheduling and project decomposition. The empirical justication for these models is increasing, although there is still room for more empirical and analytical work. Standards for successful modeling should include both academic- and practitioner-oriented components. Without achieving the academic standards of analytical rigor there will be a general reluctance to believe these models. Without achieving the practitioner standards of ease of use and data availability the ability to apply these models will be non-existent.

Product development process modeling

261

DST: design studies (page 25 )

08-03-99 08:58:19

Rev 14.02x

zdst$$141h

Anda mungkin juga menyukai