Agility in Engineering Change Management: Navigating Complexities of Emergent Changes in PLM

1. Introduction

Global distribution of business processes for product development can provide significant benefits in terms of flexibility and cost savings. However, it can also pose new challenges due to diverse requirements in different contexts, such as countries, organizations, cultures and regulatory constraints. This is especially palpable in industries like medical devices, rooted in historical, cultural, natural and economic reasons (Riascos et al., 2019).

To address the diversity in requirements, the engineering design process often involves the customization or modification of existing products during multiple optimization loops rather than starting from scratch. These transformations and changes from one state of the product to another are known as Engineering Change (EC) and are fundamental characteristics of engineering activities. EC involves any modification to the form, fit, and/or function of the product, whether it be an alteration made to parts, models, or software, to improve it (Sjögren, 2018). Engineering Change Management (ECM) is a sub-process of the product development process and is a dynamic process of knowledge generation and reuse for products, projects, processes and resources within an enterprise (Tavčar and Duhovnik, 2005). This process can help enterprises comply with the diverse requirements of different contexts, thus reducing the risk of legal or regulatory penalties (Batista et al., 2023).

Today, the ECM process must adequately support development projects in the industry to meet goals in terms of time, costs, quality and transparency. To achieve project success, it is essential to anticipate, detect, follow up and resolve ECs appropriately (Sjögren et al., 2019). ECM has demonstrated to improve the management of associated risks through the identification and mitigation of risks that may emerge with product changes. However, it is still unclear how ECM can be most effectively applied in the context of the growing complexity of products and processes (Wynn and Clarkson, 2018), shortening of time-to-market, and increasing dependencies on partners in the supply chain (Riascos et al., 2020).

The complexity of ECM in today’s world is — among many others — significantly influenced by two drivers: Globally distributed product development, which expands the number of interdependencies in a product during the design process, and the increasingly prevalent use of agile approaches in almost all engineering and management domains in recent years (Ammersdörfer and Inkermann, 2022). While an agile process inherently multiplies the number of modifications and increases the divergence of design solutions, big challenges remain in how to provide the sufficient level of convergence needed under such volatile conditions (Wilms et al., 2019). In an era of constant turbulence and unforeseeable disruptions, adaptability and agility have become crucial traits for industrial organizations and processes.

Agility is a key capability for organizations looking to respond efficiently and effectively to changes in their operational environment. Efficiency and effectiveness are critical components of agility, requiring timely, cost-effective and useful responses (Subowo, 2015). The importance of agility as a basic process capability is increasing due to the continuous and unpredictable changes in our world, coupled with the mostly uncertain development direction of the business environment. Agile methods provide significant benefits for systems with long life cycles where the needs of users and stakeholders may change over time, and it is not feasible to build a new solution for each requirement change due to resource and budget constraints. As a result, companies are increasingly turning to agile development methods, transferring and integrating them from software product development to the product development domain (Goevert et al., 2019).

To ensure the success of these design processes, they must be adequately documented and made transparent to all stakeholders. A Product Lifecycle Management (PLM) strategy and tools greatly help in this aspect (Stark, 2019). PLM is a strategic and product-centric business approach that seeks to integrate people, practices, processes and technologies within and across functional areas of the extended enterprise from inception to disposal. Agile processes can provide a valuable enhancement to PLM, but they need to be appropriately mapped within the framework (Pinquié et al., 2015; Habib et al., 2022).

However, commercial PLM systems are developed and work for the waterfall approach only (Stark, 2016). Currently, the agile process is not covered by the standard PLM processes, so a conceptual solution to adopting agile processes within PLM is necessary (Wu et al., 2014). The resulting conceptual map should support the logical flow of the referred activities and help companies to manage the concatenated challenges of product development in a more agile and effective way (Morris et al., 2016).

