Modeling integrated product-process development (IPDD) design team performance

This paper introduces the application of discrete system simulation to modeling the performance of projects using Integrated Product Process Development (IPPD) teams. The paper's foundation is the author's 1997 dissertation research and its associated prototype simulation. The research domain was the aerospace industry, but the principles demonstrated can apply to many industries. The simulation itself is offered more as a concept demonstrator than as a tool for immediate application. The approach includes both technical and organizational aspects in modeling project performance within an Integrated Product Team (IPT). It attempts to shed light on the intersection of product architecture and human organization as it occurs in a modern project environment. It is the author's opinion that tools and research of this nature suggest a new capability to evaluate, plan, and execute new product development projects more effectively.

Emergence of IPPD in Project Management

IPPD Background

Major U.S. industries gradually embraced the concept of Concurrent Engineering (CE) and Integrated Product Process Development (IPPD) during the course of the 1990s. This movement was strongly influenced by U.S. government contracting requirements in the aerospace and defense industry and by global economic pressures to improve the new product development (NPD) process. It is not exactly clear in which industry CE and IPPD originated, but its application now has a direct impact on project management philosophy across a broad spectrum in today's U.S. industrial environment. Relative to the history of project management it is a relatively new but established development. “By the early 1990s, companies recognized that concurrent engineering was not a fad and will be one of the management practices that will endure well into the twenty-first century” (Kerzner, 1998).

Contemporary CE philosophy in the U.S. started to develop in the early 1980s. The emergence of CE as an industry trend is attributed to market pressures by Rolstadâs (1995). “The need for concurrent engineering is market driven. The market conditions in both the consumer and durable goods market is gradually changing into a larger degree of diversification and shorter product life” (Rolstadâs, 1995). The U.S. Department of Defense (DoD) also attributed CE's emergence to economic conditions. The “DOD Guide to Integrated Product Process Development” states, “In the early 1980s, U.S. industry used the concept of integrated design as a way to improve global competitiveness” (p. 1–2).

Kraft recognized the potential significance of CE as a new development project management practice in 1983 when he stated, “Concurrency may be the most important new approach to hit defense industry program management since “systems analysis” … of the 1960s” (p. 12). However, widespread use and acceptance of CE as a standard practice in the defense industry did not evolve until the mid 1990s as indicated by this DoD directive in 1995;”… I am directing a fundamental change in the way the Department acquires goods and services. The concepts of IPPD and IPTs shall be applied throughout the acquisition process to the maximum extent practicable” (p. 1–1). The source document for this quotation, “The DoD Guide to Integrated Product and Process Development,” is further evidence of the recent general acceptance of CE philosophy by the DoD and its efforts to influence all DoD contractors to utilize CE in their development practices. The guide was first published in February 1996 and is based in large part on report R-338 from the Institute for Defense Analyses, “The Role of Concurrent Engineering in Weapon System Acquisition” (Winner et al., 1988).

Exhibit 1. IPT vs. WBS Structure

IPT vs. WBS Structure

The essence of managing concurrent engineering is effective coordination of development processes being conducted in parallel. The communication loading of the organization increases dramatically as project concurrency and product complexity increases (Levitt, 1994). New organizational concepts such as Integrated Product Teams (IPT) have been developed to decentralize decision-making, reduce rework and manage technical communication in a concurrent engineering environment. Recent developments in computer technology in the form of engineering design tools, decision support systems, communications networks, and manufacturing planning software have added new complexity and opportunity to the successful implementation of integrated product teams. Given the combination of these recent events, project managers face a significant challenge in effectively coordinating the human and technological aspect of the current design methods.

IPPD Organization Structure

Associated with CE and IPPD is the concept of the Integrated Product Team (IPT) organizational approach. The IPT is a modified matrix organization structure aimed at effecting concurrent engineering through the use of a multidisciplined team. Typically an IPT consists of 10–20 collocated team members from design, analysis, systems engineering, manufacturing, materials, and quality engineering functions. Collocation of the team enhances communication during the product development process. The collocated team may also be supported by people whose required time is less than full time on the project and are located away from the team. A separate IPT is formed for development of each major deliverable set in the work breakdown structure (WBS). Exhibit 1 shows an example WBS vs. IPT organization structure for a recent NASA development project, the X-33 Linear Aerospike Engine.

The IPT approach is intended to improve quality and reduce cycle time in New Product Development (NPD) by eliminating functional barriers and streamlining communication during the design activity. By eliminating serialized “throw-it-over-the-wall” engineering, both the product design and manufacturing process design can be developed concurrently within the team. This concurrent engineering approach has resulted in reduced rework downstream, reduced product life cycle time, and improved product quality. To be successful, IPPD requires an iterative and collaborative approach to design, in order to incorporate perspectives from both the product and process design disciplines. IPPD has yielded significant performance and product improvements, but carries with it its own set of issues and limitations, given our current approach to the design process.

Need for New Tools to Understand IPPD in Project Management

The following is an excerpt from the review of literature conducted as part of the author's original research associated with this paper. It points to the need for research to advance existing project management tools to eliminate current inadequacies and to address recent developments in the way new product development (NPD) is accomplished using IPPD. New technologies, approaches and organizational structures have emerged in the last decade that require new tools for measuring project communication and performance. Efforts of the Project Management Institute to encourage project management research and sharing of ideas is critical to the advancement of the project management science. With the possible exception of Goldratt's, Theory of Constraints (Goldratt, 1990), little or no fundamental philosophical changes have been made on a broad scale to the basic methods, tools, and metrics used in NPD project management for decades.

