ESTIMATING THE PROCESS COST OF IMPLEMENTING ENGINEERING CHANGE ALTERNATIVES

Transcription

1 2 nd Nordic Conference on Product Lifecycle Management NordPLM 09, Göteborg, January ESTIMATING THE PROCESS COST OF IMPLEMENTING ENGINEERING CHANGE ALTERNATIVES Naveed Ahmad, David C. Wynn and P. John Clarkson Abstract Requirement changes can arise at many points throughout the product life-cycle. Meeting these changed needs necessitates engineering changes to the design. There are various methods and tools to understand such engineering changes in terms of the knock-on effects which could propagate through the system and require change to many other elements of the design. However, there is currently little support to help designers and managers evaluate proposed changes in terms of the total process cost of implementing them and executing any knock-on rework which may occur. Such support would be useful since there are often multiple ways to implement a requirement change, and it is thus important to identify the most cost-effective option prior to beginning its implementation. This paper proposes the basis of a model-based approach to provide such support. The approach is illustrated by discussing its application to the example of bicycle design. Further work to enhance and implement the approach is outlined. Keywords: Engineering Change Implementation Process, Change Prediction Method, Applied Signposting Model (ASM) 1 Introduction Designers can often identify alternative ways to implement a change request. However, evaluating which of the multiple options would be most cost-effective to implement or whether the change is feasible at all can be difficult. This arises in large part since change implementation cost is influenced by the product, the redesign process and other processes which are executed concurrently in the organisation: 1. The product. Engineering change initiated in one element of the design tends to propagate between other, related elements [1]. The total cost of implementing a given change therefore includes the cost of redesigning not only the initiating aspects of the design, but also all other aspects which will ultimately require modification due to change propagation. 2. The redesign process. Each aspect of the design which requires change must be modified by undertaking one or more redesign tasks. This might involve rework of tasks which were completed earlier in the design process as well as the execution of new redesign tasks. Since processes can be viewed as networks of interconnected tasks which derive output information from input information, knock-on rework could also be required to many tasks downstream of those originally executed to redesign the affected elements of the product. Total implementation cost thus includes the cost of executing not only those redesign tasks initiated directly, but also those requiring indirect rework. Cost is also influenced by the amount of rework required for each task, which may be different from the amount of work required on the first attempt. 1

2 3. Interaction with other processes. Change must often be implemented concurrently with other design activities, for instance if the change request arises during the design process or if multiple changes are implemented concurrently. The process of implementing a change interacts with the ongoing workflow since it requires consideration of, and manipulation to, the same descriptions of the design this could necessitate additional assumptions and drive iterations. Furthermore, if the change must be implemented by the same personnel responsible for other workflows, resource limitations may affect the total duration of the implementation process. The implications and overheads of executing multiple concurrent workflows thus also affect the total cost of implementing a change request. The importance of estimating the cost of different change implementation options is not limited to the design process, but can be critical at all stages in the product life-cycle. For instance, implementing a change while a product is in production will potentially be much more expensive than making the same change during design. Thus it is important to ensure that appropriate change implementation decisions are made throughout the product life-cycle. The research presented in this paper is motivated by the need to guide such decisions. We introduce the basis for an approach to support designers and managers in analysing the cost of change implementation processes. The proposed approach is based on a model which combines three aspects of the design process system: 1) elements of the product and the ways in which change can propagate between them; 2) the descriptions or packages of information which describe different aspects of the product and are used during the design process; and 3) the tasks in the design process, their sequencing and input-output relationships to the design descriptions. We show how implementation cost can be estimated by systematic consideration of linkages within and across the different domains of this model. The paper proceeds as follows. Section 2 reviews the existing research on change management and on the implications of engineering changes to the design process, thus motivating the need for further research in this area. Section 3 introduces the proposed support method. Section 4 and 5 respectively illustrate the approach through discussion of an example model of bicycle design, and examination of a hypothetical change case via step-bystep evaluation of the model. Section 6 summarises the contribution of the paper and outlines directions for further work in this area. Section 7 concludes. 2 Background Engineering change is ubiquitous throughout the life-cycle of a product. Our case studies conducted at GKN Westland Helicopters, together with other companies, indicate the importance of managing changes and predicting the cost of change implementation [2]. In particular, these studies indicated that poor understanding of change implementation processes may lead to longer development time and thereby to less profitable projects. There is thus a need for support tools to assist in the management of engineering change and of the associated processes. This section reviews change management tools and approaches available today. Some limitations of these approaches are highlighted by considering the aspects of change implementation outlined above, thus motivating the development of a new approach. 2.1 Engineering change management literature and tools There has been a significant increase in the published literature on engineering change management in the past decade. The literature review published by Wright [3] indicates the 2

