Development of a modelling framework for scheduling iteration in complex new product development projects

Abstract

Producing reliable schedules for new product development projects (NPD) can be difficult because of the inherent iteration involved in most development processes. Iteration is an essential feature of product development processes and occurs in NPD projects due to the high levels of uncertainty involved and complex relationships that can exist between project tasks. Traditional project management scheduling tools, such as Program Evaluation and Review Technique (PERT), do not account for task iteration because they allow only linear one-way progression along paths and ignore feedback loops. Two main parameters are needed when modelling potential iteration loops in a project (i.e., probability of occurrence and impact on schedule). Previous approaches that address the problem of iteration in projects assume that these parameters can be estimated and subsequently used to carry out schedule risk analyses for iterative projects. Another limitation of previous models is that their effectiveness is limited for particularly complex and mature NPD processes.

This paper presents a modelling framework, which aims to use the underlying causes of iteration in a NPD process when determining the inputs to a schedule risk analysis. The modelling approach presented in this paper was developed through research done in conjunction with a company that develops complex technology-based products. The developed framework is designed for use in complex NPD processes, which have little scope for modification. For generality purposes, certain elements of the framework have been altered from the original that was developed for the case study firm. The outcome of which is a proposed methodology and modelling approach that can be adopted by any firm with similar requirements. When conducting a risk analysis using this methodology, all past project performance data are utilised in the calculations. The calculations performed use probability distribution fitting and Monte Carlo simulation techniques to provide a stochastic representation of potential project slippage caused by iteration. Some of the potential benefits of using the methodology presented are (1) producing more reliable NPD project schedules, (2) minimising the use of subjective estimates during schedule risk analyses, and (3) facilitating ongoing organisational learning regarding NPD project slippage.

Introduction

New product development (NPD) is an important process that can give a company a competitive edge if carried out effectively. Achieving the desired time to market gains an obvious advantage over competitors and thus generating reliable NPD schedules is of the utmost importance. From a project management perspective, a major challenge when managing NPD projects is to plan and account for the uncertainty regarding the project schedule. It is widely acknowledged that one contributory factor to this schedule uncertainty is the occurrence of iteration in development projects. Iteration occurs when there is a need to go back and repeat (or partially repeat) previously completed tasks. This can be caused by the discovery of a specific error that must be rectified or a change in scope mid-project, which requires certain elements to be reworked. Regardless of the cause, iteration is a fundamental aspect of complex development projects and ignoring or even under-estimating potential iteration can have a serious negative effect due to costly project over-runs (Browning & Eppinger, 2002; Chen et al., 2003). For a firm that constantly has an issue with iteration occurring during NPD projects, it is important to account for this potential risk during the planning stage of a project. Otherwise a reactive scheduling approach will be employed throughout the life cycle of a project, resulting in the need to re-evaluate the schedule every time problems are encountered.

An important consideration when attempting to model iteration is the complexity and maturity of the NPD process in question. Previous models that have addressed the issue, while using differing techniques, fundamentally use the same approach. That is, (1) identifying individual iteration loops in a process, (2) estimating the probability and schedule impact of each loop, (3) rearranging project tasks in order to minimise schedule disturbance, and (4) performing calculations to predict total project duration (inclusive of iteration). Although this type of approach can be very effective, it does have limitations when applied to NPD processes that have high levels of complexity and maturity. For highly complex processes, it is not always possible to dissect iteration into a series of ‘cause and effect' loops. Instead, iteration can only be dealt with on a macro-project level, with total slippage from the original schedule being realised post-project completion. The level of maturity of an NPD process also has a bearing on the type of analysis possible. For mature processes that have been carefully developed over time, the rearranging of project tasks to minimise the effect of iteration is not feasible. In these instances, the task sequencing of an NPD process has been optimised over time, and simple changes to the process flow and structure have no benefit. When trying to model iteration in such an NPD process environment (i.e., highly complex and mature), the goal is to establish a means of modelling the overall project risk, while also facilitating learning by providing insight into the main contributory factors.