The key point of this research is how to make the agile approach practicable for the ECM in order to achieve a balance between the almost sudden changes in the agile process and the formalism of the ECM process as built in the PLM systems. This study delves into the importance of implementing an agile approach to ECM in effectively managing the complexity of emerging change requests throughout the product development lifecycle. This research holds great significance because ECM must effectively support the development of complex projects within the industry, meeting requirements in terms of time, costs, quality and transparency. Adequate anticipation, detection, follow-up and resolution of ECs are essential prerequisites for achieving project success (Sjögren et al., 2019).

The remainder of this paper is structured as follows. Section 2 provides an insight into the literature review, followed by Sec. 3 where the need for action is presented. Our new concept is described in Sec. 4. We discuss the advantages and drawbacks of our conceptual solution in Sec. 5, followed by conclusions and outlook in Sec. 6.

2. Literature Review

EC is a cross-domain process, which affects almost all business units in the manufacturing industry. The nature of the EC as a driver and/or trigger of other processes, making it a fundamental, underlying engineering discipline, which encompasses the procedural handling of design errors with the subtler and/or more substantial resolution of issues arising from uncertainties in designer, customer and market requirements (Jarratt et al., 2011). EC may become extremely complex, a classification according to several criteria (cause, initiator, impact, etc.) is useful to process changes according to business needs. The market provides several stand-alone tools to support both workflow and decision-making in EC. EC as a process is directly connected to the makeup of the product in terms of architecture, complexity and degree of innovation (Wickel, 2017).

As EC can encompass a large scope of the product lifecycle, some simplified versions of EC or instances of the process for a smaller portion of the entire lifecycle can be already valuable for an enterprise. For example, an instance of EC, namely the Manufacturing Change Management (MCM), entails a sequence of steps to manage the changes between planning and the shop floor. MCM fulfills the business environment and identifies the main participants of the change processes. The best possible structural steps involved in the processing of a change enquiry are detailed and the typical tasks and their extents are managed throughout the process. Concrete use cases of the MCM show how to work out a software-based support structure for the concept and implementation. The key element of the implementation is to map the changes within a superordinate change list (Macke et al., 2016).

Knowledge Management (KM) in the ECM process is crucial for any manufacturing enterprise (Tavčar et al., 2019). Systematically gathered, analyzed and interpreted professional experiences can prevent technical problems, unnecessary costs and delays. A five-step KM model that is integrated into the EC process is proposed, using the Failure Modes and Effects Analysis (FMEA) and design history files as documents in order to manage the knowledge related to a specific product. Supporting activity for applying KM includes a campaign to raise awareness, and the transfer of tacit knowledge. A mixed team of senior and junior engineers can stimulate this. The content of the acquired knowledge should be checked periodically, and the analysis should be followed by corrective measures and the build-up of best practices for ECM (Iakymenko et al., 2020).

The manufacturing industry is adapting to increasing complexity in demand and requirements, the reaction to these challenges has been the adoption of agile processes or making processes more agile (Yin et al., 2022). However, most of the non-agile users are afraid of the implementation challenges and that not enough support is available. These challenges should be eliminated to make it easier for the non-agile user to implement agile development (Zheng et al., 2019). An overview of agile methods and the selection process would be particularly helpful (Goevert et al., 2018). Implementing agile development would address certain challenges, such as the overhead of managing requirements changes, currently impacting non-agile development. In the implementation process, it is important to change the company culture and the mindset of the employees as well. This underlines that a structured implementation of agile development is very important.

In order to bolster the facilitation of agile development projects and assess their applicability within the disciplines of mechatronic system development, new, innovative methodologies within the EC process are necessary (Tavčar et al., 2018). Based on an analysis aimed at identifying research priorities in the field of agility, factors were derived that would provide promising support for the development of mechatronic systems. Current approaches that take into account these factors seem well suited for their respective purposes. However, they lack the conscious integration of technical or process-related knowledge. In addition, the integrated consideration of product development and the simultaneous development of associated validation and production systems is currently not addressed by existing agile approaches (Heimicke et al., 2019).