3 scarcity of research in this area until the late nineties. Research in change management can be divided broadly in to two kinds of methods and tools: approaches to record and report changes, e.g., [4]; and approaches to model and analyse engineering changes, e.g., [5], [6], [7]. The latter category, which is most relevant to this paper, has resulted in various methods and tools to analyse the impact of changes on a product. These include risk analysis techniques, approaches to help communicate changes to the different stakeholders involved in product development, and methods to help identify the knock-on effects of change to one component. These knock-on effects propagate through the design and may ultimately require redesign of many other components and sub-systems. Since they account for a major component of implementation cost we review methods to evaluate them below. Approaches to analyse change propagation in a product include C-FAR, Redesign-IT and CPM. C-FAR (Change FAvorable Representation) captures product data as entities, attributes of each entity and relationships between attributes of different entities [6]. This method provides a qualitative analysis of engineering change. However, modelling a product in terms of entities and attributes is difficult for complex products comprising many components and sub-systems. Redesign-IT is based on a model of the product as causal relationships between exogenous quantities, which represent both physical properties of the device s components and descriptions of the device s operations [8]. This model is used to generate several possible changes in the quantities to reach the desired goal, and to select the best choice. This method does not estimate the exact values required to implement a change, but just the direction of the modification to each quantity. Finally, the Change Prediction Method (CPM) is based on a model of the product as components and their connections through linkages [5]. Each linkage connects two components and is qualified with the likelihood of change to one component propagating to the other, and the impact of the propagated change which could be interpreted as the percentage of redesign which would be required in the event that propagation does occur. The likelihood and impact values associated with each linkage are intended to be estimated by domain experts based on past experience of changes to similar products. The method can be used to predict the risk of change propagation in the product and to identify the components which are most likely to cause or to require change. 2.2 Engineering change implementation processes There is thus significant literature focusing on change from a product perspective. However, far fewer publications analyse change in terms of its implementation process or discuss in detail the relationship between change and rework. A few authors have recently begun to explore this aspect of change management by discussing changes in the context of the design process [9]. For instance, Gärtner et al. propose a simulation model for evaluating the impact of a given change implemented during the design process upon that process s total duration [10]. Eger s research on design freeze discusses the effect of engineering changes on the design process and how this is influenced by the timing of freezes [2]. According to Eger, changes which are encountered early in the design process can be implemented in many different ways as the designer can still consider a wide design space, whereas as the process continues, components and parameters are incrementally frozen. This precludes subsequent change to these aspects and thus narrows the space of possible implementation options. The approach of design for changeability aims to provide support to design a product so that it can more easily be adapted to meet future change requests [7], [11]. Another research area which explores the relationship between changes and their implications on the design process is requirement traceability. By tracing changes in requirements through different layers of the design process, the tasks which might require rework could be identified. For instance, QFD/House of Quality can support this through the mapping 3