Regardless of the circumstances of an NPD process, or the specific method employed for analysis, two main parameters are used when modelling the occurrence of potential iteration in a project: (1) probability of iteration occurring and (2) the impact iteration will have on a project schedule (Smith & Eppinger, 1997; Cho & Eppinger, 2001; Browning & Eppinger, 2002). Previous models that address the problem of iteration use estimates for these parameters but do not focus on how these estimates are arrived at or whether they fully reflect how and why iteration occurs during a product development process. Instead, the focus is generally on the analysis of project performance after the parameter estimates are decided on. Although this type of analysis is necessary to understanding the implications of iteration, the output of any model will only be as reliable as the inputs used.

This paper presents a framework for the development of a model that uses the fundamental drivers of iteration in a process to simulate the potential risk in a NPD project. Adopting this approach to modelling iteration helps in ensuring that the inputs used in developing a schedule risk analysis are accurate and relevant to a company's NPD process environment. The proposed model framework is aimed at mature NPD processes whose underlying structure is well established and cannot be modified. Thus, in this scenario, the goal is to develop a model that can fit into a company's wider NPD process.

The framework has been developed through work done with a case study company that produces complex high-tech products. The previous work with the firm identified the drivers of iteration in their process and established a comprehensive list of metrics that serve as inputs (Murphy & Ledwith, 2010). This company meets the criteria regarding the type of NPD process; in other words, (1) it is a mature and well-established process that has been developed over time and (2) the inherent complexity and structure of their process prohibit any modifications to be made in terms of task sequencing. The remainder of this paper is structured as follows. The next section provides a brief summary of previous approaches for modelling iteration in projects. The following section gives an overview of the case study findings that were used in developing the methodology. The next section provides details of the iteration modelling framework developed. A discussion regarding the implications of using the proposed methodology is then followed by the concluding remarks.

Literature Review

The occurrence of iteration in a project can be either planned or un-planned (Smith & Eppinger, 1993). Planned iteration occurs when tasks are repeated as expected additional information is obtained from related tasks. Planned iteration can be intentionally incorporated into a schedule to refine the output of inter-related tasks (Browning, 1999). As planned iteration can be accounted for and incorporated into a project schedule, it does not add risk to schedule slippage occurring. Unplanned iteration, on the other hand, can have severe consequences on meeting a project deadline (Ford & Sterman, 2003). This type of iteration is encountered for two main reasons (Smith & Eppinger, 1997):

  1. An upstream task may need to be repeated if a dependent downstream task discovers some sort of error or incompatibility (e.g., redesigning of a prototype because of failure during testing).
  2. When tasks are executed concurrently, a downstream task may need to be repeated when modified information is passed along from a related upstream task (e.g., modifications made to the initial design of a product).

In the second case, iteration occurs because of the concurrency of tasks and would not happen in a fully linear sequential project; however, concurrent engineering is often employed in NPD projects because it is seen as an effective method of reducing development time and cost (Yassine & Braha, 2003).

Traditional project management scheduling tools such as Critical Path Method (CPM) and Program Evaluation and Review Technique (PERT) do not account for task iteration because they allow only linear one-way progression along paths and ignore feedback loops. This highlights the need for additional tools that can quantify the risk of potential iteration in a project schedule.

The most widely used approach for modelling iteration is the Design Structure Matrix (DSM) technique. A DSM is a matrix-based model that is used to represent dependency relationships and information flow between tasks in a project (Steward, 1981). Using a DSM provides a concise method to show how individual project tasks interact with each other. As well as easily identifying potential iteration loops in a process, portioning algorithms have been developed, which also enables the optimal sequencing of tasks in order to minimise the occurrence of iteration. The goal of using the DSM technique is to group interdependent tasks together in order to minimise the number of project tasks involved in iteration cycles, which results in a faster development process (Yassine, 2004).

