Engineering Change Request Management in a New Product Development Process

Transcription

1 Pubkished in European Journal of Innovation Management, Vol 9, No 1, pp5-19 Engineering Change Request Management in a New Product Development Process Nadia Bhuiyan Mechanical and Industrial Engineering, Concordia University Montreal, Canada H3G 1M8 Tel: , Fax: bhuiyan@alcor.concordia.ca Gregory Gatard Mechanical Engineering, INSA Rouen, Seine Maritime, France ggatard@hotmail.com Vince Thomson Mechanical Engineering, McGill University Montreal, Canada, H3A 2K6 Tel: , Fax: vince.thomson@mcgill.ca

2 Engineering Change Request Management in a New Product Development Process Structured Abstract Category: Research paper Purpose of this paper The objective of this research was to compare the behavior of two methods of managing an engineering change request (ECR) process, viz., perform changes as they occur or in a batch. Design/methodology/approach This comparison was accomplished by creating a computer model of a new product development (NPD) process and simulating ECR management. The model connects process design and process characteristics (teamwork, parallel activities) to process outcomes (development time, effort). The first method executes the ECR promptly and the rework is done as soon as the ECR is initiated. In the second method, ECRs are batched; in other words, a number of them are accumulated, and processing of the ECRs takes place when a batch of a certain size has accumulated. Thus, the change requests are grouped into a batch, and then, the section(s) of the process to effect the change(s) is (are) reworked. Findings Batching ECRs was found to be superior to doing them one at a time. Research limitations/implications Future work should focus on refining the computer model and differentiating ECRs by assigning priorities to incoming ECRs. Practical implications For product development managers, processing ECRs in batches is preferable than attending to them on an individual basis. Nevertheless, in some situations ECRs require immediate attention. A mechanism will always be needed to deal with situations directly. Also, in terms of batching, ECRs could be processed in groups on a periodic basis. Periodically performing ECRs due to new design versions or prototypes in a timely manner is a good compromise between a random batch mode and doing them individually. What is original/value of paper The paper shows that batch processing is superior to executing ECRs promptly as they are received. This result has been shown through the use of a computer model of NPD. To the authors knowledge, no other studies have used computer modeling to study this problem. Keywords: engineering change, new product development 1