4 between customer attributes and engineering characteristics which implement them [12]. Various authors have used Multiple Domain Matrices (MDMs) to model the relationships between different process, product and organisational domains. These techniques could also be used to identify the engineering change and rework arising from a changed requirement, as requirements can be directly mapped to the related components and tasks. Requirement traceability has also been used for change impact analysis in software. For instance, Dick suggested a change management approach operating in this way [13]. On the other hand, the information required to construct traceability models is significant. Kilpinen reviews change impact analysis techniques in systems engineering and software design, and argues that the cost of maintaining the data for traceability analyses may not always justify the benefits [14]. 2.3 Summary To recap, various methods have been proposed to analyse and document changes in products. These methods vary in the mode and complexity of capturing the product information. Several identify alternatives to implement a change, but none of the methods discussed above supports the designer in evaluating the process cost of implementing change alternatives. Furthermore, although the implementation process is an important aspect of change management, and is critical to evaluating change cost and feasibility, there is currently little research focusing on the process implications of an engineering change request. This paper contributes to the discussion of engineering change by presenting a process-oriented approach to view, analyse and ultimately support the implementation of change alternatives. 3 Overview of the approach The approach proposed in this paper is based on the analysis of a product model, a design process model and a combining model which links aspects of the product to the descriptions which are considered and modified during the process. It is assumed that the architecture of the product and process are both relatively stable and thus that these models can be constructed once and re-used to evaluate subsequent change requests. This assumption holds for complex adaptive products such as aero-engines, where the product architecture remains similar across product generations and the design process is well-structured. However, the proposed approach would be less appropriate for more innovative design. The product model is a form of Dependency Structure Matrix (DSM) [15] which decomposes a product into its key elements (which may include components, subsystems and parameters) and defines the ways in which change may propagate between them. The design process is represented using the Applied Signposting Model (ASM) [16], a graphical notation and simulation approach in which the sequence of task execution is constrained by the design descriptions which each task requires and produces. The combining model is a form of Domain Mapping Matrix (DMM) [17] which indicates which descriptions in the process model encompass which design elements in the product model. Together, these three models can be used to assist the designer or design manager in estimating the total cost of implementing a given change. They form the basis of a systematic approach to consider the knock-on consequences of change alternatives in both product and process domains. The benefit of this systematic approach lies in its provision of a checklist to help avoid overlooking activities which will need to be performed to implement a proposed change. We argue this could help designers and managers estimate change costs more accurately and thereby make better decisions between alternative implementation options. The approach is outlined below prior to a more detailed description and illustrative example in Section 4. 4

5 Figure 1. Overview of the proposed approach. Our method begins with a change request. The following steps are then undertaken to estimate the cost of that change: 1. Identify initiating element(s) of the design. Each change request which must be implemented requires one or more elements of the design to be changed. Furthermore, a requirement change request may often be implemented in multiple ways. If alternative implementation options (i.e., initiating elements) are identified, steps 2-6 may be carried out for each alternative to help identify the most cost-effective option. 2. Estimate knock-on change to other elements. Knock-on changes are identified by using the product DSM to systematically consider linkages between product elements. This is based on the assumption that change can only propagate from one element to another if they are directly connected. For each element in the product DSM which is connected to the initiating element, the designer must decide whether or not that second-level (L2) element will also require change to implement the alternative being considered. For each L2 element requiring change, the connected L3 elements are identified and considered, and so on. This results in a list of all elements of the product which are believed to require direct or indirect change. 3. Identify design descriptions for modification. The DMM is used to identify the descriptions which must be modified to update the elements identified in Step Estimate direct redesign effort. The total effort required to update all descriptions identified in Step 3 is estimated by the designer or manager based on past experience. 5. Estimate knock-on rework to downstream tasks. Information flows in the process model are systematically considered to identify knock-on rework. This is based on the assumption that a change to the description(s) which are used as input to a task may propagate to cause change in the description(s) which are output from the task. For each task which uses a changed description as input (an L1 task), the designer must thus estimate whether rework is required, and if so, the amount of change which will be required in the output descriptions. Tasks which use changed L2 descriptions as inputs (L2 tasks) must then be considered for rework, and so on until all knock-on 5

