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

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, 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 self-correcting 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 (Forcada et al., 2014), 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 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.

OPEN IN VIEWER

Figure 1.

Research methodology process. *Dashed lines connect blocks in which activities take place simultaneously.

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.

OPEN IN VIEWER

Figure 2.

Semistructured interview information.

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.

OPEN IN VIEWER

Figure 3.

Case study causal map.

OPEN IN VIEWER

Figure 4.

Case study rich picture.

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.

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).

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 models—reused 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.

OPEN IN VIEWER

Figure 5.

Reuse mindset model.

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.

OPEN IN VIEWER

Figure 6.

Phase overlap model.

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.

OPEN IN VIEWER

Figure 7.

Best guess model.

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).

OPEN IN VIEWER

Figure 8.

Accidental adversaries adapted model.

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.

OPEN IN VIEWER

Figure 9.

Causal loop model: dynamics of rework.

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.