3 Introduction In companies that design and produce complex products, especially custom products, changes and modifications often take place in the design of the product as it evolves. Many of these changes are formally initiated by the customer as new requirements, or by the company as modified specifications or manufacturing changes. These requests, called Engineering Change Requests (ECRs), may occur before, during or after production. Typically, the later they occur, the more significant the time and effort needed to implement them (Pikosz and Malmqvist, 1998, Reidelbach, 1991). Changes can also occur during a product s use due to design errors, alternatives for replacement parts, or modifications for improvement towards the end of the life of the product. Implementing ECRs affects several functions across a company, such as engineering, sales, manufacturing, purchasing, inventory control, accounting, etc. With time to market being a key competitive factor, it is desirable to quickly and accurately process ECRs. Furthermore, it can be a costly process due to possible scrap, delays, new purchases, replacement of components in inventory, etc. (DePrima, 1982). How well a company responds to a customer or company-driven change often determines whether a new product is delivered on time and at a profit. Clearly, ECRs need to be well controlled and implemented to minimize time delays and costs. In the research reported in this paper, an ECR process was modeled within a new product development (NPD) process using a stochastic computer model, and the behavior of two different methods of managing the ECR process was studied. The reasons why ECRs occur were not of concern in our study; only management mechanisms to lessen their impact were considered. The organization of the paper is as follows. Section 1 highlights related work. In Section 2, the ECR process is described, while Section 3 describes the NPD simulation model. Section 4 discusses how an ECR process was built into the NPD model. The results are presented in Section 5, and finally, discussion and conclusions are given in the last section. Related Work Little work has been done on ECR process management. The studies on ECRs done to date have predominantly focused on computer-based tools for analyzing ECR problems, or on qualitative frameworks or methods for implementing ECRs (Wright, 1997). The work on tools has considered topics such as updating, disseminating and controlling information, documentation control, and configuration management (Conley, 1991, Krishnamurthy and Law, 1995). The existing literature on methods focuses on how to best effect ECRs from engineering through manufacturing, and to minimize the effect on product function (Wright, 1997). All of the studies are qualitative, focusing on specific case studies at particular companies (Pikosz and Malmqvist, 1998, Reidelbach, 1991, Watts, 1984). Presumably, this is the first study to look at the ECR process using computer modeling. ECR Process All companies must make design changes to their products in order to adapt to changes in customer requirements, changing technologies, or changes in the environment, as some examples. In addition, an ECR may be issued for problems related to the quality of a part, revision of a part, correcting an error in a document, revising and/or renewing a document, recent developments in technology, or results of prototype tests (Pikosz and Malmqvist, 1998). ECRs arise as part of the product life cycle. Once a product has been sold, there are many suggested changes at the beginning of product use (product not working correctly or not meeting expectations), a few after the initial use period (a relatively long period of stable 2

4 use), and then, many changes at the end of the life cycle (adaptation due to product obsolescence). The diagram in Figure 1 illustrates the trend in the number of ECRs over a product s lifetime (bathtub shaped curve similar to a reliability curve). When a product is in use, there are two main strategies for performing an ECR: 1) executing the ECR immediately due to concerns for safety or critical functionality, or 2) amass ECRs and perform them as a group (Crow, 2002). The latter tactic is used for several reasons: efficiency in performing ECRs together, making ECRs part of a new version or model release, or the need to create a kit of several changes due to the impact of delivering and having the customer (or others) effect the changes in the field. These tactics are used by many companies and can be seen in the automotive, software, electronics and aerospace industries to name a few. For example, to rework an injection mold in the automotive industry, executing ECRs immediately would require that, for each ECR, the mold be disassembled and reworked. If, however, the ECRs are batched, many changes can be made in one retooling setup, thus significantly saving on disassembly and setup costs (Terwiesch and Loch, 1999). Number of ECRs Time Figure 1. The number of ECRs as a function of time for a product in use. There are a large number of ECRs immediately after release, a few during most of its lifetime, and then more to extend product life. There are also ECRs that occur during the creation of a new product. Figure 2 shows a timeline and the associated number of ECRs generated during the development of a new product composed of a circuit board assembly. This graph comes from a study of new product development (NPD) processes undertaken at a high-tech company that designs and manufactures telecommunication systems (Bhuiyan et al., 2004a, Bhuiyan et al., 2004b). As can be seen, the number of ECRs increases substantially shortly after the design verification stage, and more so, right after the start of manufacturing. Most changes in the NPD process occur in an ad hoc manner during design, and many change suggestions occur out of sequence within the design process. The processing of these ECRs falls into the two main tactics: execute an ECR immediately or group many ECRs and perform them during a natural cycling of the design process when creating prototypes or new design versions. In the electronics industry, it is quite common to design a product with one respin or design version to do a final layout and part selection to appropriately accommodate ECRs that occurred during the design process. When changes do occur, a formal way to manage them is required for efficiency. The management of the ECR process is a special business process that is concerned with managing change, and is often used during the product development process. Once a change is authorized, the details of the new specifications are released to all concerned parties. The master production schedule and the Bill-of-Materials (BOM) file are then checked to verify how the change impacts the requirements for materials and components, e.g., to handle any replacement parts, parts now in short supply, or parts that are no longer needed. Thus, 3