Agility in product development can be enabled through an adaptive ECM concept. For this purpose, three categories are derived as design elements called layers: Adequate means of communication from the front end of the framework, processes and roles as the intermediate layer, and a suitable data structure as the back end. For a suitable design of the means of communication, content-related data must be accessible at any time, standards for documentation must be provided and shop floor staff must be supported in communication processes (Pan and Stark, 2022). For processes to be efficient, they have to be customized accordingly, and a clear scope of duties must be assigned to members of the organization. Schuh elucidates a step-by-step product emergence process incorporating different phases of agile manufacturing. The process is based on adaptive ECM in three layers (Fig. 1): adaptive communication, receptive EC process and consolidated data structures (Schuh et al., 2017). Conversely, agility can be achieved in the singular stage.

Scrum’s agile techniques were also assessed for use in the design of machinery and plant, since the entire Scrum process does not always have to be established in the industrial practice of manufacturing physical products. Subsequently, the methodology for agile engineering in mechanical and plant engineering was developed, which consists of a reference model, a scaling method and a software tool. The reference model discovers the current state of the art and research in relation to mechatronic development processes using agile techniques. Using the scaling method, the reference model can be applied with regard to the agile techniques to be used as well as the activities of the mechatronic development process and a suitable agility class can be concluded using context criteria (Klein, 2016).

The suggested implementation methods (method overview, selection method, adaption method, planning method) and a guideline are perceived as being helpful. In contrast to the standard Scrum procedure for managing changes, the proposed approach regards the development situation at the time of an ECR. However, the simplicity of the workflow proposed, comparing it to existing ECM approaches, enables to easily integrate it into an agile framework. Furthermore, the workflow for managing ECs within an agile framework provides decision support for evaluating the change request’s implications on the ongoing sprint (Goevert et al., 2018). Nevertheless, it is suggested to proactively manage changes by scheduling short sprint durations at the beginning of the development process, and by deriving highly specific tasks from the product backlog. Consequently, significant errors will be detected earlier and the change effort will remain low (Becerril et al., 2017).

Peterson and Summers explore challenges identified for the implementation of scrum for hardware development intersecting with agile principles. A series of comparative analyses are done at the textual level, through logical intersections and through thematic analysis. There are five underlying themes found across two sets of scrum challenges (constraints of physicality and the 13 principles). These five themes include flexibility, chunkability, scalability, endurability and teamability. These five themes further are found related to the defining principles of the agile manifesto (Peterson and Summers, 2021).

Heimicke et al. identified 25 hybrid development approaches that are the result of a combination of agile and plan-driven development which all are still in their early stages. The addition of agile elements can have a significant favorable influence on the development process in terms of customer, value, productivity and internal processes. So, the similarity of these hybrid methods is to use incremental and iterative to change the rigidity of traditional development. In summary, most of the reports are optimistic through the mixture of agile and traditional development. They believe that the incorporation of the two must be able to blend their respective advantages (Heimicke et al., 2020).

An industrial project yields that a physical prototype is indispensable for testing and validating the functionality of complex physical products. The difference to software development is that after the development of a prototype in a virtual environment, physical products still require a certain amount of time and cost to build physical prototypes. The scrum team must identify which parts of the product can be further developed during the production of the physical prototype, otherwise, time is lost while waiting for the prototype. A special feature is that it is necessary to properly prepare and plan the entire production long before the final prototype is available (Zorko et al., 2021).

Product generation engineering is understood as the development of products based on reference products. Subsystems are either adapted to the new product generation by means of carryover or they are newly developed based on shape variation or principle variation. Continuous validation is considered as the central activity in the product engineering process and is a major challenge, especially for complex mechatronic systems. By using a new validation approach, product engineering was transformed into agile framework and significant progress beyond the V-model was achieved (Albers et al., 2017).

