Enterprise Systems implementation projects: waterfall, agile or hybrid?

Association for Information Systems AIS Electronic Library (AISeL) AMCIS 2024 Proceedings Americas Conference on Information Systems (AMCIS) August 2024 Enterprise Systems implementation projects: waterfall, agile or hybrid? Przemyslaw Lech University of Gdańsk, przemyslaw.lech@ug.edu.pl Follow this and additional works at: https://aisel.aisnet.org/amcis2024 Recommended Citation Lech, Przemyslaw, "Enterprise Systems implementation projects: waterfall, agile or hybrid?" (2024). AMCIS 2024 Proceedings. 3. https://aisel.aisnet.org/amcis2024/it_pm/it_pm/3 This material is brought to you by the Americas Conference on Information Systems (AMCIS) at AIS Electronic Library (AISeL). It has been accepted for inclusion in AMCIS 2024 Proceedings by an authorized administrator of AIS Electronic Library (AISeL). For more information, please contact elibrary@aisnet.org. Enterprise System implementation projects… Enterprise Systems implementation projects: waterfall, agile or hybrid? Completed Research Full Paper Przemysław Lech University of Gdańsk, Faculty of Management przemyslaw.lech@ug.edu.pl Abstract This research investigated the predominant approach adopted during Enterprise System implementations: waterfall, agile, or hybrid. The study focused on SAP system implementations and comprised two main components. The initial phase involved analyzing the ASAP waterfall methodology and Activate agile methodology to assess their adherence to the waterfall and agile paradigms, respectively. The second phase consisted of a case study examining two implementation projects, aiming to uncover the practical methodologies employed by consultants in project completion. The conclusion is that Enterprise System projects tend to embrace a hybrid approach, closely resembling water-scrum-fall. This involves establishing a fixed scope, implementing rigorous project planning, adopting an agile approach during the realization phase, and deploying a waterfall methodology for the final system deployment. Keywords Enterprise Resource Planning, ERP, Project Management, hybrid project management methodology, Introduction “Enterprise Systems (ES) are standard, integrated, configurable, and customizable, organization-wide, multi-component Information Systems covering major business processes and management functions of an enterprise. They constitute a primary and predominant source of information for the organization and consist of transactional and analytical applications, including Enterprise Resource Planning (ERP), Supply Chain Management (SCM), Business Intelligence/Business Analytics and others” (Lech, Samól and Shygun, 2023). Formerly, not without reason, Enterprise Systems were equated to Enterprise Resource Planning (ERP) systems. However, nowadays, top Enterprise Systems significantly exceed the functionality of an ERP. As the functionality of Enterprise Systems covers most business processes and management functions of a company, implementing such a system is also a company-wide, complex and risky undertaking. First, it requires careful analysis and modelling of all business processes involved and specification of non-process-related requirements (Lech, 2013). Then, the concept of the solution, determining how these processes and requirements will be reflected in the system, must be developed. As an ES is a standard system, it offers a limited number of possible scenarios of running a given process, available by setting the system parameters (i.e. via configuration) (Lech, 2016). If a business process does not fit any of these scenarios, the company must either perform an organizational change to fit into the system standard or customize the system by adding/replacing the code. The former may not be possible due to the restrictions of the configuration of physical hardware/machinery or because a business process is part of a company’s competitive advantage. The latter increases the total cost of ownership of the system and the complexity and risk during future upgrades. In any case, the solutions for all the business processes must be harmonized. The system must be configured and customized accordingly, tested, filled with master data and opening balances, and started productively. All the above forms a massive, company-wide project that typically takes no less than a year. This type of project requires collaboration between two fundamental groups: business people and ES consultants (Lech, 2016). Consultants may be Thirtieth Americas Conference on Information Systems, Salt Lake City, 2024 1 Enterprise System implementation projects… hired internally or (in most cases) may come from a specialized consulting company. These two distinct groups of people, supported by many others such as project managers, project sponsors, programmers, and future key users, must exchange knowledge and work together towards the project goal. Business people must define the business processes to be covered by the system, formulate non-process-related requirements, verify and approve the solutions for all the requirements in the system once they are designed, test the system after it is configured and then use it. Consultants must combine the company knowledge they acquired in the initial phases of the project with their system knowledge to design, configure, customize, test and run the system in a given company. The project requires a contract (internal or external) between the business and consultants, specifying the scope of work, budget and duration, and must be performed according to the approved methodology. Historically, ES projects were performed according to waterfall project methodologies, i.e. the scope was determined at the beginning of (or before) the project. The project was planned in detail and later executed according to this plan. Waterfall implementations of Enterprise Systems faced similar (albeit not exactly the same) problems as software development projects: due to the long time before the moment requirements were defined and the moment the users saw them working, and high VUCA (volatility, uncertainty, complexity and ambiguity) of the requirements there was a great chance that the project will deliver something nobody wants (Al-Ahmad et al., 2009; Nelson, 2007; Yeo, 2002). In software development projects, the supposed remedy for the above problems was the introduction of agile methodologies (Vallon et al., 2018; Hoda et al., 2017). There is a growing trend in Enterprise Systems implementations to align with the agile paradigm, at least at the level of declared methodologies. However, the existing literature on agile Enterprise Systems or ERP implementations is not extensive. This research aims to investigate the phenomenon of ES implementation by examining the current practices of consultants in the field and comparing them with the declarative statements from the methodologies employed. The study will focus on investigating SAP systems implementation cases. Enterprise Systems implementation methodologies – literature review Traditionally, Enterprise Systems (ERP systems by then) were implemented using waterfall methodologies, in which project phases followed each other sequentially. Three historical examples of an approach to ES implementation available in the literature are Esteves et al. (2003), Ahutiv et al. (2002) and Bajwa et al. (2004). The methodology presented by Esteves et al. (2003) strictly follows the waterfall sequence, and the names of the phases match SAP’s ASAP legacy methodology: the initial definition of scope and the project plan are prepared in the Project Preparation Phase. The scope is then detailed by documenting the organizational structure and business processes, which results in the adjustment of the initial scope definition. What is missing is the solution design, which also takes place in the Blueprint phase of the project (Lech, 2013). After the business processes are documented and their representation in the system is designed, the system configuration and customization are performed. As a result, the organizational structure and business processes are reflected in the system during the Realization phase. In the subsequent phase, the system is tested against the design, end users are trained, and the system is prepared for go-live. Go-live and subsequent support of the system during the initial period of productive usage terminates the project. This approach may take as long as seven months, from the initial definition of the project scope in Project Preparation to the users’ first interaction with the solution during testing (Lech, 2016). Precisely, this very fact lies at the foundation of the critics of waterfall methodologies in software development: the period between the analysis and design of the solution and the first interaction with the working system is so long that the requirements would have been likely to change in the meantime, and the users may even have forgotten what exactly they required, and why. On the other hand, such an approach provides a clear framework for contractual relations between the implementing company and the consultants. The scope is defined at the beginning of the project so it can be included in the contract. It is then refined during the Blueprinting phase so the contract can be amended if needed. This way, the scope is clearly defined before the Realization phase, and the testing can be done against the formally approved scope. In Ahutiv et al. (2002) and Bajwa et al. (2004), the initial definition of the scope is followed by prototyping/initial implementation of the system in the first phase of the project (named Design and Thirtieth Americas Conference on Information Systems, Salt Lake City, 2024 2 Enterprise System implementation projects… Preparation, respectively). Instead of detailed documentation of the organizational structure, business processes, and requirements, there is a fit-gap analysis against that prototype. If the current organizational structure and business processes do not fit the prototype (gap is identified), the first step is to adjust the processes to the system (business process reengineering) rather than the opposite. Another prototype is built afterwards. After the prototype is approved (this step, although not explicitly mentioned, is logically inferred to be in place), full implementation of the system is performed, followed by an acceptance test, cut-over activities, go-live, and operation. The first difference between the above two methodologies concerns the approach towards the business processes and requirements. Esteves et al. (2003) follow the “business first” approach, in which the system is tailored to the company’s existing business processes and information requirements. If the standard does not meet the requirements, customization of the system via programming is applied to reflect the business processes and requirements as closely as possible. Ahutiv et al. (2002) and Bajwa et al. (2004) use the “stick to standard” approach in which the business processes should be adjusted to the system. ERP software vendors have long advocated the “stick to standard” approach, with the SAP Clean Core approach being one of the latest examples (Introducing the Clean Core Approach, 2023). However, companies must preserve business processes that differentiate them from the competition, even if they do not fit the system standard. Therefore, companies that adopt the “stick to standard” approach would not avoid some system customization. The second prototype and final implementation in Ahutiv et al. (2002) and Bajwa et al. (2004) address that point. The second difference between the two methodologies is more interesting for the sake of this paper. The methodology presented by Esteves et al. (2003) is strictly waterfall, but what Ahutiv et al. (2002) and Bajwa et al. (2004) present in their papers resembles agile to some extent, although it is very unlikely that the methodology was influenced by the Agile Manifesto (2001), as it was presented not long before. Still, there is an incremental build of functionality, starting from the first prototype based on a general scope description. The evaluation of the fit of this prototype to the company’s needs occurs during the gap analysis, followed by the refinement of the system during the second prototype build and ultimately concluding with the final configuration. While there are no two-week sprints, longer-period increments are still evident. ERP system vendors, as well as independent consultancies, were also offering implementation methodologies. A presentation of waterfall methodologies from SAP, Oracle and Microsoft is presented in Nagpal et al. (2015). Although differing in naming and number of phases, they all follow the waterfall sequence: initial scope definition and plan, analysis and detailed definition of business organization, processes and requirements, solution design, configuration and development, go-live preparation, go-live and support. Once agile has gained traction in software development, ES (or, more narrowly, ERP) vendors and consultancies also shifted their methodologies in this direction. Before jumping into agile ES/ERP implementation methodologies, it makes sense to define what agile actually is. Unlike waterfall approaches, where the scope is planned in detail and fixed before project delivery begins, agile methods fix time and resources, while the scope is only estimated and subject to change during the project if such a change is necessary to deliver value to the project customer (AgilePM, 2014, p.17; Aljaber, 2023). The most popular way of estimating scope is through the product backlog. An agile team is small (up to ten people), cross-functional (including all individuals necessary to deliver the outcome), and self-organizing. The delivery is executed in fixed timeboxes (sprints), lasting one to four weeks. The number of timeboxes, and therefore the project duration, is fixed. Items to be developed during a given timebox are selected by the project team from the product backlog and must be finalized during that time box. Each timebox comprises the entire development life cycle, including a detailed analysis of requirements, design, development, testing, sign-off, release to production (optional in some frameworks), and concludes with the delivery of a working functionality (Schwaber and Sutherland, 2020; DSDM, 2014). Madanian et al. (2021) performed a literature review regarding agile ERP implementation critical success factors. However, they did not outline what the agile ERP implementation process looks like. With negative results, Gren et al. (2018) investigated whether ERP project decision-makers could identify apriori which approach, waterfall or agile, was optimal for their project. Kraljić and Kraljić (2019) presented the SAP Activate agile methodology, although not in line with the SAP description of this method. They introduced Business Blueprint as a result of the Explore phase, “which is a detailed flow of Thirtieth Americas Conference on Information Systems, Salt Lake City, 2024 3 Enterprise System implementation projects… business process AS-IS, how they run the business operations with a to-be mapped in SAP, on how these business operations will run in SAP”. Business Blueprint was a key product of SAP ASAP waterfall methodology, while SAP Activate is based on the pre-defined system, configured based on the so-called best practices, followed by fit-to-standard presentations, resulting in a fit-gap-to-standard document (Musil, 2017). Kraljić and Kraljić (2019) also presented valid objections of SAP project participants regarding the direct implementation of agile terms and methods to ERP implementation projects, such as the need for functional division of work due to people’s expertise which conflicts with cross-functional agile team composition, ambiguity of agile terminology and problems with lack of team structure. Baig et al. (2017) investigated a small sample of ERP professionals to find out that, in their opinions, selected agile practices may contribute to the ERP system implementation success. They also pointed out that choosing the appropriate agile practices and incorporating them into the implementation process is tricky. In summary, research literature regarding agile ERP/ES implementation is far from comprehensive and does not explain how agile principles are incorporated into agile ERP implementation frameworks. In addition to the waterfall and agile methodologies, general software/Information Systems development literature also recognizes the existence of hybrid project management methodologies (Kuhrmann et al., 2017; Gemino et al., 2021). Hybrid methodologies amalgamate components from both waterfall and agile approaches. While the specific blend of waterfall and agile practices may vary, hybrid methods generally adhere to the water-scrum-fall model (West, 2011). This model dictates that the initial and final phases of the project are managed using the waterfall approach, while the agile approach is applied during the execution phase. The project commences with requirements analysis, scheduling, and budget estimation. Once the scope, schedule, and budget are planned, agile team(s) are formed and adopt the agile approach during execution. They operate within fixed timeboxes (sprints), during which they select items from the product backlog, analyze them in detail, design, develop, test, and deliver increments of the solution. The deployment to production, encompassing final testing, regression testing with existing functionality, release to production, and hypercare, is executed using the waterfall approach again. Most of the existing research on hybrid methodologies focuses on system development projects, while there is limited examination of the use of these methods during implementations of standard software packages. The search in EBSCO, Science Direct, and Google Scholar for publications regarding the use of hybrid project management methodologies in ERP/ES implementation provided very few results. Most of the publications used the term ‘hybrid’ to describe either the approach to the ERP selection process or mixed cloud/on-premise deployment options. The exceptions are two theses (Anton and Goedhard, 2016; Bidgood and Gaim, 2017), which acknowledge the actual usage of hybrid methods in ES/ERP implementations. The scarcity of research regarding the use of hybrid methodologies in ES/ERP implementation projects is acknowledged by Topi and Spurrier (2019), who state that “there is relative lack of focus on projects where utilizing and integrating packaged software and components is a central issue”. This research aims to fill the research gap regarding the actuality of ES/ERP implementation methodologies by examining the particular practices during the ES implementations to determine whether the approach is waterfall, agile, or hybrid. Research design and methods Research questions The following detailed research questions were posed in this study: RQ1: What practices are prescribed by SAP waterfall and agile methodologies during ES implementation? RQ2: What practices are performed during SAP waterfall and agile-based implementation? The responses to RQ1 and RQ2 should enable the answer to the following general question: RQ3: Does an ES implementation follow waterfall, agile or hybrid methodology? Methods Thirtieth Americas Conference on Information Systems, Salt Lake City, 2024 4 Enterprise System implementation projects… This research followed the qualitative, deductive-inductive paradigm. The deductive part aimed to answer RQ1 with the use of analysis of descriptions of two SAP-based project management methodologies: ASAP waterfall methodology and Activate agile methodology. The research method employed was document analysis. The descriptions were evaluated against criteria derived from existing literature on waterfall and agile approaches. The inductive part aimed to address RQ2 by identifying specific practices used in two SAP system implementations: one following the waterfall approach and the other adopting agile methodology. The research method employed was a multiple case study. The two cases were selected based on theoretical replication logic, wherein contrasting results were anticipated due to identifiable reasons (Yin, 2009). Data-gathering methods included the analysis of project documentation and unstructured interviews with consultants involved in the projects. During these interviews, consultants were asked about their actions and practices during each project phase. Research results Analysis of project management methodologies The first step in the research was to analyze the conformance of SAP methodologies: ASAP and Activate with the waterfall and agile paradigms, respectively. As ASAP is a legacy methodology with a limited number of currently available public sources, the analysis was based on archival SAP blog entries (Jain, 2013) and two Project Charter documents from past SAP implementation projects. SAP Activate methodology was analyzed based on the SAP Roadmap Viewer (2023) – an SAP tool designed to facilitate SAP implementations based on Activate methodology. The below description of methodologies answers the RQ1: What practices are prescribed by SAP waterfall and agile methodologies during ES implementation? SAP ASAP methodology Description The ASAP methodology comprises five phases: Project Preparation, Business Blueprint, Realization, Final Preparation, and Go-live and Support. The Project Preparation phase aims to define the project in terms of scope, schedule, and budget. It involves establishing project governance, including structure, roles, responsibility distribution, definition of project products, documentation formats, and procedures. The project team is appointed during the Project Preparation Phase. The outcome of this phase is the Project Charter document, which encompasses all the aforementioned elements. Additionally, a project kick-off meeting is held during this phase, marking the official commencement of the project and familiarizing the team with the Project Charter contents. Project Preparation phase may also include initial training of the client personnel with the use of a standard demo system (which may vary significantly from the target system resulting from the project). The project then progresses to the Business Blueprint phase, commencing with a series of workshops. In these workshops, client company process owners, along with key experts and system consultants, meticulously outline the business processes and non-process-related requirements. The consultants document these processes and requirements, enhancing them with a highlevel design that specifies how they will be implemented in the system. The comprehensive document, encompassing maps and descriptions of business processes, non-process requirements, and the high-level design of the system’s organizational structure, configuration, and potential extensions, is referred to as the Business Blueprint. It serves as a detailed scope definition for the project and forms the basis for future system configuration and customization. The Business Blueprint undergoes formal sign-off by the client. Following formal approval of the Business Blueprint, the project transitions to the Realization phase. During this phase, consultants configure and, when necessary, customize (enhance through programming) the system to align with the Blueprint. They also conduct unit tests to validate their solutions. Next comes integration testing and user acceptance testing (UAT) involving client process owners and future key users, either independently or collaboratively. This provides the client’s representatives with their first glimpse of the operational system. Upon successful test completion, the Final Preparation phase commences. This phase encompasses developing the cut-over plan, preparing the Thirtieth Americas Conference on Information Systems, Salt Lake City, 2024 5 Enterprise System implementation projects… production system, executing data migration, and delivering end-user training. Go-live marks the system’s transition to productive operation, with consultants providing initial support during this period. Evaluation The ASAP methodology closely adheres to the waterfall paradigm, with phases progressing sequentially. Subsequent phases only begin after formal sign-off by project stakeholders on the deliverables of the previous phase. The client’s process owners and future key users actually have their requirements visualized in the system only at the end of the Realization phase, during integration and user acceptance testing. SAP Activate methodology Description It is worth mentioning that SAP offers 18 variants of SAP Activate methodology, depending on whether the project is greenfield implementation or transition from older SAP systems, a specific solution to be implemented, and a deployment option (cloud or on-premise). The analysis of the two general variants, i.e. cloud and on-premise, will be presented here. The SAP Activate methodology comprises six phases: Discover, Prepare, Explore, Realize, Deploy, and Run. In both variants, the Discover phase culminates in a high-level business case for implementing SAP. During the Prepare phase, a comprehensive project plan is established, encompassing scope, schedule, budget, and governance procedures. For on-premise deployments, a scope document with a business process map is created and signed off by the customer. In the cloud version, the scope document leverages pre-delivered cloud system content. Additionally, a demo system showcasing pre-configured best practices is set up. Both variants initiate the Explore phase with fit-to-standard workshops. During these sessions, consultants walk the client through pre-configured business processes (delivered during system installation) known as best practices. The client assesses whether each process meets their requirements (“fit”) or not (“gap”). Gaps are identified and documented as backlog items. The key difference between cloud and on-premise versions emerges in subsequent activities. Public cloud deployments offer a pre-defined system configuration with limited customization options. It’s essentially a “take-it-or-leave-it” approach. Consequently, the baseline configuration is delivered during installation, resulting in fewer gaps entered into the product backlog for further setup. On-premise deployments permit extensive system configuration and modification through programming extensions. This might lead to a larger number of gaps with potentially wider-reaching modification requirements. As a result, all backlog items undergo detailed design and client sign-off before progressing to baseline configuration, where the system’s core functions are set up. Both the baseline configuration and gap design documents require client approval. The final configuration of the system is performed in sprints during the Realize phase. Each sprint adheres to the agile approach. During sprint planning, features from the product backlog are chosen for delivery in the current sprint. Throughout sprint execution, features are either configured (for standard configuration) or programmed (for extensions). The sprint concludes with unit tests and end-to-end tests of a process undergoing implementation. Once the system is configured and customized, integration tests and user acceptance tests are performed for the whole solution. Test sign-off terminates the Realize phase. During the Deploy phase, the end-users are trained and cut-over activities are planned and performed. Go-live of the system is the final deliverable of this phase. After go-live, the system is supported, and possible malfunctions are corrected in the Run phase. Evaluation The Activate methodology does not strictly adhere to the agile paradigm. Firstly, the project is comprehensively planned upfront, encompassing scope, schedule, and budget. Unlike agile, which primarily plans schedule and budget, Activate maintains a fixed scope throughout the project. Additionally, the baseline configuration is delivered in a ‘one-shot’ manner. Changes and enhancements to the standard configuration are designed and approved before implementation. Only after this approval process are the final configuration and customization carried out using an agile approach. Integration testing and user acceptance testing, on the other hand, are conducted in a waterfall mode. It’s essential to note that all versions of the Activate methodology heavily rely on the early presentation of a working system configured according to ‘best practices.’ This forms the basis for analyzing fits and gaps against Thirtieth Americas Conference on Information Systems, Salt Lake City, 2024 6 Enterprise System implementation projects… this exemplary configuration. This is in contrast to the ‘vanilla’ implementation approach of the ASAP methodology, where business processes and requirements were initially gathered, and the configuration was designed and implemented from scratch. The Activate methodology bears a strong resemblance to the water-scrum-fall hybrid methodology. Like in water-scrum-fall, Activate incorporates the waterfall approach in both the initial and final phases of the project, with the agile approach applied during the execution phase. Project planning is conducted in the waterfall mode, while the realization takes place in agile sprints. However, integration testing, user acceptance testing, release to production, and hypercare revert to the waterfall approach. Analysis of consultants’ practices in real-life projects – a case study The case study involved two projects involving SAP Extended Warehouse Management (EWM) implementations. Project A was executed according to the waterfall methodology based on ASAP, while Project B followed the agile methodology based on Activate, as per declaration in the project documentation. Both projects resulted in the successful implementation of the solutions. The case study answers RQ2: What practices are performed during SAP waterfall and agile-based implementation? In both cases, the projects were preceded by the request for quotation, offering, partner selection, contract negotiation and contract signing. Therefore, in both projects, the high-level scope was determined prior to the project in the requests for quotation. The final assessment of contract completion was done against the requirements from the request for quotation. Observation 1: In neither project did the scope remain undefined. The level of detail of scope definition was comparable in the ‘waterfall’ and ‘agile’ projects. During the Preparation phase in both projects, a Project Charter was created, which included a detailed schedule, project structure, roles and responsibilities, project governance procedures and document templates. Project managers managed both projects, and the implementation teams were formed around functional areas. Implementation teams were interdisciplinary in that they consisted of business process owners, key users, consultants and programmers of a given functional area. As project B was part of a bigger program involving the implementation of SAP S/4HANA, it could be observed that implementation teams were functional, i.e. there was a separate team for Financials, Purchasing, Sales, etc. The teams were not fully self-manageable, as they needed to obey general guidance from project managers. The level of detail of scope definition remained as in the contracts. Observation 2: Both projects followed the waterfall approach to project planning. The organizational structure was the same in both projects and reflected the traditional SAP approach used in waterfall projects. The projects entered a Business Blueprint and Explore phase, respectively. According to the documentation of Project A, the result of the Business Blueprint phase was a Blueprint document containing the design of the organizational structure in the future system, maps and descriptions of the business processes, the design of the business processes in the future system, determination and short specification of programming extensions (WRICEF – Workflows, Reports, Interfaces, Conversions, Extensions and Forms). According to the documentation of Project B, the result of the Explore phase was a backlog including the definition of the organizational structure in the system, the definition of business processes and their reflection in the system, the definition of non-process requirements and their reflection in the system, identification of enhancements, list of integration items. Observation 3: The content of the Business Blueprint in Project A is identical to the content of the backlog in Project B. The distinction lies in that the Business Blueprint comprised a single document, whereas the backlog entries were documented separately for each item. Regarding the methods employed during the analysis, the methodology of Project A involved classroom workshops, while the methodology of Project B based its workshops on the presentation of ‘best practices’ configuration and fit-gap analysis. However, the actual practices deviated from the prescribed methodology in both cases. Thirtieth Americas Conference on Information Systems, Salt Lake City, 2024 7 Enterprise System implementation projects… After the agreement on the organizational structure and master data, both teams worked process by process in the following way: 1. The process was described by the client and initially documented by the consultants. 2. Based on this general description of the process, consultants prepared a prototype of the system configuration on the sandbox system. 3. A walk-through session of the process in the system was performed for the client. If necessary, changes and amendments were made to the configuration based on the client’s remarks. 4. The configuration of the process was approved, and the process description document was created. This way, both teams had a baseline prototype ready by the end of the Business Blueprint/Explore phase. Observation 4: Regardless of the declared methodology, the implementation teams in both projects followed the agile-like approach, working in timeboxed increments, which resulted in a sign-off of a working functionality. In the Realization phase of Project A, the final configuration and customization of the system was performed. Unit testing was done by the consultants. Integration testing and user acceptance testing was done with the process owners and key users. The result was the system ready for cut-over and go-life. The Realize phase of the Project B took the form of the formal sprints. The functionality was divided between the sprints, final configuration and customization of a given part of the system was performed, unit tested and signed off. Once all the sprints were over, integration testing and user acceptance testing were performed for the whole solution, which resulted in the system ready for cut-over and go-life. Observation 5: The only significant difference between the practices in Project A and B was that in the realization phase of Project A, all the remaining configuration and customization were done in one shot, while in Project B, they were done in sprints. However, as the basic configuration in both projects was done iteratively during the Blueprint/Explore phase, this difference had little influence on the overall project performance. Afterwards, both projects went into go-live preparation and go-live, which did not differ in any aspect and was done for the whole solution, i.e. in a waterfall manner. Summary and discussion An analysis of the SAP ASAP and Activate methodologies’ descriptions led to the conclusion that ASAP follows the waterfall approach, whereas Activate is closer to a hybrid water-scrum-fall than pure agile. Project planning and preparation adhere to the waterfall model. Unlike agile methodologies, the scope is defined and fixed, with further detailing and sign-off occurring during the Explore phase. The agile approach, involving sprints, is introduced in the Realize phase, while subsequent phases revert to a waterfall approach. An examination of actual practices during two SAP implementation projects revealed a convergence towards a hybrid approach. Despite one project theoretically following a waterfall paradigm and the second an agile one, both projects tended to steer towards a hybrid methodology in reality. Consequently, the answer to Research Question 3 (RQ3): “Does an ES implementation follow a waterfall, agile, or hybrid methodology?” is that ES projects naturally gravitate towards a hybrid approach. The scope is fixed, potentially even before the project commencement, during the tendering and contracting process. Project preparation and planning, involving scope definition, detailed schedule preparation, and establishing project structures and governance, are carried out in a waterfall mode. Unlike agile, project management is present and holds authority. The agile approach manifests during the execution phase, relying on presentations of prototypes to enhance the client’s understanding of future solutions. The terminal phases of the project, such as cut-over and go-live, are again executed in a waterfall mode. Similar conclusions were drawn by Kuhrmann et al. (2017) regarding software development projects. This study extends those findings to Enterprise System projects based on standard package configurations. The main practical implication is that using an iterative, prototype-based approach during the project Thirtieth Americas Conference on Information Systems, Salt Lake City, 2024 8 Enterprise System implementation projects… execution phase is optimal for Enterprise System implementation projects. This approach accelerates acceptance by business users, reduces ambiguity, and diminishes the risk of solution rejection. Conclusion This research aimed to investigate the predominant paradigm followed by Enterprise System (specifically SAP) implementation projects: agile, waterfall, or hybrid. The initial finding indicates that although the SAP Activate methodology is marketed as agile, it essentially leans towards a hybrid model, resembling water-scrum-fall. This aligns logically with the nature of large-scale digital transformation projects, where defining the scope upfront is crucial. Given the project’s complexity and numerous interdependencies, detailed planning of activities and resources becomes imperative. However, the traditional analysis-design-execution sequence in a waterfall mode has proven suboptimal in past implementations. The shift towards an agile-like approach, featuring early presentations of partial solutions through prototypes, followed by feedback loops, fine-tuning, and sign-offs within set timeboxes, enhances the client’s understanding and engagement. Yet, certain activities such as integration testing, user acceptance testing, cut-over, and go-live cannot be compartmentalized for separate parts of the system. The architectural constraints of an Enterprise System necessitate a waterfall approach in these instances. The convergence towards a hybrid approach was evident in a case where a waterfall-based implementation project saw consultants adopting a hybrid approach nonetheless. In conclusion, for Enterprise System Implementation, a hybrid approach emerges as the most suitable and effective methodology. REFERENCES Agile Manifesto. 2001. Retrieved from: https://agilemanifesto.org/principles.html Agile Project Management Handbook v2. AgilePM®. 2014. Agile Business Consortium, Henwood Ahituv, N., Neumann, S., and Zviran, M. 2002. “A System Development Methodology for ERP Systems,” Journal of Computer Information Systems (42:3), pp. 56–67. Al-Ahmad, W., Al-fagih, K., Khanfar, K., Alsamara, K., Abuleil, S., and Abu-Salem, H. 2009. “A Taxonomy of an IT Project Failure: Root Causes,” International Management Review (5:1), pp. 93–104 Aljaber T. 2023. Iron triangle project management and agile. Retrieved from: https://www.atlassian.com/agile/agile-at-scale/agile-iron-triangle Anton, B., and Goedhard, A. 2016. “On the Determination of the Optimal Methodology for ERP Projects,” Doctoral Dissertation, Radboud University Nijmegen. Baig, J. J. A., Shah, A., and Sajjad, F. 2017. “Evaluation of Agile Methods for Quality Assurance and Quality Control in ERP Implementation,” 2017 IEEE 8th International Conference on Intelligent Computing and Information Systems, ICICIS 2017 (2018-Janua:Icicis), pp. 252–257. Bajwa, D., Garcia, J., and Mooney, T. 2004. “An Integrative Framework for the Assimilation of Enterprise Resource Planning Systems: Phases, Antecedents, and Outcomes,” Journal of Computer Information Systems (Spring), pp. 81–90. Bidgood, S., and Gaim, M. 2017. “A Hybrid Project Management Approach: Bridging Theory and Practice in ERP Implementation Projects,” Master Thesis, Umeå School of Business and Economics. Retrieved from: http://www.diva-portal.org/smash/get/diva2:1178870/FULLTEXT01.pdf. DSDM Agile Project Framework Handbook – DSDM. 2014. Agile Business Consortium, Retrieved from: https://www.agilebusiness.org/dsdm-project-framework.html Introducing the Clean Core Approach .2023. Retrieved from: https://learning.sap.com/learningjourneys/practicing-clean-core-extensibility-for-sap-s-4hana-cloud/introducing-the-clean-coreapproach_fcb6c662-7041-4c99-88bd-345636fae7f3 Esteves, J., Chan, R., and Pastor, J. 2003. “An Exploratory Study of Knowledge Types Relevance Along Enterprise Systems Implementation Phases,” in 4-Th European Conference on Organizational Knowledge and Learning Capabilities, pp. 13–14. Gemino, A., Horner Reich, B., and Serrador, P. M. 2021. “Agile, Traditional, and Hybrid Approaches to Project Success: Is Hybrid a Poor Second Choice?,” Project Management Journal (52:2), pp. 161–175. Gren, L., Wong, A., and Kristoffersson, E. 2018. “Choosing Agile or Plan-Driven Enterprise Resource Planning (ERP) Implementations - A Study on 21 Implementations from 20 Companies,” CEUR Workshop Proceedings (2107), pp. 40–55. Thirtieth Americas Conference on Information Systems, Salt Lake City, 2024 9 Enterprise System implementation projects… Kraljić, A., Kraljić, T. 2019. „Agile Software Engineering Practices in ERP Implementation,” in Information Systems. EMCIS 2019. Lecture Notes in Business Information Processing, vol 381, Themistocleous, M., Papadaki, M. (eds), Springer, Cham. Hoda, R., Salleh, N., Grundy, J., and Tee, H. M. 2017. “Systematic Literature Reviews in Agile Software Development: A Tertiary Study,” Information and Software Technology (85), Elsevier BV, pp. 60–70. Jain A. 2013. Basic understanding on ASAP methodology for beginners, Retrieved from: https://community.sap.com/t5/enterprise-resource-planning-blogs-by-members/basicunderstanding-on-asap-methodology-for-beginners/ba-p/13242013z Kuhrmann, M., Diebold, P., Münch, J., Tell, P., Garousi, V., Felderer, M., Trektere, K., McCaffery, F., Linssen, O., Hanser, E., and Prause, C. R. 2017. “Hybrid Software and System Development in Practice: Waterfall, Scrum, and Beyond,” in Proceedings of International Conference on Software System Process, pp. 30–39. (https://doi.org/10.1145/3084100.3084104). Lech, P. 2013. “Enterprise System Assimilation: Phases, Activities, and Outcomes,” Journal of Management and Finance (3:1), pp. 29 – 40 Lech, P. 2016. “Implementation of an ERP System : A Case Study of a Full-Scope SAP Project,” Journal of Management and Finance (14:1), pp. 49–64. Lech, P. 2014. “Managing Knowledge in IT Projects: A Framework for Enterprise System Implementation,” Journal of Knowledge Management (18:3), pp. 551–573. Lech, P. 2016. “Tailoring the Enterprise System to the Organisational Needs - the Case of SAP Implementation,” in European, Mediterranean & Middle Eastern Conference on Information Systems, pp. 224 – 231. Lech, P., Samól D., Shygun M. 2023. „Evolution and deployment options of Enterprise Systems – the case of SAP S/4HANA enterprise application suite,” in Proceedings of the 42-nd International Business Information Management Association (IBIMA) Conference, pp 32-42. Madanian, S., Subasinghage, M., and Tachiona, S. C. 2021. “Critical Success Factors of Agile ERP Development and Implementation Projects: A Systematic Literature Review,” PACIS 2021 Proceedings. 211. Nagpal, S., Khatri, S. K., and Kumar, A. 2015. “Comparative Study of ERP Implementation Strategies,” 2015 IEEE Long Island Systems, Applications and Technology Conference, LISAT 2015 (January 2016). Nelson, R. R. 2007. “IT Project Management: Infamous Failures, Classic Mistakes, and Best Practices,” MIS Quarterly Executive (6:2), pp. 67–78. Salas, W. H. 2023. “Model to Improve an ERP Implementation Based on Agile Best Practice: A Delphi Study.,” Procedia Computer Science (219:2022), Elsevier BV, pp. 1785–1792. Musil J. 2017. “SAP Activate – Explore Phase – Use Fit-to-Standard,” Retrieved from: https://community.sap.com/t5/enterprise-resource-planning-blogs-by-sap/sap-activate-explorephase-use-fit-to-standard-to-confirm-business-process/ba-p/13331140 SAP Roadmap Viewer. 2023. Accessed 12.02.2023 from: https://go.support.sap.com/roadmapviewer/ Schwaber, K., and Sutherland, J. 2020. The Scrum Guide. Retrieved from https://scrumguides.org/scrum-guide.html Shankar M. R. 2020. “The Beginner’s Guide to SAP Activate – Best Practices, Guided Configuration and SAP Activate Methodology,” Retrieved from https://blogs.sap.com/2020/12/08/the-beginnersguide-to-sap-activate-best-practices-guided-configuration-and-sap-activate-methodology/ Topi, H., & Spurrier, G. 2019. “A generalized, enterprise-level systems development process framework for systems analysis and design education,” Journal of Information Systems Education, (30:4), pp. 253-265 Vallon, R., da Silva Estácio, B. J., Prikladnicki, R., and Grechenig, T. 2018. “Systematic Literature Review on Agile Practices in Global Software Development,” Information and Software Technology (96:April 2017), Elsevier, pp. 161–180. West, D. 2011. “Water-Scrum-Fall Is The Reality Of Agile For Most Organizations Today,” Forrester: For Application Development & Delivery Professionals, pp. 1–15. Yeo, K. T. 2002. “Critical Failure Factors in Information System Projects,” International Journal of Project Management (20:3), pp. 241–246. Yin, R. 2009. Case Study Research. Design and Methods, (Fourth Edi.), Thousand Oaks: Sage. Thirtieth Americas Conference on Information Systems, Salt Lake City, 2024 10