5 inventory is updated, any new purchases are ordered, production schedules are changed, accounting records are updated, and resources are staffed, all as necessary. All of this requires accurate and up-to-date information, a great deal of document change, and timely communication with key personnel. Actual procedures for processing ECRs can vary depending on how the ECR arises and which functions in an organization are involved. The research in this paper focuses on ECRs that occur during the NPD process, although the results are assumed to be applicable to other processes involving ECRs. Fraction of ECRs ECO's ECRs vs Series1 vs Time Time Design verification stage DATE Manufacturing release notice Figure 2. Fraction of ECRs generated over a timeline for new product development projects in the telecommunications company. The design verification stage is after the review of the conceptual design. The manufacturing release notice is the approval for manufacturing to plan and produce the first units. In the NPD process, ECRs affect the product development time and the required person-hours (effort) since an ECR means reworking part of the NPD process. In this paper, the two possible methods for processing ECRs are considered: 1) the immediate processing of ECRs as they are issued, or 2) the processing of ECRs in batches after a certain number of them have accumulated. The two methods are compared in terms of development time and amount of effort to accomplish them. It is assumed that all ECRs take the same amount of effort in order to make comparison easier. Whether ECRs occur during the NPD process or later in a product s lifecycle, the processing of ECRs is very similar if not identical. The amount of effort and duration to effect an ECR is also similar. The rationale for treating ECRs individually or batching them can be different as discussed above. However, it is expected that there should be similar improvement in the amount of effort and duration due to batching. This study was accomplished by creating a computer model of the ECR management process. Process modeling is a technique used to study the operation of a process by considering its functional, operational, informational and/or resource viewpoints. These process models are composed of many activities that represent the organizing, managing and coordinating activities in a process. The process modeler/simulator used in the study was FirstSTEP, a product of Interfacing Technologies Ltd. (Montreal). FirstSTEP is an object-oriented software, which allows the mapping of processes and the quantitative analysis of resource usage, cost, and duration during process flow. The ECR process was based on an existing model of an NPD process originally created by Bhuiyan to study concurrent 4

6 engineering (Bhuiyan et al., 2004a, Bhuiyan et al., 2004b). The NPD model is described briefly below. NPD Process Model New product development is a strategy used by companies to drive innovation. Concurrent engineering is a method used in NPD processes to develop products faster using parallel activities and good communication. Therefore, in order to achieve reduced development time, the NPD process needs to be designed with many parallel activities as well as good communication among project members through increased functional interaction in order to assemble product specifications. However, this often comes at the expense of increased effort. A model of an NPD process was built using process information obtained during a study of CE at a telecommunications company (Bhuiyan et al., 2004a, Bhuiyan et al., 2004b). The model was created with various process mechanisms that contribute to NPD performance: multifunctional teamwork, overlapping, decision-making, and rework. The effects of these mechanisms on NPD performance were related to development time and effort. In the model, ECRs occur due to the creation of a new product, and thus, happen throughout the NPD process. The model represents an NPD project to be completed that contains four phases, as shown in Figure 3. The process begins with Phase A, the development of a Concept, where market requirements are determined, and new ideas are generated and screened for economic and technical feasibility. In Phase B, Definition, a set of specifications to make the product is defined, and the product architecture is developed. Phase C, Development, consists of detailed design, physical prototyping, and testing. Finally, in Phase D, Implementation, the product volume is ramped up in manufacturing and launched onto the market. Phase A Concept Phase B Definition Design Version B A1 or B1 Phase C.Development Design Version C C1 A1 or B1 Phase D Implementation Design Version D C1 Figure 3. Process model for NPD showing phases and design version decisions. Solid lines at the decision point (diamond) after phase B show rework paths to the beginning of phases A or B. Solid arrows at the decision points after phases C and D show possible rework decisions. The process has a major review decision at the end of each phase (stage-gate process), represented in Figure 3 by diamonds, where the gates represent decision points for moving forward to the next phase or reworking one or more phases (design version). Figure 3 illustrates the possible destinations resulting from this decision point by the solid lines for Phase B only. For Phases C and D, only the possible starting points (arrows) are indicated to D1 5

