product development process modeling

Product development is a critical function of technology-based firms.The success of product development efforts can determine the long-term viability of companies and economies1,2.

Product development of large-scale systems is a complex process; complexbecause of the range of technical issues that must be addressed, and com-plex because of the variety of people and organizational structures thatmust be employed over the life of a product development effort3,4. Productdevelopment involves many organizational units and engineering disci-plines. Research on product development includes work from diverse areasof the engineering and management research communities. Engineeringresearchers have typically focused on formal structures involved in engin-eering design decisions5–9, while management research has concentratedon 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 technicaland commercial solution11. Each product development process is unique,

1 Ulrich, K T and Eppinger, SD Product design and develop-ment McGraw–Hill, New York(1995)2 Susman, G I Integratingdesign and manufacturing forcompetitive advantage OxfordUniversity Press, New York(1992)3 Simon, H A The sciences ofthe artificial MIT Press, Cam-bridge (1981)4 Bucciarelli, L L Designingengineers MIT Press, Cam-bridge (1994)5 Finger, S and Dixon, J R ‘Areview of research in mechanicalengineering design’ Research inEngineering Design Vol 1 (1989)pp 51–67; 121–1376 Pahl, G and Beitz, W Engin-eering design: a systematicapproach Springer Verlag, NewYork (1988)7 Suh, N P The principles ofdesign Oxford University Press,New York (1990)8 Warfield, J N A science ofgeneric design: managing com-

0142-694X/99 $ - see front matterDesign Studies20 (1999) 237–261237PII: S0142-694X(98)00018-0

1999 Elsevier Science Ltd All rights reserved Printed in Great Britain

DST: design studies (page 1 ) 08-03-99 08:58:18 Rev 14.02x zdst$$141h

Product development processmodeling

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 theconstruction of process models for the product development process.Understanding and modeling a process is an important first step in theconstruction of managerially useful decision aids. Product developmentis a complex process, and it is likely that many process models will beuseful for making managerial decisions. This paper provides a summaryof such work, and points out the strengths and weaknesses of thevarious modeling approaches. It also proposes a new set of criteria forevaluating product development models, with particular attention totheir industrial relevance. 1999 Elsevier Science Ltd. All rightsreserved

Keywords: design models, modeling, product development, engineeringdesign, design management

plexity through systems designIowa State University Press,Ames (1994)9 Braha, D and Maimon, O‘The design process: properties,paradigms, and structure’ IEEETransactions on Systems Manand Cybernetics, Part A: Sys-tems and Humans Vol 27 No 2(1997) pp 146–16610 Brown, S L and Eisen-hardt, K M ‘Product develop-ment: past research, presentfindings, and future directions’Academy of ManagementReview Vol 20 No 2 (1995)pp 343–37811 Whitney, D E ‘Designingthe design process’ Research inEngineering Design Vol 2 (1990)pp 3–1312 Brady, T, Rush, H, Hob-day, M, Davies, A, Probert, Dand Banerjee, S ‘Tools for tech-nology management: an aca-demic perspective’ TechnovationVol 17 No 8 (1997) pp 417–426

but the processes share common features or elements. If we can understandwhat those processes have in common we may be able to guide the man-agement of future product development processes.

Like other processes, it is possible and useful to build quantifiable modelsof the product development process. The goals of process modeling areseveral; they include learning about the process, and suggesting ways thata process can be controlled. There are a number of process models ofproduct development, and there is a significant amount of recent researchactivity in developing or improving process models. It is the aim of thispaper to chronicle the published models, and to guide future model devel-opment.

The existence of a number of divergent product development process mod-els should not be surprising—product development is complex. In lieu oftrying to unify the product development modeling literature we shouldexplore the various advantages of each modeling approach. As researcherswe should be attempting to improve decision making and building modelsthat allow this; as practitioners we should determine which, if any, of theexisting models serve our needs. There are important interactions betweena model’s theoretical power and its practical value; neither can be neglect-ed12.

This paper is structured as follows. Section 1 suggests a set of criteria bywhich product development process models can be judged. Section 2describes the existing models of product development and measures themagainst the criteria established in section 1. Section 3 gives an overall viewof the state of product development process modeling. Section 4 serves asa summary.

1 Modeling criteriaThere are a number of criteria by which the merit of proposed models ofthe product development process should be judged. This section willpresent those criteria, and show how they apply to the field of productdevelopment process modeling. We take the ultimate goal of managementscience modeling of the product development process to be the creation ofone 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 basedon information that is available and accurate; the assumptions and simpli-fications of the model are reasonable; and the model is computationallytractable. Each of these issues is discussed below.

238 Design Studies Vol 20 No 3 May 1999


The first issue is whether the model addresses an important managerialissue. This is an inherently subjective judgment. The importance of productdevelopment would suggest that almost any realistic managerial decisioninvolved in design management would be able to fulfill this criterion. Thesedecisions might involve task scheduling, resource allocation, productrelease, target specification, or many other managerial tasks related to pro-duct development.

The second issue is whether the model relies on information that is readilyavailable in a timely manner to support decision making. This is a some-what difficult hurdle for many of the modeling methodologies, as the natureof mathematical modeling requires the use of precise data, while productdevelopment occurs in an environment of uncertainty and ambiguity.Nevertheless, there are a number of predictive data that are available earlyin the product development process, and these are the data that should beused in the construction of useful predictive models. Identifying which datathese are is a thorny problem.

The third issue involves the assumptions and simplifications necessary formodel construction and analysis. Modeling is a process of abstraction fromthe ‘real’ world. Tractable mathematical functions can be constructed froma limited set of relationships (multiplication, exponentiation, Markov pro-cesses, and so forth). It is typically necessary to assume that reality fitsone or more of these functional forms. Whether or not reality is welldescribed by this abstracted form is another important subjective judgmentthat contributes strongly to the perceived merit of the modeling approach.

The final issue is computational tractability of the model. Often this is nota 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 evendesktop computing enables the use and applicability of what were in pre-vious decades considered relatively complex models.

Once we have established the criteria by which models can be judged, weneed to establish a world in which they can be judged. The first level ofvalidity is ‘face validity’. Face validity implies that the modeling topic,data, assumptions, and tractability seem reasonable to those who are fam-iliar to the field of product development management. All the modelspresented in this paper have this level of validity.

The second level of validity is the application of the modeling frameworkto existing, but retrospective data sets gathered from industry. The best ofthe models described in the next section typically are able to demonstrate

Product development process modeling 239