6 rework is identified. Propagation of rework through tasks in the design process is thus considered analogous to propagation of change through elements of the product. 6. Estimate total implementation effort. The amount of resources required and the time to complete all tasks identified in Step 5 must be estimated to determine the cost and duration of the process for implementing the change alternative. 4 Illustrative example: bicycle design In this and the following section, an example of bicycle design is discussed to illustrate the approach. In the following sub-sections the bicycle s product model, process model and the combined model are presented for this example these were constructed by examining technical literature on bicycle design [18]. In an industry context, different techniques could be used to identify the elements of the product and process and their relationships, including interviews, discussion in group workshops and examination of existing documentation. According to Jarratt [19], group discussions are often the most effective approach for product modelling because most individuals do not sufficient overview of the whole product to ensure that important linkages are not overlooked. On the other hand, when building a model of detailed process steps, much specialist knowledge can be elicited effectively from the designers who perform groups of tasks individually prior to handing over the results of their work [16]. 4.1 Product DSM Figure 2 shows how the bicycle is decomposed into key components, parameters and features which are then used to construct the product DSM. In the DSM, the elements of the product are listed as rows and columns in the same order. A mark in the matrix indicates that change may propagate from the element in the column to that in the row. In this example, certain angles and features of the bicycle are identified alongside the components. These parameters and features are significant in the bicycle design process since they are considered during several different tasks. In our approach, it is assumed that components (such as the wheels), parameters (such as the angles) and features of components (such as the top tube A, which can be viewed as a feature of the frame), may all act to initiate, propagate or receive change. As such, they are all considered as elements of the design and are listed in the product DSM for consideration in the change propagation analysis. The product DSM in this example is relatively simple in that functional couplings between elements are not taken into account. One example of functional coupling is that the brake levers are located on the handlebar stem whereas the brakes are fitted on the wheels. The function stop the bicycle therefore directly connects the handlebar stem with the wheels, although they are not physically adjacent. This situation could be modelled by incorporating the function as an additional element in the product DSM, indicating that a change to the function would require change to all associated components. 4.2 ASM process model A subset of the ASM model of the bicycle design process is also shown in Figure 2. The model is composed from Tasks (rectangles), Iteration Constructs which may drive rework (diamonds), Interactions with design parameters, which are referred to as descriptions in this paper (ellipses), and Sub-processes. The model assumes that a task must be attempted when its input information is updated, and that this in turn causes output information to be updated. In the course of a normal design process, therefore, the input requirements which are 6

7 considered during the first task in the process are updated by an external task performed by the customer, who wishes to initiate the design of a product which is similar to a design for which the process was previously used. In the context of change implementation, a change request results in a set of external tasks being executed, resulting in a set of updated descriptions which may be distributed throughout the process. The model may then be used to identify the knock-on rework which results from these descriptions being changed. 4.3 Combining DMM Figure 2 shows an extract from the combining DMM. Each mark in this matrix indicates that an element in the product DSM (shown as column headings) is represented by a description Figure 2. Bicycle example (Product DSM, ASM process model, Combining DMM). 7

8 in the process model (in the row). Note that this is an M..N mapping; multiple descriptions can represent the same product element, and multiple product elements can be represented in the same description. 5 Example change case To illustrate the proposed method, consider the following requirement change to the bicycle: steering must be made more effective. This could be achieved in a number of ways, including: change the bearing (M); change the wheelbase; change the head angle; change the steering angle; and so on [18]. The example scenario is summarised in Figure 3. In this figure, three implementation alternatives are in the three columns. Different layers of the figure show the stages of evaluating each alternative using the proposed method. Each step of the method is illustrated below using this example. 5.1 Identify initiating element(s) Figure 3. An example change case using the bicycle example. The first step of the method is to identify the elements of the design that will be redesigned to implement each change implementation option. This step is not discussed in detail here, but could be approached in various ways. For instance, requirement traceability methods could be used to track the changes in the attributes to the product element that will be affected by the change. Alternatively, initiating elements could be identified directly from past experience. 8