7 the right of the decision point for simplicity. For modeling simplicity, it is assumed that Phase A is always successful, i.e., no rework at the end of this phase is required once a project concept has been decided upon. However, this phase may be reworked after the completion of any of the downstream phases, since, as an example, during the design phase, it may be discovered that the developed concept must be modified due to difficulties in manufacturing or the emergence of a new technology. Each phase consists of three sequential activities (A1, A2, A3; B1, B2 ) which are generically named Explore, Analyze, and Finalize respectively, for each phase. Figure 4 shows this breakdown for Phase B only. Explore was chosen to describe the initial investigation that occurs at the start of a phase. Analyze describes the in-depth study of the problem, and Finalize refers to the completion of the phase. Each activity in turn is composed of three sub-activities, as shown in Figure Work is composed of four parallel sub-activities to represent teamwork, which are executed by a team of Marketing, Design, Testing, and Manufacturing personnel. 2. Communicate coordinates the information generated by the Work sub-activity, shown in Figure 4, activity B1, by the dotted arrows representing exchange of information between team members. 3. Feedback is a decision point that determines that an activity: i) can move ahead or ii) needs rework, i.e., the three sub-activities must be re-done. B. Definition B1. Explore Marketing Design Testing Manufacturing B2. Analyze Marketing Design Testing Manufacturing B3. Finalize Marketing Design Testing Manufacturing Figure 4. The NPD model for Phase B and activities B1, B2 and B3. Boxes with designated functions represent work sub-activities. The dashed arrows between design and testing indicate the communication of information during the sub-activity. Diamonds represent review decisions to move forward or perform rework (churn). Arrows after activities B2 and B3 show moving forward to activities C1 and C2 respectively since phases B is overlapped with phase C at 33%. Functional interaction is an important feature of the model. It refers to the level of participation of the various functions on a multi-functional team. In the NPD model, these levels are represented by the percentages of 0%, 25%, 75%, and 100%. For example, consider the effect of the case of 25% functional interaction during Phase B. The Designer is responsible for this phase, so s/he participates 100% of the time during the phase. All other functions only participate 25% of the time that the Designer does. For modeling simplicity, all other functions begin at the start of the phase, and complete 25% of the duration of that phase. The rework due to the decisions at Feedback is called churn, which is the rework attributed to the informal changes to the specifications during the design process. In Figure C1 C2 6

8 4, the diamonds show the decision points where churn may take place. Probabilities for churn and design versions were estimated by creating rework profiles from the CE study at the telecommunications company (Bhuiyan et al., 2004b). The probability of churn taking place depends on the level of functional interaction (to be discussed shortly). In the study of ECRs, the case of 25% functional interaction and 33% overlap was used. The solid arrows in Figure 4 represent one-way information flows going into and coming out of all activities, sub-activities, sub-sub-activities, and decision points. Activities have the properties of duration and processing time. The duration of an activity is a component of the development time, i.e., it is the start to finish time of the activity, whereas the processing time is a component of effort, i.e., it is the person-hours required to complete the activity. Activity durations are partly deterministic and partly stochastic. Durations are fixed in terms of initial execution time; this portion is deterministic. The randomness takes place in the decision-making process (churn) and is reflected through iterative activities. When rework takes place, the increased effort and duration are added to the initial fixed duration. Initial activity durations were estimated to be approximately equal to average cycle times for general, complex NPD processes, based on findings in the literature and the CE study at the telecommunications company (Bhuiyan et al., 2004b). When rework is required, either due to design versions or churn, error correction is achieved only after repeated attempts through multiple rework loops. These iterations are characterized by a reduced activity duration and increased probability of activity success using learning curves, which capture the effect of knowledge accumulation for activities within a phase. In the model, this is accomplished through a feature built into the simulation software that dynamically updates the model; rework inputs are identified, and decision probabilities and resulting activity durations are adjusted accordingly. ECR Processes in the NPD Model ECR management processes were studied within the framework of the NPD model. Three major mechanisms were used to model decisions for initiating ECRs and subsequent process flow. A network of loopbacks modeled the effects of the engineering changes, i.e., redoing activities distinct from design versions and churn. Decision points were created in strategic positions in the process model to enable routing of the process flow, and the probabilities of ECR decision outcomes were assigned at the decision points according to the likelihood of ECRs in practical situations (Bhuiyan et al., 2004a). ECR Loopbacks It is important to note that an ECR can occur anywhere and at anytime during the model, unlike churn or design versions, which can only occur at the end of activities or phases, respectively. Furthermore, when churn takes place, only one activity is reworked at a time, and when design versions take place, one or more phases are reworked. An ECR may require rework in any number of activities and/or phases. For this reason, it is necessary to have good control of the process flow. Many companies treat ECRs differently depending on the effect on the integrity of the product and the desired response to the customer; so, ECRs may occur at different points in the process or have different impacts in terms of procedures. In our model, all ECRs as treated similarly in all phases for modeling simplicity. Although this represents a departure from real-life, the intention is to be able to make a relative comparison between two methods of managing ECRs, and so it is assumed that any error due to this assumption is minimal due to the use of comparative analysis. As shown in Figure 5 (Phase B only is shown for simplicity.), decision points for ECRs (diamonds) are included after each activity within a phase in order to simulate the probability of issuing an ECR at any point in the process. The decisions points at the end of 7