In long-lasting defense programs, which are structured by using systems engineering, the design flexibility facilitates the ability to rapidly adapt to operational and technical changes (Subowo, 2015). An agile systems engineering approach moves away from a traditional development timeline (design to deployment) of about 7.5 years, and capitalizes on opportunities to expedite the delivery of operational capabilities that have been tested, integrated, and are of value to the end user (Meißner et al., 2021). Both agile frameworks attempt to minimize risk through the continuous delivery of incremental value to the user community, where the system addresses a set of critical operational needs based on the user’s prioritization input within a fixed timeframe and a budget-constrained environment (Hermann et al., 2020).

Nevertheless, the introduction of agile methods in product development opens or multiplies a handful of other challenges like conflicts by change (Shameem et al., 2019), design trade-offs (Bricogne et al., 2014), visualization of the interdependencies (Fukuda et al., 2013) and work progress (Pfouga and Stjepandić, 2018), or modular design (Raudberget et al., 2019; Ostrosi et al., 2014) which need to be properly tackled. Therefore, agile transformation has a paramount impact on product development (Bondar et al., 2017).

Future research will examine whether the proposed approach provides sufficient documentation of ECs, when adding and removing requirements to and from the product backlog (Becerril et al., 2017). This is especially relevant for companies such as automotive suppliers or medical device manufacturers, that are required to comply with norms for documenting their ECs (e.g. DIN 199-4). Moreover, the workflow should be further evaluated by implementing it in a broader selection of startups that use agile project management methodologies (Han et al., 2015).

There are further studies on agile product development. However, no method is known at this time which handles ECM as a specific process in the agile process. The CAx toolchain must also be adapted accordingly (Enkler and Sporleder, 2019). Through the early use of simulation software, a simulation-driven development process is targeted, wherein designers and engineers create a basis for joint developments and thus a basis for discussion, suggestions and new ideas. Adjacent methods and applications can be integrated in such an approach (Wilms et al., 2019).

Key developments are summarized in Table 1.

3. DIONE: An Agile Approach to PLM for Agile ECM

The proposed agile approach to PLM for Agile ECM, named DIONE ( DIscovery, Opportu Nity, Exploit) aims to effectively manage EC processes (Fig. 2). By doing so, it can act as a catalyst for ongoing product improvement and raise an enterprise’s innovative performance. This approach recognizes that emergent or undiscovered changes may pose a risk, but it also acknowledges that these changes may present opportunities to be exploited, depending on the risk appetite of the development project. The goal is to make emerging changes a regular occurrence in order to enhance performance, while effectively managing any associated risks.

Discovery considers SIPOC (Suppliers, Inputs, Processes, Outputs and Customers), impact analysis of the affected objects (Shameem et al., 2019), root cause analysis (Peterson and Summers, 2021), cost, risks (Ward and Chapman, 2003), timeline and complexity (Wynn et al., 2014). In this way, more flexibility is given to handle changes instantly (Hamraz et al., 2015).

Opportunity can be determined by assessment of handling options, dealing with uncertainty (Reid et al., 2019), preparation of the course of action (Hamraz et al., 2013), and involvement of suppliers (Shivankar and Deivanathan, 2019), processes and customers (Reddi and Moon, 2013) with the objective of a go/no-go decision (Reid et al., 2019). During the opportunity phase, the definitions of “done” and “effective” are established.

Exploit refers to a phase where work is created and controlled iteratively. We distinguish here four main types of activities as follows:

Change propagation analysis may also be looked into more as a strategy to facilitate “Design for X” and should be done in a systematic manner. For instance, when modifying a design to incorporate new environmental or lifespan issues, change propagation would be of concern. The change could have an impact on downstream phases of the lifecycle such as manufacturability, the ability to sell and recycle, among others. A closely connected opportunity must thoroughly investigate how change propagation analysis — by analyzing the necessary design changes and other changes — might help the adoption of new manufacturing technologies (Brahma and Wynn, 2013). Therefore, the process of Impact Analysis (IA) is a crucial process to understand the consequences and implications that a proposed change can have on the product overall, systems, processes and stakeholders. The IA should include a thorough risk analysis of the proposed change and consequences logged into main, rest and secondary risks and controls.

