The interfacebetween‘‘productdesignandengineering’’ and manufacturing:Areview of the literature and empirical evidence

8/12/2019 The interfacebetweenproductdesignandengineering and manufacturing:Areview of the literature and empirical

1/15

O.R. Applications

A dynamic model for managing overlapped iterativeproduct development

Jun Lin a,*, Kah Hin Chai a, Yoke San Wong b, Aarnout C. Brombacher c

a Department of Industrial and Systems Engineering, National University of Singapore, Singapore 119260, Singaporeb Department of Mechanical Engineering, National University of Singapore, Singapore 119260, Singapore

c Department of Technology Management, Eindhoven University of Technology, P.O. Box 513, 5600 MB Eindhoven, The Netherlands

Received 9 June 2006; accepted 13 December 2006

Available online 10 January 2007

Abstract

Intense competition in many industries impels firms to develop more products in less time. Overlapping of developmentactivities is regarded as one of the most promising strategies to reduce project cycle time. However, the gain from over-lapping must be weighed against the additional resource and time for rework. This paper presents a new product deve-lopment (NPD) process model, termed Dynamic Development Process Model (DDPM), for managing overlapped iterativeproduct development. We validated the model with data from a mobile phone development project. The DDPM wasemployed to identify appropriate policies for the overlapped iterative projects in the case study company. These identified

policies were implemented in the company and led to marked improvement in project performance, thus demonstrating theviability of our model. 2007 Elsevier B.V. All rights reserved.

Keywords: Project management; System dynamics; Concurrent engineering; Design iteration; Overlapping

1. Introduction

In recent years, product development undergoesnew trends such as distributed product develop-

ment, cross-functional team, and concurrent prod-uct development because of fragmented anddemanding markets, increasing technical intensity,and short product life cycles. These new trends have

increased the complexity and uncertainty of productdevelopment. The product development processesand management practices created for relativelylong product life cycle, stable market, and technol-

ogy-based competition are no longer capable ofproducing low cost and high quality products at arapid pace (Clark and Fujimoto, 1991; Williams,2005).

Therefore, improving product development per-formance is becoming increasingly important andchallenging. Part of the difficulty is caused by theinternal structure of the product development pro-cess (Ford and Sterman, 2003a,b; Roberts, 1974).Well-intentioned changes to the development process

0377-2217/$ - see front matter 2007 Elsevier B.V. All rights reserved.

doi:10.1016/j.ejor.2006.12.022

* Corresponding author. Tel.: +65 6516 1929; fax: +65 67771434.

E-mail addresses: [email protected], [email protected](J. Lin), [email protected] (K.H. Chai), [email protected](Y.S. Wong),[email protected](A.C. Brombacher).

European Journal of Operational Research 185 (2008) 378392

www.elsevier.com/locate/ejor
mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]


2/15

may cause severe unintended side effects (Repenning,2001; Chakravarty, 2001). For example, while con-current engineering may make downstream develop-ment activities begin earlier than otherwise, it mayalso increase the time and cost for cooperation and

rework. In order to systematically analyze the effectof different policies on NPD performance, variousmodels have been proposed by researchers (e.g., Roe-mer et al., 2000; Bhuiyan et al., 2004; Abdelsalam andBao, 2006).

Traditional project management models, such ascritical path method (CPM) and program evalua-tion and review technique (PERT) (Moder et al.,1983; Badiru, 1993; Golenko-Ginzburg and Gonik,1996), describe development processes with activityduration estimates and precedence relationshipsrepresenting the network of development activities.

However, these models ignore iterations or implic-itly incorporate iterations into duration estimates(Ford and Sterman, 2003a,b), limiting the capabilityof these scheduling techniques in modeling NPDprocesses.

Therefore, some models other than CPM/PERThave been developed to study iterative productdevelopment processes. Smith and Eppinger (1997)developed a sequential iteration model based onreward Markov chain. Design structure matrix(DSM) was used to describe rework probabilities

and task durations (Eppinger et al., 1994; Steward,1981). Several other researchers (e.g., Ahmadi andWang, 1999; Belhe and Kusiak, 1996) have devel-oped extensions by considering the dynamics ofrework probability and activity duration.Browningand Eppinger (2002)developed the first DSM-basedsimulation model which analyzed NPD iterations ina generalized project network. After that Cho andEppinger (2005) developed the second-generationDSM-based simulation model which accounts forresource constraints. Cooper (1980, 1993a,b,c) andseveral other researchers (Ford and Sterman, 1998;Repenning, 2001; Richardson and Pugh, 1981) builtsystem dynamics (SD) models to understand thecontinuous evolution of NPD projects. While thesemodels have advanced our understanding on thedynamics of iterative NPD projects, they do nottake into account the overlapping nature of devel-opment activities, which is a common practice toreduce project cycle time (Lawson and Karandikar,1994; Roemer and Ahmadi, 2004).

Overlapping refers to the NPD processes wherethe downstream activities start prior to the comple-

tion of the upstream activities. Previous empirical

studies showed that overlapping can reduce projectcycle time at the cost of additional developmenteffort (Smith and Reinertsen, 1995; Helms, 2004)and the effect of overlapping is closely related tothe uncertainty of development projects (Eisenhardt

and Tabrizi, 1995; Terwiesch and Loch, 1999). Basedon these studies some models on overlapped sequen-tial product development, where the upstream activ-ities are independent on the downstream activities,have been developed. Krishnan et al. (1997) deve-loped a framework for two overlapped sequentialactivities to determine the optimal number andtiming of information transfer. They showed thatupstream information evolution and down-stream sensitivity are the two properties affectingoptimal overlapping strategies.Loch and Terwiesch(1998)adapted the concepts of evolution and sensi-

