The main theme of this ar ti cle is the collec ti on, prepara ti on, and improvement of user requirements. The research relies on a case study of a complex ERP project from an interna ti onal organisa ti on. We proceed from the fact that the development of an individual ERP solu ti on o ft en goes beyond just a single project. O ft en, the development of the ERP solu ti on con ti nues even a ft er the comple ti on of the individual project. In par ti cular, the ar ti cle addresses the user re ‐ quirements and their quality with regard to the requirements engineering process and change management. We dis ‐ cuss the characteris ti cs of adap ti ve (e.g., agile) and predic ti ve approaches, as well as how they a ffect the quality of user requirements. We emphasise that it is important for team members to be aware of the substan ti al impact that well ‐defined user requirements have on the success of the project. Although we argue that the number of change re ‐ quests should not be taken as an indicator of project success, we discuss the factors that influence the number of changes during the project and the addi ti onal work a ft er the project is completed. We iden ti fied two strategies that address the excessive number of requests for changes and addi ti onal work. The project team should give more a tt en ‐ ti on to the preparati on of high ‐quality requirements and, most of all, to enhancing their formalised tes ti ng and veri ‐ fica ti on processes. Managing changes, especially changes in user requirements, is challenging and cri ti cal to project success. Companies should constantly op ti mise requirements analysis based on lessons learned from previous projects and ensure that past lessons are applied company ‐wide in future projects. Keywords: Change Management, User Requirements, Requirements Analysis, Requirements Engineering, ERP Project Success, Enterprise System REQUIREMENTS CHANGE MANAGEMENT: A CASE STUDY OF AN ENTERPRISE SYSTEM IMPLEMENTATION PROJECT Laura Fink GEA College, Ljubljana, Slovenia laura.fink@gea ‐college.si Ajda Fošner GEA College, Ljubljana, Slovenia ajda.fosner@gea ‐college.si Andrej Dobrovoljc GEA College, Ljubljana, Slovenia andrej.dobrovoljc@gmail.com Tomaž Pozni č GEA College, Ljubljana, Slovenia tomaz.poznic1@gmail.com Dynamic Rela ti onships Management Journal, Vol. 13, No. 2, November 2024 71 Abstract Vol. 13, No. 2, 71 ‐89 doi:10.17708/DRMJ.2024.v13n02a05 Dynamic Rela ti onships Management Journal, Vol. 13, No. 2, November 2024 72 Laura Fink, Ajda Fošner, Andrej Dobrovoljc, Tomaž Pozni č: Requirements Change Management: A Case Study of an Enterprise System Implementa ti on Project 1 INTRODUCTION Agile methodologies have spread in so ft ware de ‐ velopment with the aim of improving the capabili ti es of so ft ware development teams since 2001. Agile methodologies, along with other adap ti ve method ‐ ologies (PMI, 2021), when compared to predic ti ve methodologies, are supposed to enable both quick responses to changes and new demands and ensure that the implemented system does not become rapidly outdated or fail to be implemented in reality (Gonzalez ‐Barahona et al., 2017). Agile stands for the readiness to embrace change throughout a project. In an agile se tti ng, not only requirements but also the end product, service, or what is considered accept ‐ able release may change (PMI, 2021; 2017). The predic ti ve approach, which is diametrically opposed to adap ti ve prac ti ces, obviously fueled the expansion of adap ti ve prac ti ces. The predic ti ve, also known as tradi ti onal, approach emphasises the im ‐ portance of thorough planning in early project phases, with nearly any changes in requirements and func ti onali ti es in later stages, while adap ti ve approaches, along with the agile approach, foresee changes in requirements throughout the project and rely on flexible plans and an almost immediate response to changes (IPMA, 2018; PMI, 2021, 2017). Successful projects, par ti cularly in so ft ware devel ‐ opment, have popularised agile approaches to the point where they are applied without much consid ‐ era ti on, even in projects that are less suitable for such approaches than so ft ware development pro ‐ jects. Therefore, it is vital to emphasize that the op ‐ ti mal approach needs to be selected with careful considera ti on of factors such as the characteris ti cs of the product, service, or result; the project; and the organiza ti on (PMI, 2021; Fink, 2017). Since it is rare to find a project that is perfectly suited for ei ‐ ther a fully predic ti ve or fully adap ti ve approach, many projects necessitate the applica ti on of hybrid approaches. Hybrid approaches provide the oppor ‐ tunity to apply the unique best ‐fi tti ng combina ti on (PMI, 2021; Wysocki, 2019) of predic ti ve and adap ‐ ti ve approaches to the project at hand. Businesses invest heavily in the renova ti on of business processes to adhere not only to increased ef ‐ ficiency but also to the quality of their procedures and final solu ti ons. The context of this research includes two fundamentally di fferent, or even opposing, busi ‐ ness cultures. The pharmaceu ti cal industry (Scherer, 2000), characterised by carefully planned long ‐term drug development, strict control, and rigorous regu ‐ latory requirements for the approval of products, dif ‐ fers substan ti ally from the so ft ware development industry (Tukel and Rom, 1998; Damian and Zowghi, 2003), awash with new technology, pressured by rapid development, short product life cycles, con ti nuous improvements, and constant updates. Fundamentally di fferent business environments (Iivari and Huisman, 2007) inevitably cons ti tute di fferences in opera ti ons, procedures, and working styles. The context men ti oned is the source of fresh views and perspec ti ves on the central theme of this research, which focuses on change management in developing enterprise systems and enterprise re ‐ source planning (ERP) implementa ti on projects. Ac ‐ cording to Copola Azenha et al. (2021, p. 90), the literature lacks prac ti cally oriented evidence that could enrich the discourse regarding hybrid project management approaches fi tt ed to “dis ti nct organisa ‐ ti onal cultures, specific processes, customer contrac ‐ tual requirements, and project specifici ti es.” Further, Theunissen et al. (2022) explain that minimal require ‐ ments’ documenta ti on, which might arise from im ‐ plemen ti ng agile methodology, does not always contribute to the success of so ft ware development. They suggest that the quan ti ty and quality of require ‐ ments’ documenta ti on should be increased. In our study, we are interested in what ac ti vi ti es could contribute to improving the processes of user requirements analysis and, in par ti cular, the user re ‐ quirements’ change management process in ERP ini ‐ ti a ti ves. The purpose of this study is to inves ti gate how changes in requirements a ffect project success, as well as to iden ti fy the appropriate design of busi ‐ ness processes and ac ti ons that facilitate rather than restrict the development of a so ft ware solu ti on in the best way possible. More concretely, we address not only the ques ti ons regarding the choice of pro ‐ ject methodology in the context of partnerships, which are based on fundamentally di fferent business cultures, but we also focus on the quality of user re ‐ quirements and ques ti on how constant modifica ‐ ti ons of user requirements compared to more fixed requirements influence the course of ac ti on. Finally, we also discuss the ever ‐present issue of factors that Dynamic Rela ti onships Management Journal, Vol. 13, No. 2, November 2024 73 influence the number of addi ti onal improvements required a ft er implementa ti on, especially in connec ‐ ti on with the precise defini ti on of user requirements at the beginning of implementa ti on. The challenge of achieving the best balance (Ramesh et al., 2010; Rasheed et al., 2021; Mockus et al., 2003) between thorough planning early on in the project and addi ti ons to ini ti al planning, for ex ‐ ample, at the start of each itera ti on, is a pivotal point that requires a tt en ti on in each project and context at hand. Specifically, thorough planning in the early pro ‐ ject phases strives to address requirements holis ti ‐ cally, prevent major unnecessary changes later in the project, and prevent successive requests for changes a ft er the project’s comple ti on. On the other hand, in ‐ corpora ti ng later addi ti ons to the ini ti al planning al ‐ lows for increased flexibility and prompt response to stakeholder feedback, requirement changes, and emerging market trends. This balancing, along with team coordina ti on (Bick et al., 2017), can bring long ‐ term benefits for ERP implementa ti on success. 2 THEORETICAL BACKGROUND Implementa ti on of ERP solu ti ons is inevitably linked to challenges in the requirements engineer ‐ ing process. One could hardly find a so ft ware devel ‐ opment project where requirements were not an issue. According to Sawyer et al. (1997), some of the ever ‐present major challenges in requirements en ‐ gineering include inconsistent and incomplete re ‐ quirements, requirements not reflec ti ng the actual user need, the expensive introduc ti on of any changes a ft er requirements have been agreed upon, and misunderstandings of requirements between team members. The challenges men ti oned mostly relate to a tradi ti onal point of view, which empha ‐ sises the importance of solidly defining the founda ‐ ti ons in the early stages of the project, to the extent that the project results allow. The scien ti fic discourse in which flexibility be ‐ comes the cornerstone is based on the well ‐known adage that “the only constant is change,” or, in other words, “changes are constant.” Therea ft er, scien ti fic discourse on the e fficiency of so ft ware development projects emphasised the need for the coexistence of both predic ti ve and adap ti ve (e.g., agile) ap ‐ proaches, which assume flexibility in the founda ‐ ti ons of the project throughout the en ti re course of the project. The challenges in requirements engi ‐ neering, in par ti cular the trade ‐o ff between pre ‐ cisely defining requirements early on in the so ft ware development process and using agile methods that pre ‐assume requirements to change in later project phases, tackle not only the scien ti fic community but also communi ti es of prac ti ce such as RESG (n.d.), IREB (n.d.), and INCOSE (n.d.), as well as project management associa ti ons such as IPMA and PMI. The present study is the con ti nua ti on of our previous research on the importance of user re ‐ quirements for the success of ERP implementa ti on (Fink et al., 2024), but apart from the previous study, it addresses en ti rely other research ques ti ons focusing on changes in requirements. We further divide the review of relevant studies into several parts. We begin with some basic char ‐ acteris ti cs and concepts in ERP ini ti a ti ve manage ‐ ment and con ti nue to discuss the di fferences between adap ti ve (e.g., agile) and predic ti ve project management approaches. Finally, we include a re ‐ view of previous studies that looked at the require ‐ ments engineering process and how to handle changes to user requirements. 2.1 ERP system implementa ti on projects Organisa ti ons strive to increase their e fficiency by organising their work into projects that have a clear scope, deadline, and budget. ERP projects, in comparison to other types of projects, require high investments and are usually quite risky. The com ‐ mon goal of ERP systems is to op ti mise and mod ‐ ernise business processes. ERP projects can include exis ti ng comprehensive so ft ware solu ti ons on the market, open ‐source programme solu ti ons, the de ‐ velopment of a new comprehensive so ft ware solu ‐ ti on, or a combina ti on of these. It is not uncommon that the development of a solu ti on goes beyond just one project since ERP system development is usu ‐ ally not limited to a single ini ti al investment in the ERP system but is an ongoing endeavour aimed at improving business processes. O ft en, the outcomes of the previous ERP projects include the new re ‐ quirements that form the founda ti ons for the next ERP development project. Dynamic Rela ti onships Management Journal, Vol. 13, No. 2, November 2024 74 Laura Fink, Ajda Fošner, Andrej Dobrovoljc, Tomaž Pozni č: Requirements Change Management: A Case Study of an Enterprise System Implementa ti on Project As with other types of projects, ERP projects should meet their goals within a limited dura ti on and with limited resources. The success of the pro ‐ ject can be judged according to various factors, which do not only include the achievement of the quality of the implementa ti on, the deadline, and the forecast, but rather the success is evaluated on the basis of factors such as customer sa ti sfac ti on, user sa ti sfac ti on, frequency of use of the final solu ‐ ti on, and last but not least, the benefit of the project is also evaluated from the impact it has on opera ‐ ti ons, e fficiency, and, last but not least, on the com ‐ pany’s strategy and long ‐term development (Fink, 2017). Among numerous success factors on so ft ‐ ware development projects (Kronbichler et al., 2009; Sudhakar, 2012), proper planning, appropri ‐ ate change management mechanisms, and e fficient coordina ti on importantly contribute to the success ‐ ful delivery of so ft ware solu ti ons. The op ti mal project life ‐cycle, organisa ti on, and project management are o ft en ti ed to the charac ‐ teris ti cs and the level of complexity (San Cristóbal et al., 2018) of the final solu ti on, the type of indi ‐ vidual project tasks (Baccarini, 1996; Dasovi ć et al., 2020), and the uncertainty regarding requirements (PMI, 2017). The project’s complexity is primarily determined by the project’s value, the number of stakeholders and team members, the project dura ‐ ti on, and the project’s technological innova ti veness and uniqueness. ERP projects are usually complex and risky. The development of a single solu ti on is usually ongoing and surpasses a single project. For that reason, it is of utmost importance that the pro ‐ cesses are designed in such a way that the lessons learned can be applied to follow ‐up projects (Shanks, 2000). In that sense, knowledge manage ‐ ment (Miri ć et al., 2020) plays an important role. ERP projects, whether performed based on pre ‐ dic ti ve, adap ti ve, or hybrid methodologies, include phases such as requirement analysis, conceptual de ‐ sign, code development, verifica ti on and tes ti ng, and installa ti on (Kronbichler et al., 2009; Falkowski et al., 1998). Nevertheless, there are several ways that ERP projects are implemented. Matende and Ogao (2013, p. 522), for example, suggest that re ‐ quirement analysis comes a ft er “system configura ‐ ti on, customisa ti on, data capture, conversion, and rollout.” Aloini et al. (2007), in comparison, suggest that strategic planning, requirements analysis, and selec ti on of so ft ware are performed during the con ‐ ceptual phase; so ft ware deployment, integra ti on, tes ti ng, and stabilisa ti on are performed during the implementa ti on phase; and maintenance, upgrad ‐ ing, new release management, and evolu ti on are performed during the post ‐implementa ti on phase. 2.2 Adap ti ve, predic ti ve and hybrid project management approaches Takeuchi and Nonaka (1986), who first named Scrum, nowadays one of the most popular hybrid approaches (PMI, 2021; 2017), described decades ago that successful companies manage their devel ‐ opment processes di fferently. From that point on, the discourse on how project and process method ‐ ologies contribute to e fficiency flourished among the scien ti fic community. Many authors, among them PMI (2021; 2017), IMPA (2018), Royce (2009, 2011), and Wysocki, R. K. (2011), contributed to these discussions. It is not a coincidence that agile methodologies quickly expanded and further devel ‐ oped in none other industry but in the so ft ware de ‐ velopment and product development industries. Agile approaches, which belong to a group of adap ti ve approaches that use itera ti ve and incre ‐ mental approaches (PMI, 2021), are characterized by frequent stakeholder feedback. The adap ti ve ap ‐ proaches, which fundamentally di ffer from the pre ‐ dic ti ve, also known as tradi ti onal approaches, merely focus on responding to needs as they arise and reac ti ng rapidly to changes in requirements as they occur. They are preferred when requirements are highly uncertain (PMI, 2021) and when it is nec ‐ essary to embrace and integrate changes due to feedback, new market developments, or new tech ‐ nology developments. These approaches are characterised by their shorter life ‐cycle phases (Royce, 1987; Al ‐Saqqa et al., 2020), itera ti ve planning, and evolving require ‐ ments compared to tradi ti onal comprehensive up ‐ front planning (PMI, 2017). In an agile environment, many ac ti vi ti es, for ex ‐ ample, development and tes ti ng, are performed concurrently, whereas in a tradi ti onal se tti ng, test ‐ ing is usually a separate project phase. As we indi ‐ Dynamic Rela ti onships Management Journal, Vol. 13, No. 2, November 2024 75 cated in the introduc ti on, agile is all about the readi ‐ ness to embrace change throughout a project. Not only requirements may change, but also the end product, service, or what is considered acceptable release (PMI, 2021; 2017). Whether at the organisa ti onal level (Hernaus et al., 2020) or at the project level, agility encompasses somewhat similar guiding principles, such as facili ‐ ta ti ng responses to change and viewing changes as opportuni ti es (Zhang and Sharifi, 2000). Similarly, the iden ti fica ti on of risks is performed throughout a project (Lunesu et al., 2021) compared to the pre ‐ dic ti ve approach, where it is mostly performed dur ‐ ing the planning phase. Further, agile and adap ti ve so ft ware development is based on customer in ‐ volvement and feedback throughout the project, compared to the predic ti ve approach, where cus ‐ tomers’ input is concentrated at the start and at the end of the project. Moreover, documenta ti on in an agile se tti ng is focused on the essen ti als (Behu ti ye et al., 2022) compared to a tradi ti onal se tti ng where documenta ti on includes detailed plans and exten ‐ sive requirements’ documenta ti on. The adap ti ve (e.g., agile) approach is also based on regular re ‐ view, while the predic ti ve approach is based on ti meline tracking. Finally, adap ti ve and agile teams (Zainal et al., 2020) are o ft en self ‐organising, cross ‐ func ti onal teams with a high degree of autonomy, while teams in tradi ti onal se tti ngs have a hierarchi ‐ cal team structure with specialised roles. Predic ti ve approaches have a long tradi ti on, whereas adap ti ve approaches emerged later. The agile manifesto, agile values, and agile principles (Agile manifesto, 2001) have triggered further de ‐ velopment and expansion of numerous agile ap ‐ proaches, as well as hybrid approaches, which are known to integrate the characteris ti cs of both adap ‐ ti ve and predic ti ve approaches (PMI, 2021; Wysocki, 2019). The adop ti on of specific hybrid project life ‐ cycles and specific hybrid approaches such as Scrum (Schwaber, 1997), Kanban, extreme programming, Scrumban, Crystal methods, and others (Abrahams ‐ son et al., 2017; Edison et al., 2022; Alqudah and Razali, 2016), has become widespread (PMI, 2017). The popularity of agile approaches has con ‐ tributed to a desire to highlight the benefits of agile approaches, such as their flexibility in responding to changes, while shortcomings, such as risk an ti cipa ‐ ti on and a lack of fixed planning that could prevent major unnecessary changes, unexpected costs due to late changes, or addi ti onal work in later stages, are frequently overlooked. PMI (2017) and many other previous studies, among which Wysocki (2020) and Fink (2017) pre ‐ viously recognised the need to tailor specific ap ‐ proaches to par ti cular project a tt ributes. Actually, many so ft ware development projects require hybrid approaches that include a unique blend of adap ti ve and predic ti ve characteris ti cs. The op ti mal set of predic ti ve and adap ti ve components (Karlström and Runeson, 2005, 2006; Davis, 2012; Fink, 2017; PMI, 2021; Wysocki, 2023) needs to be determined for the project and context at hand. Factors such as de ‐ gree of innova ti on, requirements certainty, scope stability, ease of change, delivery op ti ons, risk, safety requirements, regula ti ons (product, service, or result), stakeholders, schedule constraints, fund ‐ ing availability (project), organiza ti onal structure, culture, organiza ti onal capability, project team size, and loca ti on (organiza ti on) should be considered (PMI, 2021). The op ti misa ti on and fine‐tuning of the combina ti on of approaches resulted in many hybrid approaches (e.g., Žužek et al., 2020) that, by nature, combine the characteris ti cs of predic ti ve and adap ‐ ti ve (e.g., agile) approaches (PMI, 2017). The expecta ti ons about the change in require ‐ ments (PMI, 2017) are an important factor to con ‐ sider when developing the best ‐suited project life cycle. While itera ti on ‐ or incremental ‐based agile approaches coincide with hidden and misunder ‐ stood requirements, merely itera ti ve or incremental approaches assume that feedback in between en ‐ ables be tt er further planning of the project (PMI, 2017). The agile approaches are therefore more suitable for projects where there is high uncertainty regarding requirements and it is expected that re ‐ quirements “will change based on customer feed ‐ back” (PMI, 2017). The predic ti ve approaches, on the other hand, are suitable for low ‐risk serial pro ‐ jects and projects requiring substan ti al investment. They focus on the fact that the cost of change (PMI, 2021) increases exponen ti ally throughout the pro ‐ ject dura ti on. Simply put, the cost of introducing a change increases the later it occurs. Predic ti ve methods are more appropriate in cases where fail ‐ Dynamic Rela ti onships Management Journal, Vol. 13, No. 2, November 2024 76 Laura Fink, Ajda Fošner, Andrej Dobrovoljc, Tomaž Pozni č: Requirements Change Management: A Case Study of an Enterprise System Implementa ti on Project ure to integrate key parameters, assump ti ons, and premises related to requirements beforehand or in the early phases would lead to substan ti al draw ‐ backs. Failure to do so could result in severe irre ‐ versible consequences, such as unexpected repair costs, the need to remove previously completed work, a chain reac ti on of addi ti onal changes, adjust ‐ ments, rework, and additi onal work, or even jeop ‐ ardize the system’s long ‐term opera ti on. 2.3 The requirements engineering process Since the user requirements represent the founda ti on for an ERP project, they are important not only for the choice of the type of solu ti on but in general for the development of the solu ti on itself. In par ti cular, in an agile se tti ng, the requirements are o ft en underspecified, un ‐clear, and missing and are the subject of emerging refinement. On the con ‐ trary, in a stable se tti ng where requirements are perfectly clear, there is no need to introduce agile components. Therefore, the characteris ti cs of the requirements themselves are also important for de ‐ termining the set of agile components that should be applied (PMI, 2017) to a par ti cular project. Requirements engineering is a challenging pro ‐ cess that, according to ISO (2018) standards, results in “requirements for system and so ft ware products throughout the life ‐cycle.” This can include their ini ti al defini ti on, analysis, specifica ti on, valida ti on (Atoum et al., 2021), priori ‐ ti sa ti on (Regnell et al., 2001), requirements man ‐ agement, and system modelling (Sommerville, 2009). A widely used taxonomy (Laplante and Kassab, 2022) categorises requirements into user re ‐ quirements, system requirements, and design spec ‐ ifica ti ons (Sommerville, 2005), based on their level. Essen ti al for acceptance tes ti ng, user requirements o ft en include conceptual papers and user stories. They outline the specific func ti onality that the sys ‐ tem should o ffer to users. They describe desired sys ‐ tem behaviour in a manner that is comprehensible to the business user, from their perspec ti ve. System requirements, o ft en referred to as func ‐ ti onal specifica ti ons or technical annexes, are essen ‐ ti al for conduc ti ng integra ti on tes ti ng (Laplante and Kassab, 2022). These requirements outline the be ‐ haviour of a system, typically in rela ti on to func ti ons that have been previously defined in user require ‐ ments. Design specifica ti ons, derived from system requirements, are essen ti al for conduc ti ng unit test ‐ ing (Laplante and Kassab, 2022). A frequently used taxonomy categorises re ‐ quirements into functional, nonfunctional, and domain requirements, depending on their speci ‐ fication types. Functional requirements delineate the specific services that the system is expected to offer and its corresponding responses to the in ‐ puts it receives (Laplante and Kassab, 2022, p. 6). High ‐level functional requirements align with the user’s needs, whereas detailed functional require ‐ ments align with the system’s requirements (La ‐ plante and Kassab, 2022). The system is defined not only by its function ‐ alities but also by its nonfunctional behaviour. The NFRs (Non ‐Functional Requirements) (Laplante and Kassab, 2022; Rahy and Bass, 2022; Behutiye et al., 2020, 2022; Jarzebowicz and Weichbroth, 2021; and Karhapää, 2021) encompass a range of issues including security, reliability, dependability, reusability, maintainability, performance, usability, testability, interoperability, and constraints. Do ‐ main requirements encompass several aspects, such as introducing new functional requirements (FR), imposing limitations on existing FR, or deter ‐ mining the specific functions inside a given appli ‐ cation domain (Laplante and Kassab, 2022). Requirements are mul ti‐ layered and are reliant on the characteris ti cs of the product and the source of requirements (Chemuturi, 2012; Regnell et. al., 2001; ReqView, n.d.). The iden ti fica ti on of the higher ‐level requirements leads to the approval of a project in the first place (Matende and Ogao, 2013). More detailed requirements’ documenta ti on and lower ‐level requirements can be gathered and analysed throughout the en ti re project dura ti on and even a ft er the project’s comple ti on. Di fferent tech ‐ niques for conduc ti ng the requirements analysis (Köse, 2019; Nuseibeh et al., 1994; McGraw and Harbison, 2020) are more in line with either adap ‐ ti ve (e.g., agile) or predic ti ve methodologies, or a combina ti on of those. As the project management processes shall be suited to the project characteris ‐ ti cs (PMI, 2017), so should the appropriate tech ‐ Dynamic Rela ti onships Management Journal, Vol. 13, No. 2, November 2024 77 nique for requirements analysis (Guilleme tt e et al., 2021). The complexity of the project itself is impor ‐ tant for the complexity of the requirements engi ‐ neering process. Nevertheless, it is meaningful that Theunissen et al. (2022), who inves ti gate prac ti cal applica ti ons of agile methodologies, suggest there is a need for increasing the quan ti ty and quality of requirements’ documenta ti on. In the process of requirements engineering, a team should certainly consider that requirements need to be aligned, communicated, and priori ti sed (Rengell et al., 2001). Any miscommunica ti on or misalignment can seriously jeopardise the achieve ‐ ment of the goals, so it is necessary to pay a lot of a tt en ti on to the fact that the requirements are com ‐ municated in a way that everyone understands them equally (Robertson & Robertson, 2012). 2.4 Change management The ever ‐changing nature of work and the rapid technological changes made practiti oners and re ‐ searchers realise that projects in which project goals are not clearly defined and the project ac ti vi ti es are uncertain require approaches that, in their nature, pre ‐assume greater flexibility and embrace changes. The matrix of Wysocki (2011, 2014) and the Stacey complexity model (Stacey et al., 2000; PMI, 2017) support this no ti on by showing that the level of un ‐ certainty greatly a ffects how the project should be approached. Despite the di fferences between pro ‐ ject methodologies, any project and requirements engineering process must include a change control process, which ensures that any addi ti ons are “iden ‐ ti fied, documented, approved, or rejected” (PMI, 2021), as well as change management, “a compre ‐ hensive, cyclic, and structured approach” (PMI, 2017, p. 164) that embraces prac ti ces, skills, and techniques for transforming people, groups, ac ti vi ‐ ti es, projects, or organisa ti ons to another state. Whether in a predic ti ve or agile se tti ng (L’ecuyer and Ahmed, 2016), where change is the only constant, it is important to evaluate the added value and an ‐ ti cipated investment associated with changes to be implemented. An e fficient change control system (PMI, 2021), which si ft s through meaningful changes through a formal approval process, ensures that the acquired value outweighs the resources, ef ‐ fort, and costs invested. Besides, it also ensures that “scope creep” (PMI, 2021) is avoided, especially in predic ti ve se tti ngs, meaning that addi ti ons to scope or requirements should result in adjustments to the schedule, budget, and resources. Adequate plan ‐ ning and adequate risk an ti cipa ti on can prevent overload of changes and hec ti c schedules, as well as planning of the ac ti vi ti es that are likely to change during the course of the project. E fficient planning, change management, and coordina ti on are consid ‐ ered important success factors. In par ti cular, agile approaches o ft en closely in ‐ tertwine with concepts of change management and are fundamentally based on requirements’ uncer ‐ tainty and the technical degree of uncertainty (PMI, 2017). Agile methodologies begin with less ‐defined requirements and include more itera ti ons of shorter dura ti on, each of which begins with a requirements analysis. In agile projects, even the project scope may be subject to change. During subsequent iter ‐ a ti ons, changes and details are added. Predic ti ve approaches to managing projects are based on quite the opposite: a clear defini ti on of project goals, project ac ti vi ti es, and, to the greatest degree possible, the elimina ti on of all unknowns. Predic ti ve approaches devote more a tt en ti on to re ‐ quirements analysis, detailed planning, and an ti ci ‐ pa ti on of risks and changes during the ini ti al phases. This does not mean, however, that the predic ti ve methodology does not foresee the possibility of in ‐ troducing changes during the project, including “fre ‐ quent reviews, change control mechanisms, and replanning between development phases” (PMI, 2021), but it does so in a clearly defined se tti ng with a rela ti vely stable scope. The changes, especially those introduced in later project phases, can dras ti cally increase dura ‐ ti on, waste resources, and compromise the scope of any project. Though in some projects, par ti cularly those led predominately based on predic ti ve ap ‐ proaches, it might be impossible or extremely costly to introduce changes a ft er the work has already been performed. However, requirements’ docu ‐ menta ti on can be subject to change even in pre ‐ dominately tradi ti onally led projects. This is parti cularly true for complex and high ‐risk projects such as ERP . Dynamic Rela ti onships Management Journal, Vol. 13, No. 2, November 2024 78 Project teams must decide how much ti me to devote to the requirements engineering process during the early stages of the project. In this regard, agile and itera ti ve prac ti ces rely on shorter incre ‐ ments through which par ti al but con ti nuous im ‐ provement of user requirements gradually evolves. The changing nature of work and the rapid pace of technological change s ti mulate a high demand to change and upgrade more detailed user require ‐ ments on a regular basis (Al ‐Ghamdi and Saleem, 2018). Predic ti ve methodologies, on the other hand, are founded on a clear and precise descrip ti on of user requirements during the project’s early stages. In predic ti ve methodologies, user requirement anal ‐ ysis is typically developed in greater detail and fi ‐ nalised earlier in the ini ti al project phases. More a tt en ti on is devoted to immutably determining key requirements, coordina ti ng the understanding of key requirements among team members, and defin ‐ ing the specialisa ti on of team roles. However, even in predominantly tradi ti onally led projects, the user requirements can be subject to change (IPMA, 2016), and on the other hand, even in predominantly agile ‐led projects, the need for clearer defini ti on, documenta ti on (Theunissen et al., 2022), and communica ti on of user requirements exists. 3 RESEARCH QUESTIONS We divide research ques ti ons into two parts: 1.) the requirements engineering process and 2.) change management. 3.1 The requirements engineering process User requirements’ documenta ti on can be cre ‐ ated using a variety of methodologies, best prac ti ces, and industry recommenda ti ons. We’re curious about how the project management methodology influ ‐ ences user requirements’ analysis. What are the char ‐ acteris ti cs of the requirements’ gathering and analysis process? The company’s internal regula ti ons fre ‐ quently determine the choice of a par ti cular method ‐ ology and modifica ti ons to it. We want to inquire if the methodology used to gather and analyse user re ‐ quirements a ffects the quality of the requirements’ documenta ti on and the final project outcome. First research ques ti on (RQ1): How does the appro ‐ priate combina ti on of adap ti ve (e.g., agile) and pre ‐ dic ti ve waterfall methodologies a ffect the quality of requirements’ documenta ti on and the final outcome of an ERP system implementa ti on project? Second research ques ti on (RQ2): How does the level of awareness in the organisa ti on and project management about the importance of quality user requirements contribute to project success? 3.2 Change management We inves ti gate whether the fact that changes to user requirements’ documenta ti on are intro ‐ duced only during the first phases of the project rather than throughout the en ti re dura ti on of the project a ffects the project’s final outcome. We are parti cularly interested in whether change requests contribute to project success. Even experienced teams find it di fficult to ac ‐ curately state all of the requirements prior to the start of the project and to capture all user experi ‐ ences and user stories in advance. This would ne ‐ cessitate the par ti cipa ti on of a large number of users, which is not only di fficult to coordinate but mostly ti me ‐consuming. As a result, understanding that changes during projects can improve project outcomes, that changes should be seen as enhance ‐ ments and addi ti ons rather than correc ti ons of past errors, and that incorpora ti ng change management processes benefits projects is cri ti cal for any project, regardless if it is predominately applying predic ti ve or adap ti ve (e.g., agile) methodologies. Third research ques ti on (RQ3): Do constant modifi ‐ ca ti ons and improvements to user requirements’ documenta ti on throughout the project, as opposed to fixed or sta ti c requirements, increase the likeli ‐ hood of mee ti ng project goals? When the project’s scope, goals, and high ‐level requirements are lightly defined, it not only impacts the volume of changes to tasks within the project but also the volume of tasks that must be performed a ft er the project’s comple ti on or during the post ‐im ‐ plementa ti on phase. Especially in an agile environ ‐ Laura Fink, Ajda Fošner, Andrej Dobrovoljc, Tomaž Pozni č: Requirements Change Management: A Case Study of an Enterprise System Implementa ti on Project Dynamic Rela ti onships Management Journal, Vol. 13, No. 2, November 2024 79 ment, this can lead to an excessive volume of change requests during the project and addi ti onal improve ‐ ments requested a ft er implementa ti on. Fourth research ques ti on (RQ4): What strategies may a project team employ to address an excessive volume of change requests during the project and addi ti onal improvements requested a ft er the com ‐ ple ti on of an ERP system implementa ti on project? 4 RESEARCH METHODOLOGY As is common in IS and so ft ware engineering re ‐ search (Runeson and Höst, 2009), an exploratory case study methodology is applied. The ERP system imple ‐ menta ti on project was me ti culously chosen via judg ‐ mental sampling. The main reason for applying judgmental sampling is that the unique insights can be righ tf ully presented by important project stake ‐ holders with specialised, unique exper ti se. Since ERP implementa ti on projects are o ft en unique, complex, and risky, informa ti on asymmetry is o ft en prevalent, meaning that only decision ‐makers with direct in ‐ volvement may be able to provide nuanced insights relevant to the research. Judgmental sampling en ‐ ables a deeper and more comprehensive understand ‐ ing of the complexity, the associated risk, and the dynamics of changing requirements in an ERP pro ‐ ject. To avoid the possible shortcomings of judgmen ‐ tal sampling, we carefully selected the interviewee, a project manager who has a wide perspec ti ve, is a decision ‐maker, and has an overview of the en ti re project. A project manager who works for a large, in ‐ terna ti onal company and has rich experience in lead ‐ ing projects for the development and improvement of enterprise system solu ti ons was the best suited person to provide us with the insights. The research ques ti ons were derived from the research gaps that were found during the literature review. The measurement instrument was specified in advance. We applied three di fferent types of data collec ti on methods: collec ti ng informa ti on through a semi ‐structured interview based on open ques ‐ ti ons, collec ti ng further details about the key project characteris ti cs through a short survey, and forming the study itself through an extensive literature re ‐ view. The primary data are qualita ti ve in nature and were obtained at a par ti cular ti me. The interviewee and interviewers made an oral agreement outlining the confiden ti ality requirements. Two researchers conducted a one ‐hour interview with the project manager. Open ‐ended ques ti ons were used to elicit specific data. To minimise the impact of prior expe ‐ riences or assump ti ons of individual researchers, all research par ti cipants carefully chose and prepared the ques ti ons in advance. A ft er the interview, we prepared and reviewed the transcripts to iden ti fy and select the findings, and we organised a discus ‐ sion about the theore ti cal and prac ti cal ramifica ti ons of the research ques ti ons. The recommenda ti ons (Runeson and Höst, 2009; O’Brien et al., 2014) and examples (Karlström and Runeson, 2006; Andersson and Runeson, 2007) for repor ti ng qualita ti ve re ‐ search, as well as the recommenda ti ons for inter ‐ view ques ti on prepara ti on and qualita ti ve interview strategies (Harvard, n.d.), are followed as closely as possible in the prepara ti on of the qualita ti ve re ‐ search. Throughout the paper, we support the dis ‐ cussion and conclusions with quotes. With that, we enhance our comprehension of prevalent prac ti ces and methodologies applied in ERP projects that fa ‐ cilitate the achievement of higher ‐quality UR. When assessing the validity of the study, it is rea ‐ sonable to consider that this research primarily rep ‐ resents the viewpoints of a customer of an ERP system. We did not interview other project stakehold ‐ ers, such as the so ft ware company, internal and ex ‐ ternal team members, supervisors, or users. We did not collect archival data like process models or speci ‐ fica ti ons. However, by carefully selec ti ng the intervie ‐ wee, we par ti ally addressed reac ti vity, researcher bias, and respondent bias, which, according to the Lin ‐ coln and Guba model (Robson, 2002; Karlström and Runeson, 2006), represent possible threats to validity. Since it is challenging to ensure the validity of findings based on judgmental sampling, our research also in ‐ cludes limita ti ons such as limited generalizability, chal ‐ lenging assessment of representa ti veness, and challenging valida ti on of results. 5 CASE STUDY In our particular case study, the estimated cost of the upgrade ERP system implementation project ranged from 5 to 10 million euros. After 18 months, the initial solutions went live. Although Dynamic Rela ti onships Management Journal, Vol. 13, No. 2, November 2024 Laura Fink, Ajda Fošner, Andrej Dobrovoljc, Tomaž Pozni č: Requirements Change Management: A Case Study of an Enterprise System Implementa ti on Project 80 the schedule and the use of other resources di ‐ verged from the original plan, the system’s suc ‐ cessful implementation was not in any way jeopardised. Both the project’s deadline and bud ‐ get were met. Different modules, or subsystems, make up ERP systems. As shown in our case study, the modernization, renovation, and reengineering of important business processes in an enterprise system is a complex project requiring a sizable in ‐ vestment and the involvement of numerous stake ‐ holders. The final solution had an impact on more than 1000 business users, and the internal core project team consisted of 20 to 25 individuals. The project involved a large number of external parties, including about five different businesses and addi ‐ tional independent contractors. The primary objec ti ves of the project were to streamline, modernise, standardise, and improve the intricate process of product release. The deci ‐ sion to release a product must be made a ft er gath ‐ ering a lot of data and checking a lot of control points. The objec ti ve of the project was to make it possible for data to be automa ti cally gathered from various systems and sources and displayed on a dashboard. Decision ‐making is made easier and more quickly when informa ti on is accessible at a glance in one place. The project was successful in terms of user adoption and satisfaction. The internal staff is very pleased with the software solution. While ac ‐ knowledging that there is still room for improve ‐ ment, the project manager is generally pleased with the solution, the collaboration with external contractors, and the collaboration within the inter ‐ nal team, as well as with the professional compe ‐ tence, technical expertise, and process knowledge of the internal staff. The successful implementa ‐ tion of an ERP system allowed us to identify good practices and criteria leading to success, as well as strategies to overcome challenges ERP projects might face. These are the reasons that led us to choose this project as a case study. In the continu ‐ ation of the study, we provide further insight about the particular project methodology and require ‐ ments change management by supporting the dis ‐ cussion around the research questions with quotes. 5.1 The requirements engineering process The project team, under the leadership of the customer of the ERP system, adjusted project man ‐ agement methodology to the specific character of the project (RQ1). Although it followed the com ‐ pany’s general guidelines for project management methodology, it developed specific project method ‐ ology for the project. The valida ti on plan specified the specific methodology. The customer, on the one hand, put an emphasis on execu ti ng a lot of the planning ac ti vi ti es before the project started, which is typical of predic ti ve approaches. The project, on the other hand, was organised in itera ti ons, or rolling waves, which means that ac ti vi ti es within work packages were defined in greater detail as the project progressed. The project team combined pre ‐ dic ti ve and adap ti ve methodologies but did not use ordinary sprints, scrums, or strictly predic ti ve ap ‐ proaches. A clear scope and thorough specifica ti on of business requirements defined in the early pro ‐ ject phases contributed greatly to the overall suc ‐ cessful implementa ti on of the solu ti on. “The three main project packages, design, build, and tes ti ng, were performed more or less in paral ‐ lel,” says the project manager. “The ac ti vi ti es were intertwined. This flexible approach was defined in the valida ti on plan from the very beginning.” The planning process and requirements analy ‐ sis included several rolling waves. Addi ti onal plans were developed a ft er the first wave. A roadmap of a product release process with steps was an impor ‐ tant input. Some approaches in the very early stages of cus ‐ tom development, for example, included require ‐ ments that were then reviewed and signed o ff on before being handed over to the developers to de ‐ velop the so ft ware. The requirements for the por ti on of the project that included standard solu ti ons were not signed o ff on. Instead, they reviewed and signed o ff on the solu ti on a ft er it had been tested and ap ‐ proved informally. Furthermore, while the project was based on some high ‐level documents, the team did not wait for all tasks to be completed and com ‐ pared the API documenta ti on to proceed. Instead, the ac ti vi ti es were carried out simultaneously. Dynamic Rela ti onships Management Journal, Vol. 13, No. 2, November 2024 81 Another aspect that we inves ti gated was the level of awareness about the importance of quality user requirements (RQ2). The project manager stressed several ti mes during an interview that the business requirements are a star ti ng point and that it is crucial that IT and other experts understand the needs of the users. It is very important that the IT team members understand the requirements of the business team members, which are the primary drivers. Regardless of the context or type of project, understanding business requirements is a good place to start. 5.2 Change management Our research supports the no ti on that manag ‐ ing changes, par ti cularly changes in requirements, is the biggest challenge of ERP projects that strive for a high degree of user adop ti on and, on average, sa ti sfied users (RQ3). In our specific case study, the project manager emphasises that the customer’s “expecta ti on was never that the implemented system would repre ‐ sent the final solu ti on.” The high number of change requests to further improve the process during the project implemen ‐ ta ti on and a ft er the system implementa ti on was of ‐ ficially completed is a reality that the customer acknowledged from the elabora ti on of the project onwards. In the future, they want to further im ‐ prove and develop the product release process. The team gained important experience, which they made good use of during the post ‐implementa ti on improvement of the processes. The high number of change requests in no way threatened the success ‐ ful implementa ti on of the system. Nevertheless, the manager acknowledges that the number of change requests could be decreased to some degree sooner. They consider the process to be a living or ‐ ganism that can always be improved. The general scope of the project and high ‐level requirements were clearly determined early on, but a ft er the conceptual design phase, an updated ver ‐ sion of the user requirements’ documenta ti on was prepared. Throughout the en ti re project, they strived to op ti mise the requirements, and they con ‐ ti nue to do so even during the post ‐implementa ti on phase. A ft er the detailed design documenta ti on and development, the system demos were performed. During system demos, they some ti mes realised that “the requirements should be rephrased or that some important thing needs to be added.” The collabora ‐ ti on between IT and business team members was very close, and discussions about the updates took place almost throughout the en ti re project. “The change requests were quite intense. In cer ‐ tain areas, the solu ti on and the ti meline have changed substan ti ally,” said the manager. The project changes made during the course of the project had an impact on the scope, the ti meline, and the use of resources. However, each change was carefully approved and in ‐ troduced in a controlled manner . For example, the sys ‐ tem integra ti on issue that occurred later in the project automa ti cally triggered the need to add changes to the high ‐level requirements’ documenta ti on. The changes to the documenta ti on were added up un ti l the tes ti ng phase. Even a ft er implementa ti on, there are s ti ll requests for changes. As a consequence of the changed ti meline, the system integra ti on was late, and some projects that were performed in parallel on other systems had to be temporarily stopped. Never ‐ theless, the successful implementa ti on of the system was in no way compromised. According to the manager, the IT team may also be the one to ini ti ate changing user requirements, not just the business part of the team. Especially when IT professionals recognise that some solu ti ons may have a nega ti ve impact on end users or work be tt er in an ‐ other way. In that case, the team comes together to discuss how user requirements can be adjusted to im ‐ prove the impact on the end user. In such a case, the team needs to work together to discuss these changes. Depending on the size of the impact of a change, the business change manager then coordi ‐ nated the discussion and gathered feedback about the impact of user requirement changes. In the event of a change, users are no ti fied and asked to provide feedback within a week. Communica ti on with end users was also intense during requirements analysis and pilots in partner companies. The business process owners gathered user stories and feedback from the end users. During the pilots, one or two members from each pilot site joined the core team. Dynamic Rela ti onships Management Journal, Vol. 13, No. 2, November 2024 Laura Fink, Ajda Fošner, Andrej Dobrovoljc, Tomaž Pozni č: Requirements Change Management: A Case Study of an Enterprise System Implementa ti on Project 82 A change request was usually first coordinated between the person who started the change and the company’s project management. A ft er internal alignment, the project manager started to nego ti ate the change with the so ft ware company. With each request for a change, the agreed ‐upon project scope could be delayed and/or cost more than orig ‐ inally planned. So, compromises had to be made so that extra requests for changes didn’t cause big changes to the agreed ‐upon project scope but rep ‐ resented small improvements to the quality of the processes. Some change requests were put on hold and added to the backlog for implementa ti on within the next releases of the so ft ware since delaying the project was not an op ti on. It was crucial to develop a suitable business solu ti on by the agreed ‐upon deadline so that businesses could gain benefits as soon as possible and the project would not get can ‐ celled. Because of this, everyone agreed that further so ft ware releases would include more process op ‐ ti misa ti on. The project manager adds that, of course, the process “has to be further improved and enhanced based on feedback” obtained during the post ‐imple ‐ menta ti on phase. Furthermore, each product re ‐ lease represents an opportunity to find new ways to improve the process. The fact that the require ‐ ments are constantly op ti mised and gathered is im ‐ portant for future projects as well. On the other hand, the project managers clearly stated that some change requests during the project as well as addi ti onal works requested a ft er project comple ti on could be avoided and addressed earlier on during the project (RQ4). This proves that it is challenging to find the right balance between predic ti ve and adap ti ve approaches to planning, even in otherwise successful ERP system implemen ‐ ta ti on projects. According to the assessment of the project manager, the project faced too many change requests. The users who are invited to provide feed ‐ back on par ti al solu ti ons were reluctant to speak out or to provide comments on the solu ti ons that were developed. Therefore, the team readily imple ‐ mented some improvements to avoid as many change requests during the project and the post ‐im ‐ plementa ti on phase of this or other projects. It be ‐ came clear that the tes ti ng procedure contributed to the change management project and that the manager realised that improving tes ti ng and, in par ‐ ti cular, the valida ti on process could yield even more favourable results. “We plan to perform the rollouts at other sites. We have improved and will con ti nue to improve the valida ti on process. We formalised the process of valida ti ng the func ti onali ti es by introducing checkpoints. They must accept the solu ti on from the start. That way, we can be certain that they are completely sa ti sfied with the solu ti on pro ‐ vided for each func ti onality. During the post ‐im ‐ plementa ti on phase, we began collec ti ng and evalua ti ng their major pain points. That is some ‐ thing we are s ti ll working on. We intend to im ‐ prove the system and add improvements so that users can truly benefit from the new system.” 6 DISCUSSION The paper addresses the requirements engi ‐ neering process and change management, which we further discuss considering both the theore ti cal and prac ti cal ramifica ti ons. We round o ff the discus ‐ sion with limita ti ons and future research. 6.1 Theore ti cal contribu ti ons The presented case study is an excellent exam ‐ ple of high customer involvement in the develop ‐ ment of an ERP system. The customer was not only fully involved throughout the project but also took on the leadership and coordinated project partners and ac ti vi ti es. In our case study, there was no issue with lack of customer involvement, their inability, or non ‐alignment that was observed by Ramesh et al. (2010) on some other agile ‐based so ft ware de ‐ velopment projects. Having a competent customer who is able to monitor the course of the project proved to be an important success factor. In large part, the customer determined not just the team culture but also the project methodology. The pro ‐ ject team established its own unique approach to project methodology that was derived partly from the customer company’s project management stan ‐ dards and involved a blend of predic ti ve and adap ‐ ti ve methodologies. This had an e ffect on the quality of the requirements’ documenta ti on and the final Dynamic Rela ti onships Management Journal, Vol. 13, No. 2, November 2024 83 outcome. A unique combina ti on of predic ti ve and adap ti ve elements was applied to address the needs of the project, the characteris ti cs of the final system, and the characteris ti cs of all involved organisa ti ons to the best degree possible (RQ1). This has worked well since it addressed the requirements of the company, an interna ti onal organisa ti on working on large ‐scale projects, the characteris ti cs of the par ‐ ti cular process and the ERP system itself, as well as the requirements of the pharmaceu ti cal industry and its standards. It is also in line with the chal ‐ lenges that o ft en arise when applying agile method ‐ ologies to large so ft ware development projects (Alqudah and Razali, 2016). Further, the case study presented is also an excellent example of how two fundamentally di fferent business cultures, the phar ‐ maceu ti cal and IT sectors, can e ffec ti vely work to ‐ gether, given that a customer takes the lead in how the project should be approached. The literature shows both theore ti cal ERP im ‐ plementa ti on models and standardised ERP imple ‐ menta ti on steps applied in prac ti ce (Lutovac and Manjolov, 2012), as well as examples of how agile methodologies were incorporated into ERP imple ‐ menta ti ons (Nagpal, 2015; Kralji ć & Kralji ć, 2020; Kralji ć et al., 2014) and large so ft ware development (Alqudah and Razali, 2016). However, the majority of prior research predominantly focuses on the per ‐ specti ve of so ft ware companies, such as SAP , Oracle, or others, with limited considera ti on given to the viewpoints of customers of ERP systems. The case study confirms the exis ti ng findings re ‐ garding the importance of selec ti ng the right blend of predic ti ve and adap ti ve methodologies for managing projects that is best suited for a par ti cular project. The project teams are constantly choosing between the thoroughness of an ini ti al plan and the addi ti ons to the ini ti al plan that they are willing to make later in the project (Rasheed et al., 2021). On the one hand, it is known that it is more di fficult, challenging, and ti me ‐consuming to introduce changes later during the project. On the other hand, teams under ti me pres ‐ sure want to begin developing solu ti ons as soon as possible. Moreover, to further improve and develop the plan, the team would require more informa ti on, which can only be obtained once the development phase has already started. As a result, project phases frequently run concurrently. Though the lack of ti me should not compromise the quality, perfec ti ng and fine ‐tuning the ini ti al plan in the ini ti al project phases or before the start of the project takes valuable ti me. Plan addi ti ons and details can be added later during projects. The compromise between thoroughly preparing the plan as early as possible and the num ‐ ber of addi ti ons to be added later is frequently con ‐ text ‐specific. The characteris ti cs of the project and of the project ac ti vi ti es can be crucial for determining the best combina ti on of predic ti ve and adap ti ve ap ‐ proaches in a concrete project. Predic ti ve and adap ‐ ti ve approaches have certain advantages and disadvantages. Even if adap ti ve approaches regard changes as opportuni ti es, it might be hard, if not im ‐ possible, to introduce some major changes to the scope of the project later in the project due to many reasons, such as financial ones. Finally, we can draw the conclusion that both the internal company’s pro ‐ ject management regula ti on and the project specifics have an impact on project methodology. Addi ti onally, we can conclude that it is, regardless of the methodology applied, very important that the high ‐level requirements are agreed upon in advance, before the start of the project. The presented case study showcases this. A clearly defined scope and high ‐level business requirements guaranteed the suc ‐ cess of the project, which was enhanced by the ac ti ve involvement and asser ti veness of users in ac ti vi ti es such as requirements’ collec ti on, analysis, tes ti ng, and verifica ti on. Similarly, even when changes to require ‐ ments are allowed in later project phases, as is typical for agile approaches, it is crucial for the project team to be aware of the importance of high ‐quality busi ‐ ness requirements (RQ2), and any miscommunica ti on between members of the IT and business teams should be resolved as soon as possible to ensure that requirements are properly documented. The ra ti onale behind this may lie in the fact that, in any case, there is a high risk of requirements chang ‐ ing in ERP projects (Sudhakar, 2012). This is due to sev ‐ eral reasons, such as the fact that the implementa ti on of enterprise systems typically results in a substan ti al shi ft and transforma ti on in the execu ti on of pro ‐ cesses, and it in general entails the moderniza ti on of processes. Furthermore, since informa ti on technology supports processes that behave as living organisms and adhere to the tenet that you lose it if you don’t use it, they must constantly adapt and advance. Dynamic Rela ti onships Management Journal, Vol. 13, No. 2, November 2024 Laura Fink, Ajda Fošner, Andrej Dobrovoljc, Tomaž Pozni č: Requirements Change Management: A Case Study of an Enterprise System Implementa ti on Project 84 Change management is cri ti cal in ERP projects not only during the conceptualiza ti on and imple ‐ menta ti on phases but also a ft er the project has been completed, during the post ‐implementa ti on phase. Change management on an ERP project is in ‐ extricably linked to ongoing requirements analysis. The e fficient change management process associ ‐ ated with requirements is cri ti cal for improving the system and informa ti on quality, especially in com ‐ plex projects such as ERP projects with a large num ‐ ber of high ‐ and low ‐level requirements and a large number of stakeholders. Based on the case study presented, we can con ‐ clude that the companies should constantly op ti ‐ mise their requirements analysis based on lessons learned from previous projects and ensure that past lessons are applied company ‐wide in future projects (Al ‐Ghamdi and Saleem, 2018). The willingness of a customer to invest in further upgrades can speak about the success of the project, since customers who do not see benefits in the new system would be unwilling to undertake further upgrades (Markus et al., 2000). As a result, we find that modifica ti ons and improvements to user requirements’ documen ‐ ta ti on throughout the project can increase the like ‐ lihood of mee ti ng project goals (RQ3), prevent possible unnecessary changes, and incorporate some work that would otherwise be performed out ‐ side the project either as addi ti onal work or within the new project. The tes ti ng, and specifically the val ‐ ida ti on process, was shown to have an important impact on the change management process. En ‐ hancing the tes ti ng and its early introduc ti on may further improve the already posi ti ve results. The volume of change requests during the pro ‐ ject and post ‐implementa ti on is not always an indi ‐ cator of project success, but some ti mes quite the contrary. Nonetheless, by ac ti vely involving all pro ‐ ject parti cipants throughout the project, many un ‐ necessary post ‐implementa ti on changes can be avoided. Project members, par ti cularly business par ‐ ti cipants, shall ac ti vely par ti cipate in the process of defining and reviewing business requirements. Over ‐ all, we iden ti fied two strategies, which the case study exemplifies and a project team employed to address an excessive volume of change requests dur ‐ ing the project and addi ti onal improvements re ‐ quested a ft er the comple ti on of an ERP system implementa ti on project (RQ4): high ‐quality require ‐ ments and, most of all, a formalised tes ti ng and ver ‐ ifica ti on process. We further expand on these very prac ti cally ‐oriented strategies in terms of their prac ‐ ti cal implica ti ons. 6.2 Prac ti cal implica ti ons Before we further elaborate on the aforemen ‐ ti oned strategies, let us summarise several further key findings that are of importance with respect to the prac ti cal implementa ti on of future ERP systems. First, customer involvement, monitoring, and possibly leadership of ERP system implementa ti on are highly advised. Then, the specific project methodology that includes a blend of predic ti ve and adap ti ve methodologies should be determined by the project team, based on the characteris ti cs mainly of the customer’s organisa ti on where the ERP system is to be implemented, but also on the characteris ti cs of other project stakeholders, the specific processes, and the ERP system itself. Frequently, important factors such as project at ‐ tributes, project tasks, customer and stakeholder or ‐ ganisa ti on, and key team members are insu fficiently considered in prac ti ce when determining the most suitable project life cycle. However, these factors are crucial in determining the appropriate approach to project management. Not all sizes fit all. As the lead ‐ ership style should adapt not only to the situa ti on but also to the personal characteris ti cs of the fol ‐ lower and leader (Gri ffith et al., 2018) and the re ‐ search methodology to its purpose (Runeson and Höst, 2009), so should the project methodology to its project. Customers of an ERP system should not get caught in a trap by expec ti ng that the so ft ware company will take the lead in proposing the method ‐ ology best suited to their so ft ware solu ti ons. As observed in our case study, the customer took charge of the implementa ti on process, led the main development ini ti a ti ves, and controlled the course of events. Unless the customer is ac ti ve and alerts the so ft ware company of the necessary ad ‐ justments, the course of events can go in the wrong direc ti on. The role that customers play in the ERP implementa ti on project can be crucial for its suc ‐ cess. When the customer is ac ti vely resolving the Dynamic Rela ti onships Management Journal, Vol. 13, No. 2, November 2024 85 problems that arise on the project together with the so ft ware company, has the majority of the thread in his hands, is the one who has constant control and preview of the implementa ti on, holds a decisive role, and makes key decisions in agreement with the so ft ware company, the ERP implementa ti on project is much more likely to be successful. A well ‐defined scope and comprehensive high ‐ level requirements, as well as the ac ti ve par ti cipa ‐ ti on and asser ti veness of users in ac ti vi ti es such as requirements’ gathering, analysis, tes ti ng, and ver ‐ ifica ti on, can further improve the project’s outcome. In prac ti ce, however, the ini ti al requirements and final result may deviate. It may happen that high ‐ level requirements approved ini ti ally by the cus ‐ tomer do not include the whole scope they should, or that the customer confirms a too ‐complex solu ‐ ti on or an add ‐on that brings li tt le benefit compared to the addi ti onal work it requires and the substan ‐ ti al increase in complexity of the overall model. In such cases, the early inclusion of tes ti ng might be par ti cularly beneficial. Early tes ti ng, based on a clear list of tes ti ng ac ti vi ti es derived from the require ‐ ments list, might assure prompt alerts about the things that should be included in the requirements but were not or about things that are just redundant since they bring too li tt le benefit. To address an excessive volume of change re ‐ quests during the project and addi ti onal improve ‐ ments requested a ft er the comple ti on of an ERP system implementa ti on project (RQ4), project teams should give more a tt en ti on to the prepara ti on of high ‐ quality requirements and, most of all, to enhancing their formalised tes ti ng and verifica ti on processes. High ‐quality requirements: Even when agile ap ‐ proaches are applied, it might be challenging to im ‐ plement changes a ft er the key building blocks of the system have already been determined and the archi ‐ tecture of the enterprise system is set. Therefore, it might be risky to start the development before all key building blocks are determined and included in the ini ti al plan. Further, due to ti me constraints, the test ‐ ing of par ti al solu ti ons against the requirements might be limited. Similarly, the opportuni ti es for fine ‐tuning and preparing a more user ‐friendly solu ti on might not be fully realised due to ti me pressure. Therefore, we advise that at least high ‐level requirements are clear to all stakeholders in advance and that awareness about high ‐quality requirements is raised. Formalised tes ti ng and verifica ti on processes: In the absence of formalised tes ti ng and verifica ti on processes intro ‐ duced early on, the development might con ti nue too long in the wrong direc ti on, and many opportuni ti es for improvement and fine ‐tuning during the develop ‐ ment phase might be missed. Feedback on par ti al so ‐ lu ti ons is crucial since it ensures an appropriate course of development. Therefore, formalising the tes ti ng and verifica ti on processes could contribute to reduc ‐ ing the number of changes in later stages, a ft er the implementa ti on of the solu ti ons. 6.3 Limita ti ons and future research ERP implementa ti on teams should carefully ex ‐ amine what is best suited for the project at hand rather than applying a methodology similar to those adapted by organisa ti ons that have previously suc ‐ cessfully implemented ERP systems. It needs to be men ti oned that, besides the selected project and the project manager, addi ti onal relevant projects or pro ‐ ject team members were not included in our sample. Even if the exploratory study enables qualita ti ve, in ‐ depth insight into the dynamics of a par ti cular case study, it is possible that parts of the conclusions are only valid for the par ti cular project. As men ti oned previously, it is challenging to ensure validity, gener ‐ alizability, or representa ti veness based on judgmen ‐ tal sampling. 7 CONCLUSION This case study ‐based qualita ti ve research inves ‐ ti gates the requirements engineering process and the requirements’ change management process in an ERP system implementa ti on project. In rela ti on to the requirements engineering process, we inves ti gate the use of adap ti ve (e.g., agile) methodologies versus tra ‐ di ti onal, predic ti ve waterfall methodologies and the importance of user requirements in an ERP project. The project team constantly chooses between the thoroughness of an ini ti al plan and the addi ti ons they are willing to make later in the project. Agile method ‐ ologies o ffer both benefits and drawbacks, but even in these projects, it may be challenging to implement substan ti al changes to the ini ti al project’s scope. The characteris ti cs of the project and project ac ti vi ti es Dynamic Rela ti onships Management Journal, Vol. 13, No. 2, November 2024 Laura Fink, Ajda Fošner, Andrej Dobrovoljc, Tomaž Pozni č: Requirements Change Management: A Case Study of an Enterprise System Implementa ti on Project 86 can determine the best combina ti on of adap ti ve (e.g., agile) and predic ti ve approaches for a concrete project. Further, we assert that the level of awareness in the organisa ti on and project management about the importance of quality user requirements con ‐ tributes to project success. ERP projects that aim to op ti mise and mod ‐ ernise business processes are complex and require constant change management to improve system and informa ti on quality. We compare constant mod ‐ ifica ti ons versus fixed requirements and address the strategies that influence the volume of change re ‐ quests during and a ft er the system’s implementa ‐ ti on. Managing changes, par ti cularly those in user requirements, is the biggest challenge for ERP pro ‐ jects that strive for a high degree of user adop ti on and sa ti sfac ti on. In the case study, the project man ‐ ager acknowledges that the customer’s expecta ti on was never that the implemented system would rep ‐ resent the final solu ti on. Moreover, a clearly defined scope and well ‐ar ti culated business requirements ensured the project’s success. User par ti cipa ti on and outspokenness during requirements gathering, analysis, tes ti ng, and verifica ti on are important fac ‐ tors that contribute to the e ffec ti veness of the pro ‐ cess. The factors that influence the number of change requests during the project and the post ‐im ‐ plementa ti on phase include awareness about the importance of high ‐quality requirements and for ‐ malised tes ti ng and verifica ti on processes. Without formalised tes ti ng and verifica ti on processes, devel ‐ opment may con ti nue in the wrong direc ti on, which causes addi ti onal change requests in later stages. Though the number of change requests during post ‐ implementa ti on is not always an indicator of project success, by ac ti vely involving all project par ti cipants throughout the project, many unnecessary post ‐im ‐ plementa ti on changes can be avoided. REFERENCES: Abrahamsson, P ., Salo, O., Ronkainen, J., & Warsta, J. (2017). Agile so ft ware development methods: Review and anal ‐ ysis. VTT Publica ti on, 478, Espoo, Finland, 107p. Agile Manifesto. (2001). Principles behind the Agile Man ‐ ifesto. h tt p://agilemanifesto.org/principles.html Al ‐Ghamdi, A. S. A. M., & Saleem, F. (2018). General char ‐ acteris ti cs and common prac ti ces for ICT projects: Evalua ti on perspec ti ve. Interna ti onal Journal of Ad ‐ vanced Computer Science and Applica ti ons, 9(1). Aloini, D., Dulmin, R., & Mininno, V . (2007). Risk manage ‐ ment in ERP project introduc ti on: Review of the liter ‐ ature. Informa ti on & Management, 44(6), 547 ‐567. EXTENDED SUMMARY/IZVLE ČEK Članek obravnava zbiranje, pripravo in razvoj uporabniških zahtev. Raziskava sloni na študiji primera kompleksnega ERP projekta v mednarodni korporaciji. Izhajamo iz dejstva, da razvoj posamezne ERP rešitve pogosto presega en sam projekt. Pogosto se razvoj ERP rešitev nadaljuje tudi po zaklju čku posameznega projekta. Osredoto čamo se na zahteve uporabnikov in njihovo kakovost predvsem iz vidika procesa inženiringa zahtev in iz vidika managementa sprememb. Razpravljamo o zna čilnos ti h adap ti vnih (e.g., agilnih) in predika ti vnih pristopov ter o vplivu teh na kakovost uporab ‐ niških zahtev. Poudarjamo, da je pomembno, da se člani ti ma zavedajo pomembnega vpliva, ki ga imajo dobro opredeljene uporabniške zahteve za uspeh projekta. Čeprav trdimo, da število zahtevkov za spremembe ne bi smeli pojmova ti kot kazalnik uspeha projekta, razpravljamo o dejavnikih, ki vpli ‐ vajo na število sprememb tekom projekta in na dodatno delo po zaklju čku projekta. Prepoznali smo dve strategiji s katerimi lahko vplivamo na preveliko število zahtevkov za spremembe in dodatna dela. Projektni ti m bi moral ve č pozornos ti posve titi pripravi visokokakovostnih uporabniških zahtev in predvsem izboljšanju formaliziranih procesov tes ti ranja in verifikacije rešitev. Obvladovanje spre ‐ memb, zlas ti sprememb uporabniških zahtev, je bistveno za uspeh projekta. Podjetja bi morala nenehno op ti mizira ti analize zahtev na podlagi izkušenj, pridobljenih iz prejšnjih projektov, in zago ‐ tovi ti , da se pretekla spoznanja uporabljajo v celotnem podjetju v nadaljnjih projek ti h. Dynamic Rela ti onships Management Journal, Vol. 13, No. 2, November 2024 87 Alqudah, M., & Razali, R. (2016). A review of scaling agile methods in large so ft ware development. Interna ‐ ti onal Journal on Advanced Science, Engineering and Informa ti on Technology, 6(6), 828 ‐837. Al ‐Saqqa, S., Sawalha, S., & AbdelNabi, H. (2020). Agile so ft ‐ ware development: Methodologies and trends. Interna ‐ ti onal Journal of Interac ti ve Mobile Technologies, 14(11). Andersson, C., & Runeson, P. (2007). A spiral process model for case studies on so ft ware quality monitor ‐ ing—method and metrics. So ft ware Process: Improve ‐ ment and Prac ti ce, 12(2), 125 ‐140. Atoum, I., Baklizi, M. K., Alsmadi, I., Otoom, A. A., Alhersh, T., Ababneh, J., Almalki, J., & Alshahrani, S. M. (2021). Challenges of so ft ware requirements quality assurance and valida ti on: A systema ti c literature review. IEEE Ac ‐ cess, 9, 137613 ‐137634. Baccarini, D. (1996). The concept of project complexity— a review. Interna ti onal Journal of Project Manage ‐ ment, 14(4), 201 ‐204. Behu ti ye, W., Rodríguez, P ., Oivo, M., Aaramaa, S., Parta ‐ nen, J., & Abhervé, A. (2022). Towards op ti mal quality requirement documenta ti on in agile so ft ware devel ‐ opment: A mul ti ple case study. Journal of Systems and So ft ware, 183, 111112. Behu ti ye, W., Seppänen, P., Rodríguez, P., & Oivo, M. (2020). Documenta ti on of quality requirements in agile so ft ware development. In Proceedings of the 24th Interna ti onal Conference on Evalua ti on and As ‐ sessment in So ft ware Engineering, 250 ‐259. Bick, S., Spohrer, K., Hoda, R., Scheerer, A., & Heinzl, A. (2017). Coordina ti on challenges in large ‐scale so ft ‐ ware development: A case study of planning misalign ‐ ment in hybrid se tti ngs. IEEE Transac ti ons on So ft ware Engineering, 44(10), 932 ‐950. Chemuturi, M. (2012). Requirements engineering and management for so ft ware development projects. Springer Science & Business Media. Copola Azenha, F., Aparecida Reis, D., & Leme Fleury, A. (2021). The role and characteris ti cs of hybrid ap ‐ proaches to project management in the development of technology ‐based products and services. Project Management Journal, 52(1), 90 ‐110. Dasovi ć, B., Gali ć, M., & Klanšek, U. (2020). A survey on integra ti on of op ti miza ti on and project management tools for sustainable construc ti on scheduling. Sustain ‐ ability, 12(8), 3405. Damian, D., & Zowghi, D. (2003). Requirements engineer ‐ ing challenges in mul ti‐ site so ft ware development or ‐ ganiza ti ons. Requirements Engineering Journal, 8(1), 149 ‐160. Davis, B. (2012). Agile prac ti ces for waterfall projects: Shi ft ing processes for compe titi ve advantage. J. Ross Publishing. Edison, H., Wang, X., & Conboy, K. (2022). Comparing methods for large ‐scale agile so ft ware development: A systema ti c literature review. IEEE Transac ti ons on So ft ware Engineering, 48(8), 2709 ‐2731. Falkowski, G., Pedigo, P ., Smith, B., & Swanson, D. (1998). A recipe for ERP success. Interna ti onal Journal of Human ‐Computer Interac ti on, 16(1), 5 ‐22. Fink, L., Fošner, A., Dobrovoljc, A., & Pozni č, T. (2024). How user requirements a ffect the success of an en ‐ terprise system implementa ti on project. European Project Management Journal, 14(1). Fink, L. (2017). Competence heterogeneity in teams and success of projects: The case of construction teams (Doctoral dissertation). Ljubljana: Faculty of Eco ‐ nomics. Gonzalez ‐Barahona, J. M., Sherwood, P., Robles, G., & Izquierdo, D. (2017). Technical lag in so ft ware compi ‐ la ti ons: Measuring how outdated a so ft ware deploy ‐ ment is. In Open Source Systems: Towards Robust Prac ti ces: 13th IFIP WG 2.13 Interna ti onal Confer ‐ ence, OSS 2017 Proceedings 13, Springer Interna ti onal Publishing, 182 ‐192. Griffith, J. A., Gibson, C., Medeiros, K., MacDougall, A., Hardy III, J., & Mumford, M. D. (2018). Are you think ‐ ing what I’m thinking? The influence of leader style, distance, and leader–follower mental model congru ‐ ence on crea ti ve performance. Journal of Leadership & Organiza ti onal Studies, 25(2), 153 ‐170. Guilleme tt e, M. G., Freche tt e, S., & Moïse, A. (2021). Comparing requirements analysis techniques in busi ‐ ness intelligence and transac ti onal contexts: A quali ‐ ta ti ve exploratory study. Interna ti onal Journal of Business Intelligence Research (IJBIR), 12(2), 1 ‐25. Harvard. (n.d.). Strategies for qualita ti ve interviews. Harvard University. h tt ps://sociology.fas.harvard.edu/files/sociol ogy/files/interview_strategies.pdf Hernaus, T ., Konforta, M., & Sitar, A. S. (2020). A mul ti‐ in ‐ formant assessment of organiza ti onal agility maturity: An exploratory case analysis. Dynamic Rela ti onships Management Journal, 9(2), 85 ‐104. INCOSE. (n.d.). Interna ti onal Council on Systems Engi ‐ neering (INCOSE). h tt p://www.incose.org/ Iivari, J., & Huisman, M. (2007). The rela ti onship be ‐ tween organiza ti onal culture and the deployment of systems development methodologies. MIS Quarterly, 31(1), 35 ‐58. IPMA. (2018). IPMA Reference Guide ICB4 in an Agile World. Interna ti onal Project Management Associa ti on. IPMA. (2016). Project Excellence Baseline for Achieving Excellence in Projects and Programmes. Interna ti onal Project Management Associa ti on. IREB. (n.d.). Interna ti onal Requirements Engineering Board (IREB). h tt p://ireb.org/ Dynamic Rela ti onships Management Journal, Vol. 13, No. 2, November 2024 Laura Fink, Ajda Fošner, Andrej Dobrovoljc, Tomaž Pozni č: Requirements Change Management: A Case Study of an Enterprise System Implementa ti on Project 88 ISO Standard. (2018). ISO/IEC/IEEE 29148:2018 Systems and So ft ware Engineering—Life Cycle Processes—Re ‐ quirements Engineering. h tt ps://www.iso.org/stan ‐ dard/72089.html Jarz ębowicz, A., & Weichbroth, P. (2021). A qualita ti ve study on non ‐func ti onal requirements in agile so ft ‐ ware development. IEEE Access, 9, 40458 ‐40475. Karhapää, P ., Behu ti ye, W ., Rodríguez, P ., Oivo, M., Costal, D., Franch, X., Aaramaa, S., Choras, M., Partanen, J., & Abherve, A. (2021). Strategies to manage quality re ‐ quirements in agile so ft ware development: A mul ti ple case study. Empirical So ft ware Engineering, 26(2), 28. Karlström, D., & Runeson, P . (2006). Integra ti ng agile so ft ‐ ware development into stage ‐gate product develop ‐ ment. Empirical So ft ware Engineering, 11, 203 ‐225. Karlstrom, D., & Runeson, P. (2005). Combining agile methods with stage ‐gate project management. IEEE So ft ware, 22(3), 43 ‐49. Köse, B. Ö. (2019). Recent agile requirement engineering prac ti ces in IT projects: A case analysis. Business & Management Studies: An Interna ti onal Journal, 7(4), 1776 ‐1805. Kralji ć, A., & Kralji ć, T. (2020). Agile so ft ware engineering prac ti ces in ERP implementa ti on. In Informa ti on Sys ‐ tems: Proceedings of the 16th European, Mediter ‐ ranean, and Middle Eastern Conference, EMCIS 2019, Springer Interna ti onal Publishing, 279 ‐290. Kralji ć, A., Kralji ć, T., Poels, G., & Devos, J. (2014). ERP im ‐ plementa ti on methodologies and frameworks: A liter ‐ ature review. In 8th European Conference on IS Management and Evalua ti on ECIME, Academic Con ‐ ferences and Publishing Interna ti onal Limited, 309 ‐316. Kronbichler, S. A., Ostermann, H., & Staudinger, R. (2009). A review of cri ti cal success factors for ERP ‐ projects. The Open Informa ti on Systems Journal, 3(1). Laplante, P. A., & Kassab, M. (2022). Requirements en ‐ gineering for software and systems. Auerbach Pub ‐ lications. L’ecuyer, A., & Ahmed, S. A. (2016). Controlling change on agile so ft ware development projects. Universal Journal of Management, 4(1), 42 ‐49. Lunesu, M. I., Tonelli, R., Marchesi, L., & Marchesi, M. (2021). Assessing the risk of so ft ware development in agile methodologies using simula ti on. IEEE Access, 9, 134240 ‐134258. Lutovac, M., & Manojlov, D. (2012). The successful methodology for enterprise resource planning (ERP) implementa ti on. Journal of Modern Accoun ti ng and Audi ti ng, 8(12), 1838. Markus, M. L., Axline, S., Petrie, D., & Tanis, S. C. (2000). Learning from adopters’ experiences with ERP: Prob ‐ lems encountered and success achieved. Journal of Informa ti on Technology, 15(4), 245 ‐265. Matende, S., & Ogao, P . (2013). Enterprise resource plan ‐ ning (ERP) system implementa ti on: A case for user parti cipa ti on. Procedia Technology, 9, 518 ‐526. McGraw, K. L., & Harbison, K. (2020). User ‐centered re ‐ quirements: The scenario ‐based engineering process. Taylor and Francis. Miri ć, A. A., Černe, M., & Hernaus, T. (2020). Managing knowledge in organiza ti ons: On knowledge crea ti on, renewal, hiding and forge tti ng. Dynamic Rela ti onships Management Journal, 9(1), 1 ‐3. Mockus, A., Weiss, D. M., & Zhang, P . (2003). Understand ‐ ing and predic ti ng e ffort in so ft ware projects. In Pro ‐ ceedings of the 25th Interna ti onal Conference on So ft ware Engineering, IEEE, 274 ‐284. Nagpal, S., Khatri, S. K., & Kumar, A. (2015). Compara ti ve study of ERP implementa ti on strategies. In IEEE Long Island Systems, Applica ti ons and Technology, 1 ‐9. Nuseibeh, B., Kramer, J., & Finkelstein, A. (1994). A frame ‐ work for expressing the rela ti onships between mul ti ple views in requirements specifica ti on. IEEE Transac ti ons on So ft ware Engineering, 20(10), 760 ‐773. O’Brien, B. C., Harris, I. B., Beckman, T. J., Reed, D. A., & Cook, D. A. (2014). Standards for repor ti ng qualita ti ve research: A synthesis of recommenda ti ons. Academic Medicine, 89(9), 1245 ‐1251. PMI. (2021). The Standard for Project Management and a Guide to the Project Management Body of Knowledge (PMBOK Guide) (7th ed.). Project Management Ins ti tute. PMI. (2017). Agile Prac ti ce Guide. Project Management Ins ti tute. Rahy, S., & Bass, J. M. (2022). Managing non ‐func ti onal requirements in agile so ft ware development. IET So ft ‐ ware, 16(1), 60 ‐72. Ramesh, B., Cao, L., & Baskerville, R. (2010). Agile require ‐ ments engineering prac ti ces and challenges: An em ‐ pirical study. Informa ti on Systems Journal, 20(5), 449 ‐480. Rasheed, A., Zafar , B., Shehryar , T ., Aslam, N. A., Sajid, M., Ali, N., Hanif Dar, S., & Khalid, S. (2021). Requirement engi ‐ neering challenges in agile so ft ware development. Math ‐ ema ti cal Problems in Engineering, 2021, 1 ‐18. Regnell, B., Höst, M., Na tt och Dag, J. N., Beremark, P ., & Hjelm, T. (2001). An industrial case study on dis ‐ tributed priori ti sa ti on in market ‐driven requirements engineering for packaged so ft ware. Requirements En ‐ gineering, 6(1), 51 ‐62. ReqView. (n.d.). ISO/IEC/IEEE 29148 Requirements Speci ‐ fica ti on Templates. h tt ps://www.reqview.com/doc/iso ‐ iec ‐ieee ‐29148 ‐templates/ RESG. (n.d.). Requirements Engineering Specialist Group (RESG). h tt ps://www.bcs.org/membership ‐and ‐regis ‐ tra ti ons/member ‐communi ti es/requirements ‐engi ‐ neering ‐specialist ‐group/ Dynamic Rela ti onships Management Journal, Vol. 13, No. 2, November 2024 89 Robertson, S., & Robertson, J. (2012). Mastering the re ‐ quirements process: Ge tti ng requirements right. Ad ‐ dison ‐Wesley. Robson, C. (2002). Real world research. Oxford: Blackwell Publishers. Royce, W. (2011). Measuring agility and architectural in ‐ tegrity. Interna ti onal Journal of So ft ware Informa ti cs, 5(3), 415 ‐433. Royce, W. (2009). Improving so ft ware economics. IBM Corpora ti on So ft ware Group, 1 ‐40. Royce, W . W . (1987). Managing the development of large so ft ware systems: Concepts and techniques. In Pro ‐ ceedings of the 9th Interna ti onal Conference on So ft ‐ ware Engineering, 328 ‐338. Runeson, P ., & Höst, M. (2009). Guidelines for conduc ti ng and repor ti ng case study research in so ft ware engineer ‐ ing. Empirical So ft ware Engineering, 14(2), 131 ‐164. San Cristóbal, J. R., Carral, L., Diaz, E., Fraguela, J. A., & Iglesias, G. (2018). Complexity and project manage ‐ ment: A general overview. Complexity, 2018, 10p. Sawyer, P., Sommerville, I., & Viller, S. (1997). Require ‐ ments process improvement through the phased in ‐ troduc ti on of good prac ti ce. So ft ware Process: Improvement and Prac ti ce, 3(1), 19 ‐34. Scherer, F. M. (2000). The pharmaceutical industry. In Handbook of Health Economics (Vol. 1, pp. 1297 ‐1336). Schwaber, K. (1997). Scrum development process. In Business Object Design and Implementa ti on: OOP ‐ SLA’95 Workshop Proceedings 16 October 1995, Aus ti n, Texas, Springer London, 117 ‐134. Shanks, G. (2000). A model of ERP project implementa ‐ ti on. Journal of Informa ti on Technology, 15(4), 289 ‐303. Sommerville, I. (2005). Integrated requirements engi ‐ neering: A tutorial. IEEE So ft ware, 22(1), 16 ‐23. Sommerville, I. (2009). So ft ware engineering (9th ed.). Addison ‐Wesley. Stacey, R. D., Gri ffin, D., & Shaw, P . (2000). Complexity and management: Fad or radical challenge to systems thinking?Psychology Press. Sudhakar, G. P . (2012). A model of cri ti cal success factors for so ft ware projects. Journal of Enterprise Informa ‐ ti on Management, 25(6), 537 ‐558. Takeuchi, H., & Nonaka, I. (1986). The new new product development game. Harvard Business Review, 64(1), 137 ‐146. Theunissen, T., van Heesch, U., & Avgeriou, P. (2022). A mapping study on documenta ti on in con ti nuous so ft ‐ ware development. Informa ti on and So ft ware Tech ‐ nology, 142, 106733. Tukel, O. I., & Rom, W. O. (1998). Analysis of the charac ‐ teris ti cs of projects in diverse industries. Journal of Opera ti ons Management, 16(1), 43 ‐61. Wysocki, W. (2023). Macrosimula ti on model of so ft ware development process. Procedia Computer Science, 225, 746 ‐755. Wysocki, W. (2020). A hybrid so ft ware processes man ‐ agement support model. Procedia Computer Science, 176, 2312 ‐2321. Wysocki, R. K. (2014). E ffec ti ve complex project manage ‐ ment: An adap ti ve agile framework for delivering business value. J. Ross Publishing. Wysocki, R. K. (2019). E ffec ti ve project management: Tra ‐ di ti onal, agile, extreme, hybrid (8th ed.). John Wiley & Sons. Wysocki, R. K. (2011). E ffec ti ve project management: Tra ‐ di ti onal, agile, extreme (6th ed.). John Wiley & Sons. Zainal, P ., Razali, D., & Mansor, Z. (2020). Team forma ti on for agile so ft ware development: A review. Interna ‐ ti onal Journal of Advanced Science, Engineering and Informa ti on Technology, 10(2), 555 ‐561. Zhang, Z., & Sharifi, H. (2000). A methodology for achiev ‐ ing agility in manufacturing organisa ti ons. Interna ‐ ti onal Journal of Opera ti ons & Produc ti on Management, 20(4), 496 ‐512. Žužek, T ., Kušar, J., Rihar, L., & Berlec, T . (2020). Agile ‐con ‐ current hybrid: A framework for concurrent product development using Scrum. Concurrent Engineering, 28(4), 255 ‐264.