Despite past research on project management methods and tools, NPD projects still suffer from significant problems related to cost and schedule growth. “Lots of projects (50–70 percent) still come in late, are way over budget, and don't work very well” (Putnam, 1991). Cooper (1993) provides a dismal assessment of the current state of advancement of project management science and alludes to the fact that our performance today suffers from the same problems that it did when George Washington contracted to procure the U.S. Constitution, in 1794. Goldense (1993) echoes a similar thought when he states that “product development centers are the only areas of a company where missing the original project time and cost estimates by 50%, 100%, and 200% are still allowed to occur with regularity.”

The existence of such poor performance in project management of NPD leads to the conclusion by some that ample opportunity exists for additional research in this area. “NPD is an area with a lot of potential for future research.… more empirical testing is needed to establish the true value of speed” (Nijssen, 1995). Many reasons may contribute to the failure of a project to remain on budget and schedule including such things as poor planning, insufficient resources, poorly trained or inexperienced personnel, and poor management. One suggested improvement to project management science is the development of better tools for measuring project performance. Putnam indicates that a manager's ability to support organization's product development goals is limited by his ability to evaluate his processes. “He has no way to measure. No decent metrics” (Putnam, 1991). He also points out the value of metrics when they are used in managing NPD projects. “Organizations that focus on broadly improving the development process by investment, education and management attention to process measurement and control do improve their … products. They do produce them faster” (p. 106).

The basic shortcomings of commonly accepted project management tools was stated by Levitt. “Project management tools such as critical path method have been shown to make consistently optimistic predictions about project duration” (Levitt, 1995). Levitt attributes this in part to the “merge event bias” (Moder et al., 1983) and the omission of coordination tasks of project work from network-based scheduling tools. Levitt specifically emphasized the need for additional tools related to organizational aspects of concurrent engineering (CE). “Little attention has been paid to developing tools to address the organizational issues involved in concurrent engineering” (p. 160).

The emergence of CE appears to have complicated the NPD process and the ability to effectively manage it. The concerns associated with concurrency related to CE have some sources suggesting that new metrics and tools are required to assist in proper implementation of CE. Griffin points out the need for broadly applicable metrics. “Current research seeks a set of measures which produce more explicit quantifiable results across a much broader range of product examples” (Griffin, 1993). Cooper backs up Griffin's statement by pointing out the inadequacy of today's metrics. “We are, in effect, equipping project managers with half-blank tape measures as the standard tools for planning, monitoring, and managing large projects” (Cooper, 1993). He further comments that “there has been stagnation in the prevailing theory and practice of large project management. ‘Advances’ have been largely confined to the computerization of fundamentally inadequate methods” (p. 5).

As an example of currently inadequate tools, Cooper specifically refers to critical path method (CPM) as “properly constructed and updated, it is an extremely useful planning tool. Yet CPM is an inadequate model for managing complex development projects” (1995). Although he does not specifically refer to CE in his criticism, the timing of his article may be associated with the recent frustrations being surfaced across the industry because of the complications CE has added to the project management process.

In his article, “Measuring Concurrent Engineering Performance,” Goldense suggests that product development and performance measurement “are among the last two ‘Trojan horses’ still grazing the landscape of corporate America” (Goldense, 1993). McDonough agreed with Goldense. “Comparative research to better understand factors associated with speed of development is sparse” (McDonough, 1993). “Little research has examined the importance and impact of factors at the project level” (p. 241).

Exhibit 2. IPT Design Process Dynamics

IPT Design Process Dynamics

IPPD Design Team Dynamics

As a widely accepted method of organizing complex development projects, IPTs offer a fertile ground for performance analysis and research. Resulting tools and metrics that apply specifically to organizations practicing CE will enhance development project management.

The IPPD design team in today's NPD environment deals with a number of issues that add to the complexity of system dynamics. These dynamics have a dramatic effect on the overall performance of the project in accomplishing its design tasks. Taken individually, no single element of the NPD design process is overly complex. To a casual observer the process involves the straightforward accomplishment of a designated number of design tasks defined by the product architecture. However, when all elements are combined in a human environment involving communication, documentation of a creative process using new technologies, imposed organizational practices, customer requirements changes, rework, and resource limitations, the overall design process complexity increases dramatically. Understanding, planning and predicting design team performance in such an environment requires special tools and analysis.

Detailed design of complex products is now conducted using integrated solid models. These models provide high fidelity images and enable transfer of geometry rapidly between design, analysis, and manufacturing functions for accelerated development activity. While these tools for design have improved dramatically, the human approach to design development has yet to undergo an equivalent revolution. The tools remain primarily as an instrument of the product design side and are not used in a truly collaborative fashion between product designers and process designers (manufacturing engineers). Visualization and communication technology is bringing this nearer to reality.

Product architectures are still divided in segments between available design engineers. Completion of each segment of the architecture is dependent on the ability and availability of the assigned designer to complete the work in a timely manner. Interchangeability of work between designers and true concurrent collaboration on complex assemblies is not yet common practice. It is also driven by the available experience base and product complexity. This limitation impacts the design process dynamics of product architecture, work assignment strategy, team communications, and change activity.

Exhibit 3. Simulation Boundary Relative to Project Activities

Simulation Boundary Relative to Project Activities

Exhibit 4. Simplified IPT Process Flow

Simplified IPT Process Flow