The course of an EC in the waterfall and agile process differs significantly in the amount of time needed per cycle although similar tasks are done in both versions of the process. In the case of the waterfall process (Fig. 3), risks are found and controls are defined in the Discovery phase. When risks appear or are triggered in the exploit phase, there is little room for reaction. This can lead to shadow processes (“change to change”) or workarounds to mitigate the long time between risk identification and control actions. Usually, these are done in haste and are poorly documented.

The mechanics and thought process of the discovery (IA) and opportunity are not transparent for the exploit phase while they are usually done outside of the change request/change note/change order processes.

Due to the long time between risk identification and control actions, deviations need to be created that will result in unwanted, propagated, emergent changes, which must be handled in an additional change request (Bhuiyan et al., 2006). These emergent changes pose a challenge to the overall control of scope, costs, timeline and requirements. In terms of governance, these emergent changes need to run again through an IA and an approval phase.

The concept still relies on the identification of [A]ffected objects that in logical order shall be frozen, declared a [R]esulting object for release. For example, if a design item was composed of a specification, design (CAD and derived drawing) and a verification matrix, the concept would allow for parallel work on the design and building the verification matrix while the specification is being released. A released specification will then give the bases for finishing the design. While design elements are frozen, they can be concurrently verified. Once the design is frozen, the verification can be processed until the conclusion. Only when all elements of the item are released will the item be released. Any reaction to emergent problems can be absorbed in the processes, giving the flexibility to recognize that a design item is composed of freeze design for validation, verification, or concurrent design.

According to the progress, some planned tasks may become obsolete as the work is developed — these tasks can be set to be trashed. At the same time, due to emergent work, some tasks could be moved to the next sprint or iteration. This is done with the revision of the Engineering Change Notes (ECN) that carries over the incomplete tasks. The actions are collected in the corresponding change notes.

In order to mitigate the risks and overcome the challenges posed by the waterfall ways of working, some extensions need to be done to the concept. Mainly, in order to maintain transparency of issues that may lead to changes and which issues will be implemented, all of the related tasks from end-to-end change process will be tracked in the ECN. This creates a new dimension in which the change management tasks can evolve. Not only will the [A]ffected objects eventually turn into [R]esulting objects in terms of the release evolution, [A]ffected objects will be first analyzed in the discovery phase, and options will be evaluated in the opportunity phase, and then processed in the exploit phase.

Given that scrum teams have limited, known capacity per sprint or iteration, it is to be expected that the first revision of the CN contains mainly discovery phase tasks. As systems develop at different speeds, those that are ready can quickly move into the opportunity and exploit phase. With each sprint or iteration planning the backlog can be re-prioritized and the reflected tasks in the change processes shall be re-prioritized too (Fig. 4). As a result of each prioritization and new planning, a new risk assessment of the change and its consequences can be done.

The project will do its best to forecast the changes needed to deliver the product and its scope. These planned (or initiated) changes are accounted for in terms of costs, resources and timeline. Projects must account massively for emergent changes and constantly changing conditions, from severe design flaws to project and/or regulatory changes and market updates. A well-planned project will have plans and contingencies for these events. Nevertheless, this places the team in a constant reactive mode.

Reacting to emergent changes, especially those that need to be dealt with quickly will always pose a risk to the project when, if analyzed properly, they can be seen as an opportunity. Also, changes in technology shall be considered for adoption if they can be translated into a better product. Waterfall projects will tend to not consider these new technologies because of the locked scope and timeline of the project and to minimize the risk of product quality. In order to embrace this potential opportunity, a request is required to directly specify an opportunity or be detectable implicitly in order to be included in the analysis and reported as an opportunity (discovered and exploited). The identified opportunity can be exploited only if the request is accepted. Both discovery and exploitation must be identified in the data for emergent changes. The related documentation and follow-up communication must be given for additional inquiry and multiple data point validation if the evaluated change requests had unclear or insufficient input.