tivity: upstream information evolution is definedas the continuous design modification process;downstream sensitivity represents the impact ofa modification on downstream rework. Based onthese concepts, they developed an analytical modeland derived the optimal communication strategiesfor overlapped sequential process. Roemer et al.(2000) analyzed the timecost trade-offs in multi-stage product development. Chakravarty (2001)studied the trade-offs between the overlapping riskand the project time saved. Some special cases were

analyzed to establish useful insights for sequentialand overlapped processes. Unlike previous researchwe developed a model for overlapped iterative prod-uct development, where downstream activities maydiscover upstream errors and give feedback to thecorresponding activities (Fig. 1). The extension fromsequential to iterative process makes it possible tosimulate and study the effect of overlapping for com-plex development projects.

To model and analyze overlapped iterativeproduct development we developed the DynamicDevelopment Process Model (DDPM) usingsystem dynamics (SD) methodology. Discrete event

a b1 2 3 4

1

2

3

4

1 2 3 4

1

2

3

4

Fig. 1. DSM representation of sequential and iterative processes.(a) Overlapped sequential product development. (b) Overlapped

iterative product development.

J. Lin et al. / European Journal of Operational Research 185 (2008) 378392 379


3/15

simulation model and continuous time model (sys-tem dynamics) are two methods commonly usedto simulate NPD process. The former assumes theproduct development process is composed of a finiteset of activities and information flow only exists at

the beginning or at the end of an activity. In con-trast, the SD approach to project managementtreats the process of each phase as continuous workflow. It is consistent with the assumption in theoverlapping models (e.g., Loch and Terwiesch,1998; Roemer et al., 2000; Roemer and Ahmadi,2004). Through building the relationship betweenwork flow and information flow, we simulate thecontinuous upstream information evolution and itseffect on downstream rework using SD approach.

The rest of this paper is organized as follows. InSection2, we develop the concepts ofRework due to

development errors and Rework due to corruption.According to our field study and literature review(e.g., Joglekar et al., 2001; Krishnan et al., 1997)of NPD process, these are the types of rework exist-ing in overlapped iterative product development. Inthe next section, we use these concepts to constructthe dynamic development process model, followedby the validation of DDPM in Section4. Then pol-icies for the overlapped iterative projects in a devel-opment company are analyzed based on our modelin Section5. The successful application of the pro-

posed new policies further validated our model.Conclusions are summarized in Section 6.

2. Rework due to development errors and corruption

We follow the information-based view of productdevelopment (Clark and Fujimoto, 1991) in whichindividual development activities are the informa-

tion-processing units that receive information fromtheir preceding activities and transform it into newinformation to be passed on to subsequent activi-ties. The information changes between activitiesare embedded in the tasks carried out. Each activityof the product development process is related to thedevelopment tasks such as customer specificationsat concept development phase, detailed engineeringdrawings at detail design phase, and part dimen-sions at pilot production phase. The ultimate objec-tive is to ensure these tasks are carried out correctly,at low cost and in short time. We describe and sim-

ulate the rework process in the form ofRework dueto development errorsand Rework due to corruption.

2.1. Rework due to development errors

Product development, even for derivative prod-ucts, is a process with much uncertainty. Conse-quently, many tasks are incorrectly done in thecompletion and rework processes. These tasks aretermed as Development Errors (DEs). Rework dueto development errors refers to rework or rectifica-

tion of DEs which are identified through reviewand testing activities.

Complete Tasks Correctly

Complete Tasks Wrongly Development ErrorsTasks Remaining

Discover DevelopmentErrors

Tasks-done-correctly

Redo Tasks correctly

Redo Tasks Wrongly

Tasks to be Reworked

Fig. 2. Rework due to development errors.

380 J. Lin et al. / European Journal of Operational Research 185 (2008) 378392


4/15

We illustrate the rework process using a stock andflow structure (Fig. 2). Stocks represent the accumu-lation of tasks and flows represent the rates of deve-lopment activities (Sterman, 2004). Tasks initiallyreside in theTasks Remaining(Tr) stock. As the pro-

ject begins and progresses, tasks correctly done flowinto the Tasks-done-correctly (Tc) stock while taskscontaining errors or defects add to theDevelopmentErrors stock. Development Errors may be identifiedby a testing activity and flow into the Tasks to beReworked stock. Therefore the total number ofDevelopment Errors decrease as some of them arecorrectly reworked. Because rework quality is usu-ally not perfect, tasks which are incorrectlyreworked flow back into the Development Errorsstock. Some of the reworked tasks in the Develop-ment Errorsstock may need to flow into this rework

cycle one or more times. When rework quality is low,this vicious rework cycle dominates the developmentprocess. According toCooper (1993a), A quality of0.20 will require five cycles of work and cost (fourfull rework cycles) to get it right (p. 18).

2.2. Rework due to corruption

Rework due to corruptionrefers to rework or rec-tification when the change of tasks in an upstreamphase corrupts the relevant tasks in the downstream

phases, whether the downstream tasks are done cor-rectly or not. In other words, some tasks need to bereworked because they start on incorrect informa-tion from upstream phases. We termed this phe-nomenon as Corruption.

Tasks corrupted are dependent on the tasksreworked of the upstream phase, the Dependenceof the development phases, and the progress of thedownstream phase (Tasks Done). The tasksreworked of the upstream phase are positivelyrelated to Rework due to corruption. More taskschanged inevitably mean that more tasks may bereworked in the downstream phases (Krishnanet al., 1997). Dependence represents the relationshipbetween the tasks corrupted in the downstreamphase and the fraction of the tasks changed in theupstream phase. It is also positively related to