The product design cycle time is also driven by the order in which assemblies are completed. In the early stages of a design project, preliminary design activities are usually approached in a top-down manner as concepts are evaluated and merged. As the design activity progresses to detailed design, the work is typically accomplished using a bottom-up approach. That is, detail parts are finished before the next higher subassembly, etc. Under concurrent engineering, the top-down and bottom-up approaches may be in process simultaneously within the IPT, creating potential conflict in the production flow or creating potential for rework. Overall architecture of the design in terms of the “drawing tree,” as assigned to specific designers, therefore impacts the speed by which the design can be completed.

Exhibit 5. IPPD Model Elements

IPPD Model Elements

Another key factor impacting design cycle time is that of change and rework during the design process. Highly concurrent design efforts involve iteration as part of the methodology. Given rapid iteration with decreasing change as the design progresses, overall product design cycle time should be improved over older serial approaches, and should have fewer impacts once the design progresses to fabrication. However, change related to requirements changes can occur throughout the project and can significantly impact the IPPD system because of the constraints related to product architecture and designer assignment strategy discussed above. Depending on the specific element of the product architecture affected by requirements change, entire segments of the design may need to be stopped while other elements are redesigned. Delays can be aggravated when they dominate an area assigned to a single designer, thus potentially impacting the entire effort.

Communication processes also contribute significantly to the speed of design completion in the above scenario. One factor is the speed of communications between the three primary design participants; analysts, product designers, and process designers. In spite of using an IPT approach to development, individuals must still conduct these three efforts individually, to some degree. The design concept is developed through a continuous series of iterations of design information between these participants. The speed at which individual work is completed and then communicated back to the other team members is critical to overall design team performance.

All these conditions and constraints define a complex system that requires analysis to understand and develop strategies for better IPPD performance. System simulation offers a methodology to analyze the complexities of such a system, with resulting insights that may not be achievable by other means of analysis. Exhibit 2 attempts to show the interaction of dynamic contributors that impact IPT design performance.

A computer model addressing these issues was developed and used in a 1997 dissertation research effort by the author at the University of Southern California, in the Department of Industrial and Systems Engineering. A discrete system simulation was developed to study the effect on design performance of variables related to product architecture, organizational architecture, communication frequency, and work assignment strategy.

IPPD Design Team Model Concept

General Description

The IPPD project model was developed for use in exploring concurrent engineering performance in development projects. If a model could be developed that demonstrated behavior similar to that described by the empirical data collected in the research, the model may be of value in understanding the system dynamics and key factors associated with project team behavior. Such knowledge could then be validated with further research and used to suggest ways of improving project design team performance.

Exhibit 6. Product Architecture Specification Window

Product Architecture Specification Window

The boundaries of the model, relative to project activities, are shown in Exhibit 3. The project activities described in Exhibit 3 are adapted from work done by Eisenhardt (1994). As shown in the exhibit, the model included the primary elements of the IPPD process. The model did not extend into the production startup activities. The testing activity was reflected only to the degree that it would result in rework for the product and process design activities. Testing and analysis were not modeled as separate activities.

The model construction method used was that of discrete system simulation, similar to that commonly applied in industrial production modeling. A process network was established to represent the flow of information through the project design organization. The process flow focused primarily on the product designers (design engineers) and process designers (manufacturing engineers) involved in the activity. Drawings or models from the product architecture served as the information entities, which traversed the process network in the simulation.

The model used four queue and server activities and one random requirements generation activity as shown in Exhibit 4. The four primary activities were preliminary product design, preliminary process design (manufacturing planning), detailed product design, and detailed process design. Arrows in Exhibit 4 describe the data flow path through the design process. Rework paths are shown as dotted lines.

The four design activities were intended to represent a high level consolidated view of the product-process design interactions within an Integrated Product Team (IPT). In reality the discrete elements of information were probably exchanged many more times than this, but the high-level representation established a fundamental process that is thought to be a credible gross representation of reality.

Each activity in the model was represented at a high level as a composite of all subactivities that may be involved in a real project. For instance, the design activity consolidated all types of analysis and layout as a single activity. The primary separation between activities was made between those accomplished by design engineering and manufacturing engineering with a given IPT. The supporting philosophy was that although both kinds of engineers work in parallel within an IPT, the work efforts they perform are distinctly different and separate. This was also the most basic rationale behind the IPT concept: that of involving manufacturing engineering early in the development process. A clear distinction currently exists in aerospace development projects between design and manufacturing engineering disciplines.

Exhibit 7. Drawing Tree Runtime Window

Drawing Tree Runtime Window

The four primary activities were preceded by a requirements generation activity. This activity represented the flow-down of customer requirements and requirements changes that drive the design solution. The simulation defines the relationship of requirements changes to specific parts of the architecture and the corresponding level of rework required when a new requirement is changed during the project.

Exhibit 5 provides an overview of the model architecture. The overview identifies the major elements originally envisioned to be included in the model. Model elements shown in Italics were not fully implemented in the current model but the model was sufficiently developed to accomplish the intended research objectives. A detailed discussion of the architecture follows.

Simulation Architecture

The simulation architecture was based on the single server queuing simulation routine by Khoshnevis (1994). The original basic code was highly modified to represent multiple servers, multiple activities, and all the functions shown in Exhibit 4. In its current form the simulation was comprised of approximately 4,000 lines of code, of which approximately one third were remarks statements. The standard version of Microsoft Visual Basic® was used as the authoring software. The resulting simulation software was an 85K executable file for use in the Microsoft Windows® environment. The user interface involved 10 types of control and output windows.

Product-Process Architecture Scenario