9 5.2 Estimate knock-on change to other elements In this step, the set of product elements that will require redesign due to change propagation is identified. Figure 4 (right) shows the propagation tree of the Change Fork Offset alternative in Figure 3, which is developed by systematically considering the linkages between elements in the product DSM. This tree of possibilities must be pruned to identify those elements which will be changed in this specific case. The proposed method comprises two steps to guide selection of the product elements that will require redesign. These steps are illustrated below by discussing the example of the initiating change made to the Fork Offset parameter (initiating change through Fork D ; second column in Figure 3). Figure 4. Propagation tree developed from the product DSM for implementation alternative 2. Step I: This step aims to identify how change propagation will occur through the product. The information is gained from the product DSM (see Figure 2), supplemented by estimates of the likelihood and impact of change propagating through each linkage between two product elements. Jarratt describes how these values can be estimated through group workshops, in which domain experts are asked to consider each identified linkage in turn [19]. The Change Propagation Method (CPM) proposed by Clarkson et al. [5] is then used to estimate the combined risk matrix (Figure 5). This matrix indicates the total risk of change initiated in one element (the column heading) propagating to any other element in the product (in the row), either directly or through a chain of intermediate connections. For instance, considering the product DSM in Figure 4, change can propagate from A-B directly, or indirectly via A-C-B, A-D-B etc. The CPM algorithm described in [5] calculates the combined risk of change propagating from A-B through any of these possible routes and visualises this as a color-coded block in the appropriate cell of the combined risk matrix. Based on the combined risk matrix, for a particular change case all the elements in the tree may be ranked in increasing order of combined change risk. Each element can be ranked in two ways, namely global risk rank and local risk rank: Global risk rank is based on the risk of change propagating to the element under consideration through any path from the initiating element ( D in this particular case). Local risk rank is based only on the risk of change propagating from the product element at the previous level in the propagation tree. It is important to consider local rank in addition to global rank, since the global rank provides a mean value whereas the local rank indicates the risk of change propagation given that change propagation at the previous level had already occurred. Thus, in some circumstances a high direct 9

10 propagation risk might be obscured in the global ranking due to the averaging effect of many low indirect risks through other propagation paths. In the tree of Figure 4, the global risk rank of any given element is independent of where in the tree it appears, regardless of the number of times it appears, because in each case the risk of propagation is calculated with respect to the initiating element D only. The global risk ranking of all elements when the initiating element is D is C, H, I, J, K, B, A, G, F, L, E (with C being the highest ranked and E being the lowest ranked element). In contrast, the local risk rank is dependent upon the position of the product element in the tree. In this example, at level (0) the local risk rankings of the element list (A, B, E, F) is based on D at level (1) the local rankings of (K, I, F, C, B), (A, C, H, J) and (A) are based on the risk of direct change propagation from A, B and F respectively. Figure 5. Calculation of the combined risk matrix from the product DSM with likelihood and impact estimates. The linkage profile of the product element being explored can also provide guidance in determining whether that element will require change. For instance, if the change propagation path considered is D-A-B-C, the linkage-profile of the element C will be the type of link from D-A, A-B and B-C. The example in this paper is straightforward in this regard as only the spatial links are considered. However, where multiple linkage types are included in the product DSM the linkage profile may be used to further prune the propagation tree. For instance, a temperature change might be expected to impact upon product elements connected through physical relationships only, and not (for instance) between those whose only relationship is through an information linkage used as part of a control system. Step II: The objective of computing the global and local risk rankings and of considering linkage profiles is to assist designers in deciding whether a change will propagate through each link in the propagation tree. When each element in the propagation tree is considered to determine whether that element will require change, each of these values can be considered to guide the decision. For elements which are identified as requiring change, the procedure is then repeated for the elements at the next level in the tree, and so on until all elements expected to receive change have been identified. Figure 6 illustrates how the steps above facilitate the designer in pruning the tree and identifying the affected elements of the design. The selection of elements is performed manually by considering the specific change case in the context of the guidance which is derived from a generic model. In this case, after the traversal of the trees for the alternative options the affected elements for the alternative implementation options 1,2 and 3 in Figure 3 are (A, B, C, J, K), (A, B, C, D) and (A, B, D, E) respectively. 10