9 activities are distinct from churn or design version decision points, and determine whether or not an ECR will be raised. Flow control for the execution of an ECR only goes to the start of the present or any previous phase. Solid arrows depict one-way flows of information. The possible rework paths for an ECR decision within Phase B are also shown for activities B2 and B3 only. For example, when activity B2 is complete, a decision is made to determine if an ECR is required. If an ECR is raised, then the information flow is directed to the point where the change must take place. Figure 5 shows the example of an ECR that is raised at the end of B2, which requires going back to activity B1. As another example, once activity B3 is complete, if an ECR is issued, the change may be required starting either at activity B1 or activity A1. The probability assignment at the decision point determines the flow to the various activities. ECR loop B1 B. Definition B1 ECR loop A1 A1 B1 B2 B3 forward to C2 Figure 5. ECR decision points during Phase B showing possible ECR loopbacks after activities B2 and B3. After activity B2, an ECR loopback to activity B1 is shown. After activity B3, the possible outcomes at the ECR decision point are shown; there may be an ECR loopback to activity B1 or A1, or a move forward to activity C2. ECR Control Flow with Overlap Since the CE process often includes overlapping of phases or activities, phases in the NPD model are executed in parallel with a 33% degree of overlap across all phases, e.g., the first activity of Phase B, B1, is executed in parallel with the last activity of Phase A, A3. Similarly, the first activity of Phase C, C1, is executed in parallel with the last activity of Phase B, B3 (Figure 6). Since an ECR can occur at any point in the process, process flow is complex. Therefore, in addition to decision points that test whether an ECR should occur after a single activity, decision points also exist that test whether an ECR should occur after two overlapped activities. Examples of both are shown in Figure 6 for overlapping taking place between phases B and C. One decision point exists to determine if an ECR will be raised after B2 as was shown previously in Figure 5. Another decision point exists after overlapped activities B3 and C1 are completed to determine if an ECR will be raised. Once again, information flows are depicted by the solid arrows in Figure 6. Setting Probabilities of Occurrence The occurrence of ECRs, design versions, and churn are modeled by setting the probabilities for the reworking of activities and/or phases during the NPD process. Decision points for ECRs are present between each activity and at the end of each phase (except during Phase A for modeling simplicity, as previously discussed). Decision points for design versions and ECR management at the end of each phase are combined since the flow control for an ECR or a design version at the end of a phase is the same. Figure 6 shows the probabilities of churn and design versions as a function of functional interaction. The probabilities were determined based on the study of the telecommunications company (Bhuiyan et al., 2004b), experience, and examples from the literature. The probabilities for ECRs were taken to be 8