The architecture scenario was defined by three general categories of control parameters: product architecture (i.e., drawing tree), design difficulty, and requirements flowdown. A general description of the concept behind each element follows.

The product architecture, as represented by the drawing tree, was used as the primary source of process control in the simulation. Once defined, it established the amount of work to be accomplished in the project and it was used as the basis of assigning work among the available engineering resources. Each element of the drawing tree was an entity in the simulation. The drawing tree also served as the primary method of tracking and controlling the progress of the entire project.

The drawing tree was determined in one of two ways by user specification. The simulation default mode used a random number generator to select a new drawing tree for each new simulation run. The size of the drawing tree was controlled by either the default settings or a set specified by the user. Exhibit 6 shows the product architecture specification window.

In its current configuration the simulation is limited to three levels of architecture. This included the top assembly, subassemblies and detail parts. While this represented a simplistic view of typical aerospace products, it provided adequate system dynamics for evaluation of the modeling concept. The current limitations on drawing tree elements are one top assembly, 15 subassemblies, and 20 detail parts per subassembly. With these limitations the maximum number of parts in the product configuration was 316.

Exhibit 8. Baseline Model Parameter Setting

Baseline Model Parameter Setting

In the second method of drawing tree generation the user may specify a configuration by entering all the defining dimensions in terms of subassemblies and detail parts for each subassembly. The simulation then used the user-specified configuration for all simulation runs. This method eliminates the variability associated with random selection of product architecture. It also allows evaluation of a specific configuration case.

Design difficulty is addressed through two indirect input parameters. One parameter is rework not associated with requirements changes. The user can define the percentage of rework associated with the output from each activity. The rework destination can also be specified for each activity. Rework is also the method the user can use to simulate the effects of feedback from product and component testing activity. In the case of a development program with significant technology development, the user can specify high rework from the detailed design activity.

The second method of specifying design difficulty is associated with the service time specification. For projects attempting to accomplish major technology advances in the product or processes, the user can increase the mean design time for the associated design activities and/or specify a large variance.

Requirements flowdown and changes are a major element of the simulation and the research because of its hypothesized negative influence on productivity. Requirements flow-down has four categories of controlling parameters in the model including: (1) When the requirements development will begin, (2) How long requirements changes will continue, (3) What rate of requirements change arrival for a given activity, (4) How much of the drawing tree is influenced by the requirements change.

Organization Scenario

A key element of the philosophy behind the simulation relates to organizational work assignment strategy and the possibility that it may vary from activity to activity. Work assignment strategy refers to the assignments of individual designers responsibility for specific segments of the product architecture. For expediency in the design process, the product architecture is usually divided between the available designers in such a way that each individual is responsible for distinct segments or subassemblies of the overall design. This enables one individual to focus on the assigned segment and become familiar with all its related design elements. It also minimizes the need for engineers to familiarize themselves with each task they are assigned before they can begin working on it.

Work assignment strategy also constrains the work environment by decreasing flexibility in allocation of engineering resources. When work on a given segment of the architecture is limited to specific individuals, it results in longer cycle times and reduced overall productivity. This aspect of the IPT process was assumed to have an influence on the overall performance of the system and therefore was included in the model architecture.

Team communication was an obvious key element of the system being modeled. The communications between team members in this model was limited to interchange frequency. It does not include different forms of communication and their associated failure rates as was modeled by Levitt and Jin (1994). In this model the user can specify a transaction time delay between the four design activities.

The team communications interface shown in Exhibit 3 represents a gate that is opened and closed on a periodic basis. The user specifies the frequency at which the gate opens by selecting from a list of options including: (1) Collocated—gate always open, (2) Periodic, Daily—gate opens every eight work hours, (3) Periodic, Biweekly—gate opens every 16 work hours, (4) Periodic, weekly—gate opens every 40 work hours. The same gate controls all information transactions at once by transferring the contents of all gate queues to the next activity queue.

Personnel availability refers to the availability of individuals assigned to work the project. Availability was controlled in two ways within the model. The user must first specify whether the same design engineers will be used to perform both preliminary and detailed product design. In a similar fashion the user must specify whether the same manufacturing engineers will be used to perform both preliminary and detailed process design. This establishes the first level of resource control in the model.

The second level of control was accomplished by specifying the number of design and manufacturing engineers that were available for work. In the case of shared engineers, the user specified a single quantity of engineers for both product and process design. In each case the engineers were then used as a common pool for their respective activities. In the case of unshared engineers, the user must specify a quantity for each of the four activities. Work schedules were defined to enable the model to track project cycle time relative to the calendar. The work schedule was specified by defining the shift length and number of days worked.

Design time distributions refer to those times defined by the user to determine the engineering product or process design task times. The simulation user may select from three types of probability distributions including normal, uniform, and exponential. A forth option available is that of a constant service time. Users define the distribution by supplying the mean, variance, maximum and minimum, as applicable, for the selected distribution type. Random variables from the defined distribution are then calculated using the computer uniform random number generator and the specified random number seed.

Output Data

Two real-time data display windows are available for viewing during and after execution. Data files may also be defined within the code for automatic recording during the run, for use with other software applications. The statistics runtime window includes output data in the form of a real time project Gantt chart, simulation runs scheduled vs. runs completed, transaction-based concurrency statistics, time-based concurrency statistics, project cycle time, total labor hours, number of drawing tree elements completed, and drawing output rate.