Rework due to corruption. Tasks Done accounts forthe reason why more rework is needed in over-lapped NPD process than the rework in sequentialprocess. For traditional sequential product develop-ment process most of the Development Errorscan befound and resolved before the downstream activitiesstart (at that time Tasks Doneof downstream phaseis equal to zero and no Corruptionarise). For exam-ple, in a fully sequential process, pilot productiononly starts after detail design has been completedand most of the quality problems have been

Complete Tasks Correctly

Complete

Tasks

Wrongly Development ErrorsTasks Remaining

Corrupt DevelopmentErrors

Corrupt Tasks-done- correctly


Redo Tasks correctly

Redo Tasks Wrongly


Fig. 3. Rework due to corruption.



5/15

resolved. However, in practice, pilot productionusually starts before the upstream activities havebeen completed in order to reduce project cycletime. Therefore, in todays overlapped NPD pro-cess, Corruption accounts for a large portion of

rework and affects product development perfor-mance seriously (Krishnan et al., 1997).The stock and flow structure of Rework due to

corruption is shown in Fig. 3. Certain percentageof downstream tasks is completed based on wronginformation from Development Errors of upstreamphase. These tasks, together with other tasks, residein the Tasks-done-correctly stock and the Develop-ment Errors stock. Corruption occurs when DEsof an upstream phase are identified. The tasks asso-ciated withDEs of upstream phases leave the Tasks-done-correctly stock and the Development Errors

stock, and then flow into the Tasks to be Reworkedstock.

2.3. Example

Here we give a simple example to further illus-trate the rework process. As shown in Fig. 4, slotA and slot B are determined by four dimensions.These dimensions are derived in Phase 1 then theslots are fabricated inPhase2. The detailed develop-ment process can be described as follows:

(1) In the beginning, all of the dimensions residein Tasks Remaining 1 and the slots reside inTasks Remaining2.

(2) Assuming the development activity in phase 1is not perfect, Dimension 3 flows into theDevelopment Errors

1 stock. The other dimen-sions flow into the Tasks-done-correctly 1stock. The slots keep in Tasks Remaining2.

(3) Phase2 starts before the development error inPhase1 is identified and revised. Assuming thedevelopment activity inPhase2 is perfect,SlotA and Slot B are exactly fabricated accordingto the dimensions and flow into the Tasks-done-correctly 2 stock. The states of thedimensions are not changed.

(4) After that the error ofDimension3 is identifiedand revised. It is represented as Rework due to

development errorsin our model.(5) Since Slot B is determined by Dimension 3, it

needs to be revised accordingly. We term thistype of rework as Rework due to corruption.

3. Dynamic development process model

3.1. Stocks and flows

We combine Rework due to development errorsand Rework due to corruptionin one stock and flow

structure (Fig. 5). Four stocks and six flows are usedto represent the completion and rework processes.The stocks (Tasks Remaining (Tr), Tasks-done-cor-rectly (Tc), Development Errors (DEs), and Tasksto be Reworked(Ttr)) represent the sizes of the back-logs of tasks. The sizes of the stocks change due tothe flows related to development activities. InFig. 5,Complete Tasks Correctly (cc) and Complete TasksWrongly (cw) represent the completion activity;Testing Rate(gre) and Discover Development Errors(de) represent the testing activity; Redo Tasks Cor-rectly (rc) and Redo Tasks Wrongly (rw) representthe rework activity; Corrupt Tasks-done-correctly(kc) and Corrupt Development Errors (ke) representthe Corruption caused by upstream rework. There-fore the processes described in Section2can be rep-resented by the following differential equations (atthe start of a project, Tr(0) = 100%, and Tc(0),DEs(0), and Ttr(0) all equal zero):

d=dtTr cccw; 1

d=dtTc ccrckc; 2

d=dtDEs cwrw deke; 3

d=dtTtr deke kcrcrw: 4Fig. 4. Base rear of a mobile phone.



6/15

Tasks Remaining

eq_1


eq_2

Development Errors

eq_3

Complete Tasks

Correctly

eq_8

Complete Tasks

Wrongly

eq_9

Discover & Corrupt

Development Errors

eq_13 & eq_15


eq_4

Redo Tasks Wrongly

eq_18

Redo Tasks Correctly

eq_17

Completion Quality

Rework Quality

Tasks Done

eq_11

Tasks Done in

Upstream Phase

Testing Rate

eq_10

Average Rework Rate

Rework Rate

eq_16

Corrupt


eq_14

Testing Completed

eq_6

Completion

Rate

eq_7

Average Completion

Rate

Rework Rate of

Upstream Phase

Dependence

Testing Quality

Testing Rate of

Downstream Phase

Testing Quality of

Downstream Phase

Discovery Rate

eq_12

Average Testing Rate

Precedence

Constraints for

Completion

Precedence

Constraints for Testing

Testing Remaining

eq_5

Fig. 5. Dynamic development process model (DDPM).



7/15

Testing process is represented by two stocks andone flow (Fig. 5). Tested tasks leave the TestingRemaining(Gr) stock, pass through the Testing Rate(gre), and then accumulate in the Testing Completed(Gc) stock (at the start of a project Gr(0) = 100%

andG

c(0) = 0). Mathematicallyd=dtGr gre; 5

d=dtGc gre: 6

We formally model the flows related to comple-tion, testing, corruption, and rework with the equa-tions in the rest of this section. The inputparameters needed to build the model are listed inTable 1and shown as diamonds inFig. 5. The italicfont shown in Fig. 5 represents the parameters ofupstream and downstream phases. Tasks andDeve-

lopment Errors are in percentage values in ourmodel. For example at the start of a project allthe development tasks reside in theTasks Remainingstock, so that Tr(0) is 100%.

3.2. Completion