10 the same as those for design versions since the considerations for rework for ECRs are similar to those for design versions. From Figure 7 it can be seen that the probability of churn increases with increasing functional interaction, i.e., the more interaction that there is among team members, the more incremental, informal changes take place. Also, the probability of design versions decreases with increasing functional interaction, i.e., the more communication that there is, the less likely that there will be time consuming rework of entire phases. Since the case of only 25% functional interaction is used in the study of ECRs reported in this paper, only one probability point from Figure 6 is used for each of churn, design versions and ECRs for the various decision points in the model. Decision point at B2 Decision point at the end of activities B3, C1 From A2 From A3 B1 B2 Phase B. B3 C1 C2 Figure 6. Examples of the two types of decision points for ECRs with overlapped activities. Process flow is shown from activities A2 and A3 to B1 and B2 respectively for 33% overlap. Possible outcomes after the decision point at B2 are move to A1 or B1 or B3 and C1; a move to B3 and C1 is shown. After the decision point at B3, C1, possible outcomes are move to A1 or B1 or C2; a move to C2 is shown. Probability of churn, design versions and ECRs Probability of churn, design versions and ECRs Functional Interaction P(churn) P(design versions) Figure 7. Probabilities of churn, design versions, and ECRs. The probability of ECRs is the same as that of design versions. 9