The alternate output window is the real time drawing tree completion graphic shown in Exhibit 7. It includes output data in the form of a color-coded graphic showing design completion, available engineering resources, engineering resources in use, requirements change activity level, rework activity level, runs scheduled and runs completed. The simulation user can monitor design progress by viewing the Drawing Tree Window. As design progresses through the four activities, each element of the drawing tree is incrementally filled in one forth at a time, as if it were a Gantt chart activity bar. The color of the boxes indicates whether they have been impacted requirements changes and rework activity. This view gives an immediate subjective impression to the user on the impact of change and rework on design progress. It allows the user to visually monitor design progress with full view of impact related to change and rework.

Model Validation and Anchoring

Validation

Prior to using the model, it was tested for repeatability, logical results, and performance stability within the control parameter limits. Tests were conducted by exercising the model at the extreme limits of all its control parameters, in varying combinations. Initial runs were made without complicating activities such as rework and requirements changes active. Model performance and graphics output was compared with expected results and relationships. The Gantt schedule and drawing tree displays were helpful in identifying performance characteristics that did not correspond to anticipated project behavior.

One of the most insightful elements of the simulation graphics was originally added as a debugging tool. The “tree-view” runtime window was used to visualize detailed aspects of the model behavior that would otherwise be difficult and time consuming to detect using normal debugging methods and data analysis. Other graphics features such as the resource meter and rework change activity displays were added to increase visibility into the model behavior. Through the use of these displays and normal debugging methods, behavior anomalies were identified and eliminated. Additional features of the model architecture were activated, and performance evaluations were repeated as confidence in the model fidelity was established.

When all graphics performance characteristics appeared to be normal, output data was compared to predicted performance and dimensional units were examined for consistency. A detailed analysis of the data output files was conducted, including manual calculation of concurrency values. The results were then compared to the direct model output data. Necessary corrections were made to the coding until all output data appeared to be consistent, properly formatted, and repeatable.

Anchoring Data

A questionnaire was developed to provide data for setup of the simulation for final research analysis. It was also designed to validate the assumptions used to construct the simulation. A total of 37 numbered questions were included requiring approximately 75 data entries. The questionnaire was divided into an introduction and five major sections that correlated with specific elements of the model architecture. The five sections were product design work strategy, process design work strategy, communication, rework, and product architecture. Exhibit 8 shows the simulation parameters developed from the questionnaire.

The questionnaire was sent as a follow-up to research participants after they returned the initial questionnaire in the authors dissertation research. Although all participants indicated a willingness to complete the second questionnaire, only five were returned completed. Data from the questionnaire was analyzed as planned and used to anchor the IPPD model. Based on the data, a set of model parameters was selected for a baseline research model configuration.

The model was used extensively in this configuration to test the original research hypotheses regarding the relationship of project concurrency to design cycle time. Model results supported conclusions similar to those resulting from the empirical research data analysis.

Application and Results

The IPPD simulation was used to evaluate a hypothesized relationship between schedule concurrency and design cycle time as stated in the following questions.

1. Does a quantifiable relationship exist between the concurrency of specific development project activities and total project cycle time? If the relationship does exist, can it be used as a meaningful metric to assess the rationality of projected schedules given current methods?

The research methodology used empirical data from recent aerospace industry projects to evaluate time-based vs. transaction-based concurrency statistics relative to cycle time. Transaction-based measurement was developed as part of the research. It uses proximity of information transaction centroids, instead of time, to measure concurrency between two activities. The model was used to attempt to replicate and explain the dynamics associated with the empirical data as stated in the following question.

2. Can a modeling tool be built with predictive power for use in evaluating engineering development projects and their relative levels of concurrency?

Data generated by the IPPD model demonstrated correlation of concurrency with cycle time, similar to that of the empirical data. Concurrency between requirements development and product design was clearly shown to have a predominantly negative correlation with cycle time (or productivity rate), using a transaction-based concurrency measurement method. Concurrency between product design and process design showed no direct correlation with design cycle time.

Other Development Project Models and Methods

During the writing of this paper a search of the PMI® database and academic research databases through the University of Southern California resulted in no findings of recent research on modeling project management processes.

Development Project Modeling is an area that remains largely underdeveloped as pointed out by Nijssen. “We need better modeling of the NPD process. With regards to the process of acceleration, a better understanding is needed of cause and effect in the process of accelerating NPD” (Nijssen, 1995). Cooper pointed out one of the key reasons for pursuing development project modeling. “We need to improve our fundamental understanding of how projects really work” (Cooper, 1993).Abdel-Hamid (1990) adds that project “simulation experimentation can answer not only what but why.”

A few examples of development project models were found during the initial review of literature and will be discussed in this section. The types of models found include system dynamics models (Cooper, 1993) (Abdel-Hamid, 1993), network models (Belhe & Kusiak, 1995; Karagozoglu, 1993; Pourbabai & Pecht, 1994), and discrete system simulation models (Levitt et al., 1993, 1995). No recent examples of design project performance modeling has been found by the author.

The earliest example of project modeling located in the literature was by Richardson (1981). The model was used as an educational example in a system dynamics text authored by Richardson and Pugh. The model does not specifically address development projects and also does not include any elements specifically related to concurrent engineering. The primary element of significance in this model that applies to the discussion of CE as it focuses on the impact of rework in a project and the effect it can have on cycle time.

Cooper (1993) used the Richardson model as a primary element in his article on rework, which has been cited numerous times in this review. Cooper uses the Richardson model to demonstrate the need for considering rework as a natural part of the development project process. He also uses it as a basis for his argument that existing project management techniques such as CPM are inadequate because they do not specifically address rework in the planning and management processes. Cooper writes that a comprehensive management tool for development projects must include the rework process, recognizing that “there is a naturally iterative process of design engineering” (Cooper, 1993).