Three development activities drive the flows oftasks in NPD process: completion, rework and test-ing. The progress rate for each of three developmentactivities is the lesser of the average developmentrate and the rate allowed by tasks available. There-fore theCompletion Rate(cre) is the minimum of theAverage Completion Rate (Ac), and the number ofTasks Remaining (Tr) divided by the time step (s)of the simulation model when Tasks Done inUpstream Phase (Tdu) is greater or equal to Prece-dence Constraints for Completion (Pc). OtherwiseCompletion Rateequals zero. According toComple-tion Quality (Cq), Completion Rate is decomposedinto Complete Tasks Correctly and Complete Tasks

Wrongly. These conditions can be represented bythe following equations:

cre IF Tdu P Pc THEN

MinAc; Tr=s ELSE 0; 7

cc cre Cq; 8

cw cre 1Cq: 9

3.3. Testing

Similar to completion rate, Testing Rate is equalto the minimum of the Average Testing Rate (Ag)and the number ofTesting Remaining (Gr) dividedby the time step if Tasks Done (Td) is greater orequal to Precedence Constraints for Testing (Pg).Otherwise it is zero. Rework arises when the Devel-opment Errorsare found by a testing activity. As it is

typical that we cannot find all the DevelopmentErrors through a single round of testing, DEs arelikely to be discovered by subsequent testing activi-ties. We model Discovery Rate (dre) as the sum ofthe product of Testing Quality (Gq) and TestingRate from the current testing activity (denoted bym) to the last testing activity of the project (denotedby n). Discover Development Errors(de) is the resultof Discovery Rate multiplied by DevelopmentErrors. Mathematically

gre IF Td P Pg THEN

MinAg;Gr=s ELSE 0; 10Td TcDEs; 11

dre Xn

im

Gqi grei ; 12

de dreDEs: 13

3.4. Corruption

When Development Errors of an upstreamphase are found and corrected after starting the

Table 1Model parameters and performance measures

Definition

Parameters

Precedence constraints The condition to start an activityAverage activity rate The average rate of completing a development activityCompletion/rework quality The percentage of tasks correctly doneTesting quality The percentage of Development Errors identified in the testing processDependence The percentage of downstream tasks will be affected by one percentage of upstream changes

Measures of project performance

Project quality The percentage of Development Errorsremained when the overall project is completedCycle time The duration from the start to the end of a project

Development effort The tasks completed and reworked from the start to the end of a project



8/15

downstream activities, some tasks are corrupted.The amount of the tasks corrupted is the productof upstream modifications,Dependence(D) betweendevelopment phases, and Tasks Done in the down-stream phase (Loch and Terwiesch, 1998; Carras-

cosa et al., 1998; Roemer and Ahmadi, 2004). InDDPM,Rework Rate of Upstream Phase(rru) corre-sponds to upstream modifications. Tasks Done indownstream phase is the sum ofDevelopment Errors(DEs) and Tasks-done-correctly(Tc). Consequently,Corrupt Tasks-done-correctly is the product ofRework Rate of Upstream Phase, Dependence, andTasks-done-correctly. Similarly Corrupt Develop-ment Errors is the product of Rework Rate ofUpstream Phase, Dependence, and DevelopmentErrors. Note that corruption only happens whenTasks-done-correctly and Development Errors are

not equal to zero. These relationships can be pre-sented as follows:

kc rruDTc; 14

ke rruDDEs: 15

3.5. Rework

Rework Rate(rre) is formulated similarly toCom-pletion Rate. It is the lesser of the Average ReworkRate(Ar), and the number ofTasks to be Reworked

(Ttr) divided by the time step. Rework Rateis com-posed of Redo Tasks Correctly and Redo TasksWrongly. Redo Tasks Correctly is the product of

Rework Rate and Rework Quality(Rq). Redo TasksWronglyis the rate of generating wrong tasks in therework process. These relationships are representedby the following equations:

rre MinAr; Ttr=s; 16

rc rre Rq; 17

rw rre 1Rq: 18

4. Validation of the model

4.1. Base case

The company where the case study was con-ducted is a design company in Shanghai, China.The company designs mobile phones according tomarket and technology trends and sells the designto manufacturers, or according to customer require-ments when approached by a specific customer. Inorder to reduce time-to-market, overlapped iterativedevelopment process is implemented in the com-pany: downstream phase starts before the tasks inupstream phase are frozen; upstream developmenterrors are continuously rectified according to thefeedback information from downstream phases.

The project of a derivative product, which isdeveloped based on a relatively mature architecture,

is used to validate DDPM. The project started inSeptember 2003 and was completed in May 2004.As shown in Fig. 6, the development process of

Fig. 6. DSM representation of the information flows in the mobile phone development project.



9/15

the project involves three development phases andeach phase is composed of completion, rework,and testing activities:

(1) Concept development: Based on the require-

ments provided by the customer, the designcompany studied the feasibility of the productconcept, refined the requirements, and definedthe main features and specificationsof the prod-uct. This phase is composed of four develop-ment activities: completion activity of conceptdevelopment, rework activity of concept devel-opment, 3D model review (RC1in Fig. 6), anddummy sample review (RC2).

(2) Detail design:This phase constitutes the detaildesign of mechanical and electronic compo-nents. After the first prototype was completed,

engineers reviewed its mechanical and elec-tronic performance to ensure compliance withinitial requirements (RD1), followed bydetailed testing (TD1). In parallel to TD1, thecompany began making more prototypes tofurther test the mechanical and electronic per-formances of the product (TD2).

(3) Pilot production: Pilot Production is the stagewhere the product design is realized as a phys-ical product in a manufacturing plant with

further testing implemented to improve thequality of the product. Half-way through thedetail design phase, the engineers began tofabricate moulds and produce products fortesting. Normally, 100500 sets of mobile

