Investigating the Dynamics of Engineering Design Rework for a Complex Aircraft Development Project: Lessons Learned From a Soft Systems Thinking Lens

Organizations still struggle to efficiently manage their complex product development projects (PDPs). A contributor to poor project performance is the dynamics of engineering design rework (EDR), due both to the necessity of adjusting the product being developed and the disruption it causes to the development process. The purpose of this research is to evaluate the dynamics of EDR that negatively impacts the performance of complex PDPs and to suggest actions to overcome those problems. The soft systems thinking methodology underpins the research approach. The dynamics of EDR of an aircraft development project were modeled in a causal loop model.


Introduction
In organizations that implement product development projects (PDPs), project performance inefficiency can be aggravated by the level of uncertainty pertaining to the product being developed and the product development process (Turner & Cochrane, 1993). In addition, the project structural complexity, which includes the number of people, departments, and suppliers involved, can aggravate project performance inefficiency (Denicol et al., 2020;Williams, 2005). Also, since the objective of business organizations is to deliver profit, pressure for reduced time to market and costs is an important factor that cannot be neglected.
In PDPs, the project core is the design engineering team and processes, which are generally driven by product technical performance rather than by project performance in terms of cost and schedule. Even though the product development phase represents approximately 5% of the total project costs (Cao et al., 2011), 70% to 80% of the product costs are defined by the development engineering teams in this phase (Clark & Fujimoto, 1991;Kovacic & Filzmoser, 2014;Stark, 2005). Therefore, careful attention to the engineering design process is relevant. Engineering design rework (EDR) is one of the challenges presented by engineering design processes in PDPs.
Rework refers to activities that are expected to have been performed correctly the first time but need to be done again because of the identification of a problem (Love, 2002;Love et al., 2019). Generally, rework is accepted as a normal and intrinsic feature of PDPs because this type of project is a creative process (Ulrich & Eppinger, 2016) that involves uncertainty and evolving knowledge. Moreover, rework is an alternative to adjusting the product throughout the project so that an optimal solution aligned with the project requirements can be provided.
However, EDR has negative effects on PDP performance that in a worst-case scenario may be catastrophic. Engineering change can consume 30% to 50% of engineering capacity (Fricke et al., 2000;Hamraz & Clarkson, 2015;Loch & Terwiesch, 1999;Maier & Langer, 2011), meaning that engineering teams potentially spend up to half of their capacity on rework.
Because rework is a source of waste, it should be eliminated if project performance is to be improved. Consequently, the causes and effects of rework have been investigated (Love & Edwards, 2004;Love & Li, 2000;Love et al., 2014;Safapour & Kermanshachi, 2019;Wilson & Odesola, 2017;Wynn & Eckert, 2016;Yap et al., 2017). However, studies have shown that rework arises not from a list of individual root causes but from a network of multiple causes that influence one another (Love et al., 2016a;Yap et al., 2019). To address the lack of systematic knowledge concerning the dynamics of rework in the literature (Forcada et al., 2017), this research aims to understand the dynamics of EDR and possible actions to overcome its negative impacts on complex PDPs.
The presence of EDR in PDPs is a managerial problem because it disrupts the PDP process, is costly, and contributes to delays. Investigating the dynamics of EDR will provide a foundation for proposing recommendations to mitigate it and to improve PDP performance. For this reason, we seek to answer the following research question: What are the dynamics of EDR that negatively impact the performance of complex PDPs? To answer the research question, two research objectives are defined. The first is to identify the variables that make up the dynamics of EDR in complex PDPs. The second is to identify the feedback relationships between the variables that make up the dynamics of EDR in complex PDPs. For the sake of simplicity, from this point on, dynamics of EDR will be written as dynamics of rework.
The importance of investigating the nature of rework causation lies in the possibility of understanding the associated dynamics, meaning the internal structure of rework, the effects of which have been proven to contribute to project cost and schedule overruns (Safapour & Kermanshachi, 2019). The dynamics of rework are associated with interdependencies among the critical variables related to it. Love et al. (2016) supported the idea that if rework is to be addressed, it is necessary to alter or influence the dynamics of rework by changing project processes and policies so that undesirable effects can be mitigated.
The academic contributions of this research include opening the dynamics of rework black box, meaning the comprehension of their causes, consequences, and offering a set of actions to minimize them, in a way that they are not just accepted as a necessary evil of complex PDPs.
In addition, the managerial contributions include improving the understanding on how to cope with the dynamics of rework and providing a set of actionable practices, which includes the research methodology to understand complex problems and translate it into organizational behavior.
Even though the research methodology is generalizable, it is not the intention of this research to offer generalizable theoretical conclusions once the research is content dependent. Neither mirror the reality but propose models that support the comprehension of the reality and that serve as a basis for discussion. The onto-epistemological perspective is in alignment with the expected research contributions, as it will be detailed in the research methodology section.
This article is structured as follows. The first section introduces the presence of EDR in PDPs as a managerial problem that must be addressed. The second section presents the theoretical foundations of this research and the state of the art in the dynamics of rework based on a literature review. The third section presents the methodology undertaken for this research, including the theoretical perspective, the research design, and the description of the strategy for data collection and data analysis. The fourth section comprises the research results represented by the proposed dynamics of rework, and recommendations to influence the dynamics and improve project performance. The fifth section presents the key findings of the research, theoretical and managerial contributions, research limitations, and future research paths.