Many proposed models, which address the problem of scheduling iteration, use a DSM as a starting point prior to any calculations. The DSM is used to identify the optimal task sequence and potential iteration with the overall project duration then calculated using this information. Chen et al. (2003) propose a project-rescheduling framework that uses the DSM method to highlight iteration blocks. Using learning curve assumptions, the extra time caused by each iteration block is then calculated. Using the base case of no iteration as a project deadline, individual tasks are then rescheduled to help ensure the project finishes on time. Browning and Eppinger (2002) present a simulation model that integrates task iteration and concurrency into schedule and cost risk analyses of a product development project. DSMs are used in the model to identify task iteration as well to store rework probabilities and impacts. Using these inputs, as well as learning curve assumptions, simulation is used to produce schedule and cost distributions for an NPD project. The model is used to compare different process set-ups and the outputs include average cost and duration, standard deviation, and probability of surpassing a specified cost and schedule target. Similarly, Cho and Eppinger (2005) present a simulation-based model that computes the distribution of lead-time in a project and also accounts for various forms of iteration. The model accounts for various different forms of iteration, including successive feed-forward iteration in downstream tasks caused by feedback iteration in an upstream task. Again, a DSM is used to document information flow and precedence constraints as well as to describe rework probabilities and impacts. The DSM provides an overview of the information exchanges and probabilities in the project, whereas the simulation provides a quantitative analysis of an overall project duration that includes potential iteration. Wang and Lin (2009) developed a simulation algorithm that incorporates task iteration into their model, which predicts the schedule duration of NPD projects. The model includes potential iteration (again identified by a DSM) as well as different overlapping strategies for project tasks. The potential output of the model shows the effect of alternative process structures and overlapping strategies on the overall lead time of a development project.

Building DSM models for complex projects (such as product development projects) can be difficult, because the necessary data are often not readily available (Maheswari & Varghese, 2005). The process for building a DSM model is to get people knowledgeable about each task to determine the inputs and outputs for every task and to determine the relationships that exist between all tasks (Browning, 2001). Although the DSM approach is a very succinct method for highlighting iteration in a process it does have limitations in application, in particular for highly complex and mature NPD processes. In these scenarios, the partitioning algorithms used to obtain optimal task sequencing can often be redundant. This is due to the fact that a highly complex and mature NPD process will already contain the optimal sequencing that the precedence constraints allow.

Other non-DSM approaches to addressing the problem of iteration include the use of optimisation techniques. Luh et al. (1999) generate an optimisation methodology for the scheduling of design projects with an uncertain number of iterations. The simplified objective function of the model is to ensure on-time completion of a project with minimal failures occurring. Lagrangian relaxation and dynamic programming techniques are used to solve the problem. Yan et al. (2003) present a methodology for modelling a product development process using a Petri net mathematical modelling technique. The model incorporates, among other features, stochastic task durations and design iteration. Using a set of scheduling rules a product development project can be simulated to model the behaviour of the process.

Hardie (2001) uses a Markov chain–based model to represent the recursive nature of complex projects. Reversion probabilities are defined for returning to previous tasks as well as for returning to the start of a current task. By calculating the transition matrices for subsequent time periods in a project, the probability of completing a project within a specified time can be calculated. Ahmadi et al. (2001) present a methodology for structuring development processes that uses a Markov chain to model iteration in the process. An integer programming problem is also developed with the objective function to minimise the number of iterations between tasks. Smith and Eppinger (1997) also use a Markov chain approach in conjunction with a DSM in their sequential iteration model for calculating the total expected time of a project containing task iteration. The reward Markov chain is constructed from a DSM that contains task durations as well as iteration probabilities. Using this technique, the expected duration for all possible ordering of tasks can be calculated to determine the optimal sequencing of tasks.

Flanagan et al. (2005) use a non-DSM based simulation model to explore project sensitivity to task rework. In their approach, a signposting simulation model is used to analyse project duration sensitivity to different types of rework. This technique is used to investigate task ordering and rework consequences. Two main areas of project sensitivity to rework are examined in the model: (1) duration of rework and (2) task reordering to accommodate rework.