11 ECR Management Methods: Immediate Processing or Batch Processing The management of ECRs was studied using the two methods discussed earlier and compared to a baseline case in which no ECRs took place. The models were: M0: Model 0 (No ECRs occur.) M1: Model 1 (ECRs are immediately processed.) M2: Model 2 (ECRs are processed as a batch after a certain number have accumulated.). For Model 1, when the need for an ECR was decided, the target activity and/or phase for rework were/was started, or the process was continued. For Model 2, ECRs were accumulated from 4 to 24 in groups of four, and loopbacks occurred at that point in the process. Recall that no distinction was made for the amount of effort to perform an ECR. Results Both development time and effort were used to measure process performance, where development time was the start to end time of the NPD process in days, and effort was the total processing time in person-days. In the analysis of results, in order to compare development time and effort from the different scenarios, the results were normalized since ECRs occurred individually in Model 1 and in batches in Model 2. Normalization was done as follows: (Spantime(Mx) #Spantime(M0)) " = number of ECRs $ = (Effort(Mx) # Effort(M0)) number of ECRs where η represented normalized development time, ε represented normalized effort, and Mx represented the model number x, where x was 1 or 2. M0 represented the baseline model. Effort vs ECRs Effort (person-days) Number of ECRs M1 M2 M0 Figure 8. Total effort plotted against the number of ECRs executed during simulations of Models 1 (individually) and 2 (batch). The result for baseline model M0 (no ECRs) is a single point. 10

12 Normalized Effort vs vs ECRS ECR's Normalized Effort M1 M Number of of ECRs ECR's Figure 9. Normalized effort, ε, plotted against the number of ECRs executed during the simulations of Models 1 and 2 Development Time Time vs vs ECR's ECRs Development time (days) Number Number of ECRs of ECR's M1 M2 M0 Figure 10. Total development time plotted against the number of ECRs executed during simulations of Models 1 and 2. The result for baseline model M0 is a single point. Normalized Span Time vs ECRs ECR's Normalized Span Time Number of ECRs ECR's M1 M2 Figure 11. Normalized development time, η, plotted against the number of ECRs executed during simulations of Models 1 and 2. 11

13 Results for the different models are shown in Figures 8 to 11. Figures 8 and 10 show the behavior of effort and development time respectively as the number of ECRs increases in Models 1 and 2. The trend in the curves is linear, i.e., effort and development time increase linearly as the number of ECRs increases in Models 1 and 2. This is borne out by the fact that the normalized effort (Figure 9) and development time (Figure 11) are constant as the number of ECRs increases. The variation in the curves in Figures 8 and 10 is due to the stochastic nature of the models. Recall that the model is made up of several types of rework from design versions to churn to ECRs, whose frequency is determined by probabilities. Even though a few simulation runs were averaged for each scenario, significant variances still exist in the data. Nevertheless, the trends in the data are easily seen. The variations in Figures 9 and 11 are much smaller due to greater averaging. From the results, it can be seen that performing ECRs in batches yields both reduced effort and shorter development time. In Figure 8, the total effort for doing ECRs in batch mode is substantially less than the effort of doing ECRs individually. The amount of effort per ECR in batch mode is about half that in individual mode (Figure 9). Similarly for development time, in Figure 10, the development time for doing ECRs in batch mode is also much less than the development time for doing ECRs individually. It is about half, as shown in Figure 11. Discussion In our simulation study, we have found that processing ECRs in batch mode was demonstrated to be a more effective technique than dealing with them one at a time. Batching required much less effort and development time than processing ECRs individually. The main reason for this difference is the lower process overhead when ECRs are done as a group. So, although the direct amount of work necessary to do the changes is not much different than if done individually or as a group, the amount of time spent doing communication, design review meetings, and management is much less when ECRs are done as a group. Thus, these time-consuming activities are done once in batch mode, while they are executed every time an ECR is issued in individual mode, which accounts for the large difference in effort and development time. For the specific process parameters used in this study, the amount of both effort and development time for batch processing was about half that of individual processing. In other situations, the specific amounts of improvement would vary depending on the number of ECRs grouped together in batch mode and the particular NPD process being followed. However, the results here do show that the improvement can be substantial. Besides design effort, the grouping of ECRs, especially over a long period during the development process, can also affect the effort for ordering of materials, coping with end-ofline inventory, and bringing a new product into production. DiPrima (1982) showed that the cost of performing an immediate change, i.e., ordering material tomorrow as opposed to two months from now may be substantial ; in other words, rushing an order can be more expensive. This makes performing ECRs in batch mode even more attractive. Clearly, the results from the study done here suggest that, for similar types of ECRs, it is preferable to wait for a batch to form because of the reduction in effort and time due to the gained efficiency from doing similar types of actions together. Going back to the example cited earlier, if a mold requires change, whether the change is urgent or not, it will likely need to be disassembled and sent to re-tooling. To do this several times for various types of ECRs can be very time and effort consuming and expensive, whereas, spending some extra time waiting for other change requirements would keep these activities to a minimum. Thus, the batching of change orders, in some cases, can be efficient, as for example, when large set-up costs or time are involved (Harris, 1913). On the other hand, recall that we made the 12

14 assumption that all ECRs are assumed to be similar without differentiating between ECRs due to the level of criticality, the need for time phasing of certain activities in the NPD process, or the amount of required effort. Therefore, batching ECRs may delay a project since much time may be spent waiting for a batch to form, and much idle time take place due to the interdependence of certain tasks. Nevertheless, research shows that the ECR process tends to be lengthy in part because of the high proportion of non-value-added time, for example, items simply being left at someone s desk waiting to be processed (Terwiesch and Loch, 1999, Blackburn, 1991). Therefore, batching and processing the batch immediately could lessen the cumulative effect of waiting times for individual ECRs. Conclusions Nowadays, increasing product complexity with a shorter development time makes it necessary to have more people with different competencies involved in each NPD project. This makes decision making more difficult. Evidently, the ideal when designing a product is to get the design right the first time, eliminating the need to make changes. However, changes due to wrong decisions and/or evolving customer requirements, for example, are unavoidable. If an undesirable design decision has been made, the product data has to be changed in a controlled fashion. Many companies manage change by a simple and direct method, that is, redoing the activity immediately when an ECR occurs. Batching ECRs is an effective alternative in some cases. Although the processing of ECRs was studied for the NPD process, the results should apply equally to ECRs performed during a product s lifecycle after product delivery. The majority of the processes for effecting an ECR: design, purchasing, documentation, etc., are the same, and the reasons for time and effort reduction due to batching are similar. In the study described in this paper, a process modeling and simulation approach was used to study two methods for managing ECRs, individual and batch processing. The study showed the superiority of batch mode processing of ECRs. Nevertheless, in some situations ECRs require immediate attention. A mechanism will always be needed to deal with situations directly. Also, in terms of batching, ECRs could be processed in groups on a periodic basis. Periodically performing ECRs due to new design versions or prototypes in a timely manner is a good compromise between a random batch mode and doing them individually. References Bhuiyan, N., Gerwin, D., Thomson, V. (2004a) Simulation of NPD Process and Performance, Management Science, Vol 50, No 12, pp Bhuiyan, N., Thomson, V., Gerwin, D. (2004b) A Systematic Framework for Implementing Concurrent Engineering, Research-Technology Management (forthcoming) Blackburn J D (1991), New Product Development: The New Time Wars Chapter 5 in: Time- Based Competition, Homewood: Business One Irwin Conley D T (1991) Configuration status accounting made affordable, Naval Engineers Journal, Vol 103 No 6, pp Crow K (2002) Configuration Management and Engineering Change Control, DRM Associates, 2613 Via Olivera, Palos Verdes, CA 90274, USA DiPrima M R (1982) Engineering change control and implementation considerations, Production and Inventory Management, Vol 23 No 1, pp Harris F W (1913) How many Parts to Make at once?, Factory: The Magazine of Management, Vol. 10 No. 2, pp

15 Krishnamurthy K and Law K H (1995) Change management for collaborative engineering, Computing in Civil Engineering, Vol 2 pp Malmqvist J (1998) A comparative study of engineering change management in three Swedish companies, Proceedings of DETC ASME Design Engineering Technical Conference Atlanta, GA, September pp 1-11 Reidelbach P E (1991) Engineering change management for long-lead-time production, Production and Inventory Management, Vol 32. No 2, pp Terwiesch C and Loch C H (1999) Managing the Process of Engineering Change Orders: The Case of the Climate Control System in Automobile Development, Journal of Product Innovation Management, Vol 16 No 2, pp Watts F (1984) Engineering Changes: A Case Study, Production and Inventory Management, Vol 2 No 4, pp Wright I C (1997) A review of research into engineering change management: implications for product design, Design Studies Vol 18, pp AUTHORS BIOGRAPHIES Nadia Bhuiyan Department of Mechanical and Industrial Engineering, Concordia University 1455 de Maisonneuve Blvd. West, Montreal, Quebec H3G 1M8 Tel: (ext 3101), Fax: , bhuiyan@alcor.concordia.ca Dr. Bhuiyan holds a Master's degree and a Ph.D. both in Mechanical Engineering from McGill University, and a Bachelor's degree in Industrial Engineering from Concordia University. She is an Assistant Professor at Concordia University in the Department of Mechanical and Industrial Engineering and the Associate Director of the Concordia Institute for Aerospace and Design Innovation (CIADI). Previously, she worked as Assistant Professor at Queen's University s School of Business, and Lecturer at McGill's Department of Management Science for several years. Her research area is mainly in operations management, with a focus on new product development processes, and emerging tools and techniques for integrating design and manufacturing to improve process performance. Gregory Gatard Mechanical Engineering, INSA, Rouen, Seine Maritime, France ggatard@hotmail.com Mr. Gatard completed his Master of Science at McGill University in the Department of Mechanical Engineering, where he studied engineering change management practices. Vince Thomson Mechanical Engineering, McGill University 817 Sherbrooke St. West, Montreal, Canada, H3A 2K6 Tel: , Fax: , vince.thomson@mcgill.ca Dr. Thomson is the Werner Graupe Professor for Manufacturing Automation in the Department of Mechanical Engineering at McGill University. He has been involved in manufacturing and information technology related research for the past 20 years at McGill and the National Research Council (Canada). His research has ranged from shop floor control and production scheduling to the present interest in process management in manufacturing. In process management, research has focused on new product introduction, concurrent engineering and manufacturing support in terms of coordination, metrics, and process principles. 14