4. Implementation of DIONE Approach in PLM

This research follows the concept elaborated in the work presented by Riascos et al. (2020). Our solution continuously maintains the relationship between the current product configuration and the singular stages of the EC process and the corresponding objects: the Engineering Change Request (ECR), the Engineering Change Order (ECO) and ECN. ECM should become an integrated, value-adding constituent of the product development process, enabling agility without becoming an impediment to innovation. It is important to create an own solution based on the toolkit’s fundamental capabilities because the standard PLM system neither includes a function nor a module to support the necessary ECN flexibility. This proprietary solution comprises the following characteristics:

• The integral model that covers both software and non-software development,

• Reflects (with transparency) the priorities of the product backlog and the work associated with sprints, iterations and increments in the change activities,

• The distinction between the accomplished, postponed or discarded change activities,

• Interfacing with project, risk and cost management and release planning,

• Support: Change Faster & Document Better (CF&DB) approach,

• Support of early product release in the form of Minimal Viable Products (MVP).

These features should be included in a dedicated ECM module within the proprietary PDM system in order to support the change managers and decision-makers using items or nodes in the product structure (entire product, sub-assemblies, components, or specific variants). This module can be made accessible to all authorized users in a worldwide development network by being embedded into the PDM workflow (Mathiasen and Mathiasen, 2017). Figure 2 illustrates the core ECM feature integrated into the Scrum methodology (Riascos et al., 2020). This framework creates the bridge between the Agile rituals and methodology with ECM and its basic PDM capabilities (Fig. 5). A basis for this concept is to respect the product backlog as the driver of scope, effort, estimated time, priority, etc. The team will aim to reach a product increment (which itself is associated with a specific added value to the product). The tasks needed to accomplish the increment are then associated with frequent fixed time periods of work. These could be sprints or iterations depending on the scalability of the project. Singular tasks are assigned to iterations or sprints, which can be reordered according to the actual needs as the backlog can be reprioritized after each sprint or iteration. For each sprint, the team defines the activities to be done, the affected product objects which will be impacted, and the resulting objects which will be subject of release. Such a release is the next step in this concept and can be compared with a design approval in the traditional workflow.

It is important to note the change activities are not a mere clone of the backlog tasks but a reflection of the change-relevant activities that need to be done to burn down the tasks in the backlog. Ultimately, change management must fulfill the requirements to ensure the proper documentation of change activities for traceability and regulatory purposes and not supersede the project or program management.

If the authoring systems (MCAD, ECAD, etc.) are tightly coupled with PDM systems, the ECM is included in PDM as a basic sequential workflow that includes all authoring and administrative steps in the model-based process (Stark, 2019). However, such a setup can manage only the result of the agile change process as a “black box”, but not the process as such. To overcome this obstacle, the concept of ECN as an updatable PDM object was proposed (Riascos et al., 2020).

In this concept, a Change Request (CR) is an umbrella for all subsequent sub-processes and can be split into more sub-requests. The backlog is subdivided into multiple iterations which consist of 2–3 sprints each (although iteration and sprint can be used interchangeably, in this case, we assume an iteration is tied to the increment and to reach the goal a certain amount of sprints happen within the iteration). The sprint is then associated with an ECN, which contains the necessary change-relevant activities to reach the sprint and iteration goals. This structure goes hand in hand with the agile process, documenting in increments and releasing according to the backlog plan. It allows the development to roll back changes in a documented manner, and the generation of baselines as well.

