Noora Pahkala Balancing Flexibility and Structure in a NPD case company: Opportunities and Challenges of Hybrid Project Management Vaasa 2025 School of Technology and Innovations Master’s thesis Master's Programme in Industrial Engineering and Management UNIVERSITY OF VAASA School of Technology and Innovations Author: Noora Pahkala Title of the thesis: Balancing Flexibility and Structure in a NPD case company: Oppor- tunities and Challenges of Hybrid Project Management: Degree: Master of Science in Technology Discipline: Industrial engineering and management Supervisors: Ahm Shamsuzzoha, Petri Helo & Ville Tuomi Year: 2025 Pages: 118 ABSTRACT: Hybrid project management methodologies are increasingly relevant to organizations balancing with the flexibility of Agile practices and the structure of traditional project management prac- tices. However, their effectiveness is shaped by the organizational context in which they are implemented and while theories exist, empirical studies remain limited. The aim of this study is to examine what challenges the current hybrid project management model has and how project success can be improved by addressing these challenges in a case company executing large and complex new product development projects. Furthermore, this study aims to recognise how early warning indicators can create transparency to help leadership identify critical project de- lays to enable timely actions. To examine these re-search questions, mixed methods research was conducted in a global technology company’s new product development project organiza- tion. The empirical data consists of 17 semi-structured interviews working in project manage- ment roles in research and development- and supply chain departments. While the current hy- brid model was considered as the most effective project management method compared to previous ones, the findings reveal several structured challenges in the current implementation of the hybrid model, including short-term focus, lack of overall management, unclear roles and insufficient transparency between stakeholders. These factors are closely linked to frequent pro- ject delays resulting from resource constraints and unrecognized project tasks and their depend- encies. Strengthening change management, common planning, aligning schedules and re- sources to realistic levels, and increasing flexible resource use are identified as key actions for improving project performance. Furthermore, improved recognition of tasks and their depend- encies for critical path monitoring and transparency through common tools are identified as key actions for improving detection of early warning indicators and supporting overall project suc- cess. KEYWORDS: Project management, Agile, Hybrid, Leadership, Management VAASAN YLIOPISTO Tekniikan ja innovaationjohtamisen akateeminen yksikkö Tekijä: Noora Pahkala Tutkielman nimi: Balancing Flexibility and Structure in a NPD case company: Oppor- tunities and Challenges of Hybrid Project Management: Tutkinto: Diplomi-insinööri Oppiaine: Tuotantotalous Työn ohjaajat: Ahm Shamsuzzoha, Petri Helo & Ville Tuomi Valmistumisvuosi: 2025 Pages: 118 TIIVISTELMÄ: Hybridiprojektihallintamenetelmät ovat yhä merkityksellisempiä organisaatioille, jotka pyrkivät tasapainottelemaan ketterien menetelmien joustavuuden sekä perinteisten projektinhallinta- menetelmien rakenteen ja hallinnan välillä. Projektihallintamenetelmien tehokkuus riippuu kui- tenkin organisaation kontekstista, jossa niitä sovelletaan. Vaikka hybridiprojektinhallintamene- telmistä on olemassa teoreettista tutkimusta, empiirisiä tutkimuksia on edelleen vähän. Tässä tutkimuksessa tarkastellaan, mitä haasteita nykyisessä hybridiprojektinhallintamallissa on ja mi- ten näihin haasteisiin keskittymällä voidaan parantaa projektimenestystä case-yrityksessä, joka toteuttaa isoja ja monimutkaisia uustuoteprojekteja. Lisäksi tutkimuksessa pyritään tunnista- maan, miten varhaisvaroitusindikaattorit voivat lisätä läpinäkyvyyttä ja auttaa johtoa havaitse- maan kriittiset projektiviiveet ajoissa. Tutkimuskysymysten tarkasteluun käytettiin sekamene- telmää ja empiirinen tutkimus toteutettiin globaalin teknologiayrityksen uustuoteprojektien osastolla. Empiirinen aineisto koostuu 17 puolistrukturoidusta haastattelusta, joissa haastatel- tavat työskentelevät projektihallinnan tehtävissä tutkimus ja kehitys - sekä toimitusketjuosas- toilla. Vaikka nykyistä hybridimallia pidettiin tehokkaimpana projektinhallintamenetelmänä aiempiin verrattuna, tulokset paljastavat useita rakenteellisia haasteita nykyisessä hybridimal- lissa, kuten lyhytnäköisen keskittymisen, puutteellisen kokonaisjohtamisen, epäselvät roolit ja riittämättömän näkyvyyden sidosryhmien välillä. Nämä haasteet liittyvät läheisesti toistuviin projektiviiveisiin, joita aiheuttavat erityisesti resurssirajoitukset sekä tunnistamattomat tehtä- vät ja niiden riippuvuudet. Muutoshallinnan ja yhteisen suunnittelun vahvistaminen, aikataulu- jen ja resurssien realistinen kohdentaminen sekä resurssien joustavamman käytön lisääminen tunnistetaan keskeisiksi toimenpiteiksi projektien onnistumisen parantamiseksi. Lisäksi tehtä- vien ja niiden riippuvuuksien parempi tunnistaminen kriittisen polun seurantaa varten sekä nä- kyvyyden lisääminen yhteisten työkalujen avulla tunnistetaan keskeisiksi toimenpiteiksi varhais- varoitusindikaattorien havaitsemisen parantamiseksi sekä projektien kokonaisvaltaisen onnistu- misen tukemiseksi. AVAINSANAT: Projektinhallinta, Ketterät menetelmät, Hybridi, Johtaminen Contents 1 Introduction 8 1.1 Case company 8 1.2 Goals and thesis structure 10 2 Literature review 12 2.1 Agile Project Management 12 2.1.1 Agile in NPD and hardware projects 25 2.1.2 Strengths and Weaknesses of Agile and Scrum 32 2.2 Traditional project management & Waterfall model 41 2.2.1 Stage-Gate model 42 2.2.2 Strengths and weaknesses 45 2.3 Hybrid project management 49 2.3.1 Strengths and challenges of hybrid project management 53 2.4 Project success 60 3 Methodology 62 3.1 Mixed methods research 62 3.1.1 Qualitative research 63 3.1.2 Quantitative research 63 3.1.3 Data collection 64 3.2 Data analysis 66 3.2.1 Thematic analysis 66 3.2.2 Quantitative analysis 68 4 Results 69 4.1 Project management methodology 69 4.2 Project initiation and clarity of goals 70 4.3 Scope definition and changes 74 4.4 Task planning and critical path 75 4.5 Project schedule 79 4.6 Project delays 83 4.7 Multiteam collaboration 86 4.8 Hybrid project management methodology challenges 87 4.9 Hybrid project management methodology strengths 91 5 Discussion 96 5.1 Key findings 96 5.1.1 Main challenges of current hybrid project management model 97 5.1.2 Early warning indicators and reaction to project delays 101 5.2 Managerial recommendations 102 5.3 Limitations and future research 105 6 Conclusions 107 References 109 Appendix 1. Interview questionnaire 117 Figures Figure 1. APM iterations (adapted from Breyter, 2023) 17 Figure 2. Sprint events 23 Figure 3. Waterfall model (adapted from Breyter, 2023) 42 Figure 4. Stage-Gate model (adapted from Cooper, 2023) 43 Figure 5. Agile-Stage-Gate model (Cooper & Sommer, 2018) 53 Figure 6. Strategic planning process (adapted from case company process chart) 71 Figure 7. Milestone deliverables plan (adapted from case company's milestone plan) 72 Figure 8. Clarity of the project objective in the beginning 73 Figure 9. Commonness of scope changing during the project 75 Figure 10. M3 from SCRS list (example project from case company) 76 Figure 11. Commonness of project tasks changing during the project 78 Figure 12. Commonness of projects staying on schedule 80 Figure 13. Successfulness of the current PMM 95 Tables Table 1. Strengths of APM 35 Table 2. Challenges of APM 40 Table 3. Strengths of TPM 46 Table 4. Challenges of TPM 48 Table 5. Strengths of HPM 55 Table 6. Challenges of HPM 59 Table 7. Interview data 64 Table 8. Reasons for project delays 85 Table 9. Challenges of the current PMM 90 Table 10. Strengths of the current PMM 93 Abbreviations APM Agile project management ART Agile release train CMMI Capability maturity model integration HIP Hardening, innovation, planning HPM Hybrid project management IPAC Iteration, prototype, alignment & customer ISO International organization for standardization LeSS Large-scale Scrum MAHD Modified Agile for hardware NPD New product development PM Project management PMM Project management methodology PO Product owner R&D Research & development SAFe Scaled Agile Framework SC Supply chain SIPOC Supplier, input, process, output, customer TPM Traditional project management TPO Technical product owner 1 Introduction The nature of project management is undergoing a fundamental transformation. Tradi- tional project management (TPM) methodologies were originally developed to support large and linear projects with stable environments and predictable outcomes. However, because today’s projects are often executed in increasingly complex and dynamic con- texts, characterised by rapid technological developments and increased uncertainty, TPM has proven to be too rigid and slow (Cooper, 2016; Zasa et al., 2021). In response to these changes, organizations have increasingly turned to Agile methodologies, which was developed in software industry, emphasizing adaptability, responsiveness and fast iterations of development (Ciric et al., 2018; Trivedi, 2021, Zasa et al., 2021). However, organizations in other industries aiming to adopt Agile project management (APM) often struggle with the methodology’s lack of structure and governance (Sithambaram et al., 2021; Zasa et al., 2021). This is particularly the case in large organizations that execute large scale and complex projects, working in fields with strict regulations and governance (Sithambaram et al., 2021; West et al., 2021; Zasa et al., 2021). As a result, many organ- izations have begun to integrate Agile and TPM methods through hybrid project man- agement (HPM) methodologies, combining the flexibility of Agile practices with the structure provided by traditional practices (Cooper, 2016; Cooper & Sommer, 2018; Reiff & Schlegel, 2022; Sommer et al., 2015; Székely et al., 2025; Zasa et al., 2021). Despite their growing adoption, the successful implementation of HPM models remains chal- lenging (Bianchi et al., 2020; Cooper & Sommer, 2018; Zasa et al., 2021), since APM and TPM offer in many ways contradictory guidelines. Moreover, empirical research on how these methods are implemented in practice is still limited, and their effectiveness is strongly shaped by the organizational context in which they are applied. 1.1 Case company The case company is a global technology organization specializing in advanced solutions designed to reduce energy consumption, increase machine productivity and enable elec- trification to lower overall emissions. This study focuses on a business segment dedicated to power conversion and energy efficient solutions. More specifically, this study is conducted for a new product development (NPD) project organization, which is responsible for driving innovation and delivering new products to the market. The NPD project organization has adopted a HPM methodology, combining TPM practices through the Stage-Gate model with Agile practices through utilizing Scrum framework in daily work. This study includes two key departments involved in executing NPD projects: research and development (R&D) and supply chain (SC). R&D department consists of product teams, which own the products and are responsible for product design and its develop- ment. SC department is responsible for developing the whole supply chain for new prod- ucts, from physical assembly lines to system related maturity. SC department is a shared resource, working for multiple product teams simultaneously. While these two depart- ments work closely together to execute NPD project, they have different organizational structures. R&D department operates in Agile organization with product teams that in- volve the roles of product owner (PO), technical product owner (TPO) and scrum master. Whereas the SC department follows a more traditional organizational structure with the role of a project manager and team members assigned to specific projects. TPO is not officially part of a product team in Agile, but the case company has decided to include it to support PO and developers. While PO works more on customer interface, TPO works mostly towards the product team and developers to break down product goals into prac- tical things that the product team can deliver. In practice, TPO is an experienced and technically competent team member that works between PO and the customer, and the developers. This organizational setup provides a relevant context for this study. NPD projects are organized so that there are global product platform projects that in- clude a whole project family and multiple different product variants. These platform pro- jects are extremely large and are multiple years long, involving well over hundred people. From the product platform, the productization of individual products and variants are considered as their own projects, lasting around one to two years, involving around thirty people. Through the product platforms, the productization projects of products and variants can be executed faster since same materials are utilized as much as possible. These NPD projects are managed with the Stage-Gate model but daily work is organised with Scrum framework, meaning that a HPM model is used. The case company’s NPD project organization has transitioned from a TPM methodology to a HPM relevantly re- cently during the past few years and further development is required to ensure success- ful project execution. In addition, the case company frequently faces project delays and has a need to improve the transparency of early warning indicators for leadership to enable timely and informed actions. 1.2 Goals and thesis structure The goal of this study is to address the key challenges related to the successful adoption of a HPM methodology and project delays in the case company. While theoretical studies of HPM methodologies have been conducted, empirical research remains limited. Fur- thermore, the context in which project management methodologies (PMM) are imple- mented significantly influences its effectiveness, making it essential to study the current adoption of a HPM methodology within the context of the case company and the specific challenges it faces. In addition to the effective adoption of HPM methodology as a critical success factor, identifying early warning indicators to create transparency of the actual project status is also essential. To address these specific challenges in the case company the following research ques- tions are posed: RQ1: What are the challenges of the current hybrid project management model that should be addressed to improve project success? RQ2: What early warning indicators create transparency to help leadership identify crit- ical delays in projects? To address these two research questions, first a theoretical basis for the study is pre- sented in literature review. The literature review presents relevant project management methodologies as well as the benefits and challenges related to them. First, overviews of Agile and TPM are presented separately and then the combination of these is explored through HPM. Furthermore, a chapter discussing project success in NPD projects is in- cluded for taking the characteristics of complex projects and their effect on the perspec- tives of project success into account. Moving to the empirical study part of the thesis, first research methodology and execution of the study are presented. This is followed by the results, which are then interpreted and discussed in relation to previous literature. Finally, managerial recommendations are presented, along with the limitations of the study and suggestions for future research. 2 Literature review Project management institute (2021) defines project as a temporary venture undertaken to create a unique product or service in a predetermined timeframe which has a clear beginning and end. Projects can either be stand-alone or part of a program or portfolio and they are expected to create value for the organization (Project Management Insti- tute, 2021). Projects can create value in different ways, for example through business benefits, new product development, system development or investment in company in- frastructure (Wells, 2012). Kodukula (2014) highlights that only projects that align with the strategy and goals of the organizations are selected and executed. Project manage- ment is defined as the application of knowledge, skills, tools, and techniques to project activities to meet project requirements (Project Management Institute, 2021). The pur- pose of project management is to guide the project work to deliver the intended out- comes and results within the project requirements (Project Management Institute, 2021). Many different project management methodologies have been developed to help with successful project management and project execution. Project management meth- odology is defined as a structured and systematic set of principles, practices, tools and techniques that guide the planning, execution, monitoring and control of a project (Spundak, 2014; Unqureanu & Uncureanu, 2014). In the following chapters project management approaches, methodologies and models that are relevant in the context of the case company are presented. The strengths and weaknesses of each are reviewed individually. Then a HPM methodology is presented to review how two different project management methodologies can be combined to gain the strengths of both. In addition, the definition of a project success is presented in the context of complex large-scale projects. 2.1 Agile Project Management Agile approaches have grown to be part of the most common mainstream project man- agement approaches during the past two decades (Gemino et al., 2021). Agile Manifesto was published in 2001 specifically for software development and it has been generally accepted as a foundation for APM (Ciric et al., 2018; Ciric Lalic et al., 2022). Cobb (2023) writes that Agile Manifesto combined clearly all previous Agile methodologies into spe- cific values and principles. Agile Manifesto consists of four values and twelve principles to backup those values (Beck et al., 2001). Ciric Lalic et al. (2022) write that Agile ap- proach aims to promote deeper understanding of software development project com- plexity. The four values of Agile manifesto are: 1. Individuals and interactions over processes and tools. 2. Working software over comprehensive documentation. 3. Customer collaboration over contact negotiation. 4. Responding to change over following a plan (Beck et al., 2001). Beck et al. (2001) explain that the four values of Agile Manifesto have been formulated in a way that while there is value on the right side of the statement the left side of the statement is valued more. The first statement means that Agile ultimately values intelli- gent decision-making by skilled and empowered people and interactive collaboration as a team (Cobb, 2023). This comes from an essential element of Agile approach that is the distribution of responsibility between the project team members and the team being self-organizing (Gemino et al., 2021). Furthermore, this means that in Agile approach project management has a more softer leadership approach with flexible and adaptive processes instead of control-oriented and highly directive project management ap- proach with strict processes (Cobb, 2023). Cobb (2023) highlights that this doesn’t mean that Agile approach wouldn’t have well-defined processes but that they are designed to be adaptive and meant to be implemented intelligently instead of following certain pre- scriptive processes mechanically. In addition, tools are kept in a supportive role to facili- tate human interaction (Cobb, 2023). The second statement means that documentation itself should not be an essential value but rather it should always provide value to the project (Cobb, 2023). According to Cobb (2023), this was a response to the Waterfall model, in which documentation is over em- phasized. Agile’s more flexible approach to documentation addresses the challenge many users face in defining detailed requirements early in a project (Cobb, 2023). This is a significant challenge especially in uncertain and changing environment (Cobb, 2023). Cobb (2023) further explains that by reducing dependency on extensive documentation, the risk of miscommunication and misunderstandings about the intended requirements are also minimized. The third statement describes the value of a collaborative approach over strictly defined contracts. This is also a response to the Waterfall model, which often centers around the triple constraint of scope, schedule and cost (Cobb, 2023; Kodukula, 2014). According to Kodukula (2014), this focus on controlling the requirements of the contract may overlook broader indicators of project success, such as customer satisfaction and long-term stake- holder value. Agile addresses this limited view by emphasizing customer collaboration, encouraging a more adaptive and trust-based relationship with customers (Cobb, 2023). Cobb (2023) explains that this enables creating a more general agreement with high- level requirements and leave flexibility to define detailed requirements during later stages of a project. In uncertain environment this approach supports value creation be- yond rigid contract specifications, recognizing the challenge of defining detailed require- ments in the beginning of a project (Cobb, 2023). Cobb (2023) highlights the importance of always adapting the Agile approach based on the situation and finding a right balance with a customer to agree on a suitable contract. The fourth, and final statement, addresses the difficulty of defining requirements at the start of a project and recognizes that it’s often not effective or realistic (Cobb, 2023). According to Thesing et al. (2021), users aren’t often able to specify the details of general requirements, or the steps to achieve the defined objectives might not be clear. Cobb (2023) writes that in these situations it’s suitable to leave some space in the project plan for the detailed requirements to change during the project. Agile approach provides flexibility to respond to changing situations instead of strictly focusing on following a pre- defined project plan (Cobb, 2023). Lowell (2023) writes that the values highlight that it’s more important to make progress than it’s to make something perfect. The center of the four values is individuals and col- laboration between them in order to respond to change flexibly (Lowell, 2023). Accord- ing to Cobb (2023), all four values are interrelated and need to be contemplated to find a suitable approach to a particular project. Furthermore, Cobb (2023) emphasizes that there are a lot of alternatives to all-or-nothing decisions and finding the right balance of control and flexibility is important. In addition to the four values that form the foundation of Agile, Beck et al. (2001) also defined twelve principles to expand the values and provide more detail. Cobb (2023) highlights that as with the four values, these principles should not be considered as ab- solutes but more context-depended preferences. The twelve principles of agile in an adapted formulation are: 1. The highest priority is to satisfy the customer with quick and continuous delivery of valuable software. 2. Embrace evolving requirements, even late in development to provide competi- tive advantage to customer. 3. Deliver working software frequently in short iterations of couple of weeks to cou- ple of months. 4. Daily communication and collaboration between businesspeople and developers is required. 5. Create a space for motivated people, offer guidance and resources and trust their ability to succeed. 6. Face-to-face conservation is the most efficient and effective form of sharing in- formation to and within a development team. 7. The primary measure of progress is working software. 8. Sustainable and manageable work rates are supported so that sponsors, devel- opers and users can keep a consistent pace indefinitely. 9. Agility is enhanced with continuous attention to technical excellence and quality design. 10. The amount of work not done is maximized for simplicity. 11. Self-organizing teams are optimal for achieving best architectures, requirements and designs. 12. The team regularly reflects and adjusts their own ways of working to become more effective and efficient (Beck et al., 2001). These values and principles of Agile Manifesto provide a strong foundation for under- standing Agile (Cobb, 2023). Furthermore, Cobb (2023) highlights that many of the val- ues and principles can be applied to almost any project when done intelligently and in the right context. Fundamentally, APM is about succeeding in changing environments by identifying and understanding the uncertainty and being able to adapt and respond to change quickly (Trivedi, 2021). As Ciric et al. (2018) claim, the companies that will succeed in the quickly changing world of manufacturing are those that have developed the agility required to support rapid and continuous innovation. Gemino et al. (2021) writes that the ability to adapt and respond to change comes from dividing the project work into separate itera- tive cycles in which the project and it’s requirements are continuously further refined. According to Breyter (2023) each iteration contains the process of the Waterfall model: initiation, planning, execution, monitoring and controlling and closing. The difference to the Waterfall model is that value is delivered with each short iteration, allowing cus- tomer value to be realised much earlier in the project rather than only at the end of the project (Breyter, 2023). The lifecycle of APM is shown in Figure 1, where customer re- leases are done after each iteration after the minimum viable product is ready (Breyter, 2023). Figure 1. APM iterations (adapted from Breyter, 2023) In addition to early value delivery, short iterations are what makes APM flexible and adaptive. Breyter (2023) writes that in APM the product is delivered gradually with each iteration which enables the users to give feedback on the product throughout the project. When feedback is provided after each iteration the project team can adapt and respond to the feedback quickly during the upcoming iterations (Breyter, 2023). These iterative cycles require a shift in the approach of project planning from controlling changes in scope, cost and schedule to adopting a more adaptive approach focused on providing value (Cobb, 2023). Another essential element of APM is that the project team is self-organizing and respon- sibility is divided between the team members (Cobb, 2023; Gemino et al., 2021; Hoda & Murugesan, 2016). According to Hoda et al. (2012) self-organizing teams improve the organization’s flexibility and ability to respond to change which makes it a crucial ele- ment of APM. Hoda et al. (2012) emphasize that self-organizing teams are one of the critical success factors of Agile projects. Furthermore, Cobb (2023) writes that this means that Agile processes largely depend on skilled and empowered team members who can plan and organise their own work independently based on agreed goals without detailed directions given to them. Ultimately, self-organizing teams must have mutual trust and respect, a common focus and the ability to repeatedly re-organize to meet new chal- lenges (Hoda et al., 2012). In addition, Lawong and Akanfe (2025) write that team dy- namics are essential for achieving effective project management. Work role perfor- mance is built from three dimension of work role performance: proficiency, proactivity and adaptivity. As stated previously, achieving these three dimensions is crucial for self- organizing teams to achieve effective APM. There are six different characteristics of a self-organizing team: autonomy, shared lead- ership, team orientation, communication, redundancy and learning (Hoda & Murugesan, 2016; Perlak, 2019). Hoda & Murugesan (2016) write that self-organizing teams have high level of autonomy that is enabled by the support from management. Management provides minimal critical specifications with high-level goals and direction but leaves everyday decision-making to the team (Hoda & Murugesan, 2016). According to Hoda & Murugesan (2016) autonomy in self-organizing teams can be viewed across three differ- ent dimensions: individual, internal and external. Individual autonomy refers to each team member’s ability to manage their own tasks and responsibilities (Hoda & Murugesan, 2016). Internal autonomy of the team concerns the extent to which deci- sions are made collectively within the team instead of by centralized decision-making by an individual leader (Hoda & Murugesan, 2016). External autonomy involves the degree of independence the team has from external stakeholders, including management, in determining how to achieve the agreed goals (Hoda & Murugesan, 2016). Because self-organizing teams are designed to operate with a high degree of independ- ence, the responsibility of decision-making and execution which is traditionally held by project managers is shared with the team (Hoda & Murugesan, 2016; Hoda et al., 2012). According to Hoda & Murugesan (2016) this mean that in addition to executing technical tasks, Agile team members are expected to share responsibilities in project management activities such as planning estimation, stakeholder collaboration, task allocation and pro- gress tracking. By bringing decision-making authority closer to the operational level and involving Agile teams in management practices, organizations aim to improve the speed and accuracy of problem-solving. However, Hoda et al. (2012) emphasize that autonomy doesn’t mean leadership doesn’t exist in APM. Instead, leadership in self-organizing teams is characterized by a light-touch and adaptive approach that focuses on guiding rather than controlling (Hoda et al., 2012, Perlak, 2019). In APM, leaders are still respon- sible for critical functions such as setting direction, motivating teams, aligning efforts and ensuring the availability of resources (Hoda et al., 2012). Perlak (2019) writes that managers serve as facilitators who create a supportive environment, share relevant in- formation and intervene only when necessary to help the team. Hoda et al. (2012) explain that a truly autonomous team has both freedom and respon- sibility with minimal interference in day-to-day operations by management. This level of trust encourages self-monitoring, a strong sense of ownership and increased commit- ment among team members (Hoda et al., 2012). Furthermore, in mature Agile teams, autonomy often evolves into self-transcendence, a state in which team define their own goals and continuously evaluate and improve their methods for achieving them (Hoda et al., 2012). Hoda et al. (2012) explains that self-transcendence teams may determine the work load they can commit to in each iteration and take full responsibility for deliv- ering that commitment, thereby reinforcing both internal motivation and performance pressure. One other essential element of APM is close and continuous communication between stakeholders through both formal and informal communication (Gemino et al., 2021). Collaboration, communication and status reporting have been identified as critical ele- ments of project success in APM (Boerman et al., 2015; Pikkarainen et al., 2008). These elements are important since in APM detailed requirements are defined as the project unfolds, which requires a collaborative and trust-based partnership between the cus- tomer and project team (Cobb, 2023). Furthermore, Boerman et al. (2015) write that effective status reporting to external stakeholders is required to facilitate communica- tion, build confidence and provide appropriate project steering. Because APM requires active participation from external stakeholders, pure Agile approach won’t be suitable if the customer cannot or doesn’t want to actively engage in the project (Cobb, 2023). APM emphasizes frequent face-to-face interaction to enhance mutual understanding and accelerate decision-making processes across stakeholder groups (Pikkarainen et al., 2008). In a study conducted by Pikkarainen et al. (2008), practices such as open office spaces and daily meetings were effective in facilitating communication of project goals, status updates and decisions within project teams. These informal communication prac- tices not only enhanced collaboration but also reduced the need for excessive documen- tation, allowing more flexibility to respond to change (Pikkarainen et al., 2008). However, while informal communication methods can increase efficiency, Boerman et al. (2015) caution that relying too heavily on tacit, face-to-face communication may become problematic in large or complex environments. As complexity grows communication may reach its limits, making it more difficult to ensure that critical information reaches all relevant stakeholders in a timely and accurate manner (Boerman et al., 2015). This un- derlines the importance of balancing informal communication with formal status report- ing, especially when coordinating across distributed teams or departments (Boerman et al., 2015). Scrum is the most widely used Agile framework (Breyter, 2023; Cobb, 2023; Zavyalova et al., 2020). Schwaber and Sutherland (2020) have written the Scrum Guide in which they define Scrum as a lightweight framework designed to deliver value in complex environ- ments though adaptive solutions. Schwaber and Sutherland (2020) write that Scrum is based on empiricism and lean thinking. In empiricism, knowledge comes from experi- ence and decision are made based on observations (Schwaber and Sutherland, 2020). In lean thinking waste is reduced and focus is on the essentials (Schwaber and Sutherland, 2020). Furthermore, scrum is built on three interrelated pillars: transparency, inspection and adaption (Breyter, 2023; Schwaber & Sutherland, 2020). Transparency means that emergent process and work must be transparent to all internal and external stakeholders. Transparency on the project work increases the risk of value decreasing decisions and other risks (Lawong & Akanfe, 2025; Schwaber & Sutherland, 2020). Transparency ena- bles inspection that must be done frequently to identify potential problems (Schwaber & Sutherland, 2020). Inspection further enables adaption when it’s needed to keep the project on the right track (Schwaber & Sutherland, 2020). Schwaber and Sutherland (2020) explain that the Scrum framework is intentionally left incomplete to leave flexibility for people to implement it in the most suitable way. This incompleteness may be partly why Breyter (2023) describes Scrum as simple to understand but difficult to master. Scrum framework can be divided into three categories: roles, events and artifacts (Lawong & Akanfe, 2025). Scrum roles are designed for a small team of people and only consists of one scrum master, one product owner (PO) and developers (Schwaber & Sutherland, 2020). Lawong and Akanfe (2025) note that developers are often referred as simply team member outside software industry. The scrum team is responsible for all product related activities and accountable for creating value (Schwaber & Sutherland, 2020). A scrum team should be small, maximum ten people, to maintain efficient com- munication, productivity and adaptivity but large enough to have necessary expertise and skills to complete the project (Lawong & Akanfe, 2025; Schwaber & Sutherland, 2020). The project size is not a reason to grow the scrum team but instead the team should be reorganized into multiple teams that are focused on the same product (Gustavsson & Rönnlund, 2013; Schwaber & Sutherland, 2020) Scrum master ensures that Scrum is understood and properly executed within the team and organization (Cobb, 2023; Schwaber & Sutherland, 2020). Scrum master acts as a servant-leader who supports improvement, removes obstacles, coaches members and promotes effective scrum practices while also serving the organization by promoting Scrum theory and leading its adopting (Breayter, 2023; Schwaber & Sutherland, 2020). Cobb (2023) highlights that although scrum master provides guidance, scrum teams are expected to be as self-organizing as possible. PO is responsible for the product vision and maximizing product value by managing the product backlog and facilitating open stake- holder communication (Lawong & Akanfe, 2025; Schwaber & Sutherland, 2020). PO rep- resents stakeholders, makes final backlog decisions, prioritizes features and ensures that goals and backlog items are clearly communicated to the scrum team (Lawong & Akanfe, 2025; Schwaber & Sutherland, 2020). Developers, or team members, plan and adapt sprint goals daily, deliver usable product increments each sprint and ensure quality through the definition of Done (Breyter, 2023; Cobb, 2023; Schwaber & Sutherland, 2020). Lawong and Akanfe (2025) emphasize the importance of having a diverse and complementary skill set among the team members Scrum events are all included in iterations that are called sprints in Scrum (Breyter, 2023; Lawong & Akanfe, 2025). Sprints are continuous fixed length iterations of four week or less during which value is provided (Breyter, 2023; Cobb, 2023; Schwaber & Sutherland, 2020). Schwaber & Sutherland (2020) explain that one sprint contains all other scrum events: sprint planning, daily scrums, sprint review and sprint retrospective (Figure 2). According to Schwaber & Sutherland (2020) these sprint events provide the transpar- ency that is required, thus minimizing the need for any other meetings during the sprint. In addition, through transparency the events also allow for inspection and adaption (Lawong & Akanfe, 2025). During each sprint the goal is to produce a result with func- tionality that is useful for the final product (Loweng & Akanfe, 2025). Gustavsson and Rönnlund (2013) explain that because each sprint is fixed length, the length of the sprint supersedes the tasks planned for the sprint regardless of the stage of the tasks and if they have been completed. This is called a time-box concept and furthermore it means that the product owner and developers must continuously prioritize the tasks that should be done for the sprint (Gustavsson & Rönnlund, 2013). Figure 2. Sprint events Sprint planning divides project work into small and manageable pieces that can be com- pleted within one sprint, setting goals and defining the work collaboratively with the scrum team (Cobb, 2023; Schwaber & Sutherland, 2020). Schwaber and Sutherland (2020) explain that sprint planning is for determining the definition of Done and address- ing key questions about the sprint’s value, achievable work and approach to do the work. The definition of Done represent a clear and shared understanding of the criteria that must be met for a product backlog item to be considered complete and usable (Lawong & Akanfe, 2025; Schwaber & Sutherland, 2020). Throughout the sprint, short 15-minute meetings called daily scrums are held to review progress, discuss completed and planned work, identify challenges and adapt plans when necessary (Lawong & Akanfe, 2025: Schwaber & Sutherland, 2020). According to Schwaber and Sutherland (2020), daily scrums are important for improving communication, problem-solving and promoting fast decision-making among the scrum team, although team members also often have more detailed discussions outside of daily scrums. At the end of the sprint, the scrum team holds a sprint review with key stakeholders to present outcomes, gather feedback and plan future adaptions (Lawong & Akanfe, 2025; Schwaber & Sutherland, 2020). It is emphasized by Schwaber and Sutherland (2020) that sprint review should not only be a presentation but a working session. While sprint review focuses on the product and re- sults of the sprint, sprint retrospective focuses on the process to complete the work (Lawong & Akanfe, 2025). The purpose of sprint retrospective is to find ways to improve processes, quality and team effectiveness through reflecting on tools, interactions and challenges faced (Schwaber & Sutherland, 2020). Sprint retrospective is the event that concludes the sprint. The third category of scrum framework is scrum artifacts that represent work or value, containing artifacts of the product backlog, the sprint backlog and the increment (Schwa- ber & Sutherland, 2020). These artifacts promote transparency, shared understanding and focus by providing a reference point for measuring progress (Lawong and Akanfe, 2025; Schwaber and Sutherland, 2020). The product backlog is developed and refined by PO with inputs from key stakeholders and the scrum team and it’s continuously up- dated with detailed and prioritized items (Lawong & Akanfe, 2025; Schwaber & Suther- land, 2020). Schwaber and Sutherland (2020) explain that the product backlog is linked to the product goal, which defines the future state of the product and the product goal must be either fulfilled or abandoned before starting a new one. Developers select items from the product backlog to form the sprint backlog for each sprint, refining them with details such as priority and difficulty, and updating them throughout the sprint to track progress towards the sprint goal (Lawong & Akanfe, 2025; Schwaber & Sutherland, 2020). Schwaber and Sutherland (2020) explain that the sprint goal is flexible in a way that if the work proves to be different from what was initially expected, the developers can work with the product owner to adjust the scope of the sprint backlog while maintaining the sprint goal. The final artifact, the increment, represents a verified and usable addi- tion to the product that contributes to the product goal and must meet the determined definition of Done. Because scrum framework has been extensively successful, many larger enterprises with large-scale projects have also adopted scrum framework. However, since scrum framework was designed to small teams, implementing scrum to large-scale projects is not straightforward. Large-scale projects have greater complexity and require more re- sources consisting of multiple teams (Almeida & Espinheira, 2022). To modify Scrum framework to better support the characteristics of large-scale projects, Larman and Vodde developed large-scale scrum framework (LeSS) (Almeida & Espinheira, 2022). The fundamentals of Scrum framework: scrum events, iterative development, adaptabil- ity and transparency are the same in LeSS, but additionally guidelines for organizational structure, product management and working with multiple teams are presented (Almeida & Espinheira, 2022; Alqudah & Razali, 2016; Uludag et al., 2019). LeSS supports scalability by using a single product owner and central product backlog to facilitate co- ordination between multiple teams (Alqydah & Razali, 2016; Uludag et al., 2019). This is supported by modified coordination practices of joint scrum events such as sprint plan- ning, backlog refinement and retrospective which are attended by limited team repre- sentatives to enhance efficiency and alignment across teams (Alqudah & Razali, 2016; Uludag et al., 2019). Furthermore, according to Almeida and Espinheira (2022), LeSS en- courages organizational simplification with a minimal set of rules and a shift from pro- ject-oriented mindset to a product-oriented mindset. Additionally, LeSS presents ten technical and development practices to ensure high quality and adaptability in large- scale delivery: acceptance tests, architecture and design, clean codes, continuous deliv- ery, continuous integration, specification by example, test-driven development, test- driven thinking, test automation and unit tests (Almeida & Espinheira, 2022). Almeida and Espinheira (2022) emphasize that empirical process control, minimizing role com- plexity and maintaining customer focus through incremental delivery, LeSS aims to scale agility without compromising the core values of Scrum. 2.1.1 Agile in NPD and hardware projects Although APM is still primarily used in software development and lacks extensive theo- retical or practical grounding outside of it, according to Ciric et al. (2019) there is growing evidence that its use is increasing in other industries as well. APM is being increasingly applied also in hardware development due to it being particularly suitable for uncertain and complex conditions in which hardware development projects are often executed nowadays (Atzberger & Paetzold, 2019; Zasa et al., 2021). Ciric et al. (2019) write that the key motivations for adopting APM across different sectors include the need to de- crease the time for product or project delivery and improve responsiveness and adapta- bility to shifting priorities. However, Simpson and Sheth (2025) state that the pitfalls of trying to apply software-based Agile methods to physical products is that the tactics are not designed for hardware and critical elements are missing, which often leads to poor results. Moreover, while Gustavsson and Rönnlund (2013) note that understanding the behaviour of hardware products require extensive iterative work and simulated testing similar to software development, there are still several challenges unique to hardware development that must be carefully considered when applying APM in that field. Overall, according to Atzberger et al. (2019) the benefits of implementing APM are underesti- mated in soft factors such as communication, transparency and commitment, but on the other hand, overestimated in hard factors of controlling cost, time and quality. Cobb (2023) has recognized that the standard training for scrum masters and product owners focuses more on the theory and mechanics on how to practice scrum than on how to apply it in different situations such as hardware development. According to Cobb (2023), using Agile in hardware development does not necessarily mean directly apply- ing frameworks like Scrum, as often done in software development. Instead, it often in- volves creatively adapting Agile and Lean principles to build a highly efficient and effec- tive development process suited to the needs of hardware development (Cobb, 2023). Weichbroth (2022) also highlights that agile practices must be adapted to fit specific contexts and that APM presents its own challenges, risks and limitations in hardware development. The reason why adopting Agile to hardware development requires careful consideration is because hardware development has unique challenges, such as con- straints of physicality, which significantly differentiate it from software development (Atzberger & Paetzold, 2019). Significant challenges in hardware development that are unique compared to software development are related to the constraints of physicality (Atzberger & Paetzold, 2019). Hardware products being mechatronic or cyber-physical, containing mechanical, electri- cal and software components also bring its own challenges to iterative APM (Atzberger et al., 2019). Atzberger and Paetzold (2019) write that the production and testing of hardware prototypes essentially demand more time and resources than software itera- tions, making it difficult to deliver shippable increments within short development cycles. Long lead times for parts, especially from external suppliers, further restrict rapid itera- tions (Atzberger & Paetzold, 2019). Additionally, extended timelines for producing cus- tom tools and completing certifications, particularly in safety-critical areas, create signif- icant external dependencies (Atzberger & Paetzold, 2019). Atzberger and Paetzold (2019) add that the specialisation required in mechatronic development also constraints team availability, and coordinating across expertise domains and interfaces add further layers of complexity to agile practices. Moreover, synchronization between hardware, software and electronic further complicates iteration cycles and frequent feedback loops are harder to maintain due to stakeholder expectations of more complete and functional prototypes (Atzberger & Paetzold, 2019). On the other hand, Ciric et al. (2019) note that many of the challenges faced in hardware development, such as alignment among stake- holders, prioritization, insufficient time for testing and long feedback loops are also faced in software development. Many challenges may be rooted in the incompatibility of agile practices with organizational processes and functions, which Ciric et al. (2019) have also identified as one of the core challenges. Nevertheless, it’s evident that the tangible na- ture of physical products brings many unique challenges to applying APM in hardware development. These physical limitations directly affect APM practices such as continuous integration, automated testing and maintaining stable interfaces between teams (Atzberger & Paetzold, 2019). Nevertheless, evidence suggests that Agile can still bring benefits in hardware contexts. Gustavsson and Rönnlund (2013) write that even in hardware devel- opment, agile principles such as iterative work, simulation-based testing and team-level flexibility can enable responsiveness to change and decrease development time. Simu- lating environments and advanced testing techniques help hardware teams iterate ef- fectively despite physical constraints, enabling some of the core Agile benefits like im- proved adaptability and prioritization of the most valuable work (Gustavsson & Rönn- lund, 2013; Weichbroth, 2022). Gustavsson and Rönnlun (2013) note that unlike soft- ware which can be patched or upgraded post-deployment, hardware often requires a redesign or a completely new development cycle for changes. The teams from Gus- tavsson and Rönnlund’s (2019) study mitigated these kinds of legacy issues by defining project boundaries to end development at production handover and thereby avoiding costly post-production upgrades (Gustavsson & Rönnlund, 2013). Weichbroth (2022) presents three different Agile-oriented frameworks that are particu- larly suitable for hardware development: Scaled Agile Framework (SAFe), Scrum for hard- ware and Modified Agile for Hardware Development (MAHD). Additionally, Weichbroth (2022) presents hybrid Stage-Gate framework but this and other hybrid frameworks are later covered in the chapter of hybrid project management. The Scaled Agile Framework (SAFe) was developed for scaling agile practices across large enterprises, particularly in environments that require coordination among multiple teams and stakeholders (Ciancarini et al., 2022; Putta et al., 2018). Because of its suita- bility for implementing agile practices in large multi-team enterprises, SAFe has gained widespread popularity and is one of the most popular multi-team Agile methods (Cianca- rini et al., 2022; Sreenivasan & Kothandaraman, 2019). SAFe is built on combining mul- tiple agile methodologies: Scrum, Extreme Programming, Kanban and lean. Furthermore, SAFe expands these practices to work across four different levels of an organization: team, program, value stream and portfolio (Alqudah & Razali, 2016; Putta et al., 2018). All levels are tied together and each has their own roles, responsibilities, activities and structures (Alqudah & Razali, 2016; Ciancarini et al., 2022). Team level consists of agile teams that work as a typical scrum team (Alqudah & Razali, 2016; Putta et al., 2018). Program level consists of multiple agile teams that are dedicated to the program and create value to the program (Alqudah & Razali, 2016). At the program level, SAFe intro- duces Agile Release Trains (ARTs) which synchronize multiple agile teams through fixed- length iterations to develop large-scale systems (Alqudah & Razali, 2016: Putta et al., 2018). ARTs are followed by HIP (hardening, innovation, planning) iterations to produce potentially shippable increments or program increments (Alqudah & Razali, 2016; Putta et al., 2018). Alqudah and Razali (2016) write that a value stream refers to a continuous set of activities involved in defining, developing and delivering systems that provide on- going value to the business, customer or end user. Value streams are realized in SAFe through ARTs at the program level while investment themes indicate how the portfolio allocates funding to these ARTs in alignment with strategic objectives (Alqudah & Razali, 2016). These themes act as a funnel by filtering and translating strategic goals into busi- ness or technical epics within the portfolio backlog (Alqudah & Razali, 2016). Ciancarini et al. (2022) write that SAFe is based on four core values: business alignment, build-in quality, transparency and program execution. These core values are cited as con- tributing factors to enhanced productivity, quality, accelerated time-to-market, transpar- ency and improved team collaboration (Ciancarini et al., 2022; Putta et al., 2018). Weichbroth (2022) writes that in the context of hardware development, SAFe offers six tailored principles to address the hardware-specific constraints: organizing around value, assuming variability and preserving options, designing for change, building incrementally and integrating frequently, performing work in small batches, and establishing continu- ous integration for hardware. These principles aim to guide hardware teams in creating flexible and iterative development processes suited to the complexities of physical prod- uct development. However, while the structured and prescriptive nature of SAFe is ben- eficial for guiding large-scale system development, it has also drawn criticism. Its com- plexity and resource-intensive implementation present challenges such as resistance to change, difficulty in aligning distributed teams, test automation challenges and concerns about reduced agility (Ciancarini et al., 2022; Putta et al., 2018). Furthermore, some ar- gue that the rigidity of SAFe may conflict with the foundational Agile value of adaptability (Ciancarini et al., 2022). Nevertheless, Ciancari et al. (2022) find that when SAFe is fully supported by leadership and understood across the organization, it can facilitate system- atic improvements in the earlier mentioned benefits as well as in strategic alignment and enterprise-wide agility. Scrum for hardware is an adaptation of the traditional scrum framework tailored to meet the unique demands of hardware and system development (Weichbroth, 2022). Accord- ing to Weichbroth (2022) it integrates modular design principles and practices from lean and extreme programming. The framework outlines eight key focus areas to support suc- cessful implementation to hardware development: managing uncertainty in hardware projects, using stubs and mock-ups, promoting modular designs, enabling continuous integration, designing clear interfaces, applying test- and data-driven developments, forming effective teams and ensuring a functional product is delivered at the end of each sprint (Weichbroth, 2022). The third framework Weichbroth (2022) presents is modified Agile for hardware devel- opment (MAHD) which was developed by Simpson and Hinkle. MAHD framework was particularly developed for hardware that combines electronics, mechanical components and software (Simpson & Sheth, 2025). MAHD is based on four foundational principles: short development cycles for continuous learning and adaption to change, autonomous teams, validating work at the end of each development cycle, and applying rapid proto- typing strategies. Simultaneously, MAHD addresses the physical product requirements by allowing design freezes but also flexibility to change, quality planning, managing sup- ply chain, defining product attributes for electrical and mechanical components, devel- oping documentation, developing flexible prototyping and product validation strategies, and sharing resources and external partners (Weichbroth, 2022). MAHD includes the familiar agile practices, such as iterative development cycles and pri- oritized product backlog, but additionally introduces four key differences which take the unique aspect of hardware into account (Simpson & Sheth, 2025). The first difference comes on initiating a project which requires additional upfront planning to create structure and initiate the right direction compared to software development, where de- fining user stories is enough to start the project (Simpson & Sheth, 2025). Planning is done fast but comprehensively enough, including five on-ramp steps of refining the pro- ject: user stories, product attributes, focus matrix, IPAC iteration plans and task backlog. Simpson and Sheth (2025) highlight that although these on-ramp steps might resemble early waterfall activities, they are fundamentally different, focusing on collaboration and quick alignment on critical success factors to provide just enough detail to move forward confidentially. The second difference, according to Simpson and Sheth (2025), is that in- stead of one iterative development cycle, MAHD includes two levels of development cy- cles to align and manage the various disciplines required in hardware development. Ad- ditionally, to general sprints, there are also IPAC (integration, prototype, alignment and customer) iterations on product level which last between 1 to 6 sprints (Simpson & Sheth, 2025). Simpson and Sheth (2025) explain that these IPAC iterations focus on delivering system-level outcomes, ensuring integration across disciplines and subsystems, validat- ing the solutions and minimizing risk. The third difference is that hardware teams require a flexible backlog that allows them to organize tasks by discipline and subsystem, follow iteration milestones and manage additional requirements unique to hardware projects compared to software development (Simpson & Sheth, 2025). The fourth difference comes from the team roles defined in MAHD which differ a little from generalized scrum roles. Simpson and Sheth (2025) write additional to product owner, MAHD also includes product manager who acts as the ultimate decision-maker, making broader and critical decisions on scope, schedule and resources, while a supporting internal product owner keeps teams focused on customer value. Replacing the scrum master, MAHD has an agile project leader who manages cross-disciplinary coordination, removes obstacles and lead IPAC iteration planning with a stronger focus on facilitation and stakeholder alignment (Simpson & Sheth, 2025). MAHD also includes discipline-specific and system-level tech- nical leaders who define iteration goals, lead prototyping and manage their areas of the backlog (Simpson & Sheth, 2025). Simpson & Sheth (2025) also explain that while scrum teams are typically cross-functional and dedicated to one project at a time, MAHD team members include full- and part-time contributors across functions who commit to deliv- erables despite often being shared across multiple projects. 2.1.2 Strengths and Weaknesses of Agile and Scrum APM has been widely recognized across industries for its diverse strengths and benefits. These benefits can be divided into three primary categories: business, product and pro- cess, and team. Additionally, some benefits of scaling agile are introduced. Some of the benefits can also be included in multiple categories. One of the significant benefits of Agile is the increased focus on achieving meaningful business outcomes rather than accelerating delivery (Cobb, 2023). According to Cobb (2023), Agile emphasizes delivering value through adaptive and iterative methods that prioritize successful outcomes over speed alone. This approach enables organizations to align projects with strategic goals and customer expectations, which in turn improves stakeholder satisfaction (Ciric et al., 2019; Gemino et al., 2021). Gemino et al. (2021) found that Agile and hybrid projects significantly outperformed traditional approaches on stakeholder success measures although all three approaches, Agile, hybrid and tradi- tional, showed similar results on time, scope and budget. This supports the argument that the value-oriented principles of Agile strengthens stakeholder success without com- promising the triple constraint success metrics. Agile also reduces time-to-market by simplifying requirements definition and delivering incremental value more efficiently (Cobb, 2023). It allows for quicker reaction to chang- ing market conditions and customer demands, thus improving responsiveness and per- formance results (Santos & De Carvalho, 2022; Thesing et al., 2021). Furthermore, Ciric et al. (2019) writes that agile improves the organization’s ability to manage changing priorities. This can improve financial outcomes by reducing effort and increasing devel- opment speed through lean processes (Karrenbauer et al., 2019). Additionally, Agile fa- cilitates the transfer of knowledge and know-how, enabling team to better understand and respond to evolving customer needs (Ciric et al., 2018). The integration of lead users and early market alignment ensures that new product development is oriented toward future customer needs, which offers a strategic business advantage and strengthens stakeholders and customer commitment (Ciric et al., 2018). Agile practices also result in significant improvements in product development and pro- ject execution. Agile approach supports excellent product outcomes by embedding qual- ity assurance into each step of the development cycle (Cobb, 2013; Karrenbauer et al., 2019; Thesing et al., 2021). Cobb (2023) explains that in contrast to the Waterfall model, where quality is often a separated step, Agile assigns quality responsibility to the entire team, promoting a shared commitments to building quality. Frequent feedback loops and short iterations support early error detection and continuous refinement (Thesing et al., 2021; Karrenbauer et al., 2019). This iterative structure provides flexibility to inno- vation and to manage uncertainty effectively (Cobb, 2023; Ciric et al., 2018; Thesing et al., 2021). Teams are encouraged to develop exploratory prototypes and conduct incre- mental testing to experiment with partial solutions, clarify requirements and refine the product over time (Cobb, 2023; Ciric et al., 2018; Thesing et al., 2021). According to Karrenbauer et al. (2019), the flexibility and adaptability improved by this iterative struc- ture is particularly beneficial in complex or regulated environments where requirements can change quickly and issues such as compatibility with modules and integration with hardware exists. Furthermore, Santos and De Carvalho (2022) write that Agile improves the management of evolving requirements through active stakeholder engagement, re- sulting in products that align closely with user needs. Karrenbauer et al. (2019) also add that Agile improves usability through simplified documentation and transparency. This transparency is enabled through continuous feedback and ongoing comparison between planned and actual progress (Karrenbauer et al., 2019). Additionally, the use of lean frameworks like Scrum allows teams to remain closely aligned with real-world conditions when frequent adjustments are made during each iteration to better reflect evolving project realities (Karrenbauer et al., 2019). With these characteristics, APM also supports risk mitigation by allowing for early identification of deficiencies, thus improving failure management processes (Santos & De Carvalho, 2022; Thesing et al., 2021). Agile strengthens collaborative and dynamic work environments that improve team functioning and motivation (Karrenbauer et al., n.d.; Santos & De Carvalho, 2022). By promoting frequent feedback and collaboration, Agile helps build a culture of shared responsibility and ownership and mutual respect which also improves project visibility (Ciric et al., 2018; Karrenbauer et al., n.d.; Santos & De Carvalho, 2022). This environment further contributes to increased morale and greater job satisfaction (Cobb, 2023; Karren- bauer et al., 2019). The iterative structure of Agile also strengthens team motivation by reinforcing transparency and adaptability (Karrenbauer et al., n.d.; Santos & De Carvalho, 2022). Teams continuously learn and improve their processes, evolving toward more ef- fective and efficient practices (Karrenbauer et al., n.d.; Santos & De Carvalho, 2022). Ac- cording to Thesing et al. (2021), these characteristics are especially valuable during early development phases where speed and flexibility are essential. Despite the significant challenges of adopting large-scale APM, Santos and De Carvalho (2021) highlighted some benefits that emerge when agile principles are effectively scaled. One of the primary benefits is increased flexibility within mature organizations, showing the suitability of agile also for large and complex projects with long life cycles (Santos & De Carvalho, 2021). Improved collaboration during planning events leads to stronger alignment with business requirements and facilitates shared ownership and responsibil- ity across organizational units (Santos & De Carvalho, 2021). The emphasis on continu- ous feedback and client engagement contributes to higher levels of trust, transparency, and responsiveness in product development (Santos & De Carvalho, 2021). Santos & De Carvalho (2021) also write that the identification of critical paths and inter-team depend- encies enables more effective prioritization of requirements, minimizing resource waste and improving traceability, testing capabilities, and product quality. To achieve these benefits, it’s critical that the organization has strategic alignment, strong support and shared understanding of the benefits of adopting large-scale APM (Santos & De Carvalho, 2021). Table 1. Strengths of APM Strengths Sources Business: • Focus on achieving meaningful business outcomes • Alignment of projects with strategic goals and customer expectations • Improved stakeholder satisfaction and success • Reduced time-to-market through incremental delivery • Improved responsiveness to changing market conditions • Ability to manage changing priorities • Increased financial outcomes through lean processes • Knowledge transfer and customer understanding • Early market alignment and customer commitment Cobb (2023); Ciric et al. (2018, 2019); Gemino et al. (2021); Karren- bauer et al. (2019); Santos & De Carvalho (2022); Thesing et al. (2021) Product and process: • Embedded quality assurance throughout development • Early error detection and continuous improvement • Support for flexibility and innovation through iterations • Active stakeholder engagement ensures alignment with user needs • Improved usability, transparency, and documentation sim- plification • Improved adaptability in complex environments • Improved risk mitigation through early deficiency identifi- cation Cobb (2023); Ciric et al. (2018); Karrenbauer et al. (2019); Thesing et al. (2021); Santos & De Carvalho (2022) Team: • Strengthened collaboration and motivation • Culture of shared responsibility and transparency • Increased morale, mutual respect, and job satisfaction • Continuous learning and process improvement • Higher adaptability and visibility within projects Cobb (2023); Ciric et al. (2018); Karrenbauer et al. (2019, n.d.); Santos & De Carvalho (2022); Thesing et al. (2021) Scaling Agile: • Increased flexibility in large and complex projects • Improved collaboration and shared ownership across units • Increased trust, transparency, and responsiveness • Improved prioritization and resource utilization • Improved product quality and traceability through inter- team coordination Santos & De Carvalho (2021) Although APM has proven effective across various industries due to its adaptive and it- erative nature, its implementation still faces several challenges. The identified challenges can be divided into following categories: organizational challenges, managerial chal- lenges, agile method barriers, customer challenges, team challenges, product and pro- cess challenges and scaling challenges. Organizational resistance to agile adoption remains a common challenge. Ciric et al. (2019) identify the incompatibility of agile methods with existing organizational pro- cesses and functions as a common challenge, both within and beyond software devel- opment. Ciric et al. (2019) emphasize that in many cases agile methods conflict with traditional business structures that rely on rigid planning cycles, linear reporting struc- tures and detailed documentation. This misalignment limits the flexibility and iterative improvements that are central in agile methods (Ciric et al., 2019). Additionally, the lack of formal project management strategy, guidelines and standardized processes compli- cate the integration of Agile (Ciric et al., 2019). Atzberger & Paetzold (2019) also note the challenge of establishing an agile mindset among individuals. Teams that are used to traditional, plan-driven approaches often struggle to rethink their work through agile principles (Atzberger & Paetzold, 2019). The transition requires not only a shift in work- ing methods but also a deeper cultural change in how individuals approach teamwork and accountability (Atzberger & Paetzold, 2019). Moreover, Atzberger & Paetzold (2019) note that although Agile promotes transparency in many ways, if the environment and culture is not safe and truly support the transparency, individuals may withhold from openly bringing up challenges and mistakes. Ultimately, this can lead to frustration, dis- engagement and resistance to Agile adoption, undermining its effectiveness (Atzberger & Paetzold, 2019). Managerial challenges significantly affect the successful adoption and operation of agile methods. A common challenge is the difficulty in achieving senior management spon- sorship. Hoda and Murugesan (2016) found that reluctance to support agile practices often comes from senior management’s focus on final deliverables and discomfort with changing established development processes. Moreover, senior management may be hesitant to fully sponsor Agile transformation because of discomfort with iterative deliv- ery models and reduced control over detailed planning (Hoda & Murugesan, 2016). Even when agile methods were accepted by senior management, requirements for extensive documentation were still required, conflicting with the agile practices of only involving minimal documentation (Hoda & Murugesan, 2016). According to Hoda & Murugesan (2016), another managerial gap involves limited investment in team development. They note that some managers are unwilling to support professional training or certification for agile teams, perceiving it as unnecessary or low priority. This resistance to skill-build- ing compromises the team’s ability to integrate and effectively apply agile principles (Hoda & Murugesan, 2016). Furthermore, managerial misunderstanding or misapplica- tion of agile roles and responsibilities creates conflict. Managers may unintentionally mi- cromanage teams or continue enforcing hierarchical control models, limiting self-organ- ization and cross-functional collaboration (Hoda & Murugesan, 2016). Schwaber and Sutherland (2020) emphasize the importance of servant leadership within Agile settings, where managers facilitate rather than direct team efforts. Agile method and its characteristics also have practical challenges. Scope management is a central challenge in Agile projects since the foundational aspect of flexibility and adaptability also increases the risk of uncontrolled scope creep if changes are introduced without proper reprioritization of the backlog (Sithambaram et al., 2021). Sithambaram et al. (2021) write that although Agile approaches avoid extensive upfront planning, it should still be done as much ahead as possible considering all available information and predictable elements. In addition, risk management shouldn’t be neglected because risk identification and mitigation are also important in Agile to prevent being surprised by a risk that could have been foreseen (Sithambaram et al., 2021). In addition, Hoda and Murugesan (2016) identified the pressure to manage interruptions and urgent requests in the middle of a sprint as a challenge. These disruptions risk sprint integrity and reduce team focus and productivity (Ciric et al., 2019; Hoda & Murugesan, 2016). Although Scrum promotes maintaining a stable work environment throughout the sprint, practical realities often force teams to respond to unplanned tasks which reduces velocity and delivery predictability. Another challenge occurs in the difficulty of workload estimation during collaborative sprint planning (Hoda & Murugesan, 2016). Hoda and Murugesan (2016) explain that while Agile encourages team-based estimation practices, differences in experience levels as well as understanding the product and unclear requirements of- ten lead to unreliable estimates, impacting sprint outcomes and stakeholder expectation. Customer-related challenges mainly revolve around communication and expectation management. Hoda and Murugesan (2016) emphasize the difficulty in gathering clear and timely requirements from customers. While customers usually are able to give high- level requirements, gathering detailed requirements and acceptance criteria, which are critical for accurate development and testing, turns out to be a challenge (Hoda and Murugesan, 2016). Additionally, Ciric et al. (2019) write that beyond software develop- ment, visibility into client value and predictability of delivered business value are signif- icant concerns. These challenges indicate a disconnect between agile teams and cus- tomer expectations, which might affect stakeholder satisfaction. Team dynamics pose several challenges in Agile environments since teams are expected to be self-organized and autonomous. Hoda and Murugesan (2016) write that maintain- ing autonomy, particularly in newly formed and transitioning teams, requires a cultural shift that is difficult to achieve. Some team members might also resist or struggle assuming responsibility or being self-direct (Hoda & Murugesan, 2016). Additionally, the lack of clarity in task-level requirements, including missing acceptance criteria and high task dependency, further hinders effective team performance (Hoda & Murugesan, 2016). Hoda and Murugesan (2016) state that if the task-level issues are left unresolved, it leads to confusion, duplicated efforts and reduced velocity. Generally, from the challenges collected by Santos and De Carvalho (2021) the ones re- lated to product and process category are not cited as many times as the challenges in other categories. This implies product and process challenges, such as quality and pro- gress measurement, may not be as significant barriers to Agile adoption than challenges identified in other categories. However, project size is the one challenges that rises from the product and process category (Santos & De Carvalho, 2021). Santos and De Carvalho (2021) explain that project size is a significant challenge because agile practices need to be implemented differently in large projects when project complexity increases and the complexity further decreases the accuracy of task effort estimates. Moreover, adopting APM to large-scale project brings its own additional challenges, involving managing tech- nical complexity but also addressing a range of organizational, cultural and structural factors. Santos and De Carvalho (2021) have identified geographic distribution, regula- tory compliance, organizational and cultural complexities and corporate strategy issues as critical factors related to large-scale projects where agile teams are scaled. These fac- tors introduce significant coordination demands and often reduce the autonomy of self- managed agile teams (Santos & De Carvalho, 2021). Additionally, leadership and mana- gerial engagement play a critical role in successful scaling of Agile. Santos & De Carvalho (2021) write that leadership must actively shape strategy, provide cross-functional sup- port and facilitate structural changes that reinforce agile values. Traditional project man- agement metrics, such as the project triple constraints of scope, cost and time, must be adjusted to accommodate the iterative and adaptive characteristics of agile (Santos & De Carvalho, 2021). Furthermore, APM’s focus on speed and continuous delivery instead of documentation and specifications can potentially weaken auditability and compliance (Santos & De Carvalho, 2021). This can be particularly challenging when Agile methods are used in industries that require strict certifications, such as ISO and CMMI, which typ- ically demand extensive documentation and can also be time-consuming (Atzberger & Paetzold, 2019; Santos & De Carvalho, 2021). Table 2. Challenges of APM Challenges Sources Organizational: • Incompatibility with existing organizational processes • Resistance to agile adoption • Lack of formal strategy and standardized processes • Difficulty establishing an agile mindset • Unsafe culture discouraging transparency Ciric et al. (2019); Atzberger & Paetzold (2019) Managerial: • Lack of senior management sponsorship • Discomfort with iterative delivery and reduced control • Excessive documentation requirements • Limited investment in team development • Misunderstanding of agile roles and servant leadership gaps Hoda & Murugesan (2016); Schwaber & Sutherland (2020) Method barriers: • Scope creep • Sprint interruptions and unplanned work • Difficulty with work load estimation accuracy • Reduced predictability of delivery • Pressure to balance flexibility and structure Hoda & Murugesan (2016); Ciric et al. (2019); Sithambaram et al., 2021 Customer: • Difficulty gathering detailed requirements • Misaligned expectations and satisfaction gaps Hoda & Murugesan (2016); Ciric et al. (2019) • Limited visibility into client value and business predictabil- ity Team: • Difficulty achieving self-organizing teams • Resistance to accountability and autonomy • Lack of clarity in task requirements • High task dependency and confusion • Reduced velocity and duplicated effort Hoda & Murugesan (2016) Product and process • Difficulty measuring quality and progress • Project size increases complexity and reduces estimate ac- curacy • Scope management issues (scope creep, unclear defini- tion) • Cost management and resourcing difficulties • Lack of upfront planning and risk management Santos & De Carvalho (2021); Sithambaram et al. (2021) Scaling Agile: • Complexity in coordination and inter-team dependencies • Geographic, regulatory, and cultural barriers • Compliance and documentation constraints (ISO, CMMI) • Reduced team autonomy in scaled contexts • Leadership engagement and strategic alignment gaps • Misfit of traditional metrics (scope, cost, time) • Limited auditability and traceability Santos & De Carvalho (2021); Atzberger & Paetzold (2019) 2.2 Traditional project management & Waterfall model According to Wysocki (2019), TPM formed the foundation for modern project manage- ment. TPM, often referred as waterfall method, is a linear project management methodology that assumes that the circumstances of the project are predictable and clear (Gemino et al., 2021; Špundak, 2014; Zasa et al., 2021). It contains distinct goals for each phase of development (Breyter, 2023). Each phase of the development process is only done once in linear order, thus the entire product is tested and delivered all at once at the end of a project (Cobb, 2023; Wells, 2012). This is why TPM methodologies are particularly suitable for projects that have been executed before or have low uncer- tainty (Cobb, 2023). Detailed project plan is defined at the beginning of the project based on customer requirements that are assumed to be clear and stable without any need for changes during the project (Ciric et al., 2019). Because of the assumed predictability, TPM has a strong focus on planning and control, and the goal is to execute the plan effi- ciently to complete the project within the planned triple constraints of scope, time and cost (Ciric et al., 2019; Gemino et al., 2021). Over time, multiple frameworks have been developed for executing TPM, most notable the Stage-Gate model for NPD, providing a systematic way to plan, execute and control projects. Figure 3. Waterfall model (adapted from Breyter, 2023) 2.2.1 Stage-Gate model Stage-Gate moddel is a cross-functional model that breaks down a NPD project into se- quential stages from idea generation to the launch of the product, emphasizing pre-de- velopment tasks and planning (Cooper, 2016). It also acts as an action guide, providing specific best practices for each stage (Cooper, 2016). Furthermore, the model aims to ensure process quality in innovation development by providing structured guidance and discipline at each step (Reiff & Schlegel, 2022). It was developed to address the challenges of managing unstructured development projects by providing structure, con- trol, excessive front-end planning and work progress monitoring (Bianchi et al., 2020). This linear and plan-driven approach, requiring early decisions and adherence to prede- fined plans, has been a central factor in its widespread adoption across industries for decades (Reiff & Schlegel, 2022; Zasa et al., 2021). According to Reiff & Schlegel (2022), a foundational principle of the original Stage-Gate model is the early fact-based and clear definition of products to improve project outcomes. Detailed product specifications and a project plan are defined early in the process, as well as design freeze, to avoid delays in the product design and implementation stages (Bianchi et al., 2020; Cooper & Sommer, 2018). Bianchi et al. (2020) and Cooper and Sommer (2018) note that once design freeze is done, any later modifications are seen as troublesome since Stage-Gate doesn’t sup- port reversible iterations and later modifications can be costly. There are multiple variations of the Stage-Gate model but typically the model contains six stages, including idea screening, with defined tasks and deliverables to be fulfilled (Cooper, 2023; Cooper & Sommer, 2018; Sommer et al., 2015). Furthermore, the model includes five gates between the stages where go/kill investment decisions are made, cre- ating a funnel model (Cooper, 2023; Cooper & Sommer, 2018; Sommer et al., 2015). The model is presented in the Figure 4. Cooper (2016) describes that the go/kill decisions at each gate guide resources to the most potential and beneficial projects as resources are allocated for projects that get a go-decision for the next stage. Figure 4. Stage-Gate model (adapted from Cooper, 2023) The first stage, sometimes referred as stage 0, is dedicated for discovering and generat- ing new potential product ideas (Cooper, 2023). During this stage technical research is done and for potential new product ideas a one-pager is done for describing the idea (Cooper, 2023). Cooper (2023) highlights that stage 0 for ideation is not officially part of the project, but because it’s considered essential by many organizations, it is also im- portant to handle formally, building a defined and proactive system for idea generation. Stage 0 is followed by gate 1 in which the product idea is screened based on qualitative criteria such as project feasibility, strategic alignment, market opportunity and ability to leverage the organization’s resources (Cooper, 2023). Cooper (2023) highlights that fi- nancial criteria is not typically done during gate 1 because there’s not enough infor- mation yet. The go/kill investment decision to start the project is made based on the screening and resources are committed to the project (Cooper, 2023). Stage 1 is typically relevantly short stage dedicated for scoping and determining the technical and market- place merits of the project (Cooper, 2023). In gate 2, a second more rigorous screening is done, mainly re-evaluating the same cri- teria of gate 1 with the new information gathered from stage 1 (Cooper, 2023). Addition- ally, financial criterion is lightly assessed before making the go decision to move to stage 2 (Cooper, 2023). Cooper (2023) describes stage 2 as a “make or break” stage where most new product development failures happen. In stage 2, a cross-functional team con- ducts a detailed investigation about the product and a business case is constructed (Cooper, 2023). This includes for example a market analysis, customer research, compet- itive analysis, concept testing, detailed technical assessment and detailed business and financial analysis (Cooper, 2023). Project definition, justification and detailed plan are made for moving to gate 3, which the last gate before development stage with substantial financial commitments (Cooper, 2023). Cooper (2023) explains that all tasks from stage 2 are reviewed and financial anal- ysis is particularly carefully examined to make sure results are positive to pass the gate to stage 3. In stage 3, the actual development of the product is started with the implementation of the project plan (Cooper, 2023). Cooper (2023) writes that for large projects, multiple milestones and reviews can be included in this stage as check points, providing more control for project management. Gate 4 acts as a post-development re- view to check on the process to confirm the development fulfils quality aspects and product is consistent with the original definition (Cooper, 2023). Financial analysis is also reviewed and updated based on current data (Cooper, 2023). Furthermore, test and val- idation plans are made and approved for moving to stage 4 for immediate implementa- tion (Cooper, 2023). In stage 4, the viability of the project is tested and validated though multiple aspects: the product, production process, financial and customer acceptance (Cooper, 2023). Cooper (2023) writes that this includes tasks such as products tests, user trials, pilot production and operations and trial sells, and furthermore the business and financial analyses are revised. Cooper (2023) adds that if this stage is not successful, it is possible to go back to stage 3 to continue development. A successful stage 4 moves to the gate 5 which is the final gate before full production and market launch (Cooper, 2023). According to Cooper (2023), this gate mainly acts as a check for readiness to move to full production based on reviewing the results of stage 4. Passing gate 5 is followed by final stage 5 of product launch where the product is moved from the project to operations (Cooper, 2023). The project is officially terminated when the new product is fully commercialized, and a post-launch review is conducted reviewing the performance of the project (Cooper, 2023). 2.2.2 Strengths and weaknesses A core benefit of TPM, specifically the widely adopted Stage-gate mode, is its emphasis on rigorous planning and early decision-making. Cooper (2023) writes that with each step of the Stage-Gate model more information is gathered, and uncertainties are re- duced which is why the model is also presented as a risk mitigating model. Rigorous up- front planning and freezing of the product design foster stability, discipline and compli- ance which can lower development costs, enable timely project completion and improve product quality (Bianchi et al., 2020). However, Bianchi et al. (2020) note that these benefits come from the Stage-Gate model’s assumption that problems and solutions can be anticipated in advantage and risk can be managed proactively with careful planning. Another advantage is efficiency in resource allocation since in each stage cross-func- tional teams execute tasks both concurrently and in parallel, and with each gate passed more resources are allocated for the project (Cooper, 2023). Furthermore, TPM meth- odology provide fixed roles and responsibilities, stable processes, systematic documen- tation, reliable estimation of time and budget and measurable progress through mile- stones (Thesing et al., 2021). Additionally, because customer feedback is typically col- lected only at the end of the process teams can avoid lengthy and costly prototyping stages, instead focusing on refining the most promising design for launch (Bianchi et al., 2020). These characteristics make TPM approach suitable where predictability, account- ability and structured governance are essential. From a wider perspective, TPM is also valued for its ability to provide managerial control, organizational structure and trans- parency. Milestone reviews and gate approvals in the Stage-Gate model allow manage- ment to monitor progress closely and make informed go/kil decisions, reducing the risk of investing in unfavourable projects (Cooper & Sommer, 2018). Table 3. Strengths of TPM Strengths Sources Business: • Front-end planning and early deci- sion-making • Reduced uncertainty and im- proved risk mitigation • Stability, discipline and compli- ance lower costs • Improved quality Bianchi et al., 2020; Cooper, 2023 Managerial: Cooper, 2023; Cooper & Sommer, 2018; Thesing et al., 2021 • Efficient resource allocation through gate-based decision-mak- ing • Improved process monitoring • Structured governance and trans- parency through documentation and milestones • Clear fixed roles Product and process: • Concurrent and parallel task exe- cution improves process efficiency • Avoidance of lengthy prototyping stages saves time and focuses re- sources Bianchi et al., 2020; Cooper, 2023 Despite these advantages, TPM methodologies face significant limitations when applied to uncertain or rapidly changing environments (Ciric et al., 2019; Cooper & Sommer, 2018). One of the central criticisms is their lack of adaptability, as they are often consid- ered too rigid and linear to effectively respond to evolving market and customer needs, which are common in modern projects (Cooper & Sommer, 2018; Reiff & Schlegel, 2022). Bianchi et al. (2020) and Thesing et al. (2021) note that it is difficult to fully gather user needs or design alternatives during the early planning stages, particularly in NPD pro- jects. One main reason for this is that customers often struggle to define all the require- ments at the early stages (Ciric et al., 2019). The linear process of Stage-Gate model means that key decisions are made before all essential information is available, increas- ing the possibility of errors (Bianchi et al., 2020; Thesing et al., 2021). Late customer feedback and the inflexibility to adapt in later stages of the project increase the risk of discovering misalignments with customer and market needs only after significant re- sources have been invested (Bianchi et al., 2020). These late-stage corrections can cause resource-intensive rework and costly delays (Bianchi et al., 2020). Gemino et al. (2021) also note that the likelihood of stakeholder dissatisfaction increases with late-stage mis- alignments and corrections. Additionally, according to Bianchi et al. (2020), proactive risk management often leads to over-specification of products, resulting in unnecessary complexity or gold plating where unrequested features are delivered. In the end, the heavy reliance on detailed upfront planning can also mean that large portions of the project plan must be discarded when too many changes become necessary (Maier & Emmerich, 2022). Table 4. Challenges of TPM Challenges Sources Business: • Lack of adaptability and rigidity in responding to changing customer and market needs Cooper & Sommer, 2018; Reiff & Schlegel, 2022 Managerial: • Decision-making based on incom- plete early-stage information in- creases error Bianchi et al., 2020; Thesing et al., 2021 Product and process: • Late customer feedback can cause misalignment and costly rework • over-specification and gold-plat- ing due to proactive risk manage- ment • Discarding of plans when exces- sive changes occur undermines ef- ficiency Bianchi et al., 2020; Gemino et al., 2021; Maier & Emmerich, 2022 2.3 Hybrid project management HPM refers to the combination of traditional plan-driven methodologies and adaptive Agile methodologies (Mirzaei et al., 2025; Reiff & Schlegel, 2022; Székely et al., 2025). Reiff and Schlegel (2022) have identified two primary definitions of HPM. One describes HPM as a combination of TPM and APM by applying TPM practices at the decision-mak- ing level and agile practices at the operational level (Reiff & Schlegel, 2022). The other definition describes HPM as a result from integrating APM practices into already existing TPM methodologies (Reiff & Schlegel, 2022). In both cases the goal is to combine the strengths of APM and TPM methodologies while avoiding their limitations (Reiff & Schlegel, 2022; Székely et al., 2025). Several studies have found that most Agile imple- mentations are in fact using hybrid methods rather than a pure Agile approach (Bianchi et al., 2022; Edwards et al., 2019; Gemino et al., 2021; West et al., 2011). Reed et al. (2024) also found that despite many stating following only agile practices, predictive techniques and tools were still often used. One reason for this is that Agile adoption is often being practitioner-led, which leads to development teams using Agile but areas outside their control continue following more TPM methodologies (Gemino et al., 2021; West et al., 2011). Furthermore, this may suggest that organization’s leadership and pro- ject managers must balance between predictability and adaptability and therefore strug- gle to follow pure agile practices (Reed et al., 2024; Sithambaram et al., 2021). The growing relevance of HPM reflects the increasing complexity, uncertainty and con- tinuous rapid change in modern project environments (Székely et al., 2025; Zasa et al., 2021). According to Zasa et al. (2021) traditional methods such as the Stage-Gate model have proven less effective when product development activities become unpredictive, involve frequent rework or require adaptation even in late stages of the project. Today’s fast-changing conditions also challenge the feasibility of following the Stage-Gate model’s linear step-by-step structure (Cooper, 2016; Zasa et al., 2021). Contrarily, relying solely on Agile methods can be challenging because they lack the structure, governance and documentation that especially large-scale organizations require (Sithambaram et al., 2021; Zasa et al., 2021). West et al. (2011) also note that industries with strict compliance requirements require well established governance processes in NPD. For these reasons HPM has emerged with the aim of combining the strengths of both Agile and TPM meth- odologies, resulting in an adaptive and responsive project management methodology that simultaneously offers enough control and documentation (Cooper, 2016; Cooper & Sommer, 2018; Reiff & Schlegel, 2022; Sommer et al., 2015; Székely et al., 2025; Zasa et al., 2021). According to Reiff & Schlegel (2022), this balance is particularly valuable for organizations where innovation and adaptability must be maintained without undermin- ing planning reliability. Székely et al. (2025) write that industries such as manufacturing, R&D, IT and SC management are particularly suitable for implementing HPM because these industries often have complex, dynamic and high-stakes projects where it’s essential to balance flexibility and structure. Azenha et al. (2021) note that HPM is pri- marily used in projects with complex scope and high technical uncertainty where market demands are presumed to change, requiring adaptability and quick responsiveness. Additionally, NPD projects in non-software industries being less modular and requiring cross-functional collaboration between multiple teams make long-term planning essential and benefit from HPM approach (Zasa et al., 2021). Multiple reasons to why particularly large organizations are more likely to opt toward HPM rather than pure Agile methodology have been identified. Zasa et al. (2021) and Reed et al. (2024) write that large organizations likely have established and strong TPM practices in use, which they are not willing to abandon completely. Gemino et al. (2021) further reason this by organizations wanting to maintain control over managing large and complex projects with pre-set budgets and