phones are produced per batch. After that,the engineers started to review and solve thequality problems found in the production pro-cess (RP1). At the same time, quality engineerstested the product quality and provided areport to the designers (TP1). For mobilephone development, several rounds of pilotproduction are needed to identify potentialquality problems.

4.2. Data collection

In order to validate our model we collecteddetailed data based on historical records, such asproject schedule and the quality problems foundand solved over the entire period of the project.These data were double checked together with theengineers who are familiar with this project. TheAverage Completion Rate, Average Testing Rate,Completion Quality, and Precedence Constraintscan be directly accessed from the historical data(Ford and Sterman, 1998; Black and Repenning,

Table 2Model inputs for the mobile phone development project

Completion and rework activities Precedence constraints Rate (per day) Quality (%)

(a) Parameter values of completion and rework activities

Completion activity of concept development 1/5 79.73Rework activity of concept development 1/25 85.71Completion activity of detail design RC2finished 1/14 63.01Rework activity of detail design 1/13 83.48Completion activity of pilot production TD1finished 1/34 78.34Rework activity of pilot production 1/35 83.41

Testingactivities

Precedence constraints Rate(per

day)

Testing quality for each phase

Concept development

(%)

Detail design

(%)

Pilot production

(%)(b) Parameter values of testing activities

RC1 Concept development initiallycompleted

2 50.00

RC2 RC1finished 2 5.41 RD1 Detail design initially completed 4 14.29 43.28 TD1 RD1finished 1/4 50.00 62.02 TD2 RD1finished 1/10 28.57 28.28 RP1 Pilot production initially completed 1 41.30 46.24TP1 Pilot production initially completed 1/14 31.72 31.73

(c) Dependency

Dependency between concept development and detail design 2.13

Dependency between detail design and pilot production 1.63



10/15

2001). The other parameters are calculated usingfollowing equations: Average Rework Rate is theresult ofTasks Reworkeddivided byRework Dura-tion; Rework Quality equals Tasks CorrectlyReworkeddivided byTasks Reworked;Testing Qual-ity

equals Development Errors Found

divided byDevelopment Errors Exist (Cooper, 1993a); Depen-dence equals Tasks Corrupteddivided by the prod-uct ofUpstream Tasks Reworkedand Tasks Done.The parameter values of the project are listed inTable 2.

4.3. Model testing

Behavior-reproduction tests (Sterman, 2004) areused to validate the model by comparing simulation

results with field data for the mobile phone develop-ment project. Field data and model output for thethree development phases are shown inFig. 7.

The behavior patterns of our model for the threedevelopment phases follow closely the patterns of

the field data. As shown in Table 3, the errors forthree phases are reasonable (R2 > 97%, MAE/Mean < 3%, and RMSE/Mean < 4%). It is impor-tant to know the sources of errors as well as thetotal number of errors. The Theil inequality statis-tics (Sterman, 1984; Theil, 1966) decompose themean square error (MSE) into three components:Bias, Unequal Variation, and Unequal Covaria-tion. Partitioning the MSE using the Theil inequal-ity statistics reveals MSE dominated by UnequalCovariance and Unequal Variation. As the errors

Field Data of Detail Design

Model Output of Detail Design

0 20 40 60 80 100 120 140 160 180

Working Days

Working Days Working Days

Field Data of Pilot Production

Model Output of Pilot Production

0.00%

20.00%

40.00%

60.00%

80.00%

100.00%

0 20 40 60 80 100 120 140 160 180 0 20 40 60 80 100 120 140 160 180

TasksCorrectlyDone(%)

0.00%

20.00%

40.00%

60.00%

80.00%

100.00%


0.00%

20.00%

40.00%

60.00%

80.00%

100.00%


Field Data of Concept Development

Model Output of Concept Development

Fig. 7. Reference mode and simulation results.



11/15

for our model are small and Bias only accounts fora small part of MSE, this model should be accu-rate enough for us to show the behavior patternsof overlapped iterative development projects andstudy the effect of different policies on projectperformance.

5. Policies analysis

In order to check the applicability of our modelfor policy analysis, we continuously collected andanalyzed the data from the projects of the designcompany. In 2004 we studied the product develop-ment process in the company and collected relevantdata for our model. Alternative policies were ana-lyzed subsequently. In early 2005 new policies wereimplemented. The results of the new policies were

analyzed in 2006.We assume that the development projects are

completed when they achieve the required quality,with 98% of tasks correctly done (which is the stan-dard currently used in the company), and try toreduce the project cycle time and development effortwith different policies for different types of projects.Typically, there are three types of development pro-

jects in the company: projects with new architectureand new circuit board (Type 1 project), projectswith mature architecture and new circuit board(Type 2 project), and projects with mature architec-ture and mature circuit board (Type 3 project).Each of these three types of projects has differentdevelopment qualities, particularly in concept devel-opment phase and detail design phase. Generallythe development qualities are better for projectswith mature architecture and circuit board. Thedata used in this section were collected on sixprojects completed in 2004 (two projects for eachtype). All of the data are validated by experi-enced engineers from Industrial Design, MechanicDesign, Hardware, Quality Control, and Produc-

tion departments.

5.1. Overlapping between detail design and pilot

production

As shown in Fig. 6, the initial completion ofdetail design generates preliminary information forpilot production and then the preliminary informa-tion will be modified through testing and rework.Pilot production can start when preliminary infor-mation is available. However it will incur Reworkdue to corruption. Pilot production can also startafter most of the modifications are done. Thereforefour alternative overlapping policies are considered:start pilot product after TD2 (represented as over-lapping policy 1 (O1) inFig. 8), start pilot produc-tion after TD1 (O2), start pilot production afterRD1 (O3), and start pilot production immediatelyafter detail design (O4). In 2004, the standard pro-cess for the company was to start pilot production