Another non-DSM based simulation technique that has been used to address the issue of iteration is the use of system dynamics simulation. System dynamics can be used to model various different types of systems and in general it is used to gain holistic insights, of both “hard” and “soft” issues, into how a particular system will evolve over time (Williams, 2002). Several system dynamics models specifically modelling iteration in projects have been developed (Cooper, 1993a; Cooper, 1993b; Repenning, 2001; Lin et al., 2008). These models are generally used to investigate the impact iteration can have on a project's overall performance. Issues addressed using system dynamics include: the discovery of tasks to be reworked, the rate of completion of repeated tasks, iteration occurring due to inter-related tasks, and investigating the effect of different task-overlapping policies.

Regardless of the approach, one area which has not been addressed is the process by which iteration input parameters are established. Very little work has been done regarding the validity of inputs to models that simulate iteration in projects. Yassine et al. (2001) discuss the importance of having reliable inputs to a simulation model and provide a methodology for more accurate estimation of one of the iteration parameters, rework probabilities. In their approach, a more methodical process is used to determine probability values to be used when modelling iteration. However, there is no comprehensive methodology for developing an iteration modelling framework that uses inputs derived from the particular NPD process being investigated. The goal of this paper is not to provide a finalised general solution to this problem but, rather, to propose a methodological approach to achieving it. Further work in different industries is required to achieve greater generality, but the proposed framework can provide an applicable company with a ‘road map' for addressing the problem of iteration in their own NPD process.

Case Study

New product development process

The case study focuses on a large multi-national company that produces high-tech complex products for a variety of different industries. Producing new products and being a market leader are integral to the firm's success and, thus, NPD projects are continuously undertaken. New products are developed across 12 separate product lines, with varying levels of product complexity. A formal procedure is in place within the company that is followed for every development project. This procedure is divided into five main project phases with seven major milestones throughout the process (Figure 1). The milestones are used as metrics to evaluate how a project is performing in relation to time to market. Across all product lines, NPD projects are categorised based on their level of innovation (i.e., derivative, platform, and breakthrough projects). The same formal procedure is used for each of these project types; however, there is a difference in execution when developing a derivative product. During the feasibility phase of a derivative project, re-design tasks are completed instead of initial feasibility tasks, because much of the initial feasibility issues have already been addressed for derivative products in previous projects.

NPD process phases

 

Figure 1: NPD process phases.

This NPD process in place is a well established one that has been developed over time and optimised by the firm as much as possible. Precedence and procedural constraints have resulted in a process that cannot be altered in terms of task sequencing. The management involved in the new products group already fully understands the relationships between all of the process tasks and has determined the optimal sequencing that is permissible. Through interviews with project management and engineering staff, it was established that a problem existed with their ability to produce reliable schedules for NPD projects. In particular, the uncertainty surrounding the potential need to repeat tasks during a project was highlighted. The established procedure for scheduling any development project is to produce a baseline schedule on a project by project basis. The company handles iteration in a mostly reactive manner. Before any new project is undertaken, while the risk of unplanned iteration is known to exist, the schedule impact of any iteration is only investigated and dealt with if and when it occurs.

Findings

The root causes of iteration in the company's process were determined based on both the information obtained during the focus group sessions and the interviews with various management staff members. The information gathered in the focus groups was discussed with management, resulting in the identification of five main contributory factors to the occurrence of unplanned iteration:

  1. The level of virtual testing performed on a product during design
  2. The level of upfront requirements definition of a product
  3. The extent of new process and/or new technology risk in a product
  4. The level and nature of the resources available for an NPD project
  5. The required time to market for an NPD project

