Content uploaded by Josip Stjepandic
Author content
All content in this area was uploaded by Josip Stjepandic on Sep 30, 2020
Content may be subject to copyright.
An Approach for Agile Engineering
Change Management Within Global
Product Development
Roberto RIASCOSa1, Egon OSTROSIb, Jean-Claude SAGOTb and Josip
STJEPANDIĆc
aRoche Diabetes Care GmbH, Germany
b ERCOS/ELLIADD EA4661, Univ. Bourgogne Franche-Comté, UTBM, F-90010
Belfort, France
cPROSTEP AG, Germany
Abstract. Engineering Change Management (ECM) is an essential constituent of
any product development project, these project are highly dynamic process of
knowledge generation and reuse for products, projects, processes and resources
within a enterprise. Currently, ECM is fully document-, and at least partially paper-
based, and needs to be transformed to a fully model-based standard workflow.
Changes, uncertainty and hidden processes should be seen as regular events. For the
agile process, a rapid and flexible handling of task items is necessary. Due to the
unpredictable character and short time of singular task items, we have developed a
new approach to collect all changes to a superordinate, master change note as a
standard, common object in the product structure, and to and update this master
change note as often as necessary. This change note is assigned to a product during
its entire lifecycle. It collects changes in the product and related processes and
equipment. We present a new approach in order to facilitate a full object-oriented
support of all activities related to the change process. On each update, singular task
items can be re-prioritized within this master change note according to the current
needs.
Keywords. Engineering Change Management, Agile Process, Global Product
Development, Product Lifecycle Management
Introduction
The design process rarely starts from scratch, but rather by customization or modification
of existing products during multiple optimization loops. An Engineering Change (EC) is
an alteration made to parts, drawings or software, and it comprises any modification to
the form, fit and/or function of the product as a whole or in part. Engineering Change
Management (ECM) is an essential constituent of any product development project
which is a dynamic process of knowledge generation and reuse for products, projects,
processes and resources within a enterprise [1]. The increasing complexity of products,
shortening of time-to-market, and growing dependencies on suppliers increase the
number and complexity of change requests in all phases of product development. Today,
developments project in the industry need a strong support of the EC process to meet
1 Corresponding Author, Mail: roberto.riascos@roche.com.
Transdisciplinary Engineering for Complex Socio-technical Systems – Real-life Applications
J. Pokojski et al. (Eds.)
© 2020 The authors and IOS Press.
This article is published online with Open Access by IOS Press and distributed under the terms
of the Creative Commons Attribution Non-Commercial License 4.0 (CC BY-NC 4.0).
doi:10.3233/ATDE200119
584
the goals in terms of time, costs and quality. Appropriate anticipation, detection, follow-
up, and resolution of engineering changes is paramount to project success [2].
The complexity of ECM is substantially impacted by two factors. At the one hand,
global product development multiplies the count of interdependencies in the design
process. On the other hand, coping with the recent trends in business and society, agile
approaches have penetrated in almost all engineering and management disciplines in
recent years.
Globalization of product development not only offers great opportunities in terms of
flexibility and cost savings, but also creates new challenges due to the diversity of
requirements in different contexts (such as countries, organisations and situations), and
in particular regarding regulatory requirements (e.g. in the medical devices industry).
Some obvious reasons for requirements diversity for a given product in different contexts
are historical, cultural, natural, and economical [3].
Agility as a basic process capability is increasingly important because changes occur
in our world continuously and uncontrollably, and the direction of the development of
the business environment (i.e. trends, politics, customer, and project partner) is
unpredictable. To cope with the connected challenges in the area of product development,
companies try to transfer and integrate agile development methods from software
product development to the mechatronic product development domain [4].
The remainder of this paper is structured as follows: Section 1 provides an insight
into literature review, followed by section 2 where the need for action is presented. Our
new concept is described in section 3. We discuss the advantages and drawbacks of our
conceptual solution in section 4, followed by conslusions and outlook in section 5.
1. Literature review
Clarkson et al. have provided an overview of EC. They describe the nature of the
engineering change as a basic engineering process, which combines 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 [5].
Classification of EC according to different criteria (cause, initiator, impact etc) is
presented. Several stand-alone tools to support both workflow and decision-making in
ECM have been described. In addition, the authors discuss how EC is connected to the
makeup of the product in terms of architecture, complexity and degree of innovation.
Finally, they outlined management strategies to deal with the issue of engineering change.
Knowledge management (KM) in the engineering change (EC) management process
is crucial for any manufacturing enterprise [6]. Systematically gathered, analysed, and
interpreted professional experiences can prevent technical problems, unnecessary costs,
and unnecessary delays. Successful implementation of KM requires a holistic and
transdisciplinary approach. The main contribution of the paper is the five-step KM model
that is integrated into the EC process. Failure modes and effects analysis (FMEA) and
design history files are the documents used to manage the knowledge related to a specific
product. A product’s design history file should contain explanations of decisions.
Supporting activity for applying KM includes a campaign to raise awareness, and the
transfer of tacit knowledge should be emphasized. This can be stimulated by mixed
teams of senior and junior engineers. The content of the acquired knowledge should be
checked periodically, and the analysis should be followed by corrective measures.
R. Riascos et al. / An Approach for Agile Engineering Change Management 585
As the US Federal Aviation Administration (FAA) modernises its legacy air traffic
systems by 2025, traditional systems engineering practices need to be transformed to
efficiently and effectively address tomorrow’s demands [7]. Agile practices in the
commercial and federal domains have proven that it is a valid method to deliver high
quality products in alignment with users’ needs. 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. An agile
design methodology is based on the idea of an agile development process, where design
flexibility facilitates the ability to rapidly adapt operational and technical changes. 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 user’s prioritization input within a fixed timeframe and a
budget-constrained environment [7].
With agile, the systems engineer, developers, and aviation community stakeholders,
including air traffic controllers, airline carriers, and technical standards committees, must
work efficiently within the available resources, including time and money. Agile focuses
on the high priority operational needs so that the design may evolve, and ensures that the
system’s objectives are aligned with the stakeholders’ needs and goals. An agile
approach enables the FAA’s systems engineers and software developers to continuously
refine the technical scope based on cost and schedule constraints and operational and
technical changes, and to define an implementation plan that drives the delivery of usable
features for NextGen systems to the aviation community [7].
Agility in product development can be enabled through an adaptive engineering
change management concept. Hence, the three categories are proposed as design
elements and are described hereinafter as layers: Adequate means of communication
form the front-end of the framework, processes and roles the intermediate layer, and a
suitable data structure 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. For
processes to be efficient, they have to be customised accordingly and a clear scope of
duties must be assigned to members of the organisation. In order to guarantee error-free
data management, geometric data have to be digitalised and application systems must
share common data structures [8].
Scrum's agile techniques were also examined for use in the engineering of machinery
and plant construction, since the entire Scrum process does not always have to be
established in 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 shows 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 [9].
A survey shows that the participants from industry have a high demand to make their
development processes more agile [10]. 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. An overview of agile methods and selection process would be particularly
R. Riascos et al. / An Approach for Agile Engineering Change Management586
helpful [10]. Implementing agile development would address certain challenges, such as
the overhead of managing requirements changes, currently impacting non-agile
develoment. 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 the agile development is very important.
The suggested implementation methods (method overview, selection method,
adaption method, planning method) and a guideline are perceived as being helpful.
However, their application has to be supported by coaches or persons who have
experience with agile development. In contrast to the standard Scrum procedure for
managing changes, our 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 Engineering Changes within an Agile Framework provides
decision support for evaluating the change request’s implications on the ongoing sprint.
This is illustrated in the presented case study [10].
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 remains low [11].
Product generation engineering is understood as the development of products based
on reference products (precursor or competitor 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 to agile and a significant progress beyond the V-model was
achieved [12].
Nevertheless, the introduction of agile methods in product development opens or
multiplies a handfull of other callenges like work coordination [13], conflicts by change
[14], design trade-offs [15], visualization of work progress [16], modular design [17],
supplier integration or intellectual property protection [18] which need to be properly
tackled. Therefore, the agile transformation has a paramount impact to product
devlopment.
Future research will examine whether the proposed approach provides sufficient
documentation of engineering changes, when adding and removing requirements to and
from the product backlog [11]. This is especially relevant for companies such as
automotive suppliers or medical device manufacturers, that are required to comply with
norms for documenting their engineering changes (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.
There are further studies on agile product development. However, no method is
known at this time which handle ECM as a specific process in the agile process. The
CAx tool chain also must be adapted accordingly [19]. 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 [20].
R. Riascos et al. / An Approach for Agile Engineering Change Management 587
2. Need for action
In comparison with other business processes, e.g. sales, purchase or finance, managing
engineering processes is even more challenging because engineering changes can be
long-running tasks. During this time period many things may change – what has begun
as a modern, adequate requirements with correct means, can become obsolete because it
includes evolved requirements when reaching the planned deadline. Based on their mix-
ture of creative tasks, collaborative work and repeating activities, engineering processes
need to handle a high level of inherent uncertainty. This results in very complex pro-
cesses with many alternative paths and sections that cannot be planned in advance [21].
Business process modeling (BPM) systems have been developed based on a mind
model as process chains or task chains. Changes, uncertainty, and hidden processes are
seen as exceptions instead as regular events. Adequate support for engineering processes
in terms of modeling and execution obviously requires a completely new approach for
process management that is able to deal with the requirements for flexibility,
transparency, and efficiency, both in design and execution of the process [21].
A modelling approach to enable agile processes has to support the design of huge,
complex processes, by using modularity but also allowing for an overall picture of the
process, decrease the effort for changing and maintaining the process model, and allow
agility and flexibility not only in process modelling but also in process execution through
software systems. A goal- and context-oriented business process modelling provides a
solution using:
x A modular process model that describes the single steps of a process (sub-
processes, activities) separate from the goals of the process and the different
contexts in which the process can be executed;
x different modelling levels, for the different parts of the process model; and
x a seamless “translation” of the process model into process execution.
This modular, goal- and context-based process model can then be directly executed
as an agile process, by considering current goal and context when determining the next
step in the process. In our case, as a medical device manufacturer is moving into an agile
development not only for software products, it is necessary to be able to support agile
projects without compromising the compliance requirements and documentation. In the
past, Change Management project have delivered lessons learned that the Change
Management process needs to be examined and made with the following goals:
x Using the current CM system adhering to the standards
x Supports agile product and process development and improvements
x Support flexibility in scope and timing of change activities
x Leverage baselines, Change Note (CN) revision and CN reuse
x Use the current organizational structure and competences
x Incorporate recommendations and industry best practices
Such a complex process must be implemented by using a modern PDM system.
While ECM is a standard process, the implementation of the agile ECM should be
provided by using adequate PDM objects [22]. The central function in this chain should
take the Engineering Change Note (ECN). The change loops should be decomposed
according to the agile process e.g. Scrum. The adopted process could drastically reduce
or remove the need for so called emergent changes (which need to be done within a day).
R. Riascos et al. / An Approach for Agile Engineering Change Management588
3. Solution concept
Following to the overall concept of PLM [23], the demand is given last but not least by
regulatory rules. For our purpose, a solution which continuously maintains the
relationship between the current product configuration, and the different phases of the
EC process, (the engineering change request (ECR), the engineering change order (ECO)
and ECN) is necessary. A specific PLM object within ECM should make ECM an
integrated, value-adding component of product development. Complete product with all
variants and instances lies in focus - with no gap in the timeline between the first idea
and disposal. A market study has discovered that no PLM system has a straightforward
solution to support the needed ECN flexiblity, neverheless PLM systems posses the
potential to be configured to support it. Therefore, a proprietary solution based on a
standard tool set must be drawn and implemented. It includes the following
characteristics:
x Document (with transparency) product changes
x One model that fits software and non-software development
x Better monitoring of change activities
x Interfacing with project and cost management
x Support : Change Faster & Document Better (CF&DB) approach
An ECM based tool must be available for change coordinators at the desired time
and provide functionality for the entire product as well as each extent of the product
structure (e.g. specific variant). By embedding this workflow into PDM system, it will
be avaiable for all users in a global development network [24].
Figure 1. Engineering Change Management in Scrum.
While the authoring systems (MCAD, ECAD etc) are tightly coupled with PDM
systems, the Engineering Change Management (ECM) is included into PDM as a basic
workflow which includes all authoring and administrative steps [25]. Figure 1 shows the
main constituents of ECM in Scrum. First of all, the product backlog is the driver based
on scope, effort, estimated time, priority, etc. Singular tasks are assigned to sprints and
iterations which can be reordered according to the actual needs. For each sprint or
iteration must be defined what will be changed and why, the affected product objects
R. Riascos et al. / An Approach for Agile Engineering Change Management 589
which will be affected during one or more interations and resulting object which will be
subject of release.
In our case, we consider a simple assembly consisting of two half-balls which cover
a ball inside as depicted in Figure 2. The considered change should be made by changing
the ball radius. For that, the specification must be changed accordingly (affected object).
At the product level, three parts must be changed (resulting objects) which must be
finally released. By new ECM workflow, the PDM system provides the ECN object
referenced to all impacted object (part, assemblies, processes, resources etc). This object
is the central information carrier for all changes and is the subject of continuous release.
Figure 2. Affected vs. impacted objects.
The content of changes stays in the product backlog. Some objects will be updated
some will be released according to the backlog.
The impact analysis phase is important for any change, as this determines the scope
and, subsequently, the efforts and costs. It helps to understand the whole impact of a
change and trigger activities related to the change (Figure 3).
Figure 3. Impact analysis.
R. Riascos et al. / An Approach for Agile Engineering Change Management590
In our case, due to the extension of the radius, the production process must be
adapted by adding stiffener to the half-ball used to manufacture the half-spheres. That
imapcts the change of the production process and the related resources (equipment, jigs,
additional materials).
The engineering change documentation process is depicted in Figure 4. Usually,
engineers use decompositions to describe a product or process. In our case, a change
request (CR) is an umbrella for all subsequent sub-processes and can be subdivided in
more requests. The backlog is subdivided into iterations. Each iteration consists of 2-3
sprints. The implementation is stored in change notes (CN). 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.
Figure 4. The engineering change documentation process.
Figure 5 shows the structure of the revision of change notes. While the singular
action items can frequently move from a note to the another, it is necessary to define the
rules and the process of update. We propose to build one change note object for each
product item and maintain it during its lifecycle. This approach delivers flexibility in the
creation and implementation of plan without losing traceability and transparency.
Figure 5. Revising change notices.
R. Riascos et al. / An Approach for Agile Engineering Change Management 591
4. Discussion
The implementation and introduction of basic processes and workflows is challenging
each company [14]. While the company is at the forefront of deploying practical
applications of the PDM system PTC Windchill for a range of requirements, it is
necessary to reconsider the existing workflows like ECM to fulfill the process
requirements for the agile transformation [25]. Such workflows which affects the entire
company bring the risk of failure or partial success with huge consequences. In our case,
the primary risks are increasing complexity by additional processes/methods/tools,
insufficient commitment of people and culture, and, finally, delayed replication of a
globally working organization to every local situation. These challenges need to be
tackled by a proper project organisation.
5. Conclusions and outlook
Agile engineering change management embedded into PLM is a pre-requisite in order to
realise efficiency gains and not add additional cost within global product development.
[26]. Current PLM systems ,which are built to support linear change management can be
adapted to support agile product development. The artifacts of the EC process in PLM,
namely the ECR and ECN can be used to match product backlogs including priorities
and assignment to increments. To support this a two-tiered level of release has to be
enabled in the PLM system to allow design obejcts to be finally released or flexibiliy
incrementally approved until a final realease is reached.
In daily management, it is natural to define and decompose goals, define, reuse or
refine plans, and continuously monitor and check the execution of chosen plans in order
to detect problems as they occur, and to take appropriate actions. On the other hand,
preferred IT approaches currently concentrate almost exhaustively on workflows based
on procedures. The increase in process management automation that occurred with BPM
systems has also shifted the focus away from goals and plans and toward procedures.
With this innovative approach, we have overcome the limiting consequence that
processes have become more efficient in execution but less flexible in adaptation [27].
The desired result is given by achievement conditions to adapt the EC process to react to
the variacnes implicit to the Agile methodology maintaining the needed documentation
and transparency for both the enterprise and regulatory bodies. The possible ways to
obtain a result are set by process graphs extended with the conditions where they are
applicable and the results they obtain when successful.
References
[1] P. Sjögren, Towards a Learning Process for Ad hoc Engineering Change Teams, PhD thesis, Mälardalen
University, 2018.
[2] P. Sjögren, B. Fagerström, M. Kurdve and T. Lechler, Opportunity discovery in initiated and emergent
change requests, Design Science Journal, 2019, Vol. 5, e5, DOI: 10.1017/dsj.2019.4.
[3] M. Spichkova, H.W. Schmidt, M.R.I. Nekvi, N.H. Madhavji, Structuring Diverse Regulatory
Requirements for Global Product Development, IEEE Eighth International Workshop on Requirements
Engineering and Law, RELAW 2015, 7330212, 2015, pp. 57-60.
[4] K. Goevert, M. Brombeiss and U. Lindemann, Integration of Mechatronic Product Development Methods
in an Agile Development Area, in: A. Chakrabarti (ed.) Research into Design for a Connected World,
Smart Innovation, Systems and Technologies, 135, pp.119-131.
R. Riascos et al. / An Approach for Agile Engineering Change Management592
[5] T.A.W. Jarratt, C.M. Eckert, N.H.M. Caldwell and P.J. Clarkson, Engineering change: an overview and
perspective on the literature, Research in Engineering Design, Vol. 22, 2011, pp. 103–124.
[6] J. Tavčar, J. Benedičič, R. Žavbi, Knowledge management support in the engineering change process in
small and medium-sized companies, International Journal of Agile Systems and Management, Vol. 12,
Issue 4, 2019, pp. 354-381.
[7] N. Subowo, Agile engineering for development of the next generation air transportation system,
International Journal of Agile Systems and Management, Vol. 8, 2015, No. 2, pp. 163–180.
[8] G. Schuh, T. Gartzen, S. Soucy-Bouchard, F. Basse, Enabling agility in product development through an
adaptive engineering change management, Procedia CIRP, Vol. 63, 2017, pp. 342 – 347.
[9] T.P. Klein, Agiles Engineering im Maschinen- und Anlagenbau, PhD thesis, TU München, 2016.
[10] K. Goevert, M. Lindner and U. Lindemann, Survey on agile methods and processes in physical product
development, In: I. Bitran et al. (eds.) ISPIM Innovation Forum: The Innovation Game: Base Hits, Not
Home Runs, 2018, pp. 1-13.
[11] L. Becerril, V. Heinrich, A. Böhmer, S. Schweigert, U. Lindemann U. (2017) Engineering Change
Management Within Agile Product Development—A Case Study. In: A. Chakrabarti, D. Chakrabarti
(eds.) Research into Design for Communities, Volume 1. ICoRD 2017. Smart Innovation, Systems and
Technologies, Vol. 65. Springer, Singapore, pp. 643-652.
[12] A. Albers, M. Behrendt, S. Klingler, N. Reiß and N. Bursac, Agile product engineering through
continuous validation in PGE – Product Generation Engineering, Design Science Journal, 2017, Vol. 3,
e5, DOI: 10.1017/dsj.2017.5.
[13] M. Borsato and M. Peruzzini, Collaborative Engineering, in: Stjepandić J. et al. (eds.): Concurrent
Engineering in the 21st Century: Foundations, Developments and Challenges , Springer International
Publishing Cham, 2015, pp. 165–196.
[14] M. Shameem, B. Chandra, C. Kumar, and A.A. Khan, Impact of requirements volatility and flexible
management on GSD project success: A study based on the dimensions of requirements volatility, Int. J.
Agile Systems and Management, Vol. 12, 2019, No. 3, pp.199–227.
[15] M. Bricogne, L. Rivest, N. Troussier and B. Eynard, Concurrent versioning principles for collaboration:
towards PLM for hardware and software data management, Int. J. Product Lifecycle Management, 2014,
Vol. 7, No. 1, pp.17–37.
[16] R. Riascos, J. Stjepandić, L. Levy and A. Fröhlich, Digital Mock-up, in: J. Stjepandić et al. (eds.):
Concurrent Engineering in the 21st Century: Foundations, Developments and Challenges, Springer
International Publishing Cham, 2015, pp. 355–388.
[17] E. Ostrosi, J. Stjepandić, S. Fukuda and M. Kurth, Modularity: New trends for product platform strategy
support in concurrent engineering, Advances in Transdisciplinary Engineering, 2014, Vol. 1, pp. 414-
423, DOI: 10.3233/978-1-61499-440-4-414.
[18] H. Liese, S. Rulhoff and J. Stjepandić, Modularity: Securing product know-how by embedding IP-
protection into the organisation, 2010 IEEE International Technology Management Conference, ICE
2010, 2010, 7477025, DOI: 10.1109/ICE.2010.7477025.
[19] H.-G. Enkler and L. Sporleder, Agile Product Development—coupling explorative and established CAx
methods in Early Stages of Virtual Product Development, Procedia CIRP, 2019, Vol. 84, pp. 848–853.
[20] T. Myklebust, J.-A. Eriksen, A. Hellandsvik and G.K. Hanssen, The Agile FMEA Approach, SCSC The
26th Safety-Critical Systems Symposium, 2018, https://scsc.uk/r140/21:1 , accessed Feb 13 2020.
[21] B. Burmeister, H.-P. Steiert, T. Bauer and H. Baumgärtel, Agile Processes Through Goal- and Context-
Oriented Business Process Modeling, BPM 2006: Business Process Management Workshops, Springer-
Verlag, Berlin-Heidelberg, 2006, pp 217-228.
[22] J. Stark, Product Lifecycle Management (Volume 2): The Devil is in the Details, 3rd edition, Springer
International Publishing AG, 2016, https://doi.org/10.1007/978-3-319-24436-5.
[23] L. Lämmer, M. Theiß, Product Lifecycle Management, in: J. Stjepandić et al. (eds.): Concurrent
Engineering in the 21st Century: Foundations, Developments and Challenges , Springer International
Publishing Cham, 2015, pp. 389–420.
[24] J.B. Mathiasen, R.M. Mathiasen, Practicing Transdisciplinary Engineering in a Global Development
Context: The Transferring, Translating and Transforming Approaches, Journal of Industrial Integration
and Management, Vol. 2, 2017, No. 4. 1750017, DOI: 10.1142/S2424862217500178.
[25] J. Stark, Product Lifecycle Management (Volume 4): The Case Studies, Springer Nature Switzerland AG,
2019, https://doi.org/10.1007/978-3-030-16134-7.
[26] N. Wognum, C. Bil, F. Elgh, M. Peruzzini, J. Stjepandić and W.J.C Verhagen, Transdisciplinary systems
engineering: implications, challenges and research agenda, International Journal of Agile Systems and
Management, Vol. 12, 2019, No. 1, pp. 58-89.
[27] Beckett R.C., Vachhrajani H., Transdisciplinary Innovation: Connecting Ideas from Professional and
User Networks, Journal of Industrial Integration and Management, Vol. 2, 2017, No. 4, 1750016, DOI:
10.1142/S2424862217500166.
R. Riascos et al. / An Approach for Agile Engineering Change Management 593