afterTD1. However, is this level of overlapping suit-able for all of the projects in the company? In orderto answer it, we tested the influence of differentoverlapping policies for three types of projects. Ascan be seen in Fig. 8, more rework occurs as thedegree of overlapping increases. This may explainwhy overlapped product development does notalways work as predicted. There is a trade-off

Table 3Error statistics for assessing model fit to data

Phase n R2 (%) MAE/mean(%)

RMSE/mean(%)

Thiel inequality statistics

Bias (%) Unequalvariation (%)

Unequalcovariance (%)

Concept development 174 97.34 0.68 2.39 2.74 58.14 39.12Detail design 158 98.88 2.03 3.65 3.13 60.26 36.61Pilot production 129 99.50 1.97 3.10 32.14 13.55 54.31

0.4

0.9

1.4

1.9

150 175 200 225 250 275 300

Working Days

ReworkedTasksofPilotProduction

(%)

Type 1 project

Type 2 project

Type 3 project

O1

O2

O3

O4

O1O2

O3

O4

O1

O2

O3O4

Fig. 8. Project performance with different levels of overlapping

between detail design and pilot production.



12/15

between the time reduced because of overlappingand the cost and time increased due to rework.

Rework changes more significantly in Type 1project than the change in the other projects, asindicated by the steeper slope of the line. In 2004,O

2 was implemented in the company. This policyis suitable for Type 1 project, because the applica-tion of O3 or O4 will increase rework seriously.However, O3 is better for Type 2 and Type 3 pro-

jects, because project cycle time can be reduced withlittle expense of rework. Theoretically, O4 can alsobe implemented for projects with mature architec-ture. However, according to the experience of theengineers from the company, O4 may increase therisk of damaging the hard mould for pilot produc-tion, causing a tremendous increase in cost. Forexample, the size of handset housing affects a large

number of related parts, and a change of it meansbuilding new hard moulds. Pilot production shouldonly start after important specifications have beenproperly reviewed and confirmed. Consequently,the overlapping policy should be adjusted: O2 canbe used for type 1 project, and O3 can be appliedfor type 2 and type 3 projects.

5.2. Overlapping in pilot production

For mobile phone development, usually several

(24) rounds of pilot production are needed. In2004, the policy for the company was to start thenext round of pilot production immediately afterRP1ifTP1had not begun. For example, in the basecase RP1 was finished in 6 days before TP1 started.Using the old policy, engineers started the secondround of pilot production after RP1. Some engineersquestioned whether it was worthwhile to do morerounds of pilot production to reduce the projectcycle time because pilot production is costly (as typ-ically 100500 sets of mobile phones were produced

just for testing). It seems obvious that this policycan reduce the project cycle time. However, thesimulation results show that this policy not onlyincreases the cost but also increases the project cycle

time (Table 4). The policy aims to reduce the projectcycle time but in reality the opposite happensbecause quality problems found in TP1 cannot becorrected in the second round of pilot production.Therefore more rounds of pilot production may be

needed to achieve the required project quality. Con-sequently, the suggested new policy is that the nextround of pilot production should start after bothRP1and TP1, whether the projects are urgent or not.

5.3. Evaluating activity criticality

The investment policies can be evaluated byactivity criticality, which is the sensitivity of projectperformance to the investment for improving activ-ity quality and duration. The investment needed andthe resulting activity quality and duration could beestimated according to the experience of the manag-ers or by benchmarking. Based on these data we canre-analyze the project performance and compare theinvestment with the performance improved.

When we were doing the case study in the com-pany, the managers were considering introducing aprototyping machine. Prototypes are used to findand solveDevelopment Errorsof detail design beforeexpensive pilot production starts. The first proto-type was outsourced at that time and it took aboutone week. The rest of the prototypes were done

through soft tooling, which was time consuming.The new prototyping machine can reduce by 2working days for the first prototype, and 21 work-ing days for the other prototypes, but it requires alarge amount of financial investment. In order tostudy if it was worthwhile to acquire this newmachine, we compared the performance of the pro-

jects using current practice with the performanceusing the new prototyping machine (Table 5). Itturned out that the reduction of 23 working dayswith the use of the new machine could only reduce

the project cycle time by about 2%. However, itcould significantly reduce rework by about 7.6%on average. The reason is that TD1 and TD2 arenot in the critical path of the project. These are

Table 4Project performance with different levels of overlapping in pilot production

Developmentprojects

Reworked tasks of pilot production Project cycle time

Currentpolicy (%)

Newpolicy (%)

Performanceimprovement (%)

Current policy(working day)

New policy(working day)


Type 1 project 142.74 150.82 5.66 265.25 234.75 11.50Type 2 project 60.87 61.02 0.25 184.58 175.13 5.12

Type 3 project 50.14 50.26 0.24 176.58 165.92 6.04



13/15

the activities to find the quality problems of conceptdevelopment and detail design. Finding the qualityproblems earlier can reduce the rework caused bycorruption in the project. According to the simula-tion results, the number of projects done in the com-pany each year, and the cost of each project, wefound that the cost saving is greater than the invest-

ment involved. We thus suggested the company toinvest in the prototyping machine.

5.4. Application result

We simulated the product development processagain based on the new policies for overlappingand investment. The result shows that if the newoverlapping policies are adopted and the prototyp-ing machine is invested, the company can reducethe project cycle time by about 12% without signif-

icantly affecting the percentage of reworked tasks.All of the policies discussed above were accepted