The only other application found using system dynamics to model development projects was authored by Abdel-Hamid (1990, 1993). The first research published by Abdel-Hamid appears to have used a model similar to that developed by Richardson and Pugh (1982). The model was used to evaluate trades between cost and schedule compression or stretch out on a single engineering project. The model architecture is very high level and focuses primarily on organizational aspect of the project including staffing, training, and workforce resources. The model does not appear to address product architecture and complexity as a driving parameter. Work content is defined as a generic unit and quantity that is processed by the organization in the model architecture.

Following his work on single project dynamics, Abdel-Hamid (1995) published research on project dynamics in a multiproject environment. To accomplish the research he linked multiple versions of the single project model used in his 1990 research. His research addressed the importance of resource tracking in NPD modeling because “projects interact through the competition over sharing of resources … such interactions can significantly influence project behavior” (1993).

The primary method of project modeling found in the review was the use of networks. Networks have been a primary tool for project scheduling since the development of Program Evaluation Review Technique (PERT) and the Critical Path Method (CPM). As discussed earlier, networks have been criticized for their inability to address rework in a well-defined manner. Belhe and Kusiak (1995) have suggested a method to remedy this shortcoming using multilayered schedule networks implemented in IDEF3. “An IDEF3 model enables an expert to communicate the process flow of a system by defining a sequence of activities and the relationships between them” (Belhe & Kusiak, 1995). IDEF3 is one of a set of modeling tools developed by the U.S.Air Force for manufacturing planning and management. The IDEF tools have been widely used and discussed in the literature.

The modeling method suggested by Belhe and Kusiak specifically addresses a CE environment using multi-discipline teams. The methodology used is to fully define a project schedule network in IDEF3 including all its potential paths and feedback loops. Repetitions of activities are modeled by estimating the number of repetitions from historical data and using a fixed schedule duration in the network. This method effectively eliminates the potential for dynamic iteration and results in a deterministic modeling process. Once constructed, the model was used to determine a lower bound for the project cycle time.

The Belhe and Kusiak model takes into account the product architecture and organization implicitly through the development of a detailed schedule for project completion. It is necessary for one to develop a detailed activity network of the entire project schedule before useful knowledge can be obtained about the project's potential performance. The quality of the model output is therefore dependent on the person(s) ability to develop the complete activity network.

Pourbabai and Pecht developed a “quantitative decision making model for managing schedule and cost associated with the product design phase of the product development process, based on the Concurrent Engineering Management philosophy” (Pourbabai & Pecht, 1994). The method used was similar to that used by Belhe and Kusiak. A multilayered project network was used to breakdown the project work content. Pourbabai and Pecht used the product architecture as the framework for project breakdown to the lowest level activity. Construction of the network again includes identification of all required activities, required resources, time durations, and precedence relationships. The research literature does not address rework and the resulting model is purely deterministic. The overall objective function of the model is to minimize cost. As with the Belhe and Kusiak model, the quality of the model output is dependent on the person(s) ability to develop the complete activity network.

The Rolstadâs model is a schedule network approach whose architecture is based on product architecture and production constraints. Although it specifically addresses the need to optimize concurrency and reduce risk, it also relies on the ability of the individual to fully define the project activities and risks before knowledge can be determined about it's projected performance in terms of schedule and cost.

During the review of literature only one example of discrete system simulation was found in the area of development project modeling. The model was developed and published by Levitt et al. (1993, 1994, 1995). Levitt's Virtual Design Team (VDT) model was aimed at assisting in organizational reengineering. The VDT effort is intended to “develop a theoretical framework and computational simulation model to predict the impact of changes in organization structure on the performance of project-oriented organizations engaged in knowledge work” (Levitt, 1993). Levitt's and his colleague's efforts were expanded in 1995 to include “developing an enterprise level organizational simulation … where multiple and different kinds of projects and teams are involved” (p. 15).

The Levitt model applies contingency theory in evaluating how actors accomplish work through communication of work packets. Routing of information is determined using a quality functional deployment methodology that correlates the product design with organizational functions and reporting relationships (Levitt & Christiansen, 1994). Their model includes all current methods of communication between actors and helps predict bottlenecks in the organizational structure.

The performance metrics used by Levitt are organizational efficiency and effectiveness. “Measures of organizational efficiency include critical path duration and the sum of all activity durations” (Levitt, 1995). Levitt's model includes communication detail at the micro-contingency theory level by including considerations for synchronicity, cost, recordability, proximity of user, capacity, and bandwidth of the communications system.

Based on this review and no recent evidence of a similar modeling approach to that presented in this paper, the IPPD model presented in this paper has unique aspects in its attempt to model performance dynamics related to the intersection of a project organization and product architecture.

Comparison of IPPD Model Architecture with a Recent NASA Project

The author wishes to acknowledge and thank Mr. Stephen A. Hobart, IPT Leader, X-33 Design and Assembly, for his contributions to this section of the paper.

Since completing the IPPD model and the associated research, the author has been involved in managing a major NASA development program for the X-33 Linear Aerospike Engine. The X-33 engine program was organized into integrated product teams as previously described in Exhibit 1. During the course of the project, many issues related to resources, organization, work assignments and design technology impacted the design team effort. The project has now completed its design phase and the first engine is being tested at the Stennis Space Center in Mississippi.