Research Theoretical Foundations
Complex Systems Lens to Understand the Dynamics of Rework Rework is accepted as normal and an intrinsic technical risk of PDPs and sometimes described as a necessary evil (Kennedy et al., 2014). Although it is necessary to adjust the product being developed, it disrupts the product development process and negatively impacts project costs and schedule (Wynn & Eckert, 2016). An alternative to address rework is to act in a preventive approach rather than the standard reactive approach.
For this reason, and supported by the borrowing theory (Oswick et al., 2011;Whetten et al., 2009), it is recommended that the project management literature on construction be consulted, once it recognizes rework as a problem that negatively impacts project performance (Ledbetter, 1994;Love et al., 2019). Additionally, it shows that rework is not the result of a list of individual root causes but arises from a network of multiple causes that influence one another (Yap et al., 2019). This network creates complex behavior within the project that results in counterintuitive effects when managers take actions to control project performance. Better understanding the complex project behavior, which in this research is the dynamics of rework, may contribute to addressing rework in a preventive manner.
In this article we choose to look at complex projects from a complex dynamic systems perspective (Cooke-Davies et al., 2007;Tywoniak et al., 2021). Complex projects can be classified as complex dynamic systems (Howick et al., 2017;Sterman, 1992) because they feature highly interdependent parts; are situated within a changing environment; and comprise multiple feedback loops, nonlinear cause-and-effect relationships, and hard and soft data (Sterman, 1992(Sterman, , 2000. Cicmil et al. (2006) suggested that relying only on traditional project management approaches, such as the critical path method, work breakdown structure (WBS), and earned value, is not appropriate for managing complex projects. Indeed, these approaches may mislead project managers in their attempts to properly monitor and control complex projects (Levardy & Browning, 2009;Williams, 2005;Williams et al., 1995) because they neglect the project dynamics originating from the high level of uncertainty and interdependence. Moreover, according to Ford and Sterman (1998), they cannot explain multiple cause-and-effect relationships.
Systems thinking, which is a holistic approach, has been proposed as a management alternative to handle the complexity and changing environment that are part of complex projects (Jackson, 2003). The objective is to identify the structures, patterns, and mindsets behind complex situations and actual events (Senge, 1994); this includes the dynamics of rework within complex PDPs, which is the managerial problem studied in this research. Thus, the systems thinking perspective is also selected as a theoretical foundation of this research.
Among several systems thinking methodologies, the system dynamics methodology has been used to understand complex problem structures so that the behavior of a system can be predicted and modified (Sterman, 2000).
System dynamics concepts have been translated into the project management context in the forms of two types of feedback loop: positive feedback loops, which are self-reinforcing processes; and negative feedback loops, which are selfcorrecting processes. According to Sterman (2000), the dynamics of systems arise from the interaction of the network of those two types of feedback loops, which are coupled with multiple time delays, nonlinearities, and accumulations. Thus, systems thinking using system dynamics modeling has been used to understand complex project behaviors (Lyneis & Ford, 2007).

Dynamics of Rework in PDP
A review of the literature concerning rework and systems thinking reveals four research fronts. The first concerns the rework cycle and its negative impacts on project performance, as described by Cooper (1980). The rework cycle is a positive feedback loop that assumes that project activities are not perfectly executed and that the imperfect portion needs to be reworked. Additionally, the rework cycle depends on the level of staff productivity and delays in identifying imperfections (Cooper et al., 2002). Rework cycle effects can be exacerbated by management decisions that are made to control and adjust the project outputs when the project is behind schedule. In this case, the control objective is to bring the project back to the planned schedule to meet the target delivery date. However, due to the lack of awareness concerning the rework cycle, these management decisions may result in counterintuitive effects such as significant project disruptions and delays (Eden et al., 2005).
The second research front concerns another positive feedback loop, the vicious cycle of parallelism presented by Williams et al. (1995). The authors observed that for complex projects that are time constrained and behind schedule, the situation may be aggravated by management decisions made in attempts to control the project schedule. Thus, when project managers authorize the parallelization of interdependent activities, the duration of the activities increases. However, when a project is time constrained, more parallelism is added to recover the schedule slippage, which in turn results in more work to be done, again increasing the duration of the activities in a reduced time frame, increasing the rework, and so on (Williams et al., 1995). The third concerns system dynamics models of PDPs. Some authors (Akkermans & van Oorschot, 2016;Ford & Sterman, 2003;Lin et al., 2008) proposed system dynamics simulation models to understand the trade-offs between overlapping design activities to reduce the development cycle and the risk of having to rework downstream activities due to upstream changes. In the same direction, Rodrigues et al. (2006) developed a system dynamics simulation model using soft and hard systems thinking. The study objective was to understand project dynamics when changes in the scope happened because of the development of new technology. Rework was identified as a dynamic factor, in other words, a variable in the model.
The last research front comprises studies in the project management construction literature that have investigated the dynamics of rework and its causal factors. This stream of the literature reveals a lack of systematic knowledge concerning the dynamics of rework (Forcada et al., 2017). Studies have used systems thinking to fill this gap. For example, studies have proposed systemic models using influence diagrams to represent rework causation based on analyses of offshore hydrocarbon projects (Love et al., 2011), highway projects , and urban renewal projects in Colombia (Forcada et al., 2017). Burati et al. (1992) found that 78% of rework was due to design changes, which in turn represented 9.5% of the project cost of the nine construction projects being investigated. Thus, Yap et al. (2019) adopted a systemic approach to model design change causation in construction projects using causal loop modeling. The authors also considered the efficacy of communication and knowledge as a strategy to reduce design changes.
Thus far, no study in the product development literature has investigated the dynamics of rework. Curiously, although the construction literature recognizes rework as a problem, few studies have investigated the dynamics of rework, which makes it difficult to propose generalizations and predictions for addressing the rework problem (Forcada et al., 2017;Yap et al., 2019).

Research Methodology
In the context of this research, we seek a solution for a real problem, and we don't seek to theorize it. Hence, the chosen research perspective is in accordance with the instrumentalist organizing approach-which is one of the four philosophy of science approaches proposed by Kilduff et al. (2011)because the logic of scientific knowledge production of this research is problem-solving driven. This research is neither seeking to represent reality nor getting close to the truth.
The PDP environment is continuously changing and these changes come from different sources and at different times in the project life cycle (Godlewski et al., 2012). Thus, to understand the reality of the environment in which the dynamics of rework are embedded, this research adopts an organizational becoming stance as the ontological perspective (Tsoukas & Chia, 2002).
In addition, because the object of this research depends strongly on its context and on different stakeholders' perspectives, and that an improved future situation is pursued, we adopt a pragmatist epistemological lens (Kelly & Cordeiro, 2020;Simpson & den Hond, 2021). Pragmatism is appropriated as the research participants' ideas and beliefs are part of the process to solve the problem being investigated (Kelly & Cordeiro, 2020). Also, when actual organizational behaviors are not effective anymore, a transformation is needed to deliver satisfactory results (Simpson & den Hond, 2021).
The research approach is inductive because this approach is appropriate for exploring underdeveloped constructs or cases in which complex observation is required (Love et al., 1999). The process of sensemaking of the data collected is supported by the systems thinking approach, as it is a holistic and alternative way of dealing with the complexity and dynamics of complex projects (Jackson, 2003). Also, it allows modeling the complex project behavior by seeking patterns of behavior, through system archetypes (Senge, 1994) and understanding what is being observed, so that recommendations can be proposed to improve the system's future outcomes (Bredillet, 2010). Hence, we are not looking for representing the reality but the changing that is taking place. Table 1 summarizes the research foundations.

Research Strategy: Holistic Single-Case Study
The qualitative research strategy is the holistic single-case study (Yin, 2003). This research adopted a complex PDP as the single unit of analysis and the engineering design process as the level of analysis. The case study is analyzed from a holistic perspective in order to understand the dynamics of rework in a PDP. The time horizon for this research is longitudinal (Saunders et al., 2012;Yin, 2003) rather than cross-sectional, because the rework can be presented at different points in the life cycle of a complex PDP. Because of the specific features presented in this case study, such as project complexity, long duration, and extensive scope, it is considered an appropriate environment for analyzing the dynamics of rework.
The case study took place in an original equipment manufacturer (OEM) located in Canada. This OEM is a global industry leader and one of the world's top-100 aerospace companies. The case study examined a multibillion-dollar aircraft development project. The project duration was approximately 10 years and it involved hundreds of suppliers and thousands of professionals. The product developed was highly complex in terms of the level of development effort, coordination between stakeholders, and overall project scope and budget. It introduced complex technologies that were new to this OEM as well as some first-to-market features. The scope of the project analyzed in this research is the nonrecurrent project development efforts.

Research Methodological Structure
The overall research methodology was structured in three phases, as presented in Figure 1.
Phase 1 concerns the early findings of this research, which were based on the literature review and the definition of the research question and objectives.
Phase 2 concerns the data collection. The strategy for the data collection included collecting data from multiple sources, such as participant observation, documentation analysis, and semistructured interviews, to ensure construct validity (Yin, 2003). The data collection comprised more than one year at 20 hours per week for the participant observation process in the last years of the case study project; 12 ad hoc meetings with organization professionals in finance, product development, and project management, among others who were part of the case study; the analysis of hundreds of documents of the case study and the organization, including PDP assessment reports, organizational procedures, and project cost, schedule, and technical change requests; and 42 semistructured interviews to achieve information saturation were conducted with relevant professionals who worked on the case study project, representing more than 50 hours over two months. Additional details are presented in Figure 2.
Phase 3 concerns the data analysis. The strategy for the data analysis followed the iceberg model described by Stroh (2015). The iceberg model proposes three levels of understanding the dynamics of rework: events, patterns, and systemic structure.
The events layer represents the tip of the iceberg. It includes the holistic understanding of the managerial problem context, the main facts, the involved stakeholders, the decisions made, and the available options. The causal map (Ackermann & Alexander, 2016;Eden, 1994) and the rich picture (Checkland & Poulter, 2010) are the techniques of soft systems thinking being used to depict the case study events gathered during the data collection. Due to the organization's policies, the researchers were not allowed to record the semistructured interviews; consequently, the information acquired during the interviews was captured by means of note taking, which is a standard practice for capturing data in qualitative research (Yin, 2016). The interview notes were transformed into reports, which were validated by the interviewees. The semistructured interviews were represented in cognitive maps (Eden, 1988), and the merging of the cognitive maps resulted in the causal map (Ackermann & Alexander, 2016) in Figure 3, described in the next section. The results of the participant observation and documentation analysis were represented in the rich picture ( Figure 4) described in the next section. Both the causal map and the rich picture were continually validated by the case study participants, in other words, relevant participants of the project case study and organization senior specialists.
The patterns layer is the center of the iceberg. It represents the perspective of a deeper understanding of the dynamics of rework through seeking patterns of behavior. For this reason, system archetypes (Senge, 1994) are used because they are generic patterns of behaviors previously identified in the literature (Rehak et al., 2006).
The data collected-through the semistructured interviews, the participant observation, and documentation analysis-and represented in the causal map and the rich picture, in addition to the triangulation of the case study participants and the researchers' perception, allowed the modeling of the models proposed in this research.
The research relies in modeling the dynamics of rework to better understand it to improve the system's future outcomes (Bredillet, 2010). The modeling was based on the systems thinking approach (Stroh, 2015). The researchers were looking for identifying behaviors in the case study that matched with existent systems archetypes (Senge, 1994). The modeling was a sensemaking process featured by iteration and coconstruction with the case study participants, allowing a better understanding of the dynamics of rework. Thereby, four models were proposed and validated by relevant case study participants.
The systemic structure layer is the bottom of the iceberg. This layer represents the mechanism that gives rise to the previous layers' results and is the ultimate goal of this research. The causal loop model (Sterman, 2000) is used to represent the systemic structure of the dynamics of rework in a complex PDP, summarizes the main variables and feedback relationships between the variables, and is the conceptual framework proposed in this research.
Two systems archetypes were the basis of the four models proposed in the previous layer. Since systems archetypes are useful diagnosis and prognosis tools for complex behaviors, they contribute to the proposition of high-leverage recommendations to influence the systemic structure and to improve its outcome (Kim, 2000). For this reason, the results of this research allowed the proposition of six recommendations that intend to influence the dynamics of rework to mitigate the EDR and to improve PDP performance.

Results
The results presented here are the output of Phase 3 of the research process (data analysis in Figure 1). The results are divided into three levels: the events layer, patterns layer, and systemic structure layer, and are presented in the following sections.

Events Layer
The causal map and the final version of the rich picture are the results of the first layer of the data analysis, the events layer, and research process Phase 3 (see Figure 1).

Causal Map
According to Ackermann and Alexander (2016, p. 896), "Capturing the breadth of perspectives in a causal map enables the often substantial amount of qualitative data to be structured and revealed as interconnected 'chains of argument' in its entirety. As such, the map enables a holistic and systemic view of the project, particularly when in electronic form." One of the purposes of creating causal maps was to make sense of the chain of causality of the complex problem being investigated. The idiographic causal maps are used to understand the causes and the short-and long-term effects of decisions that were made throughout the project, as well as the available options and their consequences. An additional advantage of creating idiographic causal maps is that this technique does not neglect the context or different stakeholders' perspectives. Also, it is a good way to holistically communicate the problem being assessed by means of a chain of causality (Ackermann & Alexander, 2016). A causal map that summarizes the data collected during research process Phase 2 (see Figure 1) from the participant observation and documentation analysis as well as the cognitive maps created from the semistructured interviews was built and is presented in Figure 3. Figure 3 should be read from the bottom up; the chain of events of the case study that impacted project performance are connected through arrows, meaning that a cause is connected to its consequence. Figure 3 is described in three stages.
Stage 1 concerns the preliminary phase of the case study, which occurred in a highly competitive market context, necessitating an aggressive project schedule and constrained budget. Additionally, since the organization was undertaking other PDPs, the product development experts were unavailable. The organization decided to develop a product based on a previous product version, confident that the previous product information could simply be reused. As a result, the project scope was based on a reuse mindset, and the product complexity was underestimated.
During Stage 2, the previous stage contributed to the managerial decision to heavily overlap the product development phases and allow the project to progress with knowledge gaps to reduce the project duration. However, as the project progressed, the product complexity and technical challenges were revealed. Consequently, additional product requirements became necessary to assure product competitiveness, which further increased the product complexity and initiated rework cycles. This combination of factors invalidated the project reuse scope, and the new project scope turned out to be much more complex. The facts that unfolded in project Stage 2 were exacerbated by the underestimations presented in Stage 1.
During Stage 3, the combination of overlapping project phases and increased product complexity initiated rework cycles that resulted from teams working with unfrozen information and with information at different maturity levels, which consequently made them work asynchronously. The rework resulted in more work to be done and reduced the engagement of the teams, including suppliers, in collaborative work and integration. This in turn created another source of rework because as teams collaborate and integrate less, they are more likely to discover errors in downstream phases, leading to new rework cycles and contributing to project disruption. Even though the final product was outstanding-according to the perception of the organization-the project performance in terms of cost and schedule did not meet expectations. The causal map was an important tool to make sense of the chain of causality of the managerial decisions along the project life cycle.
Decision Explorer (Version 3.5.0) from Banxia Software was used as the tool to build the causal map presented in Figure 3.

Rich Picture
The rich picture is an emergent process that occurred throughout the data collection Phase 2 (see Figure 1). The final version is presented in Figure 4.
In the final version of the rich picture, two main topics are highlighted. The first is the major stakeholders, such as competitors, customers, product development, suppliers, project manager, and regulatory agencies. The second is the main contextual facts, such as market competitive environment, project portfolio management, engineering design rework, product lacking capabilities, and product not complying with the expected weight. The quotes in the rich picture represent remarkable citations of the research participants during the data collection process.

Patterns Layer
Four patterns of behaviors were identified in the causal map and rich picture. They were modeled as qualitative causal loop models based on two system archetype structures: fixes that fail and shifting the burden (Senge, 1994). The four modelsreused mindset, phase overlap, best guess, and accidental adversaries adapted-represent the results of the second layer of the data analysis, also known as the patterns layer, research process Phase 3 (see Figure 1).

Reuse Mindset Model
The context was that the organization was under pressure owing to a competitive environment and scarce experts. In such a case, a product solution should be proposed to address the competitor threat. The solution should fit within the budget, schedule, and human resource availability constraints. The combination of the previous elements contributed to the organizational decision to propose a quick-to-market product solution based on a previous product version, in other words, a product solution that was familiar to the organization. This decision was in alignment with the budget, schedule, and human resource constraints of the organization.
However, the competitive environment became even more challenging at the time the project was undertaken. The product solution that fit the budget and schedule was no longer sufficient to beat the competition. Therefore, additional product features needed to be added to the initial scope of the project, increasing the complexity of the product solution, which in turn initiated EDR cycles. The evolving understanding of the necessary effort to deliver a competitive product undermined the previously estimated budget and schedule that had been authorized for the project.
Modeling this event revealed that it matches the "fixes that fail" system archetype presented in Figure 5. The balancing loop (B11) connects the problem symptom variable and the quick-fix variable, which are the variables "late to market" and "quick-to-market response, reuse mindset," respectively. Therefore, to minimize the problem symptom, which is being late to market, the quick fix of delivering a new product based on a previous product version was implemented. The quick fix was reinforced by the product development portfolio of the organization as well as the availability of product development professionals. It was perceived as the correct choice because the product solution was already understood by the organization, was expected to consume less time and effort, and consequently offered a reduced number of unknowns and uncertainties.
However, the quick fix resulted in unintended consequences that in the long term increased the problem symptom through reinforcing loops (R11 and R12). Reinforcing loop R11 presents the unintended consequences of not achieving an optimal concept and/or design for the product, leading to the need for change, which consequently increases the amount of work to be done and contributes to delaying the product delivery and increasing the product development cost.
A second unintended consequence is presented by reinforcing loop R12. Because the quick fix was anchored in a quick-to-market response and in a reuse mindset, it led to a lack of recognition of the product complexity, which in turn led to scope creep. The need for changes and additional work undermined the goal of not being late to market.

Phase Overlap Model
The organization was late to market though it had decided to propose a quick-to-market product solution based on a previous product version. In addition, the product development experts were not available. The combination of these facts contributed to executing the PDP phases at a high level of concurrence rather than sequentially, as expected in a product development process.
The concurrence of the phases forced the teams to work with unfrozen or outdated information, necessitating future changes and EDR activities. Additionally, some long-lead-time items were expedited, which led to asynchronous work execution between interdependent teams, which also unfolded into changes. The changes increased the amount of work necessary to accomplish the project. In such cases, it may become impractical to follow the optimal product development process due to disruptions caused by the need to rework.
Modeling this event revealed that it matches the "shifting the burden" system archetype presented in Figure 6. The balancing loop (B22) connects the problem symptom variable and the quick-fix variable, which are the variables "late to market" and "phases overlap," respectively. To minimize the problem symptom, being late to market, a quick fix was implemented. The quick fix was to overlap the execution of the product development phases to reduce the product development cycle duration. Initially, the quick fix seemed inoffensive and the best option for fast-tracking the project. However, the balancing loop (B23) shows that the fundamental solution is to follow the product development process, in other words, undertake the main phases of product development sequentially.
In addition, the quick fix triggered side effects that made the fundamental solution even more difficult to implement. The side effects are represented by the reinforcing loops (R23 and R24). Reinforcing loop R23 shows that the side effects of overlapping the product development phases led the teams to work asynchronously, in other words, not in the optimal activity execution sequence. This in turn resulted in changes and additional work to be done, which disrupted the product development process. Reinforcing loop R24 shows that overlapping the product development phases led the teams to work with unfrozen information, consequently leading to changes and additional work to be done, increasing the project cost and disrupting the product development process.

Best Guess Model
Generally, knowledge gaps, a high level of uncertainty, known unknowns, and unknown unknowns are expected in the preliminary phases of a PDP. The knowledge gaps are reduced or  closed as the product development process is followed and the project evolves. However, to achieve the desired time to market, the organization chose to progress on the basis of the best guess, in other words, the best of the available knowledge.
There is a project performance risk associated with the decision to progress based on the best guess or to push the resolution of upcoming knowledge gaps. The risk is that when assumptions turn out to be invalid, changes, additional work, and increased project costs will be necessary. Moreover, invalid assumptions disrupt the product development process because new decisions may be needed based on new assumptions.
Modeling this event revealed that it matches the "shifting the burden" system archetype presented in Figure 7. The balancing loop (B34) connects the problem symptom variable and the quick-fix variable, which are the variables "knowledge gap" and "progress with best guess," respectively. To minimize the problem symptom of the knowledge gap, the quick fix of progressing with the best guess and resolving the details later in the product development process was implemented. However, the balancing loop (B35) shows that the fundamental solution is following the product development process because increasing product maturity is expected as the project progresses in its life cycle.
The quick solution triggered side effects that made it even more difficult to implement the fundamental solution. The side effects are presented in the reinforcing loop (R35), which shows that progressing in the project with the best guess may expose the project performance to the risk of invalidating assumptions, consequently leading to changes, additional work to be done, increased project costs, and disruption of the product development process.
Accidental Adversaries Adapted Model PDP performance depends on the performance of the suppliers and partners that are contracted for the project. However, in the case study, the additional features that became necessary to deliver a competitive product led to EDR for the organization itself and for the suppliers involved in the project as knock-on effects of the engineering changes.
The EDR led to additional work to be done, undermining the profit expected by the supplier. This in turn led to the supplier renegotiating the contract and engaging in a commercial dispute rather than proceeding with the project. This contributed to the ongoing erosion of the collaborative relationship between the supplier and the organization. As the collaboration decreased, the technical solutions were not necessarily optimal, which triggered new EDR cycles.
Modeling this event revealed that it matches an adapted version of the "accidental adversaries" system archetype, which resulted in a combination of two "fixes that fail" system archetypes, presented in Figure 8. The balancing loop (B46) connects the problem symptom variable and the quick-fix variable, which are the variables "optimal concept/design" and "changes," respectively. Therefore, to minimize the problem symptom that does not achieve the optimal concept/design solution, the quick fix is to perform the necessary changes to the concept/design. The quick fix of the balancing loop (B46) results in an unintended consequence, which is additional work to be done, in turn impacting the other balancing loop (B47).
Balancing loop (B47) connects the problem symptom variable and the quick-fix variable, which are the variables "supplier's profit" and "supplier commercial disputes," respectively. To minimize the problem symptom, which is reduced supplier profit due to the need to rework the design, the quick fix is to renegotiate the contract, initiating commercial disputes. The quick fix of the balancing loop (B47) results in an unintended consequence, which is the eroded relationship between the organization and the supplier. This reduces the collaborative work between them, in turn impacting the other balancing loop (B46) and reducing the likelihood that the optimal concept/design would be proposed. The combination of the unintended consequences of the balancing loops (B46 and B47) is the reinforcing loop (R46).
In summary, the initial relationship between the organization and the suppliers was expected to be a win-win relationship. However, as the project advanced, each party was concerned with achieving its own success, and the results of their actions to do so may have negatively impacted the success of the other party, eroding their relationship throughout the PDP.

Systemic Structure Layer
The causal loop model is the result of the third layer of the data analysis, the systemic structure layer. The causal loop model was built based on the combination of the four models identified previously in the patterns layer. It was modeled based on soft systems dynamics methodology. The causal loop model is the conceptual framework proposed by this research and it represents the dynamics of rework in a complex PDP.
The main variables identified in the causal loop model are asynchronous work execution by the development team, collaborative work, product development professionals' timely availability, product complexity recognition, invalid assumptions, quick-to-market response, reuse mindset, progress with best guess, phase overlap, working with unfrozen information, supplier commercial disputes, and optimal product concept and design. In addition, the feedback relationships between the variables are represented by the balancing and reinforcing loops identified in the four models previously discussed. Figure 9 presents the causal loop model identified during the data analysis, which comprises the variables and feedback relationships of the dynamics of rework in a complex PDP. Identifying the variables and understanding the balancing and reinforcing loops that represent the relationship between those variables is the ultimate goal of this research.

Recommendations
From this holistic perspective resulting from data collected and analyzed throughout this research, six recommendations are proposed as high-leverage actions to influence the dynamics of rework and improve project performance.
First, perform a robust product requirement management process and manage to have product development experts available, especially in the initial phases of the complex PDP, to ensure timely identification, validation, and verification of the product requirements. This approach is expected to uncover unknowns and lead to a better understanding of the product complexity and better project scope, budget, and schedule.  Second, reuse of previous product development information is recommended, but two points must be observed. First, information reuse must be challenged and assessed in the new PDP context so that only added-value information is retained. Second, information reuse does not mean that the time needed to perform the associated activity will be reduced; however, the risk associated with the activity will be mitigated.
Third, the overlap of project phases should be managed carefully, and extreme overlapping of project phases is not recommended. However, the involvement of downstream teams in up-front phases is recommended for two main reasons. First, downstream teams, such as manufacturing and test teams, can provide insights to the product development team. Second, downstream teams can be provided with valuable up-front information that they can use to plan their activities, contributing to streamlining the project progress.
Fourth, interdependent product development teams should have clear visibility of the development activities sequence. They should work closely together and progress at the same pace within the PDP phase. In other words, they should work synchronously, in contrast to the usual practice of teams working in silos and trying to achieve purposeless schedule dates, resulting in asynchronous work execution, the sharing of outdated information, and the consequent future need to rework.
Fifth, although knowledge gaps are expected in complex PDPs, those that represent high risk for the project should be closely managed. In addition, to ensure that the proper amount of effort is made by interdependent and downstream teams that are receiving information that is not frozen, it is recommended that the condition of technical data be clearly distinguished between teams as preliminary versus validated, ensuring transparency and collaboration.
Sixth, a sustainable win-win relationship between the organization and its suppliers throughout the PDP is recommended. Routine communication, colocated work, and a collaborative rather than opportunist attitude are important elements that contribute to a win-win relationship. Moreover, if an organization performs a robust up-front product requirement management process, the consequently improved scope, budget, and schedule will contribute to better negotiations with suppliers before contracts are signed. In the long term, this may also reduce supplier claims.

Conclusion
This research aimed to better understand the dynamics of rework in a complex PDP. The academic literature and organizations are converging in the direction of seeking alternatives to reduce the product development duration to achieve rapid time to market and reduce product development costs, while simultaneously delivering a product that satisfies the evolving requirements to keep the product competitive. However, due to the structural complexity and the dynamics of those projects, short-term managerial decisions to control project performance (in terms of time and cost) are nonoptimal in the long term and contribute to initiating rework cycles. This, in turn, undermines the initial project time and cost targets. Thus, EDR contributes to those counterintuitive effects as it unfolds knock-on effects due to product complexity and the interdependence of parts and systems.
Therefore, acknowledging the dynamics of rework, in other words, its systemic structure, and applying high-leverage actions to influence the systemic structure are the first steps in the direction of improving project performance. To better understand the EDR phenomenon, this research objectively evaluated the dynamics of EDR and proposed possible actions to overcome its negative impacts in complex PDPs.
The causal loop model in Figure 9 represents the systemic structure of the dynamics of rework in a complex PDP and summarizes the main variables and feedback relationships between the variables identified in the case study. From this holistic perspective, based on the data collected and analyzed throughout this research, six recommendations are proposed as highleverage actions to influence the dynamics of rework and improve project performance.
The academic contributions of this research include not accepting the rework just as a fatality of complex PDPs as observed in the literature, by offering a supplemental level of understanding of the causes and consequences of the dynamics of rework, as illustrated in Figure 9.
In addition, the managerial contributions include the awareness of the dynamics of rework, which was a coconstruction process between the researchers and the practitioners through the application of the systems thinking methodology, as well as the proposition of six high-leverage recommendations to minimize the dynamics of rework's negative effects on the project performance.
Despite the care taken during this research, it may present some limitations. Although the case study is a unique complex PDP, it concerns a single organization. The researchers did not interview any executive-level staff, suppliers, or procurement professionals, which would have been desirable. Finally, recording was not allowed; thus, some limitations are expected in capturing the information provided during the interviews.

Funding
This study was supported by the Coordenação de Aperfeiçoamento de Pessoal de Nível Superior Foundation (CAPES), Ministry of Education of Brazil (grant n. BEX 13606/13-1).