by the company, because we not only analyzed theeffect of different policies, but also explained theroot causes of the results. Comparing the projectscompleted before June 2004 to the projects finishedin the first half of the year 2005 when the new pol-icies had been implemented, we found that the aver-age project cycle time was reduced by about 30%.Except for the new policies mentioned above, theaverage rate of pilot production and testing (TD1,TD2

, and TP1

) was improved because of the intro-duction of new technologies and the adoption ofother development policies. There is no significantdifference between the qualities of developmentactivities for the projects developed in 2004 and in2005. The reason is that the experience of the engi-neers is not significantly changed from 2004 to 2005.Some experienced engineers left the company andrecruits were employed. The average working expe-rience of the engineers was about 5 years. Using thenew input data, the model output matched closelywith the average project cycle time of the projects

finished in 2005. It further validated our model

and showed that DDPM is a useful tool for analy-zing overlapped iterative product development.

6. Conclusion

The ability to expeditiously develop products has

been accredited as a critical factor for the survival ofmany companies (Carrillo and Franza, 2006). Over-lapping of development activities is commonlyregarded as the most promising strategy to reduceproject cycle time. However, overlapping interre-lated activities based on preliminary informationcan be costly (Roemer et al., 2000). Therefore, someresearchers have developed models to analyze over-lapped sequential product development process (e.g.Krishnan et al., 1997; Loch and Terwiesch, 1998;Roemer et al., 2000). The effect of the upstream

information evolution on the rework of the down-stream phase is studied in these models. We extendprevious research by developing a SD model foroverlapped iterative product development.

The model presented in this paper has high facevalidity (Law and Kelton, 1991; Smith and Mor-row, 1999) because it is developed based on theaccepted framework for overlapped product devel-opment (e.g., Krishnan et al., 1997; Loch and Ter-wiesch, 1998; Roemer et al., 2000), in depth casestudy of the modeled system, and system dynamicsmethodology (Black and Repenning, 2001; Cooper,1980; Ford and Sterman, 1998; Joglekar and Ford,2005; Williams et al., 1995, 2003) which has beentheoretically and practically validated. Further-more, we validated the model through comparingthe simulation results with real data of a projectdone in a mobile phone development company.The successful application of the new policiesfurther implies the usefulness of our model.Although more detailed examination may beneeded, the current level of validity is comparablewith models in the related literature (Abdelsalam

and Bao, 2006; Browning and Eppinger, 2002;

Table 5Project performance with original and improved activity duration

Developmentprojects

Reworked tasks of pilot production Project cycle time

Currentmachine (%)

Newmachine (%)


Current machine(working day)

New machine(working day)


Type 1 project 142.74 132.44 7.22 265.25 259.58 2.14Type 2 project 60.87 55.92 8.13 184.58 180.33 2.30Type 3 project 50.14 46.37 7.52 176.58 173.25 1.89



14/15

Cho and Eppinger, 2005; Ford and Sterman, 1998;Smith and Morrow, 1999).

The contribution of this study is threefold. First,development projects are usually complex and itera-tive. Although previous research has advanced our

understanding of overlapped sequential process,there is still a lack of tools to study overlapped anditerative projects. Our simulation model providesmanagement a useful tool to predict the effect of dif-ferent overlapping policies on project performancefor overlapped iterative product development. Sec-ond, the introduction of new technologies and/ornew machines can help to reduce the time requiredto complete various development activities andreduce the probability of making errors. Our modelprovides a way to evaluate these possibly substantialcapital investments by estimating the resulting

improvement of project performance. Third, ourcase study and simulation results show that someinsights drawn by previous models for overlappedsequential process are still applicable in overlappediterative product development: (1) Overlapping pol-icies are significantly affected by project uncertainty,thus different overlapping strategies can be appliedfor the projects with different uncertainty levels. (2)The total amount of downstream rework can bereduced by increasing evolution speed, which isachieved through increasing testing rate in our case.

Several aspects of the model presented in thispaper merit further examination. Firstly, more casesare needed to validate the model. Future research cantest the broader application of the DDPM by apply-ing it to other overlapped iterative NPD projects.Such tests will provide a basis for the abstraction ofmore general dynamic lessons for development pro-cess improvement. Secondly, the effective allocationof development resources, such as manpower andequipment, is difficult due to the complexity of over-lapped product development process. Therefore, ourmodel may be further developed to analyze resourceallocation policies for overlapped iterative NPD pro-

jects. Finally, overlapping development activitiesand spending resource for the rework for one projectinevitably causes delay in other projects. We mayneed to extend our model to explore suitable policiesfor managing multiple projects since it has becomemore and more important.

References

Abdelsalam, H.M.E., Bao, H.P., 2006. A simulation-based

optimization framework for product development cycle time

reduction. IEEE Transactions on Engineering Management53 (1), 6985.

Ahmadi, R., Wang, H., 1999. Managing development risk inproduct design processes.Operations Research 47 (2), 235246.

Badiru, A.B., 1993. Quantitative Models for Project Planning,Scheduling, and Control. Quorum Books, Westport, CT.

Belhe, U., Kusiak, A., 1996. Modeling relationships among designactivities. Journal of Mechanical Design 118 (4), 454460.

Bhuiyan, N., Gerwin, D., Thomson, V., 2004. Simulation of thenew product development process for performance improve-ment. Management Science 50 (12), 16901703.

Black, L.J., Repenning, N.R., 2001. Why firefighting is neverenough: Preserving high-quality product development. Sys-tem Dynamics Review 17 (1), 3362.

Browning, T.R., Eppinger, S.D., 2002. Modeling impacts ofprocess architecture on cost and schedule risk in productdevelopment. IEEE Transactions on Engineering Manage-ment 49 (4), 428442.

Carrascosa, M., Eppinger, S.D., Whitney, D.E., 1998. Using thedesign structure matrix to estimate product development time.

ASME Design Engineering Technical Conferences, Atlanta,GA.Carrillo, J.E., Franza, R.M., 2006. Investing in product devel-

opment and production capabilities: The crucial linkagebetween time-to-market and ramp-up time. European Journalof Operational Research 171 (2), 536556.