An important requirement is to support the flexible nature of the agile process. It is necessary to define rules on how to deal with change activities that, during the sprint, could not be done or were deemed unnecessary. This also applies to repeating change activities that may be performed in several sprints. For this, the capability of the PDM system to revise ECNs is leveraged as shown in Fig. 6. This requirement can be fulfilled by a change note object for each product item that is being maintained during its lifecycle. This approach delivers flexibility in the creation and implementation of a plan as experienced in the agile process without losing traceability and transparency which are provided by the PDM system. The figure also shows how from sprint-to-sprint objects that are recognized as affected or impacted will be released in an incremental way to reach the final product or increment.

5. Examining Changes in Implementation Practices: Key Findings

Based on the rationale above, we can classify the reasons to start a change as seen in Fig. 7. Four kinds of generalized changes were identified:

Both the waterfall and agile methodologies deal very differently with the changes described above. In general, we can foresee that:

Development projects will tend to be more proactive than reactive, as proactivity will mean better visibility and predictability (Fig. 8). With regard to proactivity, the agile process in ECM is proactive for fields 1, 2, 4 and reactive only in discovering of opportunity which can happen synchronously (3) but will not be completely discarded. This inherent frontloading poses an advantage in comparison with the traditional waterfall process where only planned changes will be dealt with in a proactive manner.

6. Discussion

One of the main contributions of this paper lies in introducing the DIONE approach, which offers an agile strategy for managing changes throughout the product lifecycle. Specifically, it provides a framework to support flexible ECM practices that can be adopted by manufacturing companies using the common artifacts of the change management process such as the ECR, change order and change notices. The DIONE approach aims to manage engineering change processes, and act as a catalyst for ongoing product improvement, without compromising the enterprise’s innovative performance. To implement the DIONE approach, it is necessary to understand the limitations of traditional waterfall ways of working and embrace the potential for emergent changes to disrupt timelines, lead to unwanted changes and affect costs and requirements. The findings of the paper suggest that adequate anticipation, detection, analysis, follow-up and execution of engineering changes are essential prerequisites for achieving project success in product development. The paper proposes that new ways of processing changes with traditional change management artifacts need to be implemented to manage a pipeline of change needs that can affect past, current and future development, such as tracking all related tasks from end-to-end change processes in the ECN.

The paper builds on previous research from the same authors where we proposed a method to reflect agile artifacts such as user stories, sprints and backlogs in PLM systems to support the agile development of physical products. This research used the practice of differentiating between objects affected by a change and objects resulting from a change, creating a release cascade where product development was delivered in an incremental but controlled manner. The proposed method also took into account the uncertainty embraced in agile methods and built contingencies to deal with it. Nevertheless, the research was limited to one initiated change. In this paper, we use that methodology as a core for the DIONE approach but wrap it in a framework that allows for managing both initiated and emergent changes throughout the entire product development. Furthermore, it embraces the fact that several changes are running in parallel with different levels of maturity and these changes may be related to each other in positive and conflicting ways. Therefore, the emphasis on having a structured and transparent IA of each change is crucial to mitigate the risks of unexpected consequences and assure project success.

The implications of this paper are that implementing an agile approach to ECM through the DIONE approach could be beneficial for product development projects in the manufacturing industry where agile is being adopted, creating a bridge between the agile methods and artifacts and those of change management in a PLM environment. It intends to attack common pain points in these kinds of projects such as the risk of a lack of transparency in the discovery and opportunity phases and the potential for emergent changes to disrupt timelines, lead to unwanted changes, and affect costs and requirements, which are a result of maintaining waterfall practices in agile projects. There is an inherent need for a careful introduction of agile methods in organizations.

The adoption of agile change management in existing PLM systems and processes presents several challenges for organizations, encompassing both process-related and human acceptance factors.

Organizations often face the challenge of shifting from traditional, linear change management methodologies and tools to a more iterative and flexible approach. This requires rethinking and restructuring existing processes to accommodate shorter change cycles, continuous feedback loops and adaptable decision-making. Product development teams must overcome the hurdle of cultural change and human rejection. Agile change management boosts creativity and implies a mindset and cultural shift, where collaboration, transparency and empowerment among employees are needed. This can encounter resistance from individuals accustomed to hierarchical structures and well-defined roles. Another challenge is aligning stakeholders and managing expectations. Agile change management encourages frequent iterations and incremental progress, which may conflict with traditional expectations of large, fully formed deliverables and following carefully traced plans.