In an effort to evaluate the IPPD model structure, the author enlisted the support of the IPT Leader of the X-33 Engine Design and Assembly Team. The IPT leader's recent project management experience and familiarity with a complex design process using concurrent engineering provided unique qualifications to comment on the models applicability. The IPT leader reviewed a draft of this paper and received a thorough explanation of the simulation architecture. His review was primarily focused on IPPD design team dynamics versus the modeling approach. He was also given the simulation itself and invited to experiment with it as a project management tool.

The IPT leaders review stimulated many new thoughts about enhancing the model functionality and identified some elements of the structure that can be adjusted to more accurately reflect current IPPD design processes.

The most significant structural comments were related to the increased influence that solid modeling has had on the design process and on work assignment strategy. While he confirmed the bottom-up/top-down approach to preliminary and detail design, he suggested separating all assembly drawings from detail drawings within the model. Assembly models and drawings require significantly more time than details and are the source for all detail drawing requirements. He also suggested separation of modeling from drawing generation as separate activities.

Another significant development relates to configuration control associated with solid modeling design methods. In order to carefully track and control drawing configurations generated from solid models, a convention called “mono-detailing” is used. In effect mono-detailing eliminates the use of assembly drawings containing more than one subassembly. As a result the product architecture or drawing tree grows significantly because all parts must have a distinct line of inheritance. A fallout of this development relative to modeling the process, is that the average work associated with an individual drawing is reduced while the number of drawings is increased. The overall effect of this appeared to be better configuration control but more work associated with the fixed cost of each drawing produced. The mono-detailing convention also has an effect on rework due to the added complexity of the drawing tree.

Other less significant but valuable suggestions from the IPT review were: (1) incorporate capability to select a specified drawing fidelity level, (2) incorporate the effect of system down time associated with design reliance on computer networks, (3) add interface control document activity related to intra-IPT communication, and (4) add the design analysis as a primary function on a level with product and process design. The third suggestion opens an entirely new aspect of multiteam modeling for large design projects. The IPT lead review also confirmed the need for addressing analysis as a major activity on the same level as product design and process design.

Application of IPPD Model to Future Project Management Research

Application

The model described in this paper is a prototype with obvious need for further development to enhance its use in project management research. It does break new ground in attempting to analyze one of the most current approaches to NPD—integrated product teams using concurrent engineering. Many opinions exist about the benefits of this relatively new form of project organization, but little hard research has been done to understanding its complexities and conflicting dynamics. The IPPD model is suggested as one way to conduct such research.

With additional development and validation, this modeling approach may be useful in a number of industries as a tool for analyzing, planning and predicting project design team performance. Through its use, specific questions about project performance can be addressed to devise more productive IPPD strategies in the following areas:

1. Product architecture

2. Requirements change and timing

3. Resource allocation

4. Work assignment

5. Schedule concurrency

6. Team communication

All these items are commonly recognized as critical elements of NPD project management and all are specifically addressed in the IPPD modeling approach.

A key advantage to using a discrete system simulation method for project team modeling is the limited predictive data required for its use. The more a tool like this is applied and anchored to empirical data, the more accurate it is likely to become in the hands of the user. It has obvious advantage over a network modeling approach, which is totally dependent on the a priori ability to estimate all paths, their associated logic links and activity durations. The time required to use the IPPD model is also not highly sensitive to the size of the project being analyzed, as in the case of the network model.

Enhancement

To be useful in major industries for studying team performance, several key enhancement need to be made to the existing IPPD model in the areas of coding, structure, capacity, interfaces, and fidelity. The enhancement identified by the IPT review provided an excellent starting point for model development.

All coding of the current model was done by the author as an educational experience as part of the dissertation research. The scope and utility of the model was limited to the needs of the original research effort. To be useful as a project management tool for research or application, it needs to be reconstructed by a professional programmer using a more efficient coding language. Significant improvement in execution should be achievable to enable expedient analysis of complex products and organizations using common personal computer configurations.

The capability of the model to accept a larger and more complex product architecture needs to be added. The current model is limited to two architecture levels below the top assembly. Typical industrial architectures involve four to six levels and multiple top assemblies. As the number of architecture levels increases, the complexity of data entry and viewing increases significantly. It also complicates the logic associated with rework and change control rules.

Data output windows and data formatting capability on the current model is limited to that required for the original research. Specifically it focuses on concurrency and resource utilization. Future data output windows should enable specification of the data of interest to the user. Visualization tools such as the drawing tree window also needs enhancement to enable viewing of much larger product architectures.

In the area of model control, an alternate method of run control is specification of a desired confidence level in the output data. As an alternative to a predetermined number of runs, specification of the desired confidence interval would cause the simulation to run the necessary number of runs to achieve the desired confidence level.

In addition to model development, there needs to be an effort to collect associated data for anchoring models by industry category. Although NPD follows a common general model across many industries, each industry has unique aspects to its design methodology and product architecture. A common taxonomy and methodology needs to be established for data collection in each industry.

Conclusion

The importance of project management knowledge is evident today in the rapid worldwide growth of PMI® and its membership. The economic well being of companies and governments is heavily dependent on the performance of their project managers. Technology and economic pressures are changing the landscape in which we practice project management every day. Methods of communication, work execution, and organization are also changing to keep pace with the world. Project management knowledge must also keep pace by conducting research to develop new knowledge and tools to meet tomorrow's challenges.