Chakravarty, A.K., 2001. Overlapping design and build cycles inproduct development. European Journal of OperationalResearch 134 (2), 392424.

Cho, S., Eppinger, S.D., 2005. A simulation-based process modelfor managing complex design projects. IEEE Transactions onEngineering Management 52 (3), 316328.

Clark, K.B., Fujimoto, T., 1991. Product Development Perfor-mance Strategy, Organization and Management in the World

Auto Industry. Harvard Business School Press, Boston, MA.Cooper, K.G., 1980. Naval ship production: A claim settled and a

framework built. Interface 10 (6), 2036.Cooper, K.G., 1993a. The rework cycle: Benchmarks for the

project manager. Project Management Journal 24 (1), 1722.Cooper, K.G., 1993b. The rework cycle: How projects are

mismanaged. PMNETwork (February), 57.Cooper, K.G., 1993c.The reworkcycle: Howit reallyworks. . . and

reworks. . .. PMNETwork (February), 2528.Eisenhardt, K.M., Tabrizi, B.N., 1995. Accelerating adaptive

processes: Product innovation in the global computer indus-try. Administrative Science Quarterly 40, 84110.

Eppinger, S.D., Whitney, D.E., Smith, R.P., Gebala, D.A., 1994.A model-based method for organizing tasks in productdevelopment. Research in Engineering Design 6 (1), 113.

Ford, D.N., Sterman, J.D., 1998. Dynamic modeling of productdevelopment processes. System Dynamics Review 14 (1), 3168.

Ford, D.N., Sterman, J.D., 2003a. Overcoming the 90% syn-drome: Iteration management in concurrent developmentprojects. Concurrent Engineering: Research and Applications11 (3), 177186.

Ford, D.N., Sterman, J.D., 2003b. The liars club: Concealingrework in concurrent development. Concurrent Engineering:Research and Applications 11 (3), 211219.

Golenko-Ginzburg, D., Gonik, A., 1996. On-line control modelfor cost simulation network projects. Journal of the Opera-

tional Research Society 47 (2), 266283.



15/15

Helms, R., 2004. Framework for releasing preliminary informa-tion in product development. Advanced Engineering Infor-matics 18, 231240.

Joglekar, N.R., Ford, D.N., 2005. Product development resourceallocation with foresight. European Journal of OperationalResearch 160 (1), 7287.

Joglekar, N.R., Yassine, A.A., Eppinger, S.D., Whitney, D.E.,2001. Performance of coupled product development activitieswith a deadline. Management Science 47 (12), 16051620.

Krishnan, V., Eppinger, S.D., Whitney, D.E., 1997. A model-based framework to overlap product development activities.Management Science 43 (4), 437451.

Law, A.M., Kelton, W.D., 1991. Simulation Modeling andAnalysis, second ed. McGraw-Hill, New York.

Lawson, M., Karandikar, H.M., 1994. A survey of concurrentengineering. Concurrent Engineering: Research and Applica-tions 2 (1), 16.

Loch, C.H., Terwiesch, C., 1998. Communication and uncer-tainty in concurrent engineering. Management Science 44 (8),10321048.

Moder, J.J., Phillips, C.R., Davis, E.W., 1983. Project Manage-ment with CPM, PERT, and Precedence Diagramming. VanNostrand Reinhold, New York.

Repenning, N.P., 2001. Understanding fire fighting in newproduct development. The Journal of Product InnovationManagement 18, 285300.

Richardson, G.P., Pugh III, A.L., 1981. Introduction to SystemDynamics Modeling with Dynamo. MIT Press, Cambridge,MA.

Roberts, Edward B., 1974. A simple model of R&D projectdynamics. R&D Management 5 (1).

Roemer, T.A., Ahmadi, R., 2004. Concurrent crashing andoverlapping in product development. Operations Research 52(4), 606622.

Roemer, T.A., Ahmadi, R., Wang, R.H., 2000. Timecosttradeoffs in overlapped product development. OperationsResearch 48 (6), 858865.

Smith, R.P., Eppinger, S.D., 1997. Identifying controllingfeatures of engineering design iteration. Management Science43 (3), 276293.

Smith, R.P., Morrow, J.A., 1999. Product development processmodeling. Design Studies 20 (3), 237261.

Smith, P.G., Reinertsen, D.G., 1995. Developing Products in Halfthe Time, second ed. Van Nostrand Reinhold, New York.

Sterman, J.D., 1984. Appropriate summary statistics for evalu-ating the historical fit of system dynamics models. Dynamica10 (2), 5166.

Sterman, J.D., 2004. Business Dynamics: Systems Thinking andModeling for a Complex World. Irwin/McGraw-Hill, Boston.

Steward, D.V., 1981. The design structure system: A method formanaging the design of complex systems. IEEE Transactionson Engineering Management 49 (4), 428442.

Terwiesch, C., Loch, C.H., 1999. Measuring the effectiveness ofoverlapping development activities. Management Science 45

(4), 455465.Theil, H., 1966. Applied Economic Forecasting. North HollandPublishing Company, Amsterdam.

Williams, T., 2005. Assessing and moving on from the dominantproject management discourse in the light of project overruns.IEEE Transactions on Engineering Management 52 (4),497508.

Williams, T., Eden, C., Ackerman, F., Tait, A., 1995. The effectsof design changes and delays on project cost. The Journal ofthe Operational Research Society 46 (7), 809818.

Williams, T., Ackermann, F., Eden, C., 2003. Structuring a delayand disruption claim: An application of cause-mapping andsystem dynamics. European Journal of Operational Research148, 192204.


Documents

The interfacebetween‘‘productdesignandengineering’’ and manufacturing:Areview of the literature and empirical evidence