These five general variables were identified as being critical for fully explaining the occurrence of unplanned iteration in the firm. Thus, it was decided that they would be used to drive the iteration input parameters in the subsequent scheduling risk model. Statistical analysis of a past project dataset found that the level of innovation of an NPD project had a significant effect on observed slippage time. Thus, from a modelling perspective, for a new project being analysed, the slippage associated with each of the variables will be dictated by the type of project being undertaken (i.e., level of innovation of the current project). The defined variables will then in turn dictate the iteration inputs to be used for the scheduling model (Figure 2).

Using iteration drivers as inputs to schedule risk analysis

 

Figure 2: Using iteration drivers as inputs to schedule risk analysis.

From a modelling perspective, the five general variables identified are not descriptive enough to produce meaningful output from a risk analysis. The next step was to conduct follow-up interviews with staff in the firm in order to determine a list of specific measurable metrics. Following these interviews, an extensive list of 45 measures was determined, which described the five general variables in more detail. For confidentiality reasons, the full list of measures cannot be outlined but a select number of general examples are given in Table 1, which gives a sense of the type of information required. These measures collect information at the project planning phase and are subsequently used to model potential iteration in the schedule risk analysis.

Although many of the measures discovered are specific to this case study company, the process by which they were determined can be replicated in other firms. In general terms, the steps involved in collecting the required model input data are:

  1. Independent analysis of formal NPD processes and procedures (e.g., standard operating procedures, project management processes, and project scheduling procedures).
  2. Exploratory interviews with key staff members (e.g., project management, R&D managers, and NPD engineers).
  3. Analysis of relevant historical data (e.g., product's time to market, project slippage, and data relating to iteration in projects, if available).
  4. Additional data collection based on findings from steps 1 to 3 (e.g., focus groups and follow-up interviews with a more specific focus).

Table 1: Select examples of input measures from case study investigation.

img

Development of Modelling Framework

The end goal of this research is to provide a practical modelling technique that can be used in an industrial setting to perform schedule risk analysis regarding project slippage due to iteration. The development of the model was preceded by an exploratory investigation into the root causes of iteration in a real-life NPD process so as to establish all necessary inputs. The model allows the entering of all required project information and uses simulation techniques to provide a quantitative risk analysis of project slippage.

The primary input to the model (which is optional) is a means of project classification to make the analysis more meaningful. For the company involved in the initial investigation, this classification involved differentiating between the different levels of innovation in NPD (i.e., derivative, platform, and breakthrough projects). The additional model inputs consist of the iteration root-cause measures identified through the initial investigation steps outlined in the previous section. In order for this modelling approach to function, a database of NPD project performance statistics needs to be established and this records observed project slippage times as well as the inputs entered for previous schedule risk analyses. This ensures that the model continually updates and uses all previous results, bounded by actual performance data, for every subsequent project analysis. The model consists of four separate phases and the sequence of activities is outlined in the model flow chart shown in Figure 3.

User Input Phase

When undertaking a schedule risk analysis for a new NPD project, the user(s) will first be required to enter all of the required inputs that were established through the initial research process. First, the project classification of the current project must be entered. The next input needed is the required time to market (TTM) of the current project being analysed. This TTM is established from traditional project scheduling techniques. The next range of inputs to be entered is the inputs relating to the sub-measure metrics for the root cause variables. These sub-measure metrics will have been identified as being critical to successfully accounting for the occurrence of unplanned iteration slippage in a company's NPD process. These sub-measure values are all entered at the beginning of a project so as to reflect initial project conditions and are not altered as a project progresses. All of this input information is stored for future use and altering them would negate the forecasting effect of the model for future projects.

Sorting and Data Preparation Phase

Once all model inputs have been entered, the next phase involves the analysis of all historical project data to ensure up-to-date information is used for calculations in the simulation phase. The first step in this process is identifying the classification type of the current project being analysed. Once this is done, the model will search the database of past projects and retrieve all information relating to projects of the same type. The next stage is to sort the sub-measure data into groups that have the same input values. After this is done, the next step is to retrieve all corresponding actual slippage times for each group. This is done to ensure that a slippage time can be calculated for all possible input values.

Simulation Phase

After all of the up-front data sorting and preparation have been finalised, the next stage of the model is to conduct the simulation. A single simulation run consists of a number of iterations (n), which is specified by the user. During each iteration all of the defined probability distribution functions are sampled to provide a single slippage value for each. Next, based on the inputs provided for the current project, project slippage times for each of the 45 measures are determined using these sampled values. The final total project slippage value is obtained by fitting these 45 individual values to a probability distribution function and sampling. Prior to the next iteration in the simulation run, the total project slippage time is recorded and stored. Also recorded are the slippage time relative weights for each of the 45 variable sub-measures. This is done to enable the identification of the variables, which are the top contributors to slippage. After all this has been done, the process repeats until the required number of iterations (n) have been completed.

The model uses Monte Carlo simulation for the random sampling of the defined probability distribution functions. This provides a stochastic and less rigid element to the model, which is needed due to the inherent uncertainty involved in product development. The use of recorded past project data as the basis for the inputs to the simulation ensures the validity of the outputs produced.

Model framework flowchart

 

Figure 3: Model framework flowchart.

Output Phase

Following the completion of the simulation phase, the next step in the model is to provide the user with the required outputs obtained from the analysis. The primary output provided is a probability distribution histogram for the total project slippage time, using the recorded slippage values obtained from each simulated iteration run. This histogram provides an overview of the expected variability for slippage in the current project and can also be used for specific probability queries (e.g., probability of slippage being less than or equal to a given value). In the same manner, a histogram of expected project duration is provided by the combination of slippage time and original project duration.

Another output is confidence intervals for project slippage and total project duration, with the confidence levels of these intervals determined by the user. These confidence intervals provide a succinct representation of risk involved in a project (e.g., can state that there is 95% confidence that slippage in this project will be between X and Y). Also provided is a breakdown of the probabilities for the length of project slippage expected (example shown in Table 2). This breakdown provides a more succinct representation of the potential risk in a project.

One of the main goals of having this risk analysis model is to provide a project manager with insight regarding the risk involved. Used in the planning phase of a project, this model quantifies the risk for the project on a whole and also identifies the most likely problematic areas. This is achieved through analysing the slippage times calculated for each of the 45 sub-measures and then identifying the biggest contributors to total project slippage. Outputting the top 10 contributory measures enables a project manager to flag and focus on the elements of a development project that need the most attention.

Discussion

The main motivation for this research is to provide a practical tool for undertaking schedule risk analysis in complex iterative NPD processes. Thus, the usability and performance of a developed model are integral to the research. The model framework developed was a direct result of the findings obtained during the exploratory investigation into a case study company's NPD process. This initial investigation established an extensive list of 45 measures that were deemed relevant to iterations occurring in projects. Each of these individual measures falls under one of the five general root cause variables; i.e., (1) level of virtual testing, (2) level of requirements definition, (3) new technology risk, (4) resources, and (5) required TTM.

This approach to modelling iteration differs from previous attempts because it uses the specific causes of iteration in a company's process to model potential schedule risk in a project. Using this method to model the occurrence of iteration rather than the use of subjective estimates helps to produce a more accurate representation of an iterative project. Previous models assume the iteration inputs can be determined for any project with relative ease. However, based on the investigation into the NPD process of the case study company, the calculation of these input parameters is not trivial for highly complex product development projects.

As seen in the exploratory investigation into the case study firm, modelling iteration in highly complex NPD processes is particularly challenging. High degrees of complexity prohibit the ability to identify individual cause and effect cycles of iteration. This also restricts the effectiveness of more traditional methods for modelling iteration because they rely on the identification and re-organisation of individual iteration cycles.

The model framework is constructed in such a way as to continually update and store the inputs for all past projects for future analysis. The benefit of this is twofold: (1) it ensures that any future analysis is bounded by actual historical data, and (2) it enables a general non-project specific overview of NPD projects. This second point is crucial to facilitate the company in on-going learning regarding their performance in NPD projects. For example, the largest contributors to slippage for a particular project type can be established, thus enabling further investigation. Having a sustainable modelling tool rather than a once off analysis of past project performance allows for the long-term integration of the model into a firm's established NPD process framework. This model is not intended to replace traditional project management scheduling techniques but rather to compliment them. A project manager can use the outputs generated from both this risk assessment model and their own scheduling analysis to provide a broader outlook on the project at hand. Unrealistic due dates can be flagged, and extra effort focussed on particular risky project elements. This reduces the need for a project manager to engage in reactive scheduling throughout the life of a project because a more predictive and preventative approach can be adopted.

The analysis conducted in the model uses Monte Carlo simulation techniques for the random sampling of probability distributions. This action is mostly hidden from the end user but enables the introduction of a stochastic element to the analysis. It is widely accepted that uncertainty is a fundamental part of product development and this probabilistic aspect aims to address this. Stochastic model inputs, and in turn outputs, allow for the interpretation of the results to be a risk analysis one rather than a definitive deterministic conclusion regarding slippage time for a project.

Conclusions

From the literature addressing the issue, the difficulty in generating reliable NPD schedules is apparent. Modelling potential iteration in an NPD schedule is important in order to give a realistic view of how a project will perform. The findings from a case study involving a firm that has a long-running problem with iteration in NPD projects have resulted in the identification of the requirements for a scheduling tool with the capability of incorporating a potential unplanned iteration.

The suggested approach presented in this paper is the identification of all factors that influence iteration in a company's process and the use of these variables to determine the probabilities and impacts to be used when developing an iterative project schedule. Information gathered from management interviews and design staff focus groups in a case study company indicated that iteration could only be fully modelled in the process through the use of the identified contributory factor variables. Five general root cause variables were first identified, which were then broken down into a list of 45 specific measures.

Although some of the identified variables in this case study may be specific to this particular company, the approach of identifying the main drivers of iteration and subsequently using them in a model can be adapted for different firms and industries. The use of this methodology ensures that the probability and schedule impact of potential iteration incorporated into a project schedule are accurate and relevant to a company's NPD process environment. Using these measures, along with other project information (such as classification type) as inputs, a model framework was developed which provides a schedule risk analysis regarding project slippage caused by unplanned iteration. The model uses the 45 sub-measure inputs in conjunction with actual historical project performance data to provide the user with a risk assessment regarding iteration slippage. This risk analysis, along with standard project scheduling information, provides a better understanding regarding project duration as well as an indication of the biggest risk elements (from a slippage perspective) of a particular project. An advantage of using the suggested approach is increased confidence in the accuracy of a tool to model iteration slippage, as has been seen for the case study in question. The implications of having a scheduling tool that can accurately incorporate iteration into a NPD project schedule is that realistic due dates can be set for projects from the beginning, thus minimising the need to constantly re-schedule projects when iteration problems are encountered. Such a tool provides project management teams with a means of quantifying the risk of potential iteration for various project types. Identification of the biggest contributors to iteration slippage for a given project type enables more focus and resources to be given to these most likely problematic elements of a project.

From a project management viewpoint, the benefits of the proposed modelling framework are:

  1. Minimising the use of subjective estimates in the risk analysis
  2. A means for better utilisation of project resources
  3. Producing more reliable project schedules

The general benefits of using a modelling approach such as the one in the proposed framework are:

  1. Having a sustainable risk assessment model for NPD schedules
  2. Having a credible model that uses ongoing project performance data
  3. Having a model that can be incorporated into a company's already established NPD process

Ahmadi, A., Roemer, T.A., & Wang, R.H. (2001). Structuring product development processes. European Journal of Operational Research, 130(3), 539–558.

Browning, T.R. (1999). Sources of schedule risk in complex system development. Systems Engineering 2, 129–142.

Browning, T.R. (2001). Applying the design structure matrix to system decomposition and integration problems: A review and new directions. IEEE Transactions on Engineering Management 48, 292–306.

Browning, T.R., & Eppinger, S.D. (2002). Modelling impacts of process architecture on cost and schedule risk in product development. IEEE Transactions on Engineering Management 49, 428–442.

Chen, C-H., Ling, S.F., & Chen, W. (2003). Project scheduling for collaborative product development using DSM. International Journal of Project Management 21, 291–299.

Cho, S-H., & Eppinger, S.D. (2001). Product development process modelling using advanced simulation. ASME 2001 Design Engineering Technical Conferences and Computers in Engineering Conference.

Cho, S-H, & Eppinger, S.D. (2005). A simulation based process model for managing complex design projects. IEEE Transactions on Engineering Management 52(3), 316–328.

Cooper, K.G. (1993a). The rework cycle: Benchmarks for the project manager. Project Management Journal 24, 17–22.

Cooper, K.G. (1993b). The rework cycle: How projects are mismanaged. PM Network, February, 5–7.

Flanagan, T.L., Eckert, C.M., Keller, R., & Clarkson, P.J. (2005). Rework revisited: The criticality of iteration due to task failure in NPD planning. IEEE International Engineering Management Conference (IEMC ‘05).

Ford, D., & Sterman, J.D. (2003). Overcoming the 90% syndrome: Iteration management in concurrent development projects. Concurrent Engineering: Research and Applications 11, 177–186.

Hardie, N. (2001). The prediction and control of project duration: A recursive model. International Journal of Project Management 19, 401–409.

Lin, J., Chai, K.H., Wong, Y.S., & Brombacher, A.C. (2008). A dynamic model for managing overlapped iterative product development. European Journal of Operational Research, 185, 378–392.

Luh, P.B., Liu, F., & Moser, B. (1999). Scheduling of design projects with uncertain number of iterations. European Journal of Operational Research 113, 575–592.

Maheswari, J.U., & Varghese, K. (2005). A structured approach to form dependency structure matrix for construction projects. 22nd International Symposium on Automation and Robotics in Construction, 2005.

Murphy, E., & Ledwith, A. (2010). Scheduling complex new product development projects: determining iteration inputs. 2010 EurOMA conference.

Repenning, N.P. (2001). Understanding fire fighting in new product development. Journal of Product Innovation Management, 18, 285–300.

Smith, R.P., & Eppinger, S.D. (1993). Characteristics and models of iteration in engineering design. M.I.T. Sloan School of Management Paper.

Smith, R. P., & Eppinger, S. D. (1997). A predictive model of sequential iteration in engineering design. Management Science 43(8), 1104–1120.

Steward, D.V. (1981). The design structure system: A method for managing the design of complex systems. IEEE Transactions on Engineering Management 28, 71–74.

Wang, J., & Lin, Y.I. (2009). An overlapping process model to assess schedule risk for new product development. Computers & Industrial Engineering, 57(2), 460–474.

Williams, T. (2002). Modelling complex projects. Hoboken, NJ: John Wiley & Sons.

Yan, H.S., Wang, Z., & Jiao, X.C. (2003). Modelling, scheduling and simulation of product development process by extended stochastic high-level evaluation Petri nets. Robotics and Computer-Integrated Manufacturing, 19, 329–342.

Yassine, A.A., Whitney, D.E., & Zambito, T. (2001). Assessment of rework probabilities for simulating product development processes using the design structure matrix (DSM). ASME 2001 International Design Engineering Technical Conferences.

Yassine, A.A., & Braha, D. (2003). Complex concurrent engineering and the design structure matrix method. Concurrent Engineering: Research and Applications 11(3), 165–176.

Yassine A. A. (2004). An introduction to modelling and analysing complex product development processes using the design structure matrix (DSM) method. Italian Management Review 9, 71–88.

©2012 Project Management Institute

Advertisement

Advertisement

Related Content

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.