The IPPD model and approach described in this paper merely scratches the research surface of a potential tool domain that employs system simulation to enhance project management. It is intended to demonstrate the potential to use technology as an aid in project management in the same way that technology is being used to enhance processes like product design and manufacturing operations. The combination of today's computing platforms, Internet access, and user-friendly software design, can put the power of system simulation directly in the hands of project personnel as a day-to-day management tool. Project management research needs to provide the knowledge and data for building these sophisticated tools.

PM research must include both behavioral and structural elements of project dynamics to provide profound insight into project dynamics and performance measurement. Recent PMI® publications emphasize the need to broaden our understanding of the human aspects of project management, in addition understanding mechanics of the profession. “Looking to the future. project management will … place increasing importance on the people aspects of projects” (Carter, 1999). Organization structures, relationships, work strategies, and methods of communication are an integral part of all project management systems. Understanding how these human aspects and the mechanical aspects function together as an integrated system needs to be the ultimate objective of PM research. Mere computerization of existing processes and tools is inadequate use of emerging technology in the quest for profound advancement of project management knowledge.

Abdel-Hamid T.K. (1990, Jan.). Investigating the cost/schedule trade-off in software development. IEEE Software, 97–101.

Abdel-Hamid T.K. (1993).A multiproject perspective of single project dynamics. Journal of Systems Software, 22, 151–165.

Belhe U., & Kusiak A. (1995). Resource constrained scheduling of hierarchically structured design activity network, IEEE Transactions of Engineering Management, 42 (2), 150–158.

Carter, V. (1999, Dec.). PMI Today. Newtown Square, PA: Project Management Institute.

Cleland D.I., & King. (1988). Project management handbook, New York: Van Nostrand Reinholdt.

Cooper K.G. (1993, Fall). The rework cycle. Engineering Management Review, 4–12.

DOD guide to integrated product and process development (Version 1.0), Feb 5, 1996.

Eisenhardt K.M., & Tabrizi B.N. (1995). Accelerating adaptive processes: Product innovation in the global computer industry. Administrative Science Quarterly, 40, 84–110.

Ettlie, J.E., & Stoll, H.W. (1990). Managing the design-maing process. New York: McGraw-Hill, Inc.

Frame J.D. (1989). Managing projects in organizations. San Francisco: Jossey-Bass, Inc.

Galbraith, J.R. (1977). Organizational design. Reading, MA: Addison-Wesley.

Goldense B.L. (1993). Measuring concurrent engineering performance. Concurrent Engineering: Practical Applications for Superior Performance. Goldense Group, Inc.

Goldratt E.M. (1990). Theory of constraints. Croton-on-Hudson, NY: North River Press, Inc.

Hilscher, R.W. (1997). Modeling and analysis of concurrency, work content, and cycle time in aerospace development projects. University of Southern California

Jin, Yan., Levitt, E., Kunz, J.C., & Christiansen, T.R. (1995). The virtual design team: A computer simulation framework for studying organizational aspects of concurrent design. Simulation, 64, 3.

Kerzner H. (1998). Project management a systems approach to planning, scheduling, and controlling. New York: International Thomson Publishing Company.

Karagozoglu N., & Brown W.B. (1993). Time-based management of the new product development process. Journal of Product Innovation Management, 10, 204–215.

Khoshnevis, B. (1994). Discrete system simulation, New York: McGraw Hill, Inc.

Kraft II C.L. (1983, Sept.). Concurrency: Schedule compression is quality's challenge. Quality Progress, 12–17.

Levitt R.E., Christiansen T.R., Cohen G.P., Jin Y., Kunz J.C., & Nass C.I. (1994). The Virtual Design Team: A Computational Simulation Model of Project Organizations, CIFE Working Paper Number 29. (Available from Stanford University, Center for Integrated Facility Engineering).

Levitt R.E., Jin Y., Oralkan G.A., Kunz J.C., & Christiansen T.R., (1995). Computational Enterprise Models: Toward Analysis Tools for Designing Organizations., CIFE Working Paper Number 38. (Available from Stanford University, Center for Integrated Facility Engineering).

McDonough III E.F. (1993). Faster new product development: Investigating the effects of technology and characteristics of the project leader and team. Journal of Product Innovation Management, 10, 241–250.

Nijssen E.J., Arbouw A.R.L., & Commandeur H.R. (1995). Accelerating new product development: A preliminary empirical test of a hierarchy of implementation. Journal of Product Management Innovations, 12, 99–109.

Pourbabai B., & Pecht, M. (1994). Management of design activities in a concurrent engineering environment. International Journal of Production Research, 32 (4), 821–832.

Putnam, L.H. (1991, March). Trends in measurement, estimation, and control. IEEE Software, 105–107.

Report No. 95–2037. (1995). Integrated product and process modeling of AEC projects—A framework and an application in the electrical power industry. Det Norske Veritas, Program Committee 7.

Richardson G.P., & Pugh III A.L. (1981). Introduction to system dynamics modeling with dynamo. Massachusetts Institute of Technology.

Rolstadâs A. (1995). Planning and control of concurrent engineering projects. International Journal of Production Economics, 38, 3–13.

Rosenau, M.D. (1991). Successful project management. New York: Van Nostrand Reinholdt.

Winner, R.I., Pennell, J.P., Bertrand, H.E., & Slusarczuk, M.G. (1988, Dec.). The role of concurrent engineering in weapon system acquisition. Institute for Defense Analyses Report R-338, Virginia.

Womack, J.P., Jones D.T., & Roos, D. (1990). The machine that changed the world. New York: Harper Collins.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

Proceedings of PMI Research Conference 2000

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.