13 Morris, W T ‘On the art ofmodeling’ Management ScienceVol 13 No 12 (1967) pp B707–B717

their worth by application to these types of realistic data sets. (Note thatthe 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 makingin an experimental environment. This type of environment is well-con-trolled and repeatable, so it is possible to demonstrate the effects ofimproving decision making. This type of demonstration is, however, diffi-cult, as the types of problem likely to be encountered in experimental set-tings are often much simpler than those encountered in industrial environ-ments. No model presented here attempts this level of validity, but it mayprove an important avenue in the further development of product develop-ment process modeling.

The fourth level of validity is the use of the model to guide decision mak-ing in the ‘real’ world. This is a difficult case to make, as often there isno objective comparison between the changed and the unchanged situation,and the real data are confounded with many other effects that may affectthe success of the decisions made by the model. None of the models inthis 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 managementscientist arrives at a model of the phenomenon he is studying is probablybest described as intuitive’13. If modeling is intuitive and artful, whatadvice do masters have for tyro modelers? Morris suggests that it is usefulto approach modeling as a process ofenrichmentor elaboration. One startsfrom some analogy or association with well developed logical structures,and then engages in two sorts oflooping or alternation procedures. Thefirst sort of alternation occurs between modification of a model and con-frontation by data, with each test yielding new modification insight andeach modification a new test. The second is alternation between explorationof the deductive tractability of the model and the assumptions that charac-terize it. Thus, if a model is tractable in the sense of permitting the attain-ment of the deductive goals, the analyst may seek further relaxation orcomplication of the assumptions. If the model is not tractable or cannotbe ‘solved,’ the analyst returns to strengthen or simplify the assumptions13.

But complexity and extent are not ends in themselves for modelers. Weseek deductive insight and leverage. For this the simpler a model is, subjectto reproducing the behavior we observe in the world to a necessary levelof precision, the better it is. For engineers perhaps Newtonian mechanicsis the most universal world model and Newtonian mechanics is crystalline



14 De Geus, A P ‘Modelling topredict or to learn?’ EuropeanJournal of Operational ResearchVol 59 (1992) pp 1–515 Lane, D C ‘Modelling aslearning: a consultancy method-ology for enhancing learning inmanagement teams’ EuropeanJournal of Operational ResearchVol 59 (1992) pp 64–8416 Busby, J S and Williams,G M ‘The value and limitations ofusing process models todescribe the manufacturingorganization’ International Jour-nal of Production Research Vol31 No 9 (1993) pp 2179–219417 Ross, D T ‘Structuredanalysis (SA): a language forcommunicating ideas’ IEEETransactions on Software Engin-eering Vol SE-3 No 1 (1977)pp 16–3418 Subrahmanian, E, Konda,S L, Levy, S N, Reich, Y, Wes-terberg, A W and Monarch, I‘Equations aren’t enough: infor-mal modeling in design’ ArtificialIntelligence for EngineeringDesign, Analysis and Manufac-turing Vol 7 No 4 (1993)pp 257–274

in simplicity, power, and generality. When we seek to find ‘the physics’of some aspect of the world, we dream of finding models that give thatkind of deductive leverage.

If we seek application by others of models we produce, then we mustprepare to meet their predictable resistance to taking action on the basisof models they have not personally generated14. We note tension between‘type 1 error,’ believing a model’s results when the model is wrong, and‘type 2 error,’ not believing that what a model indicates is correct whenin fact it is. We believe that many academic modelers have attended moreto avoiding type 1 error by focusing on modelvalidity (typically associatedwith greater model complexity and hence opacity). This has caused a corre-sponding rise of type 2 error because academics fail to convince prac-titioners of their model’s realism; in a word their models lackcredibility.We might associate greater credibility with an Occam’s Razor sort of sim-plicity and advocate that academics shift the balance of attention towardcredibility to improve application likelihood. Others, in acknowledging thisproblem, believe that the solution lies in helping practitioners learn toolsfor rigorous development of their own models15.

In an attempt to judge the utility of process modeling for manufacturingorganizations, it has been observed that modeling has some, but limited,value16. The limitations arise from the modeler’s need to reduce the com-plex situation to a more structured form in order to have it fit in the mode-ling framework, the lack of quantitative modeling approach, the obvious-ness of findings that arise from a model, the difficulty of capturing processsteps that are often intuitive, and the lack of the ability of the model to beupdated as the organizational situation changes. The Busby and Williamswork was based on application of IDEF017; we will see in section 2 thatthere is a number of modeling structures that exist today that allow forgreater quantitative information to be included in model construction. Butwith this exception the other criticisms are potentially valid for the mode-ling approaches that exist (obviousness of findings, difficulty of capturingintuitive steps in the process, difficulty in updating the modelcontinuously). Furthermore, none of the modeling research efforts under-taken (as described in section 2) has documented a rigorous application ofthe modeling approach to an organization in order to document its utility.This is a goal of demonstrative power to which the community of productdevelopment modeling researchers should aspire.

Another aspect of the role of modeling in product development considershow engineering designers form models of the design artifact and its per-formance18. Their view, rather than sharing our focus of modeling the



19 Cross, N and Roozenburg,N ‘Modelling the design processin engineering and architecture’Journal of Engineering DesignVol 3 No 4 (1992) pp 325–33720 Graham, R J The role ofnetwork techniques in teambuilding for project management.In Dean, B V (ed) Project man-agement: methods and studiesElsevier, Amsterdam pp 163–171 (1985)21 Liberatore, M J and Titus,G J ‘The practice of manage-ment science in R and D projectmanagement’ ManagementScience Vol 29 No 8 (1983)pp 962–974

design process, considers the way that models of technical performanceare used by designers. That type of model has its own measures of validityand utility that differ from those of process models. It is noted that informalmodels are used quite often in the design process, and design methodologyresearchers need to be aware of informality of design representations asthey go about aiding the designer.

In a comparison of modeling approaches used by engineering and architec-tural design researchers, it has been noted that engineering models of thedesign process are more structured and linear, while architectural modelsof the design process are more based on cognition and preconceptions19.This difference is probably due to the fact that engineering problems aregenerally more well-structured while architectural problems are generallyill-structured. This paper is focused on engineering design, so the modelsthat we will see will tend to be highly structured, which leads to the abilityto use mathematical techniques of varying stripes. This focus on underlyingstructure furthermore implies that the models consider the most structuredparts of the engineering design process. The models are therefore biasedtoward the system level and detail design portions of the design process,and concentrate less on the conceptual, creative or otherwise unstruc-tured aspects.

Product development process models can be seen as a type of project man-agement model. Project management models have use not only for con-trolling and evaluating projects, but also for developing common goals andunderstanding of tasks among the members of the project team20. Weshould therefore consider not only the direct benefits of models (which areoften difficult to determine) but also the indirect benefits of model building.

The utility of formal project management models was established in a sur-vey of research and development project managers21. That survey sug-gested that managers were typically unwilling to use complex mathematicalmodels, both because of the difficulty in determining input data andbecause of the opacity of the algorithm employed. Recognizing that mode-ling and decision support software have improved significantly since thesurvey was conducted, we still must consider those two criteria indetermining the effectiveness of new modeling techniques.

2 A review of modelsThis section describes the recent models that have been presented in theliterature. We will first briefly present some older models of product devel-opment, and then go into some details on a number of recent modelingefforts.



22 Marples, D L ‘The decisionsof engineering design’ IRETransactions on EngineeringManagement Vol EM-8 No 2(1961) pp 55–7123 Alexander, C Notes on thesynthesis of form Harvard Uni-versity Press, Cambridge (1964)24 Jones, J C Designmethods: seeds of humanfutures Wiley Interscience, NewYork (1970)25 Luckman, J ‘An approachto the management of design’Operational Research QuarterlyVol 18 No 4 (1967) pp 345–35826 Starr, M K Product designand decision theory Prentice–Hall, New York (1963)27 Archer, L B Systematicmethod for designers Council ofIndustrial Design, London (1965)28 Evbuomwan, N F O, Sival-oganathan, S and Jebb, A ‘Asurvey of design philosophies,models, methods and systems’Proceedings of the Institution ofMechanical Engineers Vol 210(1996) pp 301–32029 Platt, D G ‘Building processmodels for design management’Journal of Computing in CivilEngineering Vol 10 No 3 (1996)pp 194–20330 Ritchie, E ‘Planning andcontrol of R and D activities’Operational Research QuarterlyVol 23 No 4 (1972) pp 477–49031 Dougherty, D M, Ste-phens, D B and Ezell, D E ‘Thelasting qualities of PERT: prefer-ences and perceptions of R andD project managers’ R and DManagement Vol 14 No 1 (1984)pp 47–56

All of the models are based on the observation that design is composedof a number of tasks that have an underlying structure. This observationcan be traced to some of the earliest and most influential models of designdecision making22,23. The structure that is posited within each model variessignificantly, but all of these models are based on the belief that a struc-ture exists.

Jones24 does an excellent job of reviewing the design models and methodsthat arose during the 1960s and previously. Those methods will not befurther reviewed here. There are 35 methods reviewed in his treatise, parti-cularly notable among those in relevance to this paper are the methods ofAlexander23, Luckman25, Starr26, and Archer27. The ideas in those modelshave been incorporated into many of the more recent models that aredescribed below.

There is also a distinct stream of modeling research on engineering designmethodology28,29. That work focuses on descriptive methodological andphilosophical frameworks of the engineering design process. The focus inour paper is on quantitative, graphical, or otherwise formalizable predictivemodels, which constitute a distinct but related class of models.

For many of the models presented below time is one of the dependentvariables of interest. It is not surprising that this is so: product developmentlead time is one of the critical factors for success, many process choicesaffect lead time, and time is inherently quantifiable. The progenitor of time-based project modeling is the PERT/CPM method, and this serves as auseful point of comparison for time-based product development modelingefforts. PERT-type models have been applied to engineering design, withvaried success30,31. It is recognized that PERT has several limitations: thelack of the feedback and iteration that is common to the design process, andthe difficulty for managers to collect the data and understand the outputs ofthese types of model, particularly in their most complicated forms. Further-more, it is also not clear that the primary behaviors that PERT is able tocapture (stochastic activity duration, sequential activity relationships) arethe behaviors that are most critical to engineering design management. Forthese reasons many process modelers seem to be leaving the PERT frame-work to establish models that better address other behaviors while tryingto keep the models as simple as feasible.

We have grouped the models into five categories, depending on what eachmodel attempts to accomplish. The five categories are sequencing andscheduling models, decomposition models, stochastic lead time models,design review timing models, and parallelism models.



32 Steward, D V ‘The designstructure system: a method formanaging the design of complexsystems’ IEEE Transactions onEngineering Management VolEM-28 No 3 (1981) pp 71–7433 Eppinger, S D, Whitney, DE, Smith, R P and Gebala, D A‘A model-based method fororganizing tasks in productdevelopment’ Research inEngineering Design Vol 6 No 1(1994) pp 1–1334 Kusiak, A and Wang, J‘Efficient organizing of designactivities’ International Journal ofProduction Research Vol 31 No4 (1993) pp 753–76935 Eppinger, S D ‘Model-based approaches to managingconcurrent engineering’ Journalof Engineering Design Vol 2 No4 (1991) pp 283–29036 Rogers, J L ‘Knowledge-based tool for decomposingcomplex design problems’ Jour-nal of Computing in Civil Engin-eering Vol 4 No 4 (1990)pp 298–31237 Lewis, W P and Cangshan,L ‘The timely allocation ofresources in the concurrentdesign of new products’ Journalof Engineering Design Vol 8 No1 (1997) pp 3–17

2.1 Sequencing and scheduling design tasksA number of models have considered the problem of scheduling andsequencing design tasks. Product development is distinct from many pro-ject-like activities in that iteration and rework are commonplace. The pres-ence of iteration leads to difficulty in finding appropriate orderings.

2.1.1 Design structure matrixOne of the most important family of models is that based on the designstructure matrix (DSM)32–36(see Figure 1). The DSM method assumes thateach design task can be modeled as an information processing task, usingand creating information. The output information from one task becomesthe input information to another task. The input/output relationships may(in all likelihood) include cycles, which indicate the need for iteration. TheDSM formulation is a matrix representation that includes these relation-ships. Tasks in the matrix may be resequenced, which helps identify cycli-cal and acyclical tasks.

The researchers who have considered this modeling family observe that itis a feasible proposition to construct this type of matrix, even for relativelycomplex design processes with more than 100 tasks33. One limitation ofthe DSM is that it is relatively difficult for the uninitiated to understand37.



Figure 1 Design structure

matrix33

38 McCulley, C and Bloe-baum, C L ‘A genetic tool foroptimal design sequencing incomplex engineering systems’Structural Optimization Vol 12No 2–3 (1996) pp 186–20139 Altus, S S, Kroo, I M andGage, P J ‘A genetic algorithmfor scheduling and decompo-sition of multidisciplinary designproblems’ Journal of MechanicalDesign Vol 118 No 4 (1996)pp 486–48940 Smith, R P and Eppinger,S D ‘A predictive model ofsequential iteration in engineer-ing design’ ManagementScience Vol 43 No 8 (1997)pp 1104–1120

The basic assumptions of this model, that design tasks are predictable infor-mation processing tasks with identifiable inputs and outputs is reasonable(except in the case of truly novel technologies). Finding groups of tasksthat require cyclical flows of information (coupled tasks) is relatively easyonce the matrix data exist. For these reasons the model seems to havesignificant potential utility.

The DSM method as originally proposed offers little advice about how tohandle and schedule design tasks within the iterative groups. Newer vari-ations have been proposed to address this shortcoming.

The models that have been located within this subsection are those exten-sions to the DSM framework that consider sequencing and schedulingwhen only one task is occurring at a time. There are also sequencing andscheduling models that assume that parallelism may occur. Those modelshave been placed in section 2.5.

2.1.2 Feedbacks and crossoversTwo sequencing models based on the DSM are based on reducing thenumber of information feedbacks, information crossovers and length ofiterative cycles38,39. These numbers are meaningful for sequential schedulesof tasks. Feedbacks indicate a need for repetition, information crossoversindicate an opportunity for a loss of coordination information, and lengthof feedback cycles indicates a large amount of required rework. These arediscrete optimization problems, and it is shown that genetic algorithms areuseful at finding near-optimal solutions for large instances.

These studies do not provide empirical justification of the utility of feed-back, crossover and cycle length measures as critical measures of schedul-ing goodness, nor do they present empirical data that shows the utility oftheir method. These are potentially critical shortcomings in this modelingapproach. Nevertheless, the optimization method is powerful, and couldpotentially be applied to other goodness functions.

2.1.3 Sequential iteration modelAnother sequencing and scheduling model that is built on the frameworkof the DSM is the sequential iteration model40. In this model tasks arecompleted one at a time, with a probabilistic need for repetition of priortasks (see Figure 2). Each task has a fixed, deterministic duration. Theexpected duration of any given ordering of tasks can be calculated byfinding the expected reward of a reward Markov chain. The ordering ofthe tasks can be manipulated to minimize the expected time. This is acombinatorial optimization problem and several heuristics exist for findingnear-optimal orderings.



41 Eppinger, S D, Nukala, M Vand Whitney, D E ‘Generalizedmodels of design iteration usingsignal flow graphs’ Research inEngineering Design Vol 9 No 2(1997) pp 112–12342 Belhe, U and Kusiak, A‘Modeling relationships amongdesign activities’ Journal ofMechanical Design Vol 118 No 4(1996) pp 454–460

There are some useful outputs of this model, such as that it is valuable tocomplete shorter tasks before longer tasks and that it is desirable to lessenthe number of large repeat probabilities that appear as feedbacks in theoptimal ordering.

The difficulty with this model is in its assumptions. In order to keep findingthe expected duration of a given ordering tractable, the model assumes thattasks have fixed and constant durations, no matter how many times theyare repeated. Also, repetition probabilities are assumed to be known, fixedand constant, independent of the ordering of the tasks and of the numberof times that any task has been completed.

Some of the limitations of the sequential iteration model have beenremoved in an extension41. The extension allows for random duration oftasks as well as allows multiple tasks to be attempted simultaneously. Thelimitation of the extension is a corresponding decrease in the tractabilityof the model. While the original sequential iteration model could analyzeprocesses with dozens or scores of tasks, the more recent version is restric-ted to no more than about 10 if exact solutions are to be obtained. Largerproblems are approximately tractable using simulation, but the solutionsare not as reliable.

2.1.4 Iterative cycle time estimationA further extension to the DSM framework is a model that includes proba-bilistic OR and XOR (exclusive OR) relationships between tasks42. Forthis model the probabilities of executing one or more of the OR/XOR pathsare dependent on the iteration number, and these probabilities are fixed inadvance. The presented version of the model has the length of each taskbe fixed and deterministic, and the length of each task does not change asthe iteration process progresses.

The model enables calculating the probability distribution of the total timerequired to complete the design process. Knowing this distribution is usefulfor monitoring progress, predicting due dates, and allocating task resources.



Figure 2 Reward Markov

chain for sequential iter-

ation model40

43 Bird, S D and Kasper, G M‘Problem formalization tech-niques for collaborative systems’IEEE Transactions on Systems,Man, and Cybernetics Vol 25 No2 (1995) pp 231–24244 Rechtin, E and Maier, M WThe art of systems architectingCRC Press, Boca Raton (1997)45 Lewis, W P, Samuel, A Eand Field, B W ‘An example ofthe application of a systematicmethod to design’ OperationalResearch Quarterly Vol 24 No 2(1973) pp 217–23346 Smith, R P and Eppinger,S D ‘Identifying controlling fea-tures of engineering design iter-ation’ Management Science Vol43 No 3 (1997) pp 276–293

The difficulties with this model are the assumptions and the availability ofdata. We must assume that task times and iteration probabilities are fixedand known in advance, as is the task iteration structure. This requires sig-nificant 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 sig-nificant managerial problem that has important effects on design processes.They also, however, require strong assumptions in order to retain analyticaltractability. The models in this section are interesting, but their utility forindustrial practice remains to be demonstrated.

2.2 Decomposing large systemsOne essential task within product development management is how largedesign projects should be split into smaller elements43,44. This decision isdifficult, important, and amenable to formal analysis, and has thereforebeen the target of several models. Decomposition of large systems is usefuleither to allocate the work among multiple designers or design teams, oralso to suggest a decomposition of the technical artifact that will minimizeoverlapping between subsystems. Decompositions therefore have theability to speed the design process as well as create higher performancedesign outcomes.

Formal decomposition methods trace their roots to Alexander23. Alexand-er’s model uses interactions between design elements (described in matrixor graphical form) to determine appropriate subgroups of design elements.Designers are polled about where they believe the strongest interactionsexist between pairs of tasks, and the method is able to use these interactionsbetween design elements to suggest appropriate decouplings of theelements. A later paper45 applies the method to a building design problem,and compares the decompositions offered by the algorithm with those sug-gested by building designers. It is demonstrated that the method seems todo no worse in decomposing the problem than do the designers. Thisapproach has been extended in several more recent modeling approaches.

2.2.1 Work transformation matrix methodOne method developed to accomplish decomposition is the work trans-formation matrix (WTM) method46. The WTM method is an extension tothe DSM method presented earlier. In this model the off-diagonal DSMentries are replaced with rework factors, and the time for each task isestimated (see Figure 3). The rework factors indicate how much reworkneeds to be completed as a function of work completed in the previousiteration. The model assumes that the design process is iterative, and



47 Kusiak, A and Park, K‘Concurrent engineering: de-composition and scheduling ofdesign activities’ InternationalJournal of Production ResearchVol 28 No 10 (1990) pp 1883–190048 Kusiak, A and Wang, J‘Decomposition of the designprocess’ Journal of MechanicalDesign Vol 115 (1993) pp 687–69549 Michelena, N F and Papal-ambros, P Y ‘A hypergraphframework for optimal model-based decomposition of designproblems’ Computational Optim-ization and Applications Vol 8 No2 (1997) pp 173–196

iterative rework is created linearly, so that rework is a linear function ofwork in the immediately previous iteration. The total work completed dur-ing the process can be calculated by looking at the sum of the work doneduring every iteration.

The output of this model is the total work completed. One illuminatingobservation is that the total work completed is a strong function of theeigenvalues and the eigenvectors of the matrix containing the rework quan-tities. By analogy to dynamic physical systems, the dynamic behavior ofthe process is strongly indicated by the eigenvectors associated with thelargest eigenvalues of the matrix. The eigenvectors can therefore be usedfor decomposition of the problem into relatively unconnected groups oftasks.

The original paper concerning the WTM model presents an application ofthe method to brake system design at General Motors. They present evi-dence that it is relatively straightforward to collect data from real engineer-ing projects, and observe that the eigenvectors of the created WTM corre-spond well with known tightly coupled technical issues. They suggest thatthe method would be applicable in situations where the tightly coupledtechnical issues are not known in advance. The shortcomings in this modelarise from the restrictive nature of the assumptions. It is difficult to justifythe strict appropriateness of these assumptions (linear creation of rework,static measures of rework process), but the ability of the model to beapplied to a real situation is encouraging.

2.2.2 Activity module decomposition modelAnother model that describes the decomposition problem is based on thesimilarities between design process decomposition and cellular manufac-turing systems47–49 (see Figure 4). In this model the design activities areassumed to be similar to manufacturing jobs to be processed, and design



Figure 3 Work transform-

ation Matrix46

resources (such as engineers) are assumed to be similar to manufacturingprocessing equipment. It is desirable to decompose the system into modulessuch that each module (manufacturing cell or design resource) is substan-tially decomposed from other modules. If we accept the analogy, then thereare a number of results from cellular manufacturing that follow directly.For example, the cellular manufacturing optimization problem is known tobe NP-hard, and there are a number of heuristics that provide usefuldecompositions.

As we consider the applicability of this model, we must determine whetheractivities require sets of resources in the same way that manufacturing jobsrequire sets of machines, and whether the assignment of groups of designactivities to engineering resources is analogous to the creation of manufac-turing work cells. Because of the flexibility of human resources, it is likelythat the engineering design situation is likely to be more fluid and lessfixed than the manufacturing equivalent, although the analogy does havesome intellectual appeal.

The model is applied to a problem involving the design of a helical com-pression spring48. It is shown that for an instance where the functional formof the governing design equations are available it is possible to identifydecompositions that separate substantial sub-blocks of the underlyingdesign problem. Whether these equations are available in many designsituations and whether those situations are likely to exhibit the cellularstructure are open questions.



Figure 4 Activity module de-

composition matrix47

50 Bolton, B ‘Polyhedraldynamics applied to design andproject management’ IEE Pro-ceedings, Part A Vol 135 No 4(1988) pp 241–24451 Pimmler, T U andEppinger, S D Integration analy-sis of product decompositionsASME Design Theory and Meth-odology Conference ASME, Min-neapolis (1994)52 Taylor, B W and Moore, LJ ‘R and D project planning withQ-GERT network modeling andsimulation’ ManagementScience Vol 26 No 1 (1980)pp 44–59

2.2.3 Other decomposition modelsAnother decomposition model provides a novel interpretation of the DSMmethod described earlier50. This model incorporates both the DSM infor-mation concerning task precedence and cycles as well as activity resourceincidence matrices. These two sets of matrix information are combined tooffer suggestions about how a design organization should be decomposed,and which interactions between tasks and people are desirable. Unfortu-nately, the model is not highly formalized, and the recommendations ofthe model are not based on rigorous analysis. There is the kernel of auseful idea, that one needs to be aware of both interactions between tasksand between people when forming decompositions and assigning tasks, butthe model does not attempt to do this in a formal way.

A second extension to the DSM method attempts to divide design tasksinto organizational units51. This method extends the DSM structure toinclude spatial, energy, information and material interactions betweendesign elements. These interactions are used to identify clusters of designelements that should be addressed by organizational units. This model con-tains a considerable amount of structuring of design element interactions,but the clustering step remains informal.

2.3 Determining the effects of stochastic delays onproduct development lead timeTwo effects that are potentially important to product development that arenot captured in PERT/CPM models of product development are the needfor iteration as well as the potential delays in product development becauseof queueing delays. The models in this subsection recognize that productdevelopment projects do not occur in isolation, but instead there are severalsimultaneous projects that are competing for the same limited resources.The limited availability of resources (typically design engineers) causesdelay in the overall project that can adversely affect overall project leadtime. The two models below address these issues.

2.3.1 Q-GERT modelThe first model is the Q-GERT model52. GERT is an extension to PERTthat allows feedback and a more general analysis. Q-GERT is an extensionto GERT that allows for queueing delays. Taylor and Moore have appliedQ-GERT to product development.

The model includes such features as probabilistic routing of tasks to ser-vers, including probabilistic iteration; branching and joining of tasks; andmultiple simultaneous projects within multiple development groups. There



53 Adler, P S, Mandelbaum,A, Nguyen, V and Schwerer, E‘From project to process man-agement: an empirically-basedframework for analyzing productdevelopment time’ ManagementScience Vol 41 No 3 (1996)pp 458–484

are a known set of development projects with well-characterized proba-bilistic descriptions of task durations and outcomes. The Q-GERT method-ology relies on simulation analysis to make observations about the expectedthroughput time and variance. Taylor and Moore apply the Q-GERT meth-odology to a set of development projects within an unnamed textile com-pany.

In practice it is difficult to imagine that the upcoming projects will besufficiently well understood that a probabilistic characterization will beaccurate. Also, the reliance on simulation as the mode of analysis meansthat it is difficult to determine the functional relationship between variables.Every instance of the network requires a new simulation coding, whichcan become prohibitive for complex situations. They have identified aninteresting problem, but their analytical method is limited in its ability tomake useful insights.

2.3.2 Queueing network modelA more recent modeling effort has also focused on examining the effectsof queueing delays on product development lead time53. This model appliesmore recent analytical results from queueing networks regarding Brownianapproximations and fork-join networks to the problem of product develop-ment viewed as a queueing network. The outcomes of the model indicatethe total capacity available for any given network structure, as well a cycletime of a given throughput rate and resource combination.

In order for a queueing network model to be valid there are a number ofassumptions that need to hold. First, there must be a sufficient number ofsimilar projects such that a probabilistic description of them makes senseand data are available. Second, the network has to be assumed to beoperating for a sufficient period of time that the steady-state probabilitydescription applies. Third, it must be assumed that there is no meta-levelcontrol of the network (such as engineers working overtime because theyknow that they have a large backlog of work). Each of these assumptionsis troubling. In combination they may lead to significant difficulty in appli-cation of the model.

The authors of this study state ‘We found that the construction of the modelitself, rather than being a burden, was probably the most directly usefulpart of our research’53 (p 482). This is both good and bad news. There isutility in doing this type of modeling, but it really doesn’t matter whattype of modeling is done, as long as the participants and the modelers takesufficient effort to discuss the important issues.



54 Ha, A Y and Porteus, E L‘Optimal timing of reviews in con-current design for manufacturab-ility’ Management Science Vol41 No 9 (1995) pp 1431–144755 Koushik, M V and Mook-erjee, V S ‘Modeling coordi-nation in software construction:an analytical approach’ Infor-mation Systems Research Vol 6No 3 (1995) pp 220–254

2.4 Determining the timing of design reviews/productreleaseAnother class of models concerns the timing of activities that are relatedto the design process, but are not design tasks themselves. These activitiesinclude design reviews and product release.

2.4.1 Timing of design reviewsThe first model in this vein is based on the concept of determining thetiming of design reviews54. Design reviews are important milestones in thedesign process when participants exchange their partially completed ideasabout the final form of the artifact. Design reviews are valuable becausethey provide opportunities to exchange and critique ideas, but are poten-tially nonproductive because of the preparation time and other overhead.

In their model Ha and Porteus assume that there are two types of designactivities: product design activities and process design activities. Any givendesign activity may create a flaw that will only be discovered at the timeof the next design review. Flaws are corrected by some amount of rework.Also, each design review releases an amount of work from product designto process design. It is desirable to have design reviews close together sothat flaws are discovered rapidly and so that process designers are notstarved of work. It is desirable to space design reviews apart so that theoverhead of conducting the reviews is not increased. The model is statedsuch that an optimal balance can be found between these conflicting inter-ests.

This model traces its antecedents to comparable ideas in the world ofmanufacturing quality control and inspection. The model is tractable forsimple situations such as having stationary strategies and only two typesof design task. Extensions are possible that reduce tractability.

The observations about the influences on design review frequency areinsightful, but it is difficult to imagine a situation where the outcome ofthe model would be applied directly. The data are difficult to estimate forany specific instance, and some of the assumptions (for example, productreviews are the sole mechanism by which information is passed from onegroup to another, and are also the sole mechanism by which design errorsare discovered) are not reflective of design reality.

2.4.2 Module schedulingA philosophically similar model arises in the consideration of softwaredevelopment55. This model considers the effects of coordination of mod-ules in software development.



56 Cohen, M A, Eliashberg, Jand Ho, T-H ‘New product devel-opment: the performance andtime-to-market tradeoff’ Manage-ment Science Vol 42 No 2 (1996)pp 173–186

The number of developers needs to be chosen by the decision maker. Eachdeveloper works on a module of the software project. There is a fixed totalnumber of modules, and a coordination event occurs after some numberof modules are completed, which is another decision variable. During andafter a coordination event the participants communicate their results, thecompleted modules are integrated, rework occurs on incompatibilities, andfurther development work occurs on uncompleted modules. The totaldevelopment time is fixed in advance.

In this model there is a number of phenomena explored. Analysis of themodel is presented based on numerical results for examples concerningmany identical modules. In addition they present simulation results forsystems containing non-identical modules. The results concern phenomenasuch as the optimal team size as a function of time available and the opti-mal number of modules that should be completed before a coordinationevent as a function of the total number of modules.

Again the observations of this type of model seem appropriate, but thedifficulty in obtaining specific data for any given project will limit themodel’s direct applicability. The originators claim ‘the results [of thismodel] should not be interpreted in a strict numeric sense…It is reasonableto use these results to predict the impact of changing a particular systemparameter on the direction of an outcome variable’55 (p 243).

2.4.3 Product releaseA further model that addresses the scheduling of important milestones inthe product development cycle is a model that examines the relationshipbetween product performance, product release, and development56. Thismodel examines the functional relationship between performance and profitas a function of product release timing.

The model reasonably assumes that product performance is an increasingfunction of development time. The market performance of a product is afunction of the product performance as well as what other competing pro-ducts are already on the market at the time of product introduction. Productmanagers therefore have to determine when to release products such thattheir performance is high enough to satisfy customer expectations but thedevelopment cycle is quick enough that competitors do not fill the voidfirst.

The model is able to indicate optimal time-to-market and product perform-ance goals, as well as showing other relationships, such as that strictlyminimizing time-to-market does not lead to the long-term optimal productdevelopment strategy.



57 Khanna, T and Iansiti, M‘Firm asymmetries and sequen-tial R and D: theory and evidencefrom the mainframe computerindustry’ Management ScienceVol 43 No 4 (1997) pp 405–421

The model assumes that product performance has a Cobb–Douglas formof increase, similar to common assumptions in economics for productionfunctions. The authors have validated this assumption based on existingdata from consumer-oriented firms in two industries. The consumerdemand model uses the logit model for its functional form, which is acommon assumption in the marketing literature and has also receivedempirical support.

The model has strong justification for its functional relationships, whichincreases the credibility of its results. It does, however, suffer from a com-mon fault in product development process modeling in that the model relieson data that are not estimable in practice, and so the results of the modelcannot be applied directly to enable a project manager to make productdevelopment decisions.

2.4.4 Stage targetingA related model concerns how firms allocate development resources insequential stages57. This model assumes that there is a limited set ofresources (engineering professionals) who are useful to the developmentproject. A set of firms must compete to employ these resources. Productdevelopment is a two stage process (research and development), and thefirms decide how to allocate resources between these stages sequentially.Firms also decide how to set technical targets of each stage (increase thetechnical goals, possibly delaying product introduction, or lower the techni-cal goals to increase the chances that you will be early to market).

The results of the model indicate that there is advantage given to firmsthat are currently ahead of their competitors, and that these firms will tryto increase the likelihood that they arrive first to market. Laggard firms,by contrast, will raise their technical sights, hoping to be able to producea better product, albeit one that does not reach the market early.

The model developers illustrate how the effects described by the modelhave useful explicative power for competitive actions within the mainframecomputer industry in the late 1980s. Although it is not possible to specifi-cally identify parameter values and functional forms, the effects and thedirections of these major effects in the model are borne out in the empiri-cal data.

This is the only model included in this survey that includes game-theoreticconcepts. The bulk of product development process modelers do notinclude multiple firms to show how the decisions of one firm may affectthe choices of another firm. Game-theoretic modeling is a potentially



58 Nevins, J L and Whitney,D E Concurrent design of pro-ducts and processes: a strategyfor the next generation in manu-facturing McGraw Hill, NewYork (1989)59 AitSahlia, F, Johnson, Eand Will, P ‘Is concurrent engin-eering always a sensible prop-osition?’ IEEE Transactions onEngineering Management Vol 42No 2 (1995) pp 166–17060 Smith, R P and Eppinger,S D ‘Deciding between sequen-tial and concurrent tasks inengineering design’ ConcurrentEngineering: Research andApplications Vol 6 No 1 (1998)pp 15–25

fruitful area for product development, since many product developmentdecisions are strongly influenced by competitive actions.

2.5 Determining the amount of parallelismOne design management problem that has been attracting attention is theamount of parallelism that is appropriate during the design process. Recentwisdom indicates that parallelism or concurrency has significant advan-tages over a purely sequential process58. The models described below indi-cate that there are valid reasons for maintaining some amount of sequentialscheduling in the design process as a method to reduce costs and reduce thesize and complexity of the organization required to support design activity.

2.5.1 Parallel schedulingThe first model in this vein is one that examines the effects of parallelscheduling59. In this model there is a number of design tasks that need tobe completed, and there is an explicit underlying order of the design tasks.There is also uncertainty surrounding design tasks, such that if one of thedesign tasks fails to be completed successfully it will have to be repeated,along with tasks that would naturally follow the failed task. The basicassumptions of this model are based on general beliefs about how designprocesses occur, rather than any specific observations.

The advantage of doing tasks in parallel is that the design process can becompleted more quickly. The advantage of doing tasks in series is that thenumber of tasks that will require repetition is lessened, and therefore thedevelopment cost is lessened. The goal of the model is to determine howmuch parallelism is desirable, and whether minimizing development timejustifies an increase in development cost.

The model is presented in a general form, but the formal analysis is restric-ted to a more restricted version with identical tasks and limited task rep-etition. Because of the homogeneity of the developed model it is unlikelyit could be applied to practical design projects. Applying the more generalmodel would require more model development as well as the estimationof a large number of parameters concerning task cost, time and rep-etition probability.

2.5.2 WTM parallel/serial modelAnother model that has addressed the issue of how much parallelism isdesirable is the parallel-serial version of the WTM model60. The WTMmodel (as introduced in section 2.2 above) is extended to allow for sequen-tial 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.



61 Krishnan, V, Eppinger, S Dand Whitney, D E ‘A model-based framework to overlap pro-duct development activities’Management Science Vol 43 No4 (1997) pp 437–45162 Loch, C H and Terwiesch,C ‘Communication and uncer-tainty in concurrent engineering’Management Science (in press)

The subsequent set of tasks is then attempted, with iterative rework bothfor the later set as well as for earlier sets of tasks. The total developmenttime and total amount of engineering effort can be calculated based on theWTM model framework.

In addition to the WTM model assumptions, it must be assumed that thereis no change in model parameters as a function of how the tasks aresequenced, and there is no change in the product that is produced by thedesign process as a function of how the tasks are sequenced. Both of theseassumptions 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 poss-ible to collect, and the outcome of the model seems to match many meas-ures of credibility, such as primarily completing the product design and thegeneral parameters of manufacturing process design before doing detailedprocess design work.

2.5.3 Stage overlappingTwo related models are concerned with the role of stage overlappingbetween nominally sequential design stages61,62 (see Figure 5). Increasesin overlapping may arise from the early freezing of design parameters inan upstream stage. Increasing the amount of overlap has the potential toreduce the total time required to complete the design process. Increasingthe overlap may also lead to premature choice of design alternatives andassociated quality losses, or the creating of additional and expensiverework. These models are intended to illuminate this set of issues.

The models’ results are based on reasonable functional forms of qualityloss function and parameter change expressions. The models are able tocalculate minimum development time policies for identifiable data. Theyalso illustrate how one should attempt to identify parameters that could



Figure 5 Task overlapping options61

63 Harary, F, Jessop, W N,Stringer, J and Luckman, J ‘Analgorithm for project develop-ment’ Nature Vol 206 (1965)p 11864 Blandford, S and Hope, RP ‘Systematic methods for theproblem solving process withparticular reference to design’IEE Proceedings, Part A Vol 132No 4 (1985) pp 199–21265 Ramstro m, D and Rhen-man, E ‘A method of describingthe development of an engineer-ing project’ IEEE Transactionson Engineering ManagementEM- Vol 12 No 3 (1965) pp 79–8666 Morgan, J ‘A networkapproach’ Chartered MechanicalEngineer Vol 14 No 4 (1967)pp 170–172

and should be frozen early, in order to lessen development time withoutsacrificing product quality. The models are illustrated with examples fromthe automotive and electronics industries. The data were collected in retro-spect, but it is proposed that these data are typically available in manyinstances.

The models that address the parallelism/sequencing issues arise in animportant area of design process management. They indicate the likelytruth that limitations to complete parallelism are appropriate, and havebegun to construct useful decision aids that may have direct applicabilityfor design management.

2.6 Other issuesThe earliest attempts at process modeling did not focus on time as themost important process variable. They instead looked at various other for-malizable aspects of the design artifact. This subsection is intended toexamine several models that do not fit into any clear category, except thatnone of them explicitly considers time as a process variable.

One such modeling formalism is known as the AIDA (analysis of intercon-nected decision areas) model63,25,64. AIDA assumes that there is a numberof subproblems within every design problem, and every subproblem has avariety of possible solutions (see Figure 6). Some of the subsolutions willbe incompatible with solutions to other subproblems. If we know whatthese incompatibilities are, then it is possible to find feasible sets of sol-ution with no known incompatibilities.

The AIDA formalism describes a useful set of knowledge concerning thedesign process, that many design subcomponent decisions are interrelated.However, the lack of application of these methods in the literature leadsone to believe that there are difficulties in its applicability. It is possiblethat the amount of predictive knowledge concerning whether certain subso-lutions are incompatible exceeds the amount typically available at the timethat decisions are made, or collecting this information is prohibitive. Alter-natively, the interaction graph suggests that pairs of solutions may beincompatible, but in reality it may be triples of solutions that are incompat-ible, although any pair within the triple would be satisfactory.

Other formalisms examine how the sequences of decisions alter the designspace65,22,66. These models acknowledge that design is constituted of anumber of decisions, and each decision alters the decision space availablefor future decisions (see Figure 7). These models seem a good way todescribe design processes after they have occurred, but neither the authors



67 Tebay, R, Atherton, J andWearne, S H ‘Mechanical engin-eering design decisions:instances of practice comparedwith theory’ Proceedings of theInstitution of Mechanical Engin-eers Vol 198B No 6 (1984)pp 87–9668 Bretschneider, F and Lag-ger, H ‘Design-flow modelingand knowledge-based manage-ment’ Applied Artificial Intelli-gence Vol 6 No 1 (1992)pp 45–57

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 indus-trial design problem67, but again this is used for retrospective descriptionrather than as a predictive tool.

A more recent process model of design that does not address time is aPetri net model68. This model describes information flows in engineeringdesign using Petri nets. The advantages of Petri nets include their handlingof concurrency and iterative flows. The disadvantages of Petri net descrip-tions include the lack of useful measures of time, and emphasis on feasi-bility as the output measure of interest. Additionally, there is no weightingto the connections; all connections are implied to be of the same impor-tance. Furthermore, the complete structure of the project must be done inadvance if the model is to have any useful predictive utility. The proposershave not applied the modeling technique to an industrial problem.



Figure 6 AIDA options

graph25

3 DiscussionThere is no reason to believe that the existing models are sufficient andcannot be superseded. It is the goal of this paper to identify the state ofthe modeling art and to suggest metrics by which modeling efforts can andshould be judged. It remains the task of the community to find those modelsthat best fulfill the needs of importance, rigor, tractability, and applicability.

All of the models described in this paper meet the criterion of managerialimportance of the underlying issue. The models focus on development leadtime, development cost, product specifications, and other criteria, all ofwhich are indisputably of great significance in the product developmentprocess.

All of the models meet the criterion of rigor. These models are developedin an academic context and published in peer-reviewed outlets. The mode-ling process has therefore emphasized rigor (at the potential loss ofapplicability).

Computational tractability is not that difficult a hurdle for these modelingefforts. The model developers pay differing amounts of attention to



Figure 7 Design sequence chart67

tractability in the presentation of their model, but in general this is not acritical problem for this type of model. Although several of the modelsinvolve discrete optimization (and some are formally shown to be NP-hard), data are sufficiently difficult to come by that the run time is likelyto be manageable for realistic problems. Furthermore, optimal solutionsare not critical and heuristically good solutions will typically prove accept-able. If these models fail to be useful for large-scale systems, it is typicallydue to the lack of available data rather than due to computational tracta-bility.

Applicability is potentially the most significant criterion; there are multipleways that a model might fail to be applicable. A model will fail to beapplicable if it is predicated on the availability of information that is notreadily available. A model will fail to be applicable if the assumptions andsimplifications necessary for its construction do not match industrial prac-tice. Each of the models presented fails to one degree or another along theapplicability criterion. This is an area that future modelers should paygreater attention to if their work is to have practical significance.

Many of these models use iteration as a building block for mathematicalformalism. Iteration is used for two reasons: it is ubiquitous in engineeringpractice, and the repetition leads to the type of patterned behavior that isamenable to mathematical structuring.

Product development process modeling is in an earlier stage of develop-ment than modeling in other areas of management science. Product devel-opment is more difficult to model than production processes (the mostcommon type of application in the operations community). Because of agreater amount of variety in engineering practice, because of the lowernumber of repetitions, and because of the high level of human intervention,it is difficult to imagine that product development modeling will reach thelevel of sophistication and application that can be achieved in production.

Despite this shortcoming, there is the potential for great utility in productdevelopment modeling efforts. Because of the tremendous impact of designdecisions, any attempt to improve decision making will have great benefitfor those firms who are successful.

The efforts that have been made have created some potentially usefulmodeling frameworks. Because the instantiation of any model is processspecific, there is not one version of any process model that applies toall product development processes. The modeling methods, however, aresufficiently general that they can be applied to a wide variety of indus-trial situations.



These models are primarily developed in an academic context, rather thanby those who are engaged in design activities. The standards for academicmerit, such as mathematical elegance, worst-case computational tractabilityand empirically justified modeling assumptions, do not carry as muchweight with designers and their managers, who are more interested in prac-tical utility and relevance. The practical criterion is easier to state butharder to measure: is it useful? As we consider models from a utility pointof view we are swayed most strongly by the application of the model toreal problems. Unfortunately, often this type of application either is pro-prietary and therefore not presentable in the open literature, or comes onlyafter the primary model has been developed and published, such that publi-cation of the application is less likely in the academic press. Nevertheless,we suspect that most of these models have not been applied on real prob-lems in a manner that enabled action by important decision makers.

The methods described in this paper are associated with techniques that areamenable to computer analysis: mathematical algorithms and optimization.Since these models were developed for academic purposes no commercialsoftware exists for most of the models, and that which does exist is rela-tively crude and user-unfriendly. This is a barrier to wider use that willneed to be remedied if the models are to spread outside of the academiccommunity.

4 ConclusionThe field of product development process modeling is reaching a greaterdegree of maturity. There are a number of models that focus on manyinteresting and important process issues such as lead time, task schedulingand project decomposition. The empirical justification for these models isincreasing, although there is still room for more empirical and analyticalwork.

Standards for successful modeling should include both academic- and prac-titioner-oriented components. Without achieving the academic standards ofanalytical rigor there will be a general reluctance to believe these models.Without achieving the practitioner standards of ease of use and data avail-ability the ability to apply these models will be non-existent.



product development process modeling

Documents