7. Conclusion

This research examines the significance of adopting an Agile methodology for ECM in dealing with complex change requests during the product development process. It is critical that ECM effectively addresses industry standards, including meeting time, cost, quality and transparency requirements for managing complicated projects. Successful project outcomes are dependent on the proper handling of engineering changes such as timely anticipation, identification, resolution and tracking. This study emphasizes the importance of incorporating an Agile approach to ensure effective management of these crucial prerequisites for the successful completion of complex projects within specified parameters.

The DIONE approach is an agile approach to PLM for agile ECM. It aims to effectively manage engineering change processes and act as a catalyst for ongoing product improvement and raising an enterprise’s innovative performance. DIONE comprises three stages: Discovery, Opportunity and Exploit, and it recognizes that emergent or undiscovered changes may pose a risk, but it also acknowledges that these changes may present opportunities to be exploited. The goal is to make emerging changes a regular occurrence to enhance performance while effectively managing associated risks. The discovery stage considers various factors such as IA, root cause analysis, cost, risks, timeline and complexity of the affected objects. The opportunity stage can be determined by assessing handling options, preparation of the course of action, and involvement of SMEs, suppliers, processes and customers. In this stage, a change shall be described and assessed in enough detail to be able to determine if it will be pursued or not. Finally, the exploit stage involves transparent communication and documentation of the related tasks to create, maintain, update, release or retire the affected objects. These tasks are tracked in the ECN to maintain transparency of issues that may lead to changes and which issues will be implemented. The approach creates a bridge between agile methodologies and artifacts with common ECM practices for PLM, making it quickly adoptable and adaptable for companies seeking to build agility in their ECM processes.

The study revealed that the integration of agile ECM with PLM techniques and tools is feasible and applicable in real-world scenarios. It highlights the significance of undertaking change analysis and assessment to comprehend potential outcomes and repercussions stemming from suggested modifications. These evaluations can be executed through an Agile framework, which also accommodates changes during operation, establishing a continuous stream of alterations with ongoing assessments throughout execution cycles while being conscious of market, supplier and customer dependencies as well as current product complexities.

The paper discusses the need for a controlled and careful introduction of agile methodologies in manufacturing enterprises that traditionally have strong waterfall practices. The challenges companies may face in terms of system usage, processes and cultural barriers need to be addressed while adopting an agile approach in ECM. It also discusses the risks of maintaining some waterfall practices, especially in the way IA and decision making is done.

This suggests that further research is needed in the automation of the IA, the acquisition and capturing of engineering knowledge, and designing the change management process in a way that it is held to the same agile principles as the product aims to deliver, it shall be flexible enough to learn, heal and improve itself to increase the value provided to the project.

In conclusion, the adoption of agile methodologies in the manufacturing industry, specifically for medical devices, presents a significant opportunity for enhanced efficiency, flexibility and responsiveness to the market. The manufacturing industry stands to benefit from delivering quicker and iteratively valuable products with the adoption of agile methodologies. Moreover, embracing agility fosters a culture of innovation, empowers employees and promotes cross-functional collaboration. However, successful adoption requires further research about how the industry can gradually adopt these methodologies without the need to completely reinvent themselves in the process, repurposing the tools at hand that have proven efficient. The potential rewards, including improved competitiveness, enhanced product quality and the ability to quickly respond to changing customer needs, make the adoption of agile methodologies a worthwhile pursuit.

ORCID

Roberto Riascos  https://orcid.org/0000-0001-7964-069X

Egon Ostrosi  https://orcid.org/0000-0002-5036-4676

Josip Stjepandić  https://orcid.org/0000-0003-0877-3799

Jean-Claude Sagot  https://orcid.org/0000-0002-8969-6096