11 Figure 6. Identification of affected product elements for implementation alternative Identify design descriptions which must be modified Once the list of affected product elements is available, the combining DMM shown in Figure 2 may be examined to identify all descriptions which represent them in the design process. For the bicycle example, the descriptions requiring modification for each of the three implementation alternatives of Figure 3 are shown in Table 1 below. Table 1. Descriptions requiring change to implement each alternative. Implementation alternative Elements requiring change Descriptions requiring change 1 A, B, C, J, K 2, 5, 9, 10, 14, 15, 17, 28, 29, 30 2 A, B, C, D 2, 6, 15, 16, 25, 27 3 D, E 23, 24, 25, Estimate direct redesign effort Table 1 shows the descriptions which encompass the product elements which require change for each alternative. The designer must therefore estimate the work required to update each of these descriptions in order to implement the change. The current approach does not directly support the estimation of this direct redesign effort. However, by indicating the descriptions which must be updated it provides a checklist to help ensure that required activities are not overlooked. Further work to support estimation of redesign effort is discussed in Section Estimate knock-on rework to downstream tasks Modifying a design description can propagate to require the rework of many downstream tasks. For instance, the arrows overlaid on Figure 7 indicate some of the potential knock-on rework required to fully implement change alternative 2 from the bicycle example. In the case of the change steering angle option, tasks in the sub-process design frame would require rework, thus causing knock-on changes to the frame measurements description. This is used as input to the tasks design fork sub-process, design fork sub-process, design seat post, design cassette and design handlebar stem. If rework of the task design seat post is required, it will lead to changes in the description measurement to saddle resulting in knock-on rework to the task design saddle (shown by the solid black line). For this simple 11

12 example the knock-on rework may be quite simple to locate, but for more complex design processes using the process model to trace through process connections and systematically consider possible rework could help avoid overlooking activities which must be performed. 5.6 Estimate total implementation effort The total implementation effort for a given change alternative can be expressed in terms of the time and resource required to rework all affected tasks identified in Sections 5.4 and 5.5. Various issues must be considered to evaluate this effort once the tasks requiring direct and knock-on rework are identified. For instance: Does the whole task require rework, or is only partial rework required? Are other activities which were not part of the original design process and thus not captured in the process model required to perform the redesign work? Similarly, it may be important to consider activities which may be undertaken in parallel with the change implementation process, since the concurrency may result in resource constraints and bottlenecks as well as additional design iterations caused by the simultaneous modification of the design. These issues will be explored in future work. Figure 7. Knock-on rework can propagate through tasks in the design process. 6 Discussion and future directions This paper has presented research developed during the first year of a Ph.D. project. As such there is much further work still required to explore the issues, implications and implementation of the proposed approach. The main contributions of this paper are as follows. Firstly, we identify the need for process-oriented support of engineering change implementation, an area not explored in detail in the existing literature. Secondly, we identify the need to consider knock-on rework in the design process alongside the more widely discussed knock-on effect of changes to the product in order to estimate the cost of implementing engineering change. Finally, we propose the outline of a method to support designers in estimating the cost of alternative change implementation options, based on systematic consideration of a cross-domain model capturing elements of the product together with its design process. 12

13 In future, the proposed approach will be developed further through industry case studies. A key aspect which we aim to examine through these studies is to understand how the magnitude and type of a change made to a product element or description affects the amount of rework required on subsequent design tasks, and how this propagates to determine the magnitude and type of change in the design tasks output descriptions. We envisage that gaining this understanding could allow the modelling of design elements and descriptions not just as binary entities, but as entities which are qualified by meta-data describing their context in the design process, in terms such as the current confidence in the information and the percentage and type of change from a baseline case requiring no rework of subsequent tasks. Tasks could then be modelled in terms of functions which map the values of meta-data in input descriptions to values of meta-data in output descriptions after performing the task. For instance, tasks could be modelled as propagating, absorbing or amplifying the magnitude of change. The exploration and representation of descriptions and of task behaviour in this way could be used to develop a deeper understanding of both engineering change processes and, more generally, of the behaviour of iteration in the design process. It could also form the basis of support, analogous to the use of the CPM technique described in Section 5.2, to help designers identify the amount of rework required in each task for a specific change. 7 Conclusions When assessing alternative approaches to implement requirement change, designers could benefit from support to assess the process cost of engineering change implementation. In this paper, we have argued that this could be achieved through a model-based approach which considers elements of the product, tasks in the design process and the interdependencies between these aspects. Although currently in an early stage, the ultimate objective of this research is to develop a pragmatic approach which can support change management in industry. The method proposed in this paper, following additional research and implementation in an interactive software tool, could potentially support the evaluation of change alternatives and thereby support an important aspect of change management. Acknowledgements The authors wish to thank Claudia Eckert and Rene Keller for many helpful discussions. References [1] Eckert, C.M., Clarkson, P.J. and Zanker, W., Change and Customization in Complex Engineering Domains, Research in Engineering Design, Vol. 15(1), 2004, pp [2] Eger, T., Design Freeze during Product Development: Supporting Change Prediction during Detail Design, PhD thesis, University of Cambridge, United Kingdom, [3] Wright, I.C., A Review of Research into Engineering Change Management: Implications for Product Design, Design Studies, Vol. 18(1), 1997, pp [4] Huang, G.Q., Yee, W.Y. and Mak, K.L., Development of a web-based system for engineering change management, Robotics and Computer Integrated Manufacturing, Vol. 17(3), 2001, pp [5] Clarkson, P.J., Simons, C.S. and Eckert, C.M., Predicting Change Propagation in Complex Design, Journal of Mechanical Design, Vol. 126(5), 2004, pp

14 [6] Cohen, T., Navathe, S. B. and Fulton, R. E., "C-FAR, Change Favorable Representation, Computer-aided Design, Vol. 32(5-6), 2000, pp [7] Silver, M.R. and de Weck, O.L., Time-Expanded Decision Networks: A Framework for Designing Evolvable Complex Systems, Systems Engineering, Vol. 10(2), 2007, pp [8] Ollinger, G.A. and Stahovich, T.F., RedesignIT A Model-Based Tool for Managing Design Changes, Journal of Mechanical Design, Vol. 126(2), 2004, pp [9] Browning, T.R. and Ramasesh, R.V., A Survey of Activity Network-based Process Models for Managing Product Development Projects, Production and Operations Management, Vol. 16(2), 2007, pp [10] Gärtner, T., Rohleder, M., Schlick, C.M., Simulation of Product Change Effects on the Duration of Development Processes based on the DSM, 10 th International DSM Conference, Stockholm, Sweden, November [11] Fricke, E. and Schulz, A.P., Design for Changeability (DfC): Principles To Enable Changes in Systems Throughout Their Entire Lifecycle, Systems Engineering, Vol. 8(4), 2005, pp [12] Hauser, J.R. and Clausing, D., The House of Quality, Harvard Business Review, Vol. 66(3), 1988, pp [13] Dick, J., Design Traceability, IEEE Software, Vol. 22(6), 2005, pp [14] Kilpinen, M.S., The Emergence of Change at the Systems Engineering and Software Design Interface, Ph.D. thesis, University of Cambridge, [15] Browning, T.R., Applying the Design Structure Matrix to System Decomposition and Integration Problems: A Review and New Directions, IEEE Transactions on Engineering Management, Vol. 48(3), 2001, pp [16] Wynn, D.C., Clarkson, P.J., Eckert, C.M., A model-based approach to improve planning practice in collaborative aerospace design, Proceedings of ASME IDETC/CIE 2005, Long Beach, California, USA, [17] Danilovic, M., Browning, T.R., Managing Complex Product Development Projects with Design Structure Matrices and Domain Mapping Matrices, International Journal of Management, Vol. 25, Number 3, 2007, pp [18] Whitt, F.R. and Wilson, D.G., Bicycling Science, The MIT Press, Cambridge, Massachusetts, London, 1995, c1982. [19] Jarratt, T., A model-based approach to support the management of engineering change, Ph.D. thesis, University of Cambridge, Corresponding author: Naveed Ahmad Engineering Design Centre (EDC), Department of Engineering The University of Cambridge Trumpington Street, CB2 1PZ, Cambridge, United Kingdom Tel: Int Fax: Int na315@cam.ac.uk 14