Standard Article Managing engineering change requirements during the product development process Concurrent Engineering: Research and Applications 1–16 Ó The Author(s) 2017 Reprints and permissions: sagepub.co.uk/journalsPermissions.nav DOI: 10.1177/1063293X17735359 journals.sagepub.com/home/cer Inayat Ullah1, Dunbing Tang1, Qi Wang1, Leilei Yin1 and Ishfaq Hussain2 Abstract Product redesign is not a straightforward task, specifically for complex commodities. Engineering change requirements can be evoked in any phase of the product development process, thus making engineering change management a challenging task. The motive of this study is to explore the best possible way of managing engineering change requirements taking execution sequence of change requirements into consideration. In this article, a new approach supporting engineering change requirements implementation sequence, by considering the risk associated with engineering changes, is presented. The risk of the redesign is hard to foresee since the engineering change effects are being dispersed from the instigating component to other associated components. In this article, the term of rework-risk is used for the amount of rework needed to be done to redesign the products’ components. The practicality of suggested method is analyzed using the redesign of an optical mouse as a case study. Managing engineering change requirements in a group with proper sequence can ensue with a 15% decrease in the redesign duration as compared with the prompt implementation of engineering change requirements. Conversely, it can also cause 36.23% increase in the redesign duration, if not handled in an appropriate sequence. The results from a single, simple case, indicates that running engineering change requirement batches can be beneficial. Keywords engineering change requirement, product development process, rework-risk, redesign duration, design change urgency Introduction In today’s competitive environment, managing engineering change requirements (ECRs) efficiently cannot be devalued. Time to market is a critical issue in the manufacturing industry. In design and production firms, there is a growing awareness that skilfully managing ECRs is the key to success (Inness, 1994). It is, therefore, essential to explore the best possible way of managing ECRs to reduce the product redesign time. In this article, two different techniques, that is, individual and batch processing, are presented to manage ECRs. Product design and development is primarily driven by needs and stakeholder requirements (Hull et al., 2005). In the literature, requirements are defined as statements, identifying system, or product constraints necessary for satisfying stakeholder needs (INCOSE, 2010; Palmer et al., 2010). ECRs can be taken in two different perspectives: changes triggered by innovation and problem-oriented changes (Lindermann and Reichwald, 1998). First, ECRs are considered as a source of innovation and notably influential driving factors of product design improvement (Eckert et al., 2004). Second, ECRs cause reworks: the extraneous effort of redesigning an activity or a process that was erroneously realized the first time (Love, 2002). The outcome of both changes leads to a value-added product. ECRs can be initiated at any stage during the product development (PD) process, thus making the 1 College of Mechanical and Electrical Engineering, Nanjing University of Aeronautics and Astronautics, Nanjing, China 2 College of Electronic and Information Engineering, Nanjing University of Aeronautics and Astronautics, Nanjing, China Corresponding author: Dunbing Tang, College of Mechanical and Electrical Engineering, Nanjing University of Aeronautics and Astronautics, Nanjing 210016, China. Email: [email protected] 2 management of engineering changes (ECs) a challenging task (Vianello and Ahmed-Kristensen, 2012). In early decades, ECs were predominantly seen as a problem and people were reluctant to implement the engineering change management (ECM) system (Acar et al., 1998). From the last few decades, industrialists construed it as an opportunity and source of innovation (Balogun and Jenkins, 2003; Eckert et al., 2004). Every organization experiences ECs, therefore, its management practices need to evolve. ECs can benefit the organization in many aspects such as cost reduction, on-time delivery, and quality enhancement if they are managed appropriately and implemented efficiently. It can also elevate the firm’s reputation in the market. ECRs should be categorized in a most refined manner, depending on the class and the significance of the change and should be managed with distinct techniques to minimize the lead time (Balcerak and Dale, 1992). Wright (1997) differentiated the research in the field of ECM into two broad classes. First, tools to investigate ECM issues, and second, techniques to minimize the impact of changes in various aspects. According to the classification made by Wright (1997), this research work falls into the second category with an aim to minimize the impact of ECs. Two different techniques, individual and batch processing, are presented, and the comparison is made to decide the best possible option. In the literature, discussion about the execution sequence of ECRs in batch processing has not been found. Therefore, this article focuses on the influence of execution sequence in batch processing to provide a technique for the better management of ECRs during PD process. Change propagation model based on the component design structure matrix (DSM) is applied to explore different change propagation paths (CPPs) in the product’s structure. The technique is based on time computing models, where iterations of earlier design activities are also considered. Redesign change propagation evolution is carried out by considering two types of mapping, that is, ‘‘And’’ and ‘‘Or.’’ Finally, to demonstrate the usefulness of the proposed technique, an optical mouse is examined as a case study. In the rest of this article, section ‘‘Background’’ presents a brief overview of the previous related work, while detailed clarification of the suggested method is presented in section ‘‘Model framework and rework-risk assessment.’’ The evaluation of the proposed algorithms is explained in section ‘‘Algorithms for managing single and multiple ECRs,’’ and the case study is discussed in section ‘‘Case description.’’ Finally, the conclusion and some directions for future research are presented in section ‘‘Concluding remarks and future work.’’ Concurrent Engineering: Research and Applications 00(0) Background ECRs play a critical role in the PD process. Besides, identifying, maintaining, and satisfying a system’s requirement are essential to the project’s success (Pahl and Beitz, 1998; Ullman, 2003; Ulrich and Eppinger, 1995). Due to requirement issues, PD failure and unnecessary increase in the cost, time, and quality problems have been observed by Worinkeng and Summers (2014), which are illustrious contributing factors of competitive advantage in the market. ECRs are identified as the second leading source that challenges the project’s success (The Standish Group, 1995). One of the major problems in managing ECRs is the lack of planning when changing them (Hull et al., 2005). ECs may have severe implications on the design time, cost, and quality of a product if not managed effectively (Hamraz et al., 2013). The literature related to ECM is comparatively limited to the other topics such as the product life cycle management (Jarratt et al., 2011). ECRs are one of the dominant determinants that encourage disruptions and cost overrun of projects, which subsequently cause claims, conflicts, and consumer’s disappointment. The clients usually instigate most of the ECRs as new requirements or by the firm as improved specifications. ECRs can also be stirred during an artifact’s use due to faults’ rectification, parts’ substitution, or alterations for upgrading near the end of product life (Nadia et al., 2006). Inefficient management of ECRs can cripple the productivity of a firm. In PD process, the components that are considered to be completed might have a chance to change (Huang and Mak, 1999). Due to an inadequate ECM system, sometimes the defective product is launched to the market, thus affecting the customers. Moreover, it can also impair firms’ reputation in the market and can incur substantial recovery cost. A study conducted by Wasmer et al. (2011) showed that 20%–40% of the lead time could be reduced by properly managing ECs. In a new PD process, the occurrences of design changes can affect productivity up to 24% and lead time up to 44% (Li and Moon, 2012). Process modeling and a simulation-based approach were used to manage the ECRs in a new PD process (Nadia et al., 2006). It is revealed from the literature that cumulative effect of ECR propagation at any scale can have detrimental consequences on the project (Giffin et al., 2009; Morkos and Summers, 2010; Shankar et al., 2012). Limited research has been performed to effectively model and manage ECRs fluctuations and changes (Harker et al., 1992; Lam and Shankararaman, 1999; Sugden and Strens, 1996). Most of the research work, done so far in the field of ECRs management, is of Ullah et al. qualitative nature and emphasizing particular case studies in a specific firm (Reidelbach, 1991; Watts, 1984). Therefore, it is essential to manage ECRs to ensure that the effects are not detrimental (Nuseibeh and Easterbrook, 2000). A designer may save time and money if the overall effects of ECRs could be assessed before its implementation (Ollinger and Stahovich, 2001). 3 EC implementation (DiPrima, 1982; Maull et al., 1992): EC An EC is a fact and should be considered as a routine job. EC is defined by numerous researchers (Huang and Mak, 1999; Terwiesch and Loch, 1999; Wright, 1997) in a different perspective. The complete definition is given by Jarratt et al. (2004) by considering the scope, size, time, and type of change. Numerous researchers (Eckert et al., 2004; Nadia et al., 2006; Terwiesch and Loch, 1999) categorized ECs based on the artifact such as coming from the products (emergent changes) and originated from outside of the product (initiated changes). ECs can trigger at any point during PD process (Huang et al., 2003; Lee et al., 2006; Terwiesch and Loch, 1999), which are considered as the means by which the product evolves (Masmoudi et al., 2017). EC need is raised from different sources as a result of numerous reasons such as technology evolution, product functionality improvement, innovation, current legislative requirements, safety concerns, and customer requirements (Eckert et al., 2003; Huang and Mak, 1998; Keller et al., 2009; Mohringer, 2006; Pikosz and Malmqvist, 1998; Wright, 1997). According to Mohringer (2006), ECs can be originated at the firm’s level due to three main origins or sources, that is, suppliers, customers, and internal departments. Earl et al. (2005) studied ECs in terms of changing descriptions. Kidd and Thompson (2000) in their study summarized the economic significances of ECs, which are made during the design process. ECs were classified into minor, general, and major changes by Yu et al. (2013). In a study conducted by Balcerak and Dale (1992), the authors concluded that categorization of changes should be established by two determinants: first, the urgency of change and second, the impact of change on the product. EC urgency. ECs can arise in different circumstances to address the need. It depends on the requirement that how quick response is required to implement the desired change. ECs are classified into three distinct categories, that is, immediate, mandatory, and convenience changes, which indicate a degree of urgency for Immediate changes must be executed on a priority basis to resolve the issues. Safety- and defect-related concerns fall into this category. Safety-related affairs have no concern with economic boundaries (Inness, 1994). Mandatory changes should be implemented as soon as possible, but there is some time flexibility. New legislation or certification requirement, repair and maintenance, and product quality-related issues fall into this category. Convenience changes can be carried out at the manufacturer’s ease. Changes related to the product’s esthetics, the customer’s request regarding improvement in range, the performance of the product, and new technology are regarded as convenient changes. EC impact. EC request plays an important role during the PD process (Pahl and Beitz, 1998; Ullman, 2003). To evaluate the possible impact of ECs is the most crucial task in change propagation process. Clarkson et al. (2004) define impact as ‘‘the average proportion of the design effort that will require being redone if the change propagates.’’ Three determinants have influenced the impact of a change on a product: product structure, product intricacy and the degree of innovation within the product (Jarratt et al., 2011). Numerous methods have been proposed to simulate and analyze the change propagation in an artifact, to allocate resources, cost, and time according to the impact of the change (Cohen et al., 2000; Hamraz et al., 2012; Li and Zhao, 2014; Tang et al., 2016). The connectivity between product’s components via rework probability and impact allows the flow of information between components. The values of both rework probability and impact may be achieved from the history of previous design changes and/or interviewing the expert designers (Clarkson et al., 2004). The risk defined by Van Bossuyt et al. (2013) as ‘‘the possibility of happening of an event multiplied by the intensity of its consequences’’ is adopted in this article. In this research work, two types of rework-risks, namely, initial and propagated rework-risk are considered. Initial reworkrisk depends on the severity of ECR and is divided into three different categories as detailed in Table 1. Whereas, propagated rework-risk depends on the connectivity and iterations between the design components. The summation of both risks is termed as accumulated risk, which varies from 0 to 1. Besides, in the suggested model 1 indicates maximum risk and 0 refers to no risk. 4 Concurrent Engineering: Research and Applications 00(0) Table 1. Initial rework-risk categorization. S. no. Risk classification Risk range 1 2 Low initial rework-risk (LIR) Medium initial rework-risk (MIR) High initial rework-risk (HIR) 0 \ LIR 0.35 0.35 \ MIR 0.7 3 0.7 \ HIR 1 Research motivation and assumption The authors of the extant studies in this field have not focused on the execution sequence of ECRs in a batch processing. Therefore, the objective of this article is to address this gap in the pertinent literature by answering the following research questions: What is the best feasible way to execute ECRs? What is the impact of the ECRs execution sequence on the PD process? Following three assumptions are made in the suggested techniques: ECRs will fall into the category of convenience and mandatory changes. When the accumulated risks become greater than ‘‘1,’’ it should be replaced by ‘‘1.’’ Each ECR is specifically related to each component. Model framework and rework-risk assessment Change propagation network for single and multiple ECRs In this article, two distinct models, namely, single and multiple ECRs, are presented. The suggested models evaluate the progress of PD process over time, to investigate the optimal way of managing ECRs. These models require information about different design components that integrate the PD process, that is, rework probability and impact, logical dependencies, component design duration, and instigating components. The components’ rework probability and impact are presented in the form of DSM, which is a square matrix. A DSM provides an easy way to recognize the structure of event linkages as illustrated in Figure 1(a). A marking ‘‘ 3 ’’ in the off-diagonal cell represents the information flow between the corresponding design components. The off-diagonal cell in the ith row (Component B) and the jth column (Component D) denotes the relationship that is defined as the ith row component ‘‘B’’ affects the jth column component ‘‘D.’’ Which implies that the jth column component ‘‘D’’ receives information from the ith row component ‘‘B.’’ In a complex product design, the components are interconnected in a closed fashion; therefore, logical relationships ‘‘And’’ and ‘‘Or’’ exist between them. The logic relationship ‘‘And’’ represents that various downstream components are affected by an upstream component simultaneously. Conversely, the logic relationship ‘‘Or’’ accounts for the fact that only one downstream component is influenced by an upstream component at a time. Due to the presence of logical relationships between components, parallel and sequential change propagation patterns exist in the design process. A logical dependency matrix for illustrated example is shown in Figure 1(b). The numerals in the cells indicate the existence of logical dependency between the components. If digits in a row are the same, then ‘‘And’’ logical dependency exists between the corresponding components. Otherwise, the logical dependency ‘‘Or’’ occurs. For instance, if component D is modified, then components B and C may be changed concurrently due to the presence of ‘‘And’’ logical Figure 1. (a) DSM—information flow interaction and (b) logical dependencies between components. Ullah et al. 5 between components. Change initiated in one component propagates to the other connected components. Therefore, the total execution cost comprises the redesigning cost of the initial aspects of design and also caused by change propagation. Once the component dependencies have been captured, the possible CPPs can be determined. Distinct ECRs have different initial rework-risks, termed as, planned rework-risk, that depend on the degree up to which the initiating component should be affected by the change request. One CPP as a result of ECR(s) is highlighted in Figures 2 and 3. Figure 2. Change propagation network in a product’s structure as a result of single ECR. Change initiated in component c1 due to engineering change requirement (ECR). Layers1 2 k represent the change steps. dependency. However, if change propagates to component A, it may be changed alone because of ‘‘Or’’ logical dependency. The change flow between the components is explained by considering a product consisting of m components as shown in Figures 2 and 3. For managing ECRs, two primary approaches are considered. First, ECRs are implemented on an immediate basis when they are raised as shown in Figure 2. Second, ECRs are accumulated and then executed at once as presented in Figure 3. In both methodologies, same ECRs are utilized to explore an effective strategy. In Figures 2 and 3, c1 to cm denote the number of product’s components, whereas K2p represents the number of change steps as a result of ECR2. In both cases, n distinct ECRs are initiated during the PD process in a single product. The arrow lines depict the dependency Rework-risk propagation and assessment Quantitative risk analysis based approach is suggested to manage ECRs during the PD process. Information interaction between design components as a result of product functionality usually leads to rework in PD process. The links between product’s components by rework probability and impact permit the changes to propagate to the associated components. The rework probability and impact have values between 0 and 1. Rework-risk by its very nature always has some negative impact in terms of cost, schedule, and quality. The proposed model relates the rework-risk to the amount of rework needed to be done to accomplish the ECRs. Let us consider a product comprising of m components. As a result of ECR, component ci propagates the change to component cj with the rework probability of RPij and rework impact of RIij. Then, according to Van Bossuyt et al. (2013) and Zhang et al. (2015), the rework-risk RR(ci, cj) between directly connected components can be expressed as Figure 3. Change propagation network in a product’s structure as a result of multiple ECRs. Change initiated in different components c3, c2, and c1 due to multiple engineering change requirements (ECRs). Layers represent the change steps for a particular change requirement. 6 Concurrent Engineering: Research and Applications 00(0) RR(ci , cj ) = RPij 3 RIij ð1Þ In equation (1), i and j denote the change instigating and affected components, respectively. CPPs are the chain of changes that consist of two distinct types of rework-risk, that is, planned rework-risk PlRR and propagated rework-risk PrRR. Planned rework-risk is caused as a result of ECR because it must be executed to fulfill the need. Conversely, propagated rework-risk is produced due to the change propagation. Both the risks can be expressed as Pl RR(r, ci ) = RPr, i 3 RIr, i ð2Þ Pr RR(ci , c1 ) = RPi, 1 3 RIi, 1 ð3Þ In equation (2), RPr,i and RIr,i are the rework probability and impact because of the change request r, respectively. Whereas, in equation (3), PrRR(ci, c1) is the propagated rework-risk between the instigating component ci and the directly connected component c1. Likewise, change propagation takes place throughout the whole product structure. The rework probability and impact are defined for the components that are directly linked to each other. However, changes can propagate to other components, which are not directly connected. By considering both effects of change propagation, the predictive model is extended to calculate the cumulative rework-risk, as a result of single ECR and can be expressed as RRkr (ci , cj ) = Pl RR(r, ci ) 3 Pr RR(ci , c1 ) 3 Pr RR(c1 , c2 ) 3 3 Pr RR(ck2 , ck1 ) 3 Pr RR(ck1 , cj ) ð4Þ In equation (4), RRkr (ci , cj ) is the rework-risk between the instigating component ci and the end component cj to realize ECR r in k change steps through k 2 1 components. Equation (4) can be generalized for n number of change requests as follows In equation (6), k1 up to kn represent the number of change steps in the same CPP for specific change requests. Iterations are the essential characteristic of the design process, and even small changes in iterationlikelihoods can have substantial impacts on process effort and duration in concurrent design processes (Shapiro et al., 2015). Iterations are mostly triggered by incomplete information (Hollins and Pugh, 1990). During each iteration, designer’s familiarity and experience boost regarding product design. Therefore, less effort is needed to accomplish the design tasks in successive iterations (Maier et al., 2014). Each iteration serves to improve the results and increase the product quality. In the proposed model, computation of the PD time is facilitated by incorporating the learning effect. During the change propagation process, the component affected by an upstream component to a small amount will also influence the downstream component to a little extent and vice versa. Therefore, the risk propagated to the downstream component depends on the change risk of an upstream component. Thus, the risk propagated from a component i to j in the xth change iteration, considering the learning effect, can be expressed as follows RR(ci , cj )½x = (RPij 3 RIijx ) 3 RR(ci1 , ci ) ð7Þ Andersson et al. (1998) defined a curve termed as ‘‘learning-by-doing,’’ in which the accomplishment time decreases because of each iteration with an associated learning curve function. Therefore, equation (7) is derived based on the assumption that the component change impact has a nonlinear relationship with the number of iterations between each pair of components to incorporate the learning effect. The total redesign duration (TRD) of any CPP to be resolved completely can be expressed as 9 RRKr1 r2 rn (ci , cj ) = ½ ½½Pl RR(r1 , ci1 ) 3 Pr RR(ci1 , cr11 ) 3 Pr RR(cr11 , cr21 ) 3 3 Pr RR(crk11 2 , crk11 1 ) 3 Pr RR(crk11 1 , ci2 ) > > r2 r2 r2 r2 r2 r2 > + Pl RR(r2 , ci2 ) 3 Pr RR(ci2 , c1 ) 3 Pr RR(c1 , c2 ) 3 3 Pr RR(ck2 2 , ck2 1 ) 3 Pr RR(ck2 1 , ci3 ) > > > = .. . > > .. > > . > > ; rn rn rn rn rn rn + Pl RR(rn , cin ) 3 Pr RR(cin , c1 ) 3 Pr RR(c1 , c2 ) 3 3 Pr RR(ckn 2 , ckn 1 ) 3 Pr RR(ckn 1 , cj ) ð5Þ In equation (5), cin represents the instigating components, while crknn 2 denotes the intermediary components for a particular ECR in the CPP. Moreover, k indicates the whole number of change steps in the CPP to realize the desired n number of change requests in a product and can be expressed as ð8Þ K = k1 + k2 + k3 + + kn ð6Þ TRD = y X RRi1, i 3 DDci i=1 In equation (8), y denotes the number of changes caused by ECRs in a single CPP to fulfill the desired need, and DDci represents the component design Ullah et al. 7 Figure 4. Flowchart for exploring propagation paths as a result of single ECR. duration. The design duration of each component may be in days or months, depending on the project. Algorithms for managing single and multiple ECRs For the better management of ECRs during the PD process, two algorithms based on the above-mentioned mathematical model in different formats are proposed. First, execute the change request promptly when it occurs, as explained in Figure 4. Second, the ECRs are accumulated, which is followed by execution when a certain lot size is grouped, as detailed in Figure 5. Graph-based search technique is used to explore different CPPs in the suggested algorithms because the graph takes account of cycles, which represent iterations in the PD process. The algorithm proposed by Dijkstra (1959) is used to explore the shortest paths from a single initiating node to all other nodes in the graph. Whereas, the advanced algorithms can discover the most time-saving CPPs initiating from a single or multiple components to the associated components. Moreover, the Dijkstra algorithm is used to explore the paths between finite nodes, and the node once visited will never be checked again; consequently, no stop criterion and iteration are considered in the algorithm. Queue data structure is applied, which works on the principle of first-in, first-out (FIFO). It implies that the child components attained by expanding the parent component are added to the FIFO queue, and they are explored in the same order in which they arrived. In the proposed algorithms, when the instigating component is selected, it explores all the descendants of the initiating component before exploring any successor of its child components. Both the algorithms systematically search the paths to explore every component, which is reachable from the instigating component. In a single ECR algorithm, two data arrays are introduced, that is, traced array and propagated path array. Whereas, in a multiple ECRs algorithm, one additional array named as instigating components array is presented. Traced array in both algorithms is used to keep track of the in-process CPPs, while propagated path array maintains a record of the completed paths. Instigating components array in multiple ECRs algorithm stores the data of change initiating components, which depend on the number of ECRs. The inprocess CPPs are stored in the form of layers in traced array, and it serves on the rule of FIFO queue. From the literature, it is revealed that changes can usually propagate up to four change steps (Pasqual and De Weck, 2012); therefore, it is used as a stop criterion in the suggested algorithms. Inputs to both the algorithms are rework probability and impact matrices, logical dependency matrix, component design duration, instigating components, and the number of change steps. When the simulation is run, the planned rework-risk as a result ECR r1 is calculated and all the child components along with the parent component are stored in the succeeding layer of the traced array. In each step, it will assess the type of logical dependency that exists between the components. Then, the process will check the repetition of the design component pair to add the learning effect in the process. Whereas, in the case of multiple ECRs, it will also check that the new component is an instigating component or not. In the case of instigating component, the 8 Concurrent Engineering: Research and Applications 00(0) Figure 5. Flowchart for exploring propagation paths as a result of multiple ECRs. planned rework-risk due to change request rn will be calculated and added to the propagated rework-risk. If the accumulated rework-risk becomes greater than ‘‘1,’’ then it should be replaced by ‘‘1,’’ which means that the whole design of the component should be changed. In both algorithms, if the number of change steps in propagated path reaches up to four, then the path will be stored in the propagated path array along with TRD. Next, the simulation run will go back to the traced array to pick the succeeding path and hence repeat the process. Conversely, if the number of change steps is less than the defined value, then it will pick all the child components and add it to the traced array along with the parent component in the succeeding layer and repeat the process. The simulation will be executed until the traced array is empty. Thus, all the CPPs from different instigating components to the associated components are explored. Case description To demonstrate the usefulness of the proposed methods, the design project of an optical mouse is considered. The dependencies between the components and Ullah et al. 9 Table 2. Completion time of design components (Kang and Hong, 2009). S. no. Design components Completion time (days) 1 2 3 4 5 6 7 8 9 Connection cable Top case Bottom case Wheel mechanism Main board Microprocessor Click mechanism Balance weight Optical sensor 2 11 8 6 8 8 3 2 6 their design duration are taken from the article by Kang and Hong (2009). The designers’ team from the optical mouse manufacturing company was consulted regarding the initial assessment of the suggested approaches. The designers have vast experience in the related field. Both the approaches were evaluated by the designers, and it was found that the methods could help to better focus discussions on management strategies of design change requests. The optical mouse component list, along with expected completion time, is presented in Table 2. However, numeric DSMs provide information regarding dependencies and logical relationships between components, as illustrated in Figures 6 and 7. In Figure 6, the number above the line in each cell represents the rework probability, whereas the number below the line denotes the rework impact. For instance, a rework probability of 0.3 at the position of the design component (i, j) means that there is a 30% probability for changes to propagate to the component j when component i is completed. The logical dependencies between components have been acquired by consulting the designers from the manufacturing firm, as shown in Figure 7. For instance, a design change is made in Bottom case (E3), which has a 70% probability to propagate the changes to Microprocessor (E6), with the rework impact of 90%. The rework-risk for a given design component can be estimated by multiplying the respective values of rework probability and impact. Moreover, component redesign time can be computed by multiplying the rework-risk by the expected completion time. Three design changes in an optical mouse are proposed by the designer to explore the best possible approach for managing ECRs. The designer based on his experience suggests the initiating components, that is, Bottom case (E3), Microprocessor (E6), and the Optical sensor (E9) having initial rework-risk of 0.5, 0.9, and 0.7, respectively. The following sub-sections explain that how ECRs can be implemented in two different ways. Immediate implementation of ECRs In this method, ECRs are executed without any delay, and the rework is done immediately. In this case study, instigating components are categorized based on the risks mentioned in Table 1, and it is considered that change initiating components have medium and high Figure 6. Probability and impact matrix for optical mouse design process (Kang and Hong, 2009). 10 Concurrent Engineering: Research and Applications 00(0) Figure 7. Logical dependencies between the components of optical mouse. Figure 8. Redesign duration of CPPs in three different cases. initial rework-risks. The change requests are implemented separately in three distinct components, and as a result, several CPPs are achieved. The redesign duration of all possible CPPs in three different cases are shown in Figure 8. It is evident from Figure 8 that all the CPPs have different redesign duration, as well as the number of CPPs also varies. The Bottom case (E3) has medium initial rework-risk of 0.5; therefore, it gives minimum redesign duration as compared to other instigating components. In Bottom case (E3), a sudden increase in the redesign duration can be seen in Figure 8: this rise is due to high propagated risk between components Bottom case (E3) and Microprocessor (E6), as shown in Ullah et al. 11 Table 3. Accumulative number of distinct change components involved in several CPPs. S. no. Number of CPPs CPPs (%) Number of distinct components 1 2 3 4 5 6 7 8 6 42 116 236 627 1408 830 107 0.18 1.25 3.44 7.00 18.59 41.76 24.61 3.17 2 3 4 5 6 7 8 9 CPP: change propagation path. Figure 9. Number of distinct components in various CPPs for all the three initiating components. Figure 6. The Optical sensor (E9) and Microprocessor (E6), both have high initial rework-risk of 0.7 and 0.9, respectively. Therefore, they contribute substantially to accumulative redesign duration. From the above, it can be inferred that for any instigating component, the number of CPPs depends on three factors, that is, (1) the number of directly connected components, (2) rework probability and impact values, and (3) the presence of logical dependency between components. Different CPPs have distinct design components. It can be seen in Figure 9 that the frequency distribution of propagated path containing different design components varies for all the three instigating components. For Bottom case (E3), the number of distinct components reaches up to nine, while in the case of Microprocessor (E6) and Optical sensor (E9), it reaches up to eight. Although Microprocessor (E6) and Optical sensor (E9) have high initial rework-risk, the number of distinct components is less than Bottom case (E3). It owes to the fact that Bottom case (E3) propagates changes to the components, which have ‘‘And’’ logical dependency, as shown in Figure 7. It can also be witnessed from Figure 9 that in Bottom case (E3), 45.35% and 30.80% of CPPs contain seven and eight numbers of distinct components, respectively. Whereas, in Microprocessor (E6) 32.61% and Optical sensor (E9) 25% of CPPs comprise seven number of distinct components. From this analysis, it can be established that increase in a number of CPPs and distinct components not only depends on the initial rework-risk but also on the components to which the change is propagated and the logical dependencies between them. To analyze the accumulative results, consider Tables 3 and 4. The number of distinct change components involved in different CPPs is presented in Table 3, whereas accumulative redesign duration and CPPs are shown in Table 4. ECRs implementation in batch In batch processing, an appropriate sequence of ECRs is identified to avoid futile effort during the redesign process. Whereas, an appropriate sequence can be defined as ‘‘the best possible sequence of ECRs that provides minimum redesign duration for the implementation of initiated change requests.’’ First, ECRs are gathered in a group of a predefined size, followed by the execution process. In this case study, a group size of three ECRs has been defined. Therefore, each sequence comprises three components. The Bottom Case, Microprocessor, and Optical Sensor are the instigating components for each ECR. To implement the design changes, the designer should decide the execution sequence of ECRs. In this case study, following six possible sequences of design changes can be implemented: Bottom case (E3)–Microprocessor (E6)–Optical sensor (E9); Bottom case (E3)–Optical sensor (E9)– Microprocessor (E6); Microprocessor (E6)–Bottom case (E3)–Optical sensor (E9); Microprocessor (E6)–Optical sensor (E9)–Bottom case (E3); Optical sensor (E9)–Bottom case (E3)– Microprocessor (E6); Optical sensor (E9)–Microprocessor (E6)–Bottom case (E3). In all the six sequences, changes are initiated in different instigating components to satisfy the change requirements. As a result, several CPPs are obtained to 12 Concurrent Engineering: Research and Applications 00(0) Table 4. Accumulative redesign duration and number of CPPs. S. no. Component description Minimum redesign duration (days) Maximum redesign duration (days) Average redesign duration (days) Propagation Paths 1 2 3 Bottom case Microprocessor Optical sensor Total 4.19 7.28 6.54 18.01 6.94 8.45 8.07 23.46 4.29 8.24 7.09 19.62 2516 696 160 3372 CPP: change propagation path. Table 5. Redesign time and CPPs for six different sequences. S. no. Sequence Minimum redesign duration (days) Maximum redesign duration (days) Average redesign duration (days) Propagation Paths 1 2 3 4 5 6 E3–E6–E9 E3–E9–E6 E6–E3–E9 E6–E9–E3 E9–E3–E6 E9–E6–E3 15.62 15.60 15.64 17.73 10.73 12.29 45.13 48.07 22.12 33.61 32.38 24.04 26.74 26.64 18.80 24.19 18.82 17.06 968 442 23 532 78 82 CPP: change propagation path. Figure 10. Redesign duration of CPPs in batch processing. implement the changes. The redesign duration of all the propagated paths in the entire sets of sequences is presented in Figure 10. The redesign duration and number of CPPs of the entire sets of sequences are indicated in Table 5. All the six sequences have different minimum and maximum redesign duration to resolve the change requests as shown in Table 5. By comparing the results of both approaches, it can be observed that all the six sequences in batch processing have a smaller minimum redesign duration than the accumulated minimum redesign duration in individual processing. However, only one sequence E6–E3–E9 has a smaller maximum redesign duration than the cumulative maximum redesign duration in individual processing. In product designing, some tolerances are kept in the component parameters, which decrease over a period due to the incorporation of changes. Moreover, the strategy of design freeze is used for standardized and expensive components. Therefore, the designer should avoid the propagated path, which contains such components, despite the fact that they have minimum redesign duration. In view of the above, the conclusion is made on the basis of average redesign duration because it represents the entire sets of propagated paths. The average redesign duration of three sequences, that is, E6–E3–E9, E9–E3–E6, and E9–E6–E3 provide better results than the individual processing as highlighted in Table 5, while other three give the worst result as compared with individual processing. It can be apprehended from Figure 11 that the path distribution in all the six sequences is different in perspective of a numbers of distinct design components. It is evident from Figure 11 that seven and eight numbers of distinct components are involved in 85.54% and 88.69% of CPPs in sequences E3–E6–E9 and E3–E9–E6, respectively. Whereas, in sequences E9–E6–E3 and E6– E3–E9, the path distribution is almost uniform. The entire sets of sequences have 71.55% of propagated paths, which contain seven and eight numbers of distinct change components while only 5.04% of CPPs contain nine numbers of distinct change components as shown in Figure 11. In most cases, the propagated path comprising a fewer number of change components will be easier to execute the changes with lesser time. The Ullah et al. Figure 11. Number of distinct change components in various CPPs for six different sequences. results from the above-conducted study show that performing ECRs in a batch with a proper sequence has a significant impact on the design process duration. To verify these findings further, the outcomes were later presented to the designer team from the optical mouse manufacturing company. The designers appreciated achieved results and stated that they have no idea that the execution sequence of ECRs has such drastic effects on the redesign duration of CPPs. The designers’ team suggested that the proposed technique may be assessed further by considering more complex case examples. Concluding remarks and future work Managing ECRs in a batch processing with appropriate sequence provides better results than individual processing. Moreover, ECRs execution sequence has a substantial effect on the PD process in terms of lead time. In this article, two different techniques individual and batch processing were introduced to manage ECRs during the PD process. These techniques are based on the time computing models where iterations of the earlier design components are also considered. The process starts with building the product model in view of the rework probability and impact matrices. The product design process is described by considering the logical relationships ‘‘And/Or’’ between the components. ECRs are categorized by urgency and rework-risk, whereas the term rework-risk is applied to the amount of rework required to be done to redesign the product’s components. All the CPPs are explored in product’s structure using the proposed algorithms and a mathematical model. An example based on an optical mouse design process illustrated the feasibility of the suggested methods. Three ECRs having different initial rework-risks are considered to compare the outcomes of both approaches. In the first method, after the change 13 initiation, ECRs are implemented immediately and the rework is done without any delay. While in the second approach, ECRs are treated in a batch and the execution takes place when a group of predefined size is collected. In batch processing, six possible sequences of design changes are implemented. The sequence E9–E6– E3 causes 15% decrease in the redesign duration of CPPs whereas another sequence E3–E6–E9 results in 36.23% increase in the redesign duration of CPPs as compared with individual processing. Based on the case study, it can be inferred that the number of CPPs and distinct design components not only depends on the initial rework-risk but also on the components to which the change is propagated and the logical dependencies between them. The results from a single, simple case study indicates that running ECR batches with proper sequence can be beneficial. The authors, however, admit that more work is required to validate the modeling approach further. The case study discussed in this research work is simple, having a few coupled components, whereas the component dependencies increase substantially in complex products. Therefore, the suggested approach may be extended to complex systems, which as a result increases the research scope and also provides opportunities to assess the techniques against more complex products. The proposed approach has one limitation: it cannot be applied if ECRs are of safety critical nature. Because, in safety critical nature ECRs, an immediate action is required as the process is much more focused on the quality and functionality of the product rather than the lead time or cost. Acknowledgements The authors express their gratitude to the anonymous reviewers for their insightful feedback. Declaration of conflicting interests The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article. Funding The author(s) disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: This work was supported by the National Natural Science Foundation of China under grant number 51575264 and Qing Lan Project. References Acar BS, Benedetto-Neto H and Wright IC (1998) Design change: problem or opportunity. In: Engineering design conference, Brunel University, UK, 23–25 June 1998, pp. 445–454. London, UK: Professional Engineering Publishing. 14 Andersson J, Pohl J and Eppinger SD (1998) A design process modeling approach incorporating nonlinear elements. In: ASME 10th international conference on design theory and methodology, Atlanta, GA, 13–16 September. Balcerak KJ and Dale BG (1992) Engineering change administration: the key issues. Computer Integrated Manufacturing Systems 5(2): 125–132. Balogun J and Jenkins M (2003) Re-conceiving change management: a knowledge-based perspective. European Management Journal 21(2): 247–257. Clarkson PJ, Simons C and Eckert CM (2004) Predicting change propagation in complex design. Journal of Mechanical Design 126(5): 788–797. Cohen T, Navathe SB and Fulton RE (2000) C-FAR, change favorable representation. Computer Aided Design 32(5–6): 321–338. Dijkstra EW (1959) A note on two problems in connexion with graphs. Numerische Mathematik 1(1): 269–271. DiPrima M (1982) Engineering change control and implementation considerations. Production and Inventory Management 23(1): 81–87. Earl CF, Eckert CM and Clarkson PJ (2005) Design change and complexity. In: 2nd workshop on complexity in design and engineering, Glasgow, 10–12 March. Eckert C, Clarkson PJ and Zanker W (2004) Change and customisation in complex engineering domains. Research in Engineering Design 15(1): 1–21. Eckert CM, Pulm U and Jarratt TAW (2003) Mass customization, change, and inspiration–changing designs to meet new needs. In: Folkeson A, Gralen K, Norell M, et al (eds) 14th international conference on engineering design, Stockholm, Sweden, 19–21 August, pp. 1–10. Glasgow: The Design Society. Giffin M, De Weck O, Bounova G, et al. (2009) Change propagation analysis in complex technical systems. Journal of Mechanical Design 131: 081001. Hamraz B, Caldwell NHM and Clarkson PJ (2012) A multidomain engineering change propagation model to support uncertainty reduction and risk management in design. Journal of Mechanical Design 134(10): 100905. Hamraz B, Hisarciklilar O, Rahmani K, et al. (2013) Change prediction using interface data. Concurrent Engineering: Research and Applications 21(2): 141–154. Harker SDP, Eason KD and Dobson JE (1993) The change and evolution of requirements as a challenge to the practice of software engineering. In: IEEE international symposium on requirements engineering, San Diego, CA, USA, 4–6 January 1993, pp. 266–272. IEEE. Hollins B and Pugh S (1990) Successful Product Design. London: Butterworths. Huang GQ and Mak KL (1998) Computer aids for engineering change control. Journal of Materials Processing Technology 76(1–3): 187–191. Huang GQ and Mak KL (1999) Current practices of engineering change management in UK manufacturing industries. International Journal of Operations & Production Management 19(1): 21–37. Concurrent Engineering: Research and Applications 00(0) Huang GQ, Yee WY and Mak KL (2003) Current practice of engineering change management in Hong Kong manufacturing industries. Journal of Materials Processing Technology 139(1–3): 481–487. Hull E, Jackson K and Dick J (2005) Requirements Engineering. London: Springer. INCOSE (2010) Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities (INCOSE-TP2003-002–03.2). John Wiley & Sons Inc. Inness J (1994) Achieving Successful Product Change. London: Financial Times/Pitman Publishing. Jarratt TAW, Clarkson PJ and Eckert CM (2004) Engineering change. In: Clarkson PJ and Eckert CM (eds) Design Process Improvement: A Review of Current Practice. London: Springer, pp. 262–285. Jarratt TAW, Eckert CM, Caldwell NHM, et al. (2011) Engineering change: an overview and perspective on the literature. Research in Engineering Design 22(2): 103–124. Kang C and Hong YS (2009) Evaluation of acceleration effect of dynamic sequencing of design process in a multiproject environment. Journal of Mechanical Design 131(2): 021008 (11 pp.). Keller R, Eckert CM and Clarkson PJ (2009) Using an engineering change methodology to support conceptual design. Journal of Engineering Design 20(6): 571–587. Kidd MW and Thompson G (2000) Engineering design change management. Integrated Manufacturing Systems 11(1): 74–77. Lam W and Shankararaman V (1999) Requirements change: a dissection of management issues. In: 25th EUROMICRO conference: informatics: theory and practice for the new millennium, Milan, 8–10 September, pp. 244–251. New York: IEEE. Lee HJ, Ahn HJ, Kim JW, et al. (2006) Capturing and reusing knowledge in engineering change management: a case of automobile development. Information Systems Frontiers 8(5): 375–394. Li W and Moon YB (2012) Modeling and managing engineering changes in a complex product development process. The International Journal of Advanced Manufacturing Technology 63(9): 863–874. Li YL and Zhao W (2014) An integrated change propagation scheduling approach for product design. Concurrent Engineering: Research and Applications 22(4): 347–360. Lindermann U and Reichwald R (1998) Integriertes Anderungsmanamement. Berlin, Heidelberg: Springer. Love PED (2002) Influence of project type and costs in building procurement method on rework construction projects. Journal of Construction Engineering and Management: ASCE 128(1): 18–29. Maier JF, Wynn DC, Biedermann W, et al. (2014) Simulating progressive iteration, rework and change propagation to prioritise design tasks. Research in Engineering Design 25(4): 283–307. Masmoudi M, Leclaire P, Zolghadri M, et al. (2017) Change propagation prediction: a formal model for twodimensional geometrical models of products. Concurrent Engineering: Research and Applications 25(2): 174–189. Ullah et al. Maull R, Hughes D and Bennett J (1992) Special feature. The role of the bill-of-materials as a CAD/CAPM interface and the key importance of engineering change control. Computing & Control Engineering Journal 3(2): 63–70. Mohringer S (2006) From design errors to chances—a computer-based error tracking system in practice. In: International design conference, Dubrovnik, 15–18 May, pp. 943–950. Bristol: The Design Society. Morkos B and Summers JD (2010) Requirement change propagation prediction approach: results from an industry case study. In: ASME international design engineering technical conferences, Montreal, QC, Canada, 15–18 August, pp. 111–121. New York: ASME. Nadia B, Gregory G and Vince T (2006) Engineering change request management in a new product development process. European Journal of Innovation Management 9(1): 5–19. Nuseibeh B and Easterbrook S (2000) Requirements engineering: a roadmap. In: Conference on the future of software engineering, Limerick, 4–11 June, pp. 35–46. New York: ACM. Ollinger GA and Stahovich TF (2001) RedesignIT – a constraint-based tool for managing design changes. In: ASME design engineering technical conferences, Pittsburgh, PA, 9–12 September, pp. 197–207. New York: ASME. Pahl G and Beitz W (1998) Engineering Design: A Systematic Approach. London: Springer. Palmer G, Morkos B and Summers JD (2010) Investigation of design tools as complexity management techniques. In: ASME international design engineering technical conferences, Montreal, QC, Canada, 15–18 August, pp. 511–522. New York: ASME. Pasqual MC and De Weck OL (2012) Multilayer network model for analysis and management of change propagation. Research in Engineering Design 23(4): 305–328. Pikosz P and Malmqvist J (1998) A comparative study of engineering change management in three Swedish companies. In: ASME design engineering technical conference (DETC98), Atlanta, GA, 13–16 September, pp. 1–11. New York: ASME. Reidelbach PE (1991) Engineering change management for long-lead-time production. Production and Inventory Management 32(2): 84–89. Shankar P, Morkos B and Summers JD (2012) Reasons for change propagation: a case study in an automotive OEM. Research in Engineering Design 23(4): 291–303. Shapiro D, Hamraz B, Sommer AF, et al. (2015) Investigating the impact of changes in iteration-likelihoods on design process performance. Concurrent Engineering: Research and Applications 23: 250–264. 15 Sugden RC and Strens MR (1996) Strategies, tactics and methods for handling change. In: IEEE symposium and workshop on engineering of computer based systems, Friedrichshafen, 11–15 March, p. 457. New York: IEEE Computer Society. Tang D-B, Yin L-L, Wang Q, et al. (2016) Workload-based change propagation analysis in engineering design. Concurrent Engineering: Research and Applications 24(1): 17–34. Terwiesch C and Loch CH (1999) Managing the process of engineering change orders: the case of the climate control system in automobile development. Journal of Product Innovation Management 16(2): 160–172. The Standish Group (1995) The Standish group report. Chaos 1: 8. Ullman D (2003) The Mechanical Design Process. New York: McGraw-Hill Education. Ulrich KT and Eppinger SD (1995) Product Design and Development. New York: McGraw-Hill Education. Van Bossuyt DL, Dong A, Tumer IY, et al. (2013) On measuring engineering risk attitudes. Journal of Mechanical Design 135(12): 1–13. Vianello G and Ahmed-Kristensen S (2012) A comparative study of changes across the lifecycle of complex products in a variant and a customised industry. Journal of Engineering Design 23(2): 99–117. Wasmer A, Staub G and Vroom RW (2011) An industry approach to shared, cross-organisational engineering change handling–the road towards standards for product data processing. Computer-Aided Design 43(5): 533–545. Watts F (1984) Engineering changes: a case study. Production and Inventory Management 2(4): 55–62. Worinkeng E and Summers JD (2014) Analysing requirement type influence on concept quality and quantity during ideation: an experimental study. In: ASME international design engineering technical conferences, Buffalo, NY, 17– 20 August. Wright IC (1997) A review of research into engineering change management: implications for product design. Design Studies 18(1): 33–42. Yu X, Yang Z, Wang G, et al (2013) Study on design change review for small and medium-sized enterprises. In: 2013 IEEE international conference on industrial engineering and engineering management, Bangkok, Thailand, 10–13 December, pp. 556–560. New York: IEEE. Zhang J, Song X, Chen H, et al. (2015) Optimisation of critical chain sequencing based on activities’ information flow interactions. International Journal of Production Research 53(20): 6231–6241. 16 Concurrent Engineering: Research and Applications 00(0) Appendix 1 Notation kn number of change steps as a result of nth change request K m total number of change steps in a single CPP number of product0 s components n Pl RR(r, ci ) number of change requirements planned rework risk from change request 0 r0 to instigating component 0 ci 0 Pr RR(ck2 , ck1 ) propagated rework risk between any two successive components RIij RPij rework impact between component 0 i0 and 0 j0 rework probability between component 0 i0 and 0 j0 RR(ci , cj ) rework risk between component 0 i0 and 0 j0 RRKr1 r2 rn (ci , cj ) rework risk propagated from component 0 i0 to 0 j0 as a result of 0 n0 change requests in 0 K 0 steps TRD x total redesign duration of propagated path number of iterations y number of changes caused by change requests Author biographies Inayat Ullah is a Ph.D. candidate at Nanjing University of Aeronautics and Astronautics, Nanjing, China. He received his Master degree in industrial and manufacturing engineering from University of Engineering and Technology Taxila, Pakistan in June 2010. His research is mainly focused on Engineering Design, Engineering Change Propagation, Design Change analysis and optimization. Prof. Dr. Dunbing Tang earned his Ph.D. from Nanjing University of Science and Technology (NUST). During 2002-2005, he conducted the scientific research at Aachen University (Germany) and Cranfield University (UK). He joined Nanjing University of Aeronautics and Astronautics at the end of 2005. Prof. Tang’s research interests include Intelligent Manufacturing System and Automation, Product Design Theory and Methodology. Qi Wang is currently a Ph.D. candidate at the College of Mechanical and Electrical Engineering, Nanjing University of Aeronautics and Astronautics, China. His research interests include Product Design Theory and Methodology. Leilei Yin is currently a Ph.D. candidate at the College of Mechanical and Electrical Engineering, Nanjing University of Aeronautics and Astronautics, China. His research interests include Product Design Theory and Methodology, Design Change analysis and optimization. Ishfaq Hussain is currently pursuing the M.S. degree (Communication and Information System) at Nanjing University of Aeronautics and Astronautics, Nanjing, China. His research interests include programming, algorithm development, computational electromagnetics, and communication systems.