Otto Salvi Applying Agile Project Management to Network Infrastructure Projects: Developing a Hybrid Model for Elisa Oyj Vaasa 2025 School of Technology and Innovations Master’s thesis in Industrial Management Master of Science in Economics and Business Administration 2 UNIVERSITY OF VAASA School of Technology and Innovations Author: Otto Salvi Title of the thesis: Applying Agile Project Management to Network Infrastructure Pro- jects: Developing a Hybrid Model for Elisa Oyj Degree: Master of Science in Economics and Business Administration Discipline: Industrial Management Supervisor: Jyri Naarmala Year: 2025 Pages: 84 ABSTRACT: This thesis explores the potential of using Agile project management in network infrastructure projects at Elisa Oyj, a leading telecommunications and digital services provider in Finland. The organization recently updated its project management model, which continues to rely on tradi- tional project management methodologies. However, there is a growing interest from corporate customers in Agile, leading the organization to investigate how Agile methodologies could be applied in customer project implementations. The thesis follows design science research methodology (DSRM), aiming to design and evaluate a hybrid project management model that integrates Agile practices into Elisa’s customer delivery context. The research contributes to theory by adapting traditional project management frame- works to include Agile practices, specifically within the context of network infrastructure pro- jects. Before developing the model, the current state of Agile project management at Elisa was examined through semi-structured interviews with internal stakeholders to understand how Ag- ile is used in other departments. The interviews revealed that Agile practices, particularly Scrum, have been successfully implemented in internal development teams and some customer pro- jects, demonstrating benefits such as enhanced flexibility, improved collaboration, and better alignment with customer needs. However, challenges remain, including contractual constraints, a lack of dedicated teams, and operating in a multi-project environment, which have limited broader adoption. Based on these insights, a hybrid project management model was developed, combining tradi- tional project management with Agile practices and Scrum. The model utilizes both Microsoft Project’s traditional Gantt chart functionality and Agile task boards to structure and manage the work. The model was validated through simulation rather than in a real-life project setting, using expert feedback to assess its relevance and applicability. Despite the lack of real-world testing, the evaluation indicates that the model is relevant, useful, and adaptable to Elisa’s project envi- ronment, offering a solid foundation for future experimentation and refinement. The simulation suggested that the hybrid model could potentially enhance flexibility, improve stakeholder col- laboration, and better align with evolving customer expectations. The study contributes practi- cal recommendations for integrating Agile practices into traditional project management frame- works and offers a foundation for further development of hybrid approaches in network infra- structure projects. KEYWORDS: Project management, Agile project management, Hybrid project management, Scrum, Network infrastructure projects 3 VAASAN YLIOPISTO Tekniikan ja innovaatiojohtamisen yksikkö Tekijä: Otto Salvi Tutkielman nimi: Ketterän Projektinhallinnan Soveltaminen Verkkoinfrastruktuuri- projekteihin: Hybridimallin kehittäminen Elisa Oyj:lle Tutkinto: Kauppatieteiden maisteri Oppiaine: Tuotantotalous Työn ohjaaja: Jyri Naarmala Valmistumisvuosi: 2025 Sivumäärä: 84 TIIVISTELMÄ: Tämä tutkielma tarkastelee ketterän projektinhallinnan soveltamisen mahdollisuuksia verk- koinfrastruktuuriprojekteissa Elisa Oyj:llä, joka on johtava telekommunikaatio- ja digitaalisten palvelujen tarjoaja Suomessa. Organisaatio on viime aikoina päivittänyt projektinhallintamal- linsa, joka edelleen perustuu perinteisiin projektinhallinnan menetelmiin. Kuitenkin yritysasiak- kaiden kiinnostus ketteriä menetelmiä kohtaan on kasvanut, minkä seurauksena Elisa on alkanut selvittää, miten ketteriä toimintamalleja voitaisiin hyödyntää asiakasprojektien toteutuksessa. Tutkielma noudattaa design science research- tutkimusmetodologiaa (DSRM) ja tavoitteena on kehittää hybridiprojektinhallintamalli, jossa ketteriä menetelmiä yhdistetään Elisan asiakastoi- mitusympäristössä käytettäviin perinteisiin projektinhallinnan menetelmiin. Tutkielma tuottaa teoreettista tietoa mukauttamalla perinteisiä projektinhallinnan viitekehyksiä sisältämään ket- teriä menetelmiä erityisesti verkkoinfrastruktuuriprojektien näkökulmasta. Ennen mallin kehit- tämistä selvitettiin Elisan ketterän projektinhallinnan nykytila puolistrukturoitujen haastattelu- jen avulla. Haastatteluissa kerättiin kokemuksia sidosryhmiltä ja pyrittiin ymmärtämään, miten ketteriä menetelmiä hyödynnetään muissa yksiköissä. Haastatteluiden perusteella kävi ilmi, että ketteriä menetelmiä, erityisesti Scrum-viitekehystä, on onnistuneesti käytetty sisäisissä kehitys- tiimeissä ja joissakin asiakasprojekteissa. Käytön hyötyinä nähtiin muun muassa lisääntynyt jous- tavuus, parantunut yhteistyö ja parempi kyvykkyys vastata asiakkaan tarpeisiin. Laajamittaisen käyttöönoton osalta koettiin kuitenkin haasteita, kuten sopimusten muodostamat rajoitteet, de- dikoitujen tiimien puute ja moniprojektiympäristössä työskentely. Näiden havaintojen pohjalta kehitettiin hybridiprojektinhallintamalli, jossa yhdistyvät perintei- nen projektinhallinta, ketterät menetelmät ja Scrum-viitekehys. Mallissa hyödynnetään Micro- soft Projectin perinteistä Gantt-kaaviotoiminnallisuutta sekä Agile-tauluja työn suunnittelussa ja hallinnassa. Mallin toimivuutta arvioitiin simulaation avulla, ei kuitenkaan todellisessa projekti- tilanteessa. Arviointi perustui asiantuntijapalautteeseen, jolla mallin soveltuvuutta Elisan ympä- ristössä tarkasteltiin. Vaikka mallia ei testattu käytännössä, arvioinnin perusteella malli on hyö- dyllinen ja mukautettavissa Elisan projektitoimintaan. Simulaatio osoitti, että malli voi lisätä joustavuutta, parantaa sidosryhmien välistä yhteistyötä ja vastata paremmin asiakkaiden muut- tuviin vaatimuksiin. Tutkielma tarjoaa käytännön suosituksia ketterien menetelmien käytäntö- jen integroimiseksi perinteisiin projektinhallinnan viitekehyksiin sekä pohjan hybridilähestymis- tapojen jatkokehitykselle verkkoinfrastruktuuriprojekteissa. AVAINSANAT: Projektinhallinta, Ketterä projektinhallinta, Hybridiprojektinhallinta, Scrum, Verkkoinfrastruktuuriprojektit 4 Contents 1 Introduction 7 1.1 Background 7 1.2 Objectives and research questions 9 1.3 Structure of the thesis 10 2 Case organization 11 2.1 Elisa Oyj 11 2.2 Project management at Elisa Oyj 11 2.3 Elisa project management model 12 2.4 Hybrid project management at Elisa Oyj 13 3 Literature review 15 3.1 Traditional project management 15 3.1.1 The Waterfall methodology 16 3.1.2 Stage-Gate model 16 3.1.3 Benefits and limitations of traditional project management 17 3.2 Agile project management 18 3.2.1 Agile beyond software development 20 3.2.2 Kanban 23 3.2.3 Scrum 25 3.3 Hybrid project management 32 4 Methodology 36 4.1 Research design 36 4.2 Data collection 40 4.3 Data analysis 42 5 Interview results 44 5.1 Frameworks in use 44 5.2 Daily use of frameworks 44 5.3 Roles 45 5 5.4 Data and metrics 47 5.5 Tools 47 5.6 Motivation for Agile and benefits 48 5.7 Challenges 49 5.8 When to use Agile methods 52 5.9 Hybrid models 53 5.10 How to start using Agile methods 54 6 Hybrid project management model creation 56 6.1 Main insights from the interviews 56 6.2 Choosing core methodologies 56 6.3 Conceptual framework 57 6.3.1 Roles 58 6.3.2 Key processes in the model 59 6.3.3 Tools 61 6.4 Overview of the hybrid project management model 64 7 Hybrid project management model validation 66 7.1 Validation setup and process 66 7.2 Results 67 8 Discussion 73 8.1 Key findings 73 8.2 Theoretical and practical contributions 74 8.3 Limitations of the study 75 8.4 Suggestions for future research 76 9 Conclusion 77 References 78 Appendices 83 Appendix 1. Interview questions 83 6 Figures Figure 1. Elisa project model. 13 Figure 2. Elisa's Agile best practices toolkit. 14 Figure 3. An overview of a Stage-Gate system. 17 Figure 4. The four values of Agile Manifesto. 19 Figure 5. Different Agile methodologies. 20 Figure 6. An example of a Kanban board. 24 Figure 7. The communication model in Agile teams compared to traditional teams. 26 Figure 8. Scrum framework. 31 Figure 9. DSRM-model. 37 Figure 10. Interview themes. 42 Figure 11. Elisa's project model (EPM), highlighting the area for improvement. 57 Figure 12. Modified Scrum ceremony model for hybrid project management. 60 Figure 13. Modified Scrum workflow for hybrid project management. 60 Figure 14. An overview of MS project and task distribution between traditional and Agile methodologies. 63 Figure 15. Sprint board view on Microsoft Project. 64 Tables Table 1. Interview participants. 41 7 1 Introduction 1.1 Background In recent years, academic discussions and industrial interest have increasingly focused on the integration of Agile project management methodologies in various sectors, espe- cially those that operate in rapidly changing environments (Ferreira & Nobre, 2022). Ac- cording to Zasa et al. (2021), there has been a significant shift in the business environ- ment since the 1980s, which has led to the development of new project management practices to cope with the emerging challenges while balancing efficiency, speed, and quality. As product development activities grew more unpredictable and uncertain, the traditional project management methodologies faced limitations, especially when there were requests for changes even in the later stages of the project. Because of the evolving nature of the project management environment, project managers began questioning the effectiveness of the traditional methods, and at the same time organizations started searching for more flexible and innovative ways to manage projects. The Agile approach originated within the software industry, and the Agile Manifesto (Beck et al., 2001) presented the guiding principles of the new methodology. When Agile emerged in the early 2000s, it was seen as an answer to various problems in the IT sector that traditional project management and its processes could not solve. Traditional pro- ject management tends to focus on long-term planning, but in the IT sector, it was often viewed as inefficient because it involved too much up-front planning and change man- agement, causing inefficiencies and slowing down the development. Agile was intro- duced to the field of IT to deal with these issues by implementing adaptive planning, a time-boxed, iterative approach with a flexible response to changes (Cooper & Sommer, 2016b). Over the past years, it has been widely accepted that Agile methods are primarily appli- cable to software development projects where they have generated positive results. Ag- ile brings adaptability and expedites the development projects through frameworks such 8 as Scrum, and tools such as sprints, burndown charts, and backlogs to create software code to reach a working end-product quickly. At its core, Agile development consists of several short, time-boxed sprints that are undertaken by a dedicated project team, and the aim is to produce a working piece of software at the end of each sprint that can be demonstrated to the end customer. The question remains whether Agile methodologies can be effectively applied to other industries than IT and software development and in- tegrated with the traditional Stage-Gate model and other sequential project manage- ment approaches. Recent studies indicate that larger IT companies have successfully in- tegrated Agile methodologies with the Stage-Gate model, creating a hybrid approach to managing projects (Cooper & Sommer, 2016b). By introducing Agile methods to project management outside of software development, it changes the approach to new product development compared to the traditional Stage- Gate model established over 30 years ago (Cooper & Sommer, 2016a). Initial studies in- dicate that mixing traditional methodologies with Agile approaches to create hybrid frameworks allow for quicker adaptation to changing customer needs, enhance commu- nication, teamwork, and productivity, resulting in faster product releases to market. However, this transition is challenging, requiring significant modifications to successfully implement Agile practices. Even though results have been promising, further research is necessary to explore the hybrid methodologies that combine Agile and traditional pro- ject management (Cooper & Sommer, 2016b). This thesis is completed for Elisa Oyj, one of the leading telecommunication and digital service providers in Finland. The author works as a customer project manager in the organization, leading various network infrastructure projects for corporate customers. According to Cisco (n.d.), network infrastructure is defined as “hardware and software that enable network connectivity and communication between users, devices, apps, the internet, and more”. The inspiration for this thesis came from the organization’s interest in Agile project management as a potential supplement to its recently updated project management model. While the new project management model relies on traditional 9 project management methodologies, there is an increasing demand from corporate cus- tomers for Agile approaches, leading the organization to explore their applicability in customer projects. A comprehensive overview of the case organization is presented in Section 2: Case organization. 1.2 Objectives and research questions Considering the organization's interest in introducing Agile methodologies into customer project implementations, the primary objective of this thesis is to develop a hybrid pro- ject management model that the organization can pilot to evaluate the suitability of Ag- ile methodologies for its project portfolio and assess the potential benefits. The thesis will follow the design science research methodology (DSRM) by Peffers et al. (2007) to create an artifact which will be the hybrid project management model. Relevant ele- ments for the new model will be determined by investigating the academic literature and interviewing individuals within the organization who actively use Agile methodolo- gies in their daily work. Consequently, the research questions are as follows: Research question 1: How well do Agile methodologies fit into the implementation of customer projects, and what potential benefits could their adoption bring to the busi- ness unit? Research question 2: How have other business units and departments within the organ- ization implemented Agile methodologies, and what lessons and best practices can be applied to the development of a hybrid project management model for customer project implementations? The primary research question explores whether Agile methodologies can be effectively introduced into customer projects and what benefits their adoption might bring. The secondary research question investigates how other departments within Elisa have im- plemented Agile methodologies, identifying benefits, challenges, and best practices. By answering these questions, the study will provide key insights into how Agile 10 methodologies can be adapted for customer projects and how experiences within the organization can contribute to the development of a practical hybrid project manage- ment model. 1.3 Structure of the thesis The thesis is divided into nine sections. The first section introduces the topic, providing background information along with the research questions and objectives. The second section presents the case organization, describing its project environment and the cur- rent status of its project management methodologies. The third section provides the theoretical framework, reviewing existing literature on project management, including traditional methodologies, Agile methodologies, and the emerging trend of hybrid pro- ject management. The fourth section outlines the research design, including the chosen research methodology and the plan for data collection and analysis. The fifth section presents the results of the interviews conducted. The sixth section describes the hybrid project management model, and the process used to create it. The seventh section dis- cusses the validation of the hybrid project management model. The eighth section is the discussion, highlighting both the theoretical and practical contributions of the study, along with suggestions for future research. The ninth section concludes the thesis. 11 2 Case organization 2.1 Elisa Oyj The case organization, Elisa Oyj, is a leading provider of telecommunications and digital services in Finland. Founded in 1882, Elisa now serves over 2,8 million customers in Fin- land, Estonia, and other international markets. The company has more than 6100 em- ployees across 20 countries and offers a wide range of services for both consumers and businesses, including traditional telecommunication services, internet and broadband services, digital services, ICT services, network management and security, mobile de- vices and accessories, customer support and professional services, and many others. In recent years, Elisa has shifted its focus from traditional telecommunications to digitali- zation (Elisa, n.d.). The Corporate Customers unit at Elisa consists of five business units that provide IT and communication services as well as digital solutions for various business needs. Two of the five business units are primarily responsible for business operations, while the other three serve as supporting units for the operations. The Corporate Customers unit has 1200 employees working in 15 distinct locations in Finland, with additional personnel in subsidiaries in Estonia (Elisa, 2024). 2.2 Project management at Elisa Oyj A significant amount of work at Elisa is organized as projects with many employees work- ing on development projects in addition to their daily operational work. Some work full- time on customer delivery projects or internal development projects. Internal develop- ment projects focus on simplifying IT architecture, eliminating overlapping operations, typically aiming to improve organizational efficiency. The other category of projects at Elisa consists of customer delivery projects where a dedicated project manager oversees the implementation. Efficient project management enables customers to put their in- vestments into production quickly, minimizing the recovery time for their initial 12 investment. For its project leading service, Elisa has ISO-9001:2015 quality certification and the quality standards for the project management model are externally audited once a year. Elisa’s project management service is flexible and can be scaled from complex projects with a long duration into shorter, less complex projects. In its project manage- ment office (PMO), Elisa has over 40 individuals that specialize in customer project im- plementations (Elisa, 2024). Network infrastructure projects at Elisa consist of delivering comprehensive connectivity and security solutions customized for the needs of corporate customers. Typical projects include the implementation and modernization of wide area networks (WAN) and local area networks (LAN), firewall deployments, cloud services, and many others. Projects often require coordination of several stakeholders, including customers’ IT teams, Elisa’s technical specialists, and third-party service providers or vendors. Often the services are implemented in complex environments and may involve migration of services from one provider or technology to another. The projects are typically delivered as part of a broader transformation roadmap and may differ in size and complexity, from targeted upgrades to implementations that include multiple locations. 2.3 Elisa project management model Elisa recently renewed its project management model (EPM, Elisa Project Model) which combines both domestic and international best practices of project management. The updated project model follows the Stage-Gate approach, defining each phase and nec- essary decisions required at each gate. The model offers a clear framework that adds value to the customer and makes project execution more structured and transparent. The model brings transparency over the project and ensures the quality requirements are met at each point of the implementation. While the model is mainly stage-based, it also allows for iterations and Agile practices and can function as a hybrid model if agreed with the customer (Elisa, 2024). The newly released model does not provide predefined guidelines on when to use traditional methodologies and when to use Agile approaches. Instead, the choice depends on the nature of each project. Currently, the business unit 13 where the author works, primarily follows the Stage-Gate model with a traditional Wa- terfall approach which remains the standard way of implementing customer projects. Figure 1. Elisa project model (Elisa, 2024). 2.4 Hybrid project management at Elisa Oyj Elisa Project Model (EPM) includes Agile elements and emphasizes several tools that support Agile and hybrid project management practices. The model provides a toolkit for Agile, which includes retrospectives, daily meetings, Kanban, development sprints, backlog management, virtual whiteboards, iterations, and value stream mapping. The model also clearly states the benefits of Agile practices, emphasizing how they can cre- ate value for customers more quickly, enable continuous learning from completed pro- ject components, improve output quality, detect, minimize, and resolve potential risks and challenges more quickly, and increase responsiveness to changes in the project and its environment (Elisa, 2024). 14 Figure 2. Elisa's Agile best practices toolkit (Elisa, 2024). Even though the new project management model encourages implementing projects us- ing Agile, and recommends several tools to support Agile practices, it leaves the choice of methodology to each individual project. At the start of a project, the project manager and team determine the most suitable approach for implementation throughout the project lifecycle. In the business units where the author currently works, some Agile el- ements are integrated into project execution, but not necessarily in the way outlined in Agile literature. This raises the need to investigate how Agile methodologies could be more effectively utilized in customer projects to enhance flexibility, efficiency, and over- all project success. 15 3 Literature review 3.1 Traditional project management Project Management Institute (2017) defines a project as “a temporary endeavor under- taken to create a unique product, service, or result” (p. 4). Project management is de- scribed as “the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements” (p. 10). Projects create value and benefits for organ- izations, and in today’s dynamic and rapidly changing business environment, organiza- tions must deliver value consistently through effective project management to remain competitive. Consequently, project management can be considered a strategic compe- tency within an organization (Project Management Institute, 2017). Betta and Boronina (2018) state that project management is a field of study with no universal solutions, despite the development of various paradigms, methods, and stand- ards. Traditionally, projects have been managed by breaking the processes into distinct stages, forming a linear structure. This approach remains standard in manufacturing and engineering projects, where it is assumed that requirements will remain stable through- out the project. According to guidelines from the Project Management Institute (2017), traditional project management includes the completion of five distinct phases: initiat- ing, planning, execution, monitoring and controlling, and closing. To support these phases, there are also ten different knowledge areas: scope, time, cost, quality, risks, communication, procurement, human resources, stakeholders, and integration manage- ment. As Patil (2019) describes, approaches where the phases are conducted in a linear way can be called sequential project management approaches since the next phase can- not be started before the earlier one concludes. 3.1.1 The Waterfall methodology The Waterfall methodology was first introduced by Winston W. Royce in 1970. The core idea behind Waterfall is that software is developed through distinct phases that follow a 16 linear and static order. These phases can include, for example, requirements determina- tion, design, implementation, verification, and maintenance. A tool closely related to Waterfall is the Gantt chart created by Henry Gantt between 1910-1915, as it visualizes project tasks, subtasks, and dependencies between the phases throughout the project lifecycle. Gantt chart provides an easy tool to visualize progress in sequential project management approaches (Volovyk & Harmash, 2022). According to Andrei et al. (2019), this traditional approach is a methodology that divides the project into sequential stages, each requiring the completion of the previous stage before moving forward. This model is especially effective for projects with fixed schedules, scopes, and budgets, as it relies on comprehensive documentation and well-defined requirements established in the be- ginning of the project. 3.1.2 Stage-Gate model In the mid-1980s Robert G. Cooper introduced the concept of a Stage-Gate model, a framework that structures the process required to transition a product from ideation to launch. Originally created to enhance the development of new products, the model in- volves dividing the work into distinct stages, each with defined activities and prerequi- sites that must be met before progressing to the next phase. While work is carried out within these stages, gates function as checkpoints to ensure quality before advancing in the process. Typically consisting of four to seven stages, each with prescribed and inter- related activities, the Stage-Gate model introduces inputs, exit criteria, and outputs at each gate. Inputs consist of deliverables that must be presented at the gate, exit criteria define success benchmarks against which the product’s success will be measured, and outputs typically include a decision on whether to proceed with the product, along with an action plan for the next stage (Cooper, 1990). 17 Figure 3. An overview of a Stage-Gate system (Cooper, 1990). According to Cooper (1990), the Stage-Gate model moves the project sequentially from gate to gate, guided by the project leader. It is necessary for the project leader to under- stand the deliverables required at each stage and lead the team's activities accordingly. The Stage-Gate model also works as a visible roadmap for diverse team members from various teams and departments. This clarity allows team members to easily understand the project's status and expected future direction. A key advantage achieved by employ- ing the Stage-Gate model is its clarity, introducing discipline into the processes. Its sim- plicity lies in the transparent articulation of requirements for each stage. 3.1.3 Benefits and limitations of traditional project management According to Salameh (2014), a key strength of traditional project management and se- quential approaches lies in defining all the requirements and details before the execu- tion begins. This approach is well-suited for some projects where it is essential to define and plan all the requirements beforehand. Andrei et al. (2019) note that in small projects with fixed schedules and budgets, Waterfall can be beneficial, as it provides teams with comprehensive documentation and a structured timeline, allowing for better organiza- tion and even distribution of work. When properly implemented, the project will have better cohesion and there is a streamlined process for the team. 18 Salameh (2014) states that traditional project management can be challenging to apply as projects rarely follow a strict sequential model, and it is difficult to define the require- ments accurately in early phases. Traditional project management assumes that the pro- ject and its activities are predictable, and the risks and unexpected events are predicta- ble as well. In traditional project management, completed phases are not revisited once they are finalized. This approach works with some industries such as construction where all the requirements and sequence of activities are well-defined, however in other in- dustries, such as IT, this is rarely applicable. Dybå et al. (2014) state that traditional project management primarily follows a linear structure, viewing development as a sequence of activities such as requirements, design, coding, and testing. In traditional project management, it is assumed that all necessary information and details are available from the beginning of the project, and the expected solution is clear. This approach does not easily allow changes to scope, schedule, or re- sources. As the complexity of a project increases and the environment undergoes rapid changes, including shifts in customer requirements and project goals, it becomes neces- sary for the team to move away from traditional project management and towards Agile. This flexibility allows the team to redefine activities or even restructure the project plan when necessary. Operating in such dynamic environments requires managers to employ roles and techniques that rely less on extensive planning and more on flexibility and con- tinuous learning. 3.2 Agile project management Agile methodologies are approaches created to enhance flexibility in managing projects, specifically tailored for the software industry, which typically involves high uncertainty, undefined requirements, and short development cycles. The origin of Agile methodolo- gies can be traced back to the flexible mass production systems introduced by Toyota in the 1950s, later evolving into what is known as Lean thinking within the quality move- ment. It was the quality movement that paved the way for Agile software development 19 (Hobbs & Petit, 2017). Lean thinking examines resource usage, emphasizing the elimina- tion of anything that does not add value to the customer. Value, in this context, is defined as something customers would be willing to pay for. Agile is rooted in the same principles as Lean thinking, applying them to software development. This involves examining each step and evaluating whether the activities contribute value. Implementing these princi- ples in software development requires a thorough evaluation of each process step and adjusting as needed (Cobb, 2011). In year 2001, seventeen software professionals created the Agile Manifesto, aiming to form better principles and guidelines for software development. After the publication, the Manifesto has been widely accepted by software developers, and outside of the IT sector as well. The Agile principles mentioned in the Manifesto created new innovative ways to manage software and product development (Hohl et al., 2018). Figure 4. The four values of Agile Manifesto (Beck et al., 2001). Dybå et al. (2014) state that Agile software development transforms the approach to project management by de-emphasizing well-defined plans and placing more emphasis on informal collaboration and continuous learning. Essentially, Agile project manage- ment is focused around managing the complexity and uncertainty of projects, acknowl- edging the need for a shorter interval between planning and execution. Planning an ac- tion does not reveal all details, instead, learning during the process is essential to gain a deeper understanding of the environment. In contrast to traditional project 20 management, which relies on sequenced and well-defined tasks and actions, Agile pro- ject management concentrates on delivering features in smaller, iterative, and incremen- tal cycles with continuous integration. Juricek (2014) summarizes the key differences compared to traditional project management methodologies, and they consist of under- standing that the changes are normal part of the project, requirements evolve through- out the implementation, requirements are prioritized at the beginning of each iteration, the work is focused on quickly adding value, and a high level of communication and cus- tomer collaboration. 3.2.1 Agile beyond software development Even though Agile methods were initially developed to meet the needs of the software industry, Agile practices are now widely utilized across various industries. Agile itself rep- resents an approach or mindset that consists of specific values and principles. It serves as an umbrella term that includes any approach, tool, or framework rooted in the prin- ciples outlined in the Agile Manifesto by Beck et al. (2001). Different Agile methodologies are subsets of Lean thinking, and they share the same concepts such as elimination of waste, focus on value, and small delivery batches (Project Management Institute, 2017). Figure 5. Different Agile methodologies (Project Management Institute, 2017). 21 Today there are over 20 different Agile methodologies existing. The choice of whether to use any method depends on the project type, organization and its employees. Em- ployee characteristics play a key role as well and their mutual relations and motivation affect the effectiveness of Agile methodologies, and these factors need to be considered before the adoption of any Agile methodology. Some of the most studied frameworks in existing literature are Scrum, Kanban, Feature Driven Development, Agile Unified Pro- cess, Dynamic Systems Development Methods and Extreme Programming (Rasnacis & Berzisa, 2017). In addition, there is a rising number of different frameworks that are aimed for large organizations to be able to extend the use of Agile methodologies amongst several teams, as today many organizations develop large-scale projects that include multiple teams that need to have their work integrated together. There are sev- eral scaled Agile frameworks today, such as Scaled Agile Framework (SAFe), Disciplined Agile Delivery (DAD), Large Scale Scrum (LeSS) and many others in large organizations (Ozkan & Tarhan, 2019). To implement a methodology effectively, an organization should follow the steps of iden- tifying the most suitable methodology and understanding the organization's specific re- quirements. Adapting a methodology involves understanding the necessary roles, pro- cesses, and artifacts tailored to the specific situation. Additionally, factors such as the internal and external environment, organizational maturity levels, and existing knowledge must be considered to ensure a successful implementation (Rasnacis & Ber- zisa, 2017). Organizations typically adopt Agile methods in one of two ways. The first approach involves adopting a specific, proven Agile framework and thoroughly learning its principles and practices before considering any customization. Tailoring the method- ology prematurely can diminish its potential benefits. The second approach focuses on selecting Agile practices that best suit the specific needs of a project. This may involve using various iteration techniques to develop features and breaking down project com- ponents into smaller, manageable parts. The goal is to implement Agile practices that enhance project success, with the primary aim to deliver continuous value and achieve 22 better business outcomes, rather than simply relying on Agile principles for their own sake (Project Management Institute, 2017). An organization can be considered Agile when it demonstrates the ability to quickly re- spond and adapt to evolving business requirements. Although the concept initially emerged in software development, agility has become a fundamental competency for modern organizations, offering a balance between stability and flexibility. While Agile project management remains mostly associated with software development, there is a steadily increasing number of professionals supporting the use of Agile practices beyond software development projects (Ciric et al., 2019). Ciric et al. (2019) investigated the implementation of Agile project management meth- odologies outside of software development by analysing data from numerous studies describing the needed strategies and actions to implement Agile methodologies in a tra- ditional environment. Several key findings emerged from the analysis. It is it essential to note that Agile is not fit for every purpose and therefore, there should be a clear under- standing how the methodology works. Agile should be applied in projects where un- known solutions are delivered, the requirements are not completely clear, there is a strong collaboration together with the customer, and there is a possibility to modularize the work. Another important aspect is that the Agile approaches must be customized to meet the specific needs of the organization. Every organization is unique and there might be various challenges when implementing the Agile methodology. When starting Agile adoption, it is recommended to begin with small pilot projects rather than trying a large- scale implementation. Many organizations make the mistake of trying to implement Ag- ile on large scale at once, but starting with small pilots typically leads to better results. According to Fitriani et al. (2021), even though Agile project management has been widely applied in software development projects, there is a limited amount of literature on its application in network infrastructure projects. In their study, Fitriani et al. (2021) investigated how Agile project management methodologies could be applied to a 23 network transformation project in which an India-based organization migrated its com- pany network to a new solution. To support such network transformation project, the researchers proposed a project management model using design science research, draw- ing inspiration from Lean and Kanban practices. 3.2.2 Kanban Kanban is a well-known Agile method that Toyota made famous back in the 1950s and has since been adopted in various industries. Kanban focuses on process improvement and aims to improve the efficiency of a team and their day-to-day activities by imple- menting several key practices. Key practices in Kanban include visualizing the workflow, managing the flow of work, and limiting work in progress (WIP). Kanban uses a pull sys- tem, where new tasks are pulled into the workflow once there is enough capacity avail- able, rather than being pulled into the system purely based on demand. Limiting the work in progress is one of the fundamental aspects of Kanban (Damij and Damij, 2021). According to Cobb (2015), understanding Kanban requires recognizing the difference be- tween push and pull processes. The push process is based on predetermined require- ments and plans, and resources are scheduled according to the plan. Traditional Water- fall methodology typically works like this. On the other hand, the pull process is driven by demand and the tasks are performed only when there is a clear need for a certain task to be completed. While there might still be a light plan outlining necessary resources, no actual work is started or planned before the demand for a specific task arises. Visualizing the workflow is an essential part of Kanban, and it typically means creating a board that displays different process stages. Each stage represents the status of each task, and the tasks are typically represented by a sticky note placed in a certain column. In software development, the stages are typically “backlog”, “analyze”, “develop”, “test”, and “deploy” (Damij and Damij, 2021). According to Lei et al. (2017), Kanban uses a card wall to visualize the process, tasks and goals within a project. Tasks required to complete the project are identified and placed in the backlog section of the Kanban board. Once a 24 task is completed, it is moved to the next section, and another task from the backlog is pulled into the next stage of the process. Figure 6. An example of a Kanban board (Lei et al., 2017). According to Lei et al. (2017), to control the project and deliver outcomes on time, there are specific limits implemented for each stage. If a stage has fewer ongoing tasks than its current work in progress (WIP) limit, it may accept new tasks from the previous stages. If the stage limit has been reached, the current work must be completed before any new work can be accepted. Damij and Damij (2021) emphasize that limiting the work in pro- gress is a crucial step in Kanban which makes the system work efficiently. This approach requires each team member to complete their current tasks before accepting new work. This aims to reduce the multitasking that employees often tend to do. According to Lei et al. (2017), one of the key elements of Kanban is that it provides high visibility into the status of a project by displaying all tasks that are currently being worked on. Kanban also highlights potential bottlenecks caused by overloading and reveals gaps between workflows. By using cards formed in distinct colors and placing them on the board, Kanban offers a clear overview of the progress and is a helpful tool in tracking the constraints of the project. 25 3.2.3 Scrum Scrum is a development framework that uses incremental and iterative Agile practices for managing product development. The idea of Scrum was first introduced in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka in their publication The New Product Development Game. It was originally defined as “a flexible, holistic product development strategy where a development team works as a unit to reach a common goal.” (Sachdeva, 2016, p. 16792). In the early 1990s, Ken Schwaber and Jeff Sutherland continued the ideas of Takeuchi and Nonaka, and the concept of Scrum was presented to the public at the OOPSLA Conference in 1995 (Schwaber & Sutherland, 2020). Schwaber and Sutherland (2012) describe Scrum as “a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value” (p. 57). At its core, Scrum divides work into iter- ations (sprints) that last no longer than four weeks. The goal at the end of each sprint is to present a ready product increment. All requirements are collected in the product backlog, which is a living document containing all recognized user needs. Before each sprint, a planning meeting is held where the items to be developed in the upcoming sprint are selected. The work is guided by daily standup meetings, where team members share their latest progress, and at the end of each sprint there is a sprint review session where the ready increment is presented. After the sprint ends, a retrospective meeting is held in which the team reflects on how the sprint went and identifies areas for im- provement (Hron & Obwegeser, 2018). The Scrum framework offers significant flexibility when requirements and constraints – whether financial or technical – change during a project, and it emphasizes prioritizing the tasks that deliver the most value and have the highest priority (Andrei et al., 2019). Scrum challenges the traditional, sequential approach to product development and en- courages self-organizing teams, close online collaboration, and face-to-face communica- tion among all team members. Scrum emphasizes real-time decision-making based on actual information and therefore requires a team that is capable of self-management, 26 with effective communication and decision-making skills. While Scrum can be applied to any project type, it has been mostly used in software development. It is particularly ef- fective in projects that are complex and involve rapidly changing requirements (Sachdeva, 2016). Scrum roles In traditional project management and product development, various leadership roles and models are commonly employed. Teams may have named leaders, and typically, a project manager is responsible for overseeing the project timeline, budget, and facilitat- ing team meetings. This role is often assigned by the project management office (PMO) of the organization. However, Agile and especially Scrum introduce a completely differ- ent structure with new roles compared to traditional project management. In Scrum, three core roles are identified: The Product Owner, The Scrum Master, and the develop- ment team (Cooper & Sommer, 2016a). Figure 7. The communication model in Agile teams compared to traditional teams (Cooper & Sommer, 2016a). In this model, the Product Owner is responsible for keeping the project on track and managing stakeholders, functioning similarly to a project manager in a traditional Stage- Gate model. The daily operations fall under the management of a Scrum Master, who 27 ensures that the development team follows the agreed Agile methods and tools and helps remove potential blockers for the project (Cooper & Sommer, 2016a). Cooper and Sommer (2016b) emphasize that the most vital role in Agile is the individual member of the development team, as each member is empowered to take responsibility for execut- ing the project. Schwaber and Sunderland (2012) describe the development team in Scrum as self-organized individuals who have all the necessary skills to create a product increment and the knowledge to transform backlog items into a working solution. Cooper and Sommer (2016a) emphasize that the introduction of new roles in Agile, com- pared to traditional project management, alters the communication dynamics within the project team. In the absence of a project manager serving as the daily decision-maker, the team must self-manage and distribute tasks among its members to ensure project progress. While this decentralized approach can lead to conflicts, the presence of a Scrum Master mitigates such challenges by keeping the team's focus on task execution. The practice of shared decision-making empowers the team and fosters a higher level of engagement among its members. Removing the project manager as the central commu- nication point is believed to create additional communication paths, thereby enhancing knowledge sharing and learning within the team. It is argued that when responsibilities in Agile are effectively distributed among the Product Owner, Scrum Master, and devel- opment team, the likelihood of project success increases compared to traditionally or- ganized projects. Schwaber and Sunderland (2012) describe the Product Owner as the person responsible for maximizing the value of the product and the work performed by the development team. The Product Owner maintains the product backlog, ensuring it is up to date, and prioritizes features to deliver the maximum value. It is crucial to keep the backlog clearly visible and transparent to ensure the development team understands each item. Accord- ing to Sachdeva (2016), the Product Owner is the main link between the Scrum team and stakeholders. The Product Owner’s role is to ensure the development team delivers the highest value to the business, requiring an understanding of business needs to prioritize 28 the work of the team accordingly. In addition to overseeing the value of the product, the Product Owner is also responsible for verifying the quality of the product before releas- ing it to the end-users. The Scrum Master is responsible for ensuring that the rules, practices and principles of Scrum are understood and followed by the project team (Schwaber & Sunderland, 2012). Cooper and Sommer (2016b) describe this role as a process owner and facilitator who supports the project team throughout each sprint. The Scrum Master coaches the team on how to implement Scrum processes and helps to improve the team’s delivery flow. Additionally, the Scrum Master schedules necessary resources for the various Scrum cer- emonies and practices, such as sprint planning, daily standups, and sprint reviews. While the Scrum Master is not involved in the decision-making of the team, their role is to ensure that everyone follows Scrum practices. In addition to guiding these practices, the Scrum Master needs to address any obstacles that may disrupt the team’s daily work or slow down the current sprint. In Scrum, the development team consists of professionals who create the product during each sprint. The members of the development team are cross-functional, meaning they possess all the necessary knowledge to create the product within the team. Each mem- ber may have a specialized area of focus, but overall accountability belongs to the devel- opment team as a whole. Ideally the development team size should be small to maintain agility, but large enough to include all the necessary skills to complete the work. Gener- ally, there should be at least three members to ensure productivity, but no more than nine members, as larger teams require more coordination and increase complexity (Schwaber & Sunderland, 2012). Scrum events In Scrum, several meetings are defined and held regularly to minimize the need for ad- ditional meetings that are not part of the Scrum framework. Each meeting is time-boxed, meaning there is a maximum duration to ensure efficiency and prevent waste in the 29 process. Aside from the sprint itself, all the events provide transparency and a possibility to inspect the development process and adjust as needed (Schwaber & Sunderland, 2012). Lei et al. (2017) describe the sprint as the heart of the Scrum process. Each sprint is a time-boxed event designed to create a usable product, with a plan outlining what to build and how to build it. Schwaber and Sunderland (2012) state that each sprint should be limited to four weeks. If a sprint extends beyond that timeframe, the requirements and definitions of what needs to be built may change, increasing complexity and risks. The core principle in the sprint ideology is that it allows for inspection at least once a month, providing opportunities to adapt if needed. Before each sprint, a sprint planning meeting is held, where the entire Scrum team con- tributes. Sprint planning is also a time-boxed event, typically lasting eight hours for one- month sprint. The purpose of the sprint planning meeting is to form a clear understand- ing of the increment that will be built in the upcoming sprint, what is needed to create the increment and how it can be achieved (Schwaber and Sunderland (2012). During the sprint planning meeting, the Product Owner collaborates with the development team to set the goals for the upcoming sprint, and the sprint backlog is created (Lei et al., 2019). The activities in the sprint are guided by daily Scrum meetings. This is a time-boxed event lasting 15 minutes, held each day at the same place and time to reduce complexity. Dur- ing the meeting, three key questions are addressed: What has been done since the last meeting? What will be done before the next meeting? Are there any impediments block- ing progress? (Schwaber and Sunderland (2012). The core idea behind the daily Scrum is that it gives the development team an opportunity to synchronize their work, provide the latest status updates, and address any possible issues. (Lei et al., 2019). At the end of each sprint, there is a sprint review session where the development team presents the increment that was created during the sprint. The purpose of the sprint 30 review session is to increase collaboration and gather feedback on the product. During the review session, the Product Owner decides how well the increment fits the specifi- cations, and what was accomplished and what was not. The development team answers any additional questions regarding the increment and also discusses what went well dur- ing the sprint, what challenges were faced, and how they were solved. Based on the achievements, the Product Owner updates the backlog and may modify project duration estimates. At the end of the meeting, the whole team collaborates on what to do next, ensuring that the current sprint offers valuable insights for the next sprint planning (Schwaber and Sunderland, 2012). The last event in the Scrum process is the retrospective meeting, which takes place at the end of the sprint. The purpose of this meeting is not to inspect the actual product created during the sprint, as this occurs in the sprint review session, but to analyze and improve the team’s functioning and dynamics. During the retrospective, team members reflect on their working methods during the sprint and seek ways to improve for the upcoming sprint (Cooper & Sommer, 2016a). According to Schwaber and Sunderland (2012), in the sprint retrospective, the sprint is thoroughly reviewed, including the peo- ple, processes, relationships, and tools. The Scrum Master encourages the development team to identify areas for improvement and find ways to increase quality and productiv- ity. Even though improvements can be implemented at any time in Scrum, the retrospec- tive meeting provides a formal opportunity for this purpose. 31 Figure 8. Scrum framework (Scrum.org, n.d.). Scrum artifacts There are artifacts in Scrum designed to present work in a way that allows for inspection and adoption, aiming to maximize transparency and help ensure that Scrum teams are successful in delivering the planned increment. The main Scrum artifacts are the product backlog, sprint backlog, and increment (Schwaber & Sunderland, 2012). The product backlog is a list of requirements for creating a product, and the Product Owner has the responsibility to maintain the product backlog and keep it up to date. A key element of the product backlog is that it is never complete; at the beginning it con- tains only the initial, best-understood requirements, and as development progresses, the backlog evolves. The product backlog is dynamic, constantly identifying features, re- quirements, functions, enhancements, and fixes for the product to be remain relevant and useful. Typically, the items in the product backlog are organized by priority, risk, and value, with high priority items placed at the top. These high-priority items are typically more detailed and thoroughly analyzed compared to the lower-priority items. The se- lected items from the product backlog are included in the development sprint. As the product is used, more requirements become clear, causing the product backlog to grow, thus making it a living artifact. Changes in market conditions and technology may also affect the product backlog (Schwaber & Sunderland, 2012). 32 The sprint backlog is the set of items from the product backlog that have been selected for a specific sprint for delivering the planned sprint increment. It consists of items that the development team has estimated are required to complete the increment, and it serves as a plan with enough details to guide the work. The sprint backlog is also a living document, and the development team modifies it during the sprint as new information becomes available and a better understanding of what is needed to create the increment is gained. When new work is required, the development team adds it to the sprint back- log, and the estimate of the remaining work is updated. Sprint backlog is a visualization of the work in progress and what the development team aims to accomplish during the sprint (Schwaber & Sunderland, 2012). The increment consists of all the sprint backlog items that are completed during the sprint or were completed in previous sprints. By the end of the sprint, the increment must be ready and meet the definition of done, which is established by the Scrum team. The specifics of the definition of done may vary between Scrum teams, but fundamen- tally, it represents a shared understanding within the Scrum team on what constitutes a finished product and when it can be considered complete. The definition of done guides the Scrum team, and as the team matures, the definition will evolve to include higher quality requirements. Each increment delivered in the sprint is integrated with prior in- crements, and all increments are assessed to ensure they function together as a cohesive whole (Schwaber & Sunderland, 2012). 3.3 Hybrid project management To support organizations and practitioners in incorporating Agile methodologies, the Project Management Institute (PMI) published the Agile Practice Guide in 2017 (Project Management Institute, 2017). This guide provides a comprehensive set of tools, tech- niques, and best practices, making it a valuable resource for project managers operating in Agile environments or looking to adopt Agile practices. Furthermore, the seventh edi- tion of the PMBOK Guide (2021) marks a significant shift by emphasizing Agile 33 methodologies alongside traditional project management approaches (Project Manage- ment Institute, 2021). This edition focuses on principles and performance domains, high- lighting Agile methodologies as essential tools for achieving project success in dynamic and complex environments. According to the PMI Pulse of the Profession (2024), a global survey and research report provided by Project Management Institute, project managers today are using more hybrid project management approaches than ever before. The number of project professionals using hybrid project management approaches has in- creased from 20% in 2020 to 31,5% in 2024. In their article “Hybrid project management – a systematic literature review”, Reiff and Schlegel (2022) conducted a systematic literature review on hybrid project management, aiming to form an understanding of the current research on the topic. They highlight that, because of several different hybrid project management models, it remains chal- lenging to understand the differences between them and the general benefits of hybrid project management. In their work, they clarify the current definition of hybrid project management, present several different hybrid project management models, and de- scribe the recognized benefits and challenges of implementing these methodologies. Re- iff and Schlegel (2022) also emphasize the increasing importance of hybrid project man- agement for organizations and the need to acquire new competencies to manage and control projects. According to their findings and systematic analysis of a total of 34 academic papers in the topic of hybrid project management, Reiff and Schlegel (2022) state that there is no single, established definition for hybrid project management. The majority of the papers define it as a method of combining elements from traditional and Agile approaches, while some papers define it as a way to incorporate Agile methodologies into traditional approaches, where applicable. Both definitions highlight the core idea of hybrid project management, which is the ability to choose the best practices and benefits from both approaches. 34 Reiff and Schlegel (2022) present several hybrid project management models that com- bine elements from both traditional and Agile methodologies: Water-Scrum-Fall, Water- fall-Agile, Hybrid-V-Model, and Agile Stage-Gate. Each of the frameworks share an idea that an Agile development methodology, mostly Scrum, is incorporated in some parts of the project, while the use of traditional methods such as careful planning of require- ments and strict gate control ensure it remains easy to keep the structure and control in the project. In the Water-Scrum-Fall model, planning follows a traditional approach, Scrum is used during the development phase, and the project concludes with a Waterfall approach. Waterfall-Agile uses traditional methods only in the planning phase, while the other activities are completed using Agile practices. Hybrid-V-Model utilizes a model where the project starts by using traditional methods and applies Agile methods in phases where there is a need for flexibility, before returning to traditional methods. Agile Stage-Gate, on the other hand, focuses on keeping the gating process for strategic and administrative activities, while utilizing Agile methods in the development activities in between. In their study, Reiff and Schlegel (2022) address the recognized challenges and benefits of hybrid project management as well. The analysis shows that the expected benefits are similar to what can be expected with the use of Agile methodologies in general, such as increased efficiency, faster achievement of project goals with lower costs, faster re- sponse to changes, and higher creativity in finding solutions. On the other hand, ex- pected challenges are related to the organizational culture, the need for additional knowledge and training in Agile methodologies, and the implementation of transparent and active communication. To start using hybrid approach, there are also several prereq- uisites and success factors that must be understood to ensure its effectiveness. When starting to implement Agile, the organization should already have efficient traditional project management methods in place, and at least a basic understanding of the Agile approaches. In addition, the team should consist of experienced members who are well- networked and open to innovative ideas. 35 To deal with the uncertain environments and multiple fast changes, it requires adapting different project management methodologies to different environments, resulting in hy- brid project management models. However, it remains challenging to recognize the best possible Agile solution, since there is a large variety of projects and environmental fac- tors. Today, the discussion has evolved to the point where it is no longer about choosing Agile methods A or B, or between Agile or Waterfall. It has been observed that by com- bining different management approaches, Agile and Waterfall, it is possible to achieve more effective project management (Bianchi et al., 2022). 36 4 Methodology 4.1 Research design This thesis is based on a combination of a qualitative case study and the design science research methodology (DSRM). Design science has its roots in engineering and was first introduced by Simon (1996) in the Sciences of The Artificial. According to Brocke et al. (2020), design science research is a “problem-solving paradigm that seeks to enhance human knowledge via the creation of innovative artifacts” (p. 1). The artifacts created through design science research aim to solve problems and improve the environment in which they are applied (Brocke et al., 2020). These artifacts are rarely complete systems intended for immediate deployment, rather, they often define the necessary domains for the analysis, design, implementation, management, and utilization of new systems. The artifacts created in design science research define the concepts, technical capabili- ties, and essential components for these purposes (Denning, 1997; Tsichritzis, 1998, as cited in Hevner et al., 2004). While design science has its roots in engineering, it is now primarily associated with in- formation systems research. According to Peffers et al. (2007), researchers in the field of information systems became interested in design science in the early 1990s, and since then, numerous studies have applied and expanded the methodology within this domain. In their paper, Hevner et al. (2004) introduce seven guidelines to support researchers in conducting effective design science research. They emphasize that design science re- search is a problem-solving process, requiring the creation of an innovative and purpose- ful artifact designed to address a specific problem. The guidelines are not intended as strict rules, instead they are flexible principles that require judgment to determine which are most applicable in each context. However, Hevner et al. (2004) state that all seven guidelines should be considered to some extent to make the design science research process complete. 37 In 2007, Peffers et al. reviewed the earlier literature and publications of other research- ers on design science research and proposed a new model aimed at establishing a com- monly accepted framework for conducting design science research. They combined ele- ments from seven existing papers and applied a consensus-building approach to develop their model. Figure 9. DSRM-model (Peffers et al., 2007). The framework presented by Peffers et al. (2007) consists of six different activities. The process begins with problem identification and motivation. This first activity involves de- fining the research problem and justifying the underlying value of its solution. This helps to motivate the researcher and other stakeholders to pursue the solution. In the context of this thesis, the identified problem is that Elisa’s business unit is uncertain whether Agile methodologies are suitable for their current project portfolio and how these meth- ods could be effectively applied. This is particularly important, as Agile methodologies are widely adopted among large corporations, many of which are customers of Elisa. In the model proposed by Peffers et al. (2007), once the problem has been identified and the value of possible solution justified, the objectives for the solution need to be defined. These objectives should be derived from the problem identification and by understand- ing what is technically and organizationally feasible. The objectives can be either 38 quantitative, indicating measurable improvements compared to the existing solutions, or qualitative, explaining how the new solution is expected to address previously un- solved issues. In this thesis, the objectives are primarily qualitative, aiming to explain how the proposed artifact can support the adoption of Agile methodologies within Elisa’s business unit, an environment where Agile has not been used previously. According to Peffers et al. (2007), once the problem and the objectives have been iden- tified, next comes the design and development of the artifact. Broadly defined, the arti- facts can be models, methods, or constructs. In the context of design science research, an artifact can be any object that has been designed in a way that it has research contri- bution included in it. When designing the artifact, it is essential to define the required functionality and architecture before proceeding to its actual creation. The design phase requires a solid understanding of the theoretical knowledge that can be implemented in the solution. In this thesis, the artifact is a hybrid project management model, consisting of a set of tools and principles intended to support the application of Agile methodolo- gies within the business unit. To assist in the development process of the artifact, several semi-structured interviews will be conducted to understand how Agile methodologies are currently used within other departments of the organization, and how that infor- mation can be utilized when creating the hybrid project management model. The next phase in the process is the demonstration of the artifact. In this phase, the newly created artifact is demonstrated to show how it can solve the problems it was initially designed to solve. The demonstration can take various forms, such as real-life experimentation, simulation, or a case study (Peffers et al., 2007). In this thesis, the pi- loting of the new model will be conducted by a simulation. While the model is planned to be evaluated in a real project environment at a later stage, that is beyond the scope of this thesis. According to Peffers et al. (2007), the fifth activity is evaluation, where the initial objec- tives of the new solution are compared to the results obtained from the demonstration. 39 Different analysis techniques can be used, and the form of evaluation depends on the research context. The evaluation may include qualitative system performance measures, such as the number of items produced or how the lead time has changed. It can also be qualitative, such as feedback received. Technically, any form of empirical evidence can be used to assess how well the artifact meets the intended goals. After the evaluation phase, it is up to the researcher to decide whether to return to the design and develop- ment phase to improve the artifact, or to proceed to the next phase and leave further development for future research. In this thesis, the plan is to evaluate the model in a simulated project environment, gather experiences and improvement ideas, and refine the model based on the feedback received. The final activity in the model is communication. Once all other activities are completed, the problem and its importance need to be communicated, as well as the designed arti- fact and its utility, novelty, and effectiveness. The results should be shared with research- ers, or, if appropriate, with other professionals in the field (Peffers et al., 2007). In this thesis, the purpose is to share the progress and results with other professional working in projects, with the goal on increasing their understanding of Agile principles and help- ing them apply them more efficiently in the future. Once the thesis process is complete, the author will continue developing the hybrid project management model and piloting it in the upcoming customer projects. This thesis follows the guidelines of a qualitative case study, as the objective is to under- stand the possibilities of utilizing Agile project management methodologies within a spe- cific organization, Elisa Oyj. According to Schoch (2020), case study research “involves a detailed and intensive analysis of a particular event, situation, organization, or social unit” (p. 245). Schoch (2020) highlights that case studies offer several benefits, during both the research process and the outcomes. A case study allows the researcher to focus on a specific case and provides opportunities to collect data through various methods, such as document analysis, interviews, observations, or surveys, to get a comprehensive un- derstanding of the organization. In terms of the outcomes, case studies provide a broad 40 understanding of the studied unit and help others to understand the case, potentially offering valuable insights. This thesis aims to understand the implementation of Agile methodologies within Elisa Oyj and explore their potential application within the au- thor's business unit. Therefore, a qualitative case study is a suitable approach to gain insight into the organization's current state. 4.2 Data collection The primary data collection for this thesis will be conducted through several semi-struc- tured interviews. Saunders et al. (2007) state that in semi-structured interviews, the re- searcher has a predefined list of interview questions organized in different themes, but the order of the questions may vary depending on the flow of the interview. Additionally, some questions can be left out if they are not relevant to a specific interview, and possi- ble additional questions might be introduced, allowing for a deeper exploration, and un- derstanding of the responses. Semi-structured interviews allow researcher to gain a deep understanding of the topics, as the interview participants explain their responses in detail. During the interviews, spe- cific words or ideas may be used in a certain way, and the ability to capture the main idea behind the responses can add significant value to the data collected. As interview- ees explain their responses, it can lead the discussion to new topics that were not con- sidered when creating the preliminary set of questions. These topics can provide valua- ble information when aligned with the research questions. Semi-structured interviews also give the interviewee the opportunity to organize their ideas and thoughts, some of which they might not have previously considered, leading to the collection of valuable and detailed data (Saunders et al. 2007). Participants for the interviews were selected based on purposive sampling to ensure a diverse range of perspectives. Palinkas et al. (2015) state that purposive sampling is com- monly used in qualitative research, as it allows the researchers to select participants based on their knowledge, expertise, and experience relevant to the objectives of the 41 study. In this thesis, the participants for the interviews were selected based on their ex- perience with Agile methods and Agile project management, expecting that they could provide some valuable insights into the topic. The main interest was to interview indi- viduals who work as project managers and actively use Agile methods. However, due to limited amount of such participants, the scope of the interviews was extended to include other roles as well, and a few Scrum Masters were also interviewed. All the interview participants had experience with Agile methods in their current roles, previous positions, or both. The interviews were guided by a set of predefined questions organized into various themes. However, the order and use of each question varied de- pending on the participant and the flow of the discussion. Four of the participants worked as project managers and had various experiences with Agile methods, either from their earlier careers or in their current roles. Two of them worked on internal de- velopment projects, while the other two focused on customer projects. Two additional participants worked as Scrum Masters in their development teams, with one of them also having the responsibilities of a Product Owner. These two participants did not nec- essarily work on projects, instead project work was integrated into weekly activities of their teams. They were identified as valuable candidates for providing insights into how Scrum practices were applied on a daily basis. Table 1. Interview participants. Interview Interview date Interviewee position Language Duration 1 11.6.2024 Project Offer Manager Finnish 61 min 2 17.6.2024 Senior Project Manager Finnish 51 min 3 2.7.2024 Senior Project Manager Finnish 55 min 4 12.9.2024 Senior Project Manager Finnish 57 min 5 13.9.2024 Technical Product Owner / Scrum Master Finnish 44 min 6 30.10.2024 Team Leader / Scrum Master Finnish 60 min 42 The themes used in the interviews consisted of earlier experiences working with Agile methods, acknowledged best practices and benefits, experienced challenges, tools, ways of daily implementation of Agile practices, insights on when to use traditional methods and when to use Agile, and ideas how to start implementing Agile practices as a new methodology in customer projects. Each interview was conducted virtually via Microsoft Teams and recorded with the participants' approval. The platform's automatic transcrip- tion feature was utilized for the initial transcription of the interviews. Figure 10. Interview themes. 4.3 Data analysis The data collected from the interviews was analyzed using thematical analysis. Braun and Clarke (2012) describe thematical analysis as “a method for systemically identifying, organizing, and offering insight into patterns of meaning (themes) across a dataset” (p. 2). Thematical analysis allows the researcher to understand and make sense of shared meaning and experiences, and to identify similarities how the topic is written or dis- cussed. By using thematical analysis, the researcher can identify themes that are rele- vant to the topic and research questions. Thematical analysis is a flexible way for 43 analyzing qualitative data and can be conducted in several diverse ways, depending on the choice of the researcher. Braun and Clarke (2012) further explain that thematical analysis can be conducted by using either an inductive or deductive approach to data analysis. Inductive analysis is a bottom-up approach and focuses on what is in the data, meaning that the researcher codes the data and creates the themes purely based on what is found in the data. On the other hand, the deductive approach is a top-down approach, where the researcher brings ready-made concepts, ideas, or theories to the data and codes the data according to these. In this thesis, a deductive approach was chosen as it allows for a structured analysis based on the predefined themes, which are designed to align with the objectives of the thesis and provide a clear framework for interpreting the data. The analysis of the interviews started by transcribing each interview into text format, utilizing the pre-made transcription created by Microsoft Teams. Next, the recorded in- terviews were listened to and read several times to ensure that the key insights were correctly captured by the author. Since the number of interviews was relatively small, it was not seen as necessary to use any specific software for analysis. The results were organized according to predefined themes to support a structured interpretation of the data. 44 5 Interview results 5.1 Frameworks in use When the interview participants were asked how they had implemented Agile in their teams, all of them stated that Scrum was the primary Agile method they have used. While all participants had experience with Scrum, their implementation methods varied, proving that the framework is often tailored to fit specific needs. Several participants had also worked with Kanban but later changed it to Scrum, due to finding it more effi- cient way of organizing work. Among the participants, it was highlighted that Kanban is a valuable framework as well, especially for visualization, but often lacks control com- pared to Scrum. Kanban does not provide a structured, time-boxed approach, which can create challenges in managing and controlling the work. In addition, in Kanban the tasks often pass the deadlines, and one participant emphasized that Scrum puts pressure in a good way on team members to complete the tasks in agreed period of time, leading to improved efficiency and overall progress. 5.2 Daily use of frameworks When participants were asked to describe in detail how they had implemented Scrum in their teams and daily operations, there were different approaches. A common practice among participants was conducting two-week sprints, which is in line with the widely used standard in Scrum method. However, one participant shared that their team organ- izes the work in three-week sprints, as they have found this approach to be the most suitable for their needs. Another participant noted that even though the two-week sprint is the most common, the framework itself allows tailoring. The framework recom- mends a maximum sprint length of four weeks, but it is possible to have sprints even longer than that. On Scrum ceremonies, the responses varied, and none of the participants followed Scrum exactly as the framework suggests. Some participants stated they have daily 45 standup meetings, while some other participants had them every other day or even weekly. One participant explained that in their team daily standups are held twice a week, with the expectation that some new information for each task is provided during the meeting. They highlighted the value of Agile practices in ensuring that progress on tasks is visible, and possible blockers can be identified early. Other Scrum ceremonies were also adjusted to fit the needs of each team. All partici- pants stated they have planning and review sessions, though the timing varied. Some teams combined planning and review into one session, while others kept them separate. Retrospectives were also conducted differently as some teams held them after each sprint, others every other sprint, and some only twice a year. Backlog refinement was also emphasized as an important ceremony for structuring and prioritizing work, but the way of execution differed among teams. 5.3 Roles Most participants had the basic Scrum roles in their teams: Product Owner, Scrum Mas- ter, and the development team, even though the implementation practices varied. Par- ticipants shared that while there is typically someone assigned as the Product Owner, the role is sometimes shared between multiple team members. All interview partici- pants emphasized that the Product Owner role is essential, as someone must be respon- sible for prioritizing work and deciding the most important tasks to be completed both in the short and long term. Several participants highlighted that each role in Scrum should be assigned based on the competence requirement, including the Product Owner. The Product Owner manages the backlog, so they must have a deep understanding of the features and requirements to be able to represent the customer efficiently. One par- ticipant noted that in network infrastructure projects, the Product Owner role could be assigned to a network architect, service manager, or even a project manager, as long as the individual has the required expertise. 46 Another crucial role in Scrum is the Scrum Master, who is responsible for facilitating the Scrum process. A few of the interview participants currently work in the Scrum Master role, and one also has similar responsibilities as Product Owner at the same time. By demonstrating their daily and weekly activities, it became self-evident that it is a key role, since they have all the responsibility to coordinate the work and to ensure the develop- ment team follows the Scrum practices. The role of the project manager is particularly interesting, as Scrum does not officially recognize it. One participant explained that in earlier Scrum implementations, particu- larly in customer projects, they had functioned as a project manager and a Scrum Master at the same time. Initially, there was some ambiguity regarding whether the project manager was needed in Scrum projects. However, over time, it became clear that the role is still essential, due to different responsibilities compared to the Scrum team. The same participant noted that they did not experience any challenges in managing both project manager and Scrum Master responsibilities simultaneously. They also mentioned that they partially functioned as a Product Owner and supported customer in that func- tion as well. Participants shared the view that while the project manager is not an official member of the Scrum team, it is still necessary for them to stay informed about the development progress and it is recommended to join the key Scrum ceremonies as well. A few partic- ipants who have worked as project managers in Scrum projects stated that attending daily stand ups is not necessary, but they recommended joining sprint planning and re- view meetings to stay aligned with the direction of the project. Additionally, some par- ticipants work as project managers in large-scale development projects that consist of several Scrum teams. In such projects, the role of a project manager is to coordinate the overall work and facilitate weekly Scrum of Scrum meetings to align activities across dif- ferent teams. 47 5.4 Data and metrics Most participants stated that they use story points to estimate work and track completed tasks. However, different methods were in use across teams, some teams used t-shirt sizing, others relied on person-days, and some applied Fibonacci scale. The use of met- rics varied among participants. One participant noted that they use story points to esti- mate the amount of work for the upcoming sprints, but the data is not analyzed closely after the sprint. Another participant mentioned that their team lacks proper tracking how the estimated story points match the reality, highlighting some room for improve- ment. One participant, who has been leading the same team for several years in Scrum Master role, shared detailed insights into how they track work across sprints. Their team first uses Fibonacci scale for estimation, and then there is a separate tool where team members enter their estimated working days during the sprint. The tool calculates a role- specific completion target for the sprint. After the sprint, the amount of completed work is compared to the original plan, with the impact of scope creep also considered in the analysis. 5.5 Tools When participants were asked about the tools, they use to support Scrum, they all had experience with Jira, which was the most commonly used tool. Some participants also mentioned using other tools, such as Microsoft Project, Microsoft Planner, and Excel, to manage sprints. While there was consensus that Jira is the best tool for running Scrum, it was also considered somewhat complex. One participant noted that using Jira and continuously tracking every task in detail can limit the original idea of agility, as consid- erable time is spent documenting tasks and actions. Another participant mentioned that employees might feel stressed because everything needs to be recorded precisely in Jira. Additionally, it was pointed out that the basic version of Jira lacks certain useful features, and fully using the tool often requires add-ons. This can increase costs due to the need for additional licenses. Despite the minor challenges, Jira was still considered the best 48 available tool for Agile, since it has superior features compared to other commonly used tools. 5.6 Motivation for Agile and benefits When asked about the motivation behind adopting Agile methods, one participant em- phasized that the primary goal was to achieve greater flexibility. They explained that Scrum focuses on delivering results in time-boxed increments and that is especially ben- eficial in projects where the requirements and end goals may not be fully defined in the beginning of the project. Scrum allows the project team to concentrate on planning for the upcoming sprint, rather than for the entire project. The same participant noted that according to their experience, team members have liked the Scrum framework because it has allowed them to work independently and customize sprint lengths and work prac- tices to suit their needs. Additionally, it was highlighted that Scrum simplifies the role of a project manager by improving monitoring and reporting. The use of product or project backlog, divided into sprint backlogs, provides a clear near future roadmap, making it easier to track the progress effectively. One participant described that the need for Scrum originated from the customer needs. The customer had experience of requesting pieces of work through several independent requests, but often the work did not proceed in the desired schedule. The customer wanted to try setting up a project with a certain budget and dedicated resources to com- plete the same work that was earlier completed by independent requests and with the assistance of a ticketing system. The same participant highlighted that there have been significant benefits of using the sprint method: customer has remained satisfied throughout the project, and they have even increased the budget for the work constantly. All status indicators in the project have remained stable, and there have not been any notable issues during the project. Team members have stayed motivated, and started to openly provide their own suggestions on how things should be completed, leading to a more transparent and efficient team environment. Another advantage noted was that this approach required minimal supervision and guidance. The framework itself 49 facilitates a naturally structured workflow, creating an environment that has been effec- tive and supportive for all participants. Other participants also shared that Scrum has improved team spirit. When working closely with the customer, it removes the usual distinction between the service provider and the customer. Instead, they work together as one team, reflecting the core ideas of Agile and Scrum. The same participant also noted that while the beginning of a project could be difficult, the benefits become clear once the project progresses, leaving both the customer and the service provider satisfied. Additionally, Scrum was seen as highly beneficial since it allows the customer to see the results quickly and provides flexibility to change the direction of the project based on evolving requirements. When participants were asked about how the benefits of Agile practices were identified and whether any numerical data demonstrated increased productivity, they did not re- port having such metrics. One participant remarked that it was an interesting question but noted the difficulty of measurement. They explained that no two projects are iden- tical, making it challenging to directly compare projects implemented using traditional methods versus Agile practices. The unique nature of each project complicates the use of such metrics. Another participant highlighted that the observed benefits were primar- ily qualitative, including improved motivation, enhanced team spirit, better communica- tion, faster feedback loops, and better capability of estimating the future work. 5.7 Challenges When asked about the challenges in implementing Agile methods, several participants named resistance to change as an obstacle. One participant, with extensive experience in Agile implementations, emphasized that change management is often the most chal- lenging aspect. They noted that the success of transitioning to Agile largely depends on organizational factors and how open employees are to adopt new ways of working. In one example, the participant worked at a company with well-defined guidelines for pro- ject management. Implementing Agile there simply involved replacing one framework 50 with another, and it was clear from the beginning that everyone would follow the new process. In contrast, they described another organization where employees had used the same methods for many years. This created a less receptive environment, leading to greater resistance to change. The same participant continued that Scrum itself is quite simple as there are lots of materials available online today, but it depends very much on the organizational culture and how willing people are for the change. One participant emphasized the importance of providing necessary support when intro- ducing something new and ensuring that the novel approach is effectively implemented. They noted that organizations often implement changes on paper, but without proper monitoring, these changes may not be fully adopted in practice. Providing adequate training, support, and ongoing monitoring of the implementation process is crucial. In one organization, they began by applying Scrum to smaller projects, while larger projects continued to follow traditional methods. The participant also suggested that following some widely recognized change process model could be a useful approach when man- aging change within an organization, ensuring all critical aspects of the transition are addressed. Another participant also emphasized the challenges of resistance to change, particularly when people are asked to learn a new framework or tool that will be used daily. They pointed out that Agile has traditionally been seen as a more flexible way of working with less emphasis on documentation compared to traditional project management method- ologies. However, they noted that Agile is increasingly starting to resemble Waterfall, as the amount of documentation, tasks, and tickets requiring monitoring has grown. This shift may be challenging for some individuals, as the new tools enable more detailed tracking and monitoring of work. When asked how the change resistance related challenges have been addressed, partic- ipants provided similar responses. They noted that while some individuals quickly em- brace new ways of working, others prefer to stay with the old methods. In such situations, 51 it is crucial to consider everyone's opinions and apply strong negotiation skills. Several participants highlighted the importance of having a reward system in place, as it typically motivates individuals. One participant suggested improving the overall atmosphere in the project team by celebrating small victories and organizing informal get-together meetings whenever possible. The same participant also emphasized that if it becomes clear the new framework is not working and people are not adapting to it, it is unneces- sary to force the change. Forcing often leads to lower motivation and can be counter- productive. Another challenge identified was the lack of dedicated project teams. One participant highlighted that subject matter experts often have to divide their workload across differ- ent projects, which goes against the core principles of Agile. Agile emphasizes the use of dedicated teams that are fully committed to a specific project and have all the necessary resources to deliver the final product. The same participant noted that only exceptionally large projects would have the capacity to allocate professionals exclusively to a single project. Often it is seen as an issue that project manager does not have a good enough view for the resources of the professionals, and it is difficult to plan the work since there is no proper visibility. Often there are situations when some professional has too much work that is not realistic to complete all the agreed tasks, and some minor conflicts might arise. One participant noted that during each sprint, there are critical errors that require im- mediate troubleshooting taking priority of other tasks. This might lead to a situation that not all the planned work gets completed. Additionally, there are sometimes requests from upper management that need to be prioritized, further affecting the completion of the original scope for the sprint. The same participant noted that there are often chal- lenges in prioritizing the work since the same development team is responsible for han- dling multiple tasks, including projects work, development, troubleshooting, and maintenance. This leads to resource constraints and difficulties in balancing the work effectively. 52 5.8 When to use Agile methods One interesting question to participants was when to use traditional methods versus Agile methods. Responses varied on this topic. One participant suggested that all small projects could easily be managed with Scrum, while it might be more practical to use traditional methods for larger projects. They explained that Scrum simplifies project planning and, in most cases, helps achieve project goals more efficiently. They also noted that common concern that Agile methods can make project pricing more challenging, but often that is not necessarily true if professional hours are invoiced on time and ma- terials basis. The tasks themselves remain unchanged, only the management approach differs. The same participant highlighted that in network infrastructure projects, where novel solutions are implemented in multiple locations, it would be easy to divide the rollouts into several sprints. If a task cannot be completed within one sprint, it can simply be moved to the next one. The same participant highlighted that it simplifies the plan- ning, as it is not necessary to know the exact details for each location. Instead, it is enough to know which locations will be completed and in which weeks. One participant noted that while Agile methods offer multiple benefits, careful imple- mentation is still needed. The core idea of Agile is that only one of the three typical pro- ject constraints (scope, schedule, cost) is fixed. However, in practice, most projects need to be completed as fast as possible, cost-effectively, and of the highest possible quality. It is rare to see a project which allows for pure Agile implementation, providing room for flexibility. Another participant shared similar ideas, emphasizing that in customer pro- jects, Agile methods are rarely used in a form they were originally planned for. Customers typically want to know what is being delivered, when it will be completed, and at what cost, leaving little room for flexibility. The same participant noted that while there might be activities where Agile practices are used, such as troubleshooting or finding worka- rounds, those are more reactive crisis situations rather than structured Agile practices. One participant suggested that there might be possibilities to use Agile methods during the preparation of a project offer. Typically, when there is a request from the customer, 53 different stakeholders start to independently assess how the requirements could be met. Instead, there could be a more structured process by gathering all the necessary people together and using Agile methods to coordinate the efforts. Another participant noted that when projects include multiple teams, each development team has the autonomy to decide their preferred working methods. Agile methodologies are encouraged when- ever possible, but teams are free to choose other approaches if they consider them more suitable. This flexibility comes from the idea that teams know best how to work effec- tively, leading to the best results. 5.9 Hybrid models When asked the participants whether they had experience of hybrid project manage- ment models, one participant shared that they had been involved in projects where the planning followed traditional methods to keep the structure in the project, but the actual implementation was executed using Agile methodologies. The same participant contin- ued that Agile methods are not limited only to implementation phase but can be used in planning phase as well. However, the primary reason for adopting a hybrid approach was to ease the selling of the projects, while still enabling Agile practices during the execution. Another participant emphasized that Agile methods should be used whenever possible, as they offer significant advantages over traditional methods. However, they cautioned against forcing Agile implementation. If certain aspects of the work clearly do not align with Agile principles, traditional methods should be used instead. They further noted that if the work is straightforward, with well-defined steps and minimal need for flexibil- ity or adaptation, using Agile might cause unnecessary confusion. Agile is most effective in situations where requirements are not fully defined, and the process involves a high degree of ambiguity. These elements align with Agile principles, enabling continuous im- provement and iteration as the project progresses. One participant noted that most of the work in their team is completed as hybrid and best practices are used from both traditional and Agile methodologies. They continued that in hybrid, they would still keep the traditional project plan but avoid breaking it down into too many details. Instead, 54 the project plan would be structured into high-level phases, while the specific tasks within each phase would be further refined and executed within individual sprints. 5.10 How to start using Agile methods When asked how to begin implementing Agile and hybrid project management methods, one participant suggested starting with the creation of a process model that integrates Agile techniques. They recommended using a previously completed project as a case study, transforming it into an Agile format, and simulating the project through a demo to gather feedback on its effectiveness. This approach allows for improvements and ad- justments before applying the model in a real-world context. The participant noted that this aligns with Elisa's focus on continuous improvement, enabling iterative development and refinement. Another participant highlighted the importance of organizing Agile training to help team members understand key roles such as Scrum Master and Product Owner. They suggested gradually introducing Agile practices, such as sprints, retrospec- tives, and other ceremonies. The participant emphasized that the key to successful adop- tion lies in taking small, incremental steps. They warned that a common reason for fail- ure is the unrealistic expectation of immediate results, which can lead to the new ap- proach being prematurely considered as unsuccessful if quick success is not achieved. One participant also viewed hybrid project management models as an effective way, highlighting their flexibility in applying Agile methods where they work best and using traditional methods where they are more appropriate. They emphasized the importance of carefully assessing each project's needs to figure out where Agile methods make sense. Forcing Agile implementation purely for the sake of being "Agile" is counterproductive and unlikely to succeed. Instead, the focus should be on promoting the adoption of Agile practices while integrating the most beneficial elements of both methodologies. They emphasized the importance of granting the project team autonomy to choose the ap- proach that best suits their work, ensuring a balance between flexibility and structure. 55 When asked about the best Agile framework to start with, participants recommended beginning with Scrum and its time-boxed sprints. They explained that sprints provide significant value to the customer by enhancing communication and enabling faster feed- back loops. The participants suggested maintaining a traditional project management plan but structuring the implementation phase in sprints. They recommended estimat- ing the number of sprints needed to achieve the project objectives while keeping the content of individual sprints flexible. This flexibility accommodates evolving require- ments and allows the project team to adapt as they gain more insight into the product. The participants also recommended planning for a couple of additional sprints, as pro- jects often encounter new requirements as they progress. Another participant shared their experience of planning and selling project work in terms of a set number of sprints. They noted that this approach benefits the service provider, as it ensures the end cus- tomer stays actively engaged and committed to the sprints. One participant shared valuable advice when implementing Agile or hybrid practices: they key is to ensure individuals are committed to the new way of working. The process fails the moment when people start skipping the daily meetings and other ceremonies. It requires strong commitment from all involved, which is essential for success. 56 6 Hybrid project management model creation The hybrid project management model is designed to mix elements from both tradi- tional project management and Agile methodologies, keeping the Stage-Gate model, while including Agile elements in it and combining strengths of both approaches. The proposed model will be presented to selected stakeholders in a simulated project envi- ronment, allowing for feedback and iterative development. This approach ensures that the new hybrid model is practically valid and meets the specific requirements of the or- ganization. The primary goal is to create a flexible hybrid framework that enables the use of Agile methodologies when applicable, while still keeping the traditional Stage- Gate structure. The following section describes the steps involved in the development process and presents an overview of the model created. 6.1 Main insights from the interviews The interviews conducted provided valuable information on what needs to be consid- ered when implementing Agile methodologies. It became clear that there is no single “correct” way to implement Agile and teams often tailor their approach by combining different elements that meet their specific needs. Participants had experience of Scrum, Kanban and hybrid methodologies, but Scrum was the most recommended approach, mainly because of its ability to produce deliverables fast and enable fast feedback loops. While Kanban was considered as a practical choice, some participants noted that it lacks structured control, which can lead to inefficiency. However, interview participants shared an understanding that the choice of methodology should be based on what best suits the unique needs of the team. 6.2 Choosing core methodologies Since the business unit is already using the Stage-Gate model as the foundation for each project, there is no need to replace it. Instead, the goal is to add Agile elements into the existing framework. Considering the nature of customer project implementations, it is 57 not possible to replace traditional elements with a pure Agile approach. Typically, cus- tomers require a preliminary cost estimate and defined list of tasks, which limits the flexibility to leave the scope entirely open. Therefore, the hybrid project management model maintains the traditional Stage-Gate structure, while integrating Agile practices in the execution phase, resulting in an Agile Stage-Gate model. Figure 11. Elisa's project model, highlighting the area for improvement (adapted from Elisa, 2024). Elisa’s renewed project management model already supports the use of Agile practices, describing how work can be organized into sprints, starting from the planning phase and continuing through the execution phase, ending in the acceptance of the project deliv- erables. The novelty lies in setting up guidelines on how to conduct and organize the project work according to Agile practices and sprints, and how to ensure the alignment with the overall Stage-Gate model in network infrastructure projects. The objective is to provide guidelines on how Agile methodologies can be integrated, and what modifica- tions it requires to existing roles, processes, and tools. 6.3 Conceptual framework The chosen Agile method for the new hybrid project management model is Scrum, as Elisa’s project management model emphasizes the ability to organize work into sprints. 58 The interview results also confirmed the expected benefits of Scrum. By implementing Scrum, the model aims to enhance efficiency, control of work, facilitate fast feedback loops, and increase collaboration, communication, and teamwork. Successful Agile adoption requires a comprehensive understanding of the processes and necessary ad- aptations to effectively manage and lead the work. The model was developed by defining processes and roles and visually representing the information using Lucidchart. 6.3.1 Roles A key consideration when implementing Scrum is its predefined roles: Product Owner, Scrum Master and the development team. In customer project environment, these roles do not exist, instead, work is primarily carried out by technical consultants and network engineers and guided by the project manager. As a result, Scrum cannot be implemented in its pure form suggested by the framework. While there might be new roles in the future, the initial piloting stage will keep existing roles to make the piloting as effortless as possible. Implementing Scrum without the predefined roles results in a customized Scrum where team members keep their existing roles, and responsibilities are shared. In this model the project manager will adopt the Scrum Master role, facilitating the Scrum process while continuing traditional project management activities. The development team will consist of technical consultants responsible for network configurations and implemen- tation, closely aligning with the Scrum framework’s definition of a development team. The Product Owner role presents the biggest challenge as it requires effective task pri- oritization and clear understanding of project needs. In this initial stage, it is recom- mended to share the Product Owner responsibilities among the project team, involving all members in prioritization activities. In projects with strong customer collaboration and close relationship, the customer’s project manager or a technical architect may also adapt the Product Owner role. 59 6.3.2 Key processes in the model The core idea of the new hybrid project management model is to increase the level of flexibility and support iterative work. To achieve this, the model replaces traditional, de- tailed upfront planning with Agile elements that prioritize adaptability, while keeping a clear overall vision for the project. In the new model, there will not be a detailed Gantt chart describing each step into detail. Instead, there will be a high-level roadmap show- ing the main deliverables and timeline, while the project execution tasks will be added to a project backlog. The work will be broken down into sprints, each with its own dura- tion and goals. When implementing Agile practices, it allows for fast and continuous feedback, focusing on tasks that provide the most value and removing the need for too detailed upfront planning, which by experience has proven to be difficult in most net- work infrastructure project settings. To balance the needs for more traditional project management with the flexibility brought by Agile elements, the hybrid project management model will implement cer- tain ceremonies that aim to foster collaboration, communication, and iterative delivery. The model allows to implement daily stand ups with intervals that the project team sees reasonable, sprint planning sessions to prioritize the near future goals, sprint review ses- sions to review the completed work, and retrospective sessions to identify areas for im- provement. In the new model, Scrum ceremonies will be implemented to guide the iterative parts of the project. The project team has the freedom to choose the frequency of daily standups and other ceremonies as well to match the specific needs of the project. In the initial model, each team member would take part in all ceremonies, as the project manager takes on the Scrum Master role, and the Scrum team shares the responsibility of the Product Owner. The model allows other stakeholders to join the sprint review sessions to see what the project team has accomplished during the sprint, but this depends on the project and whether there is something to present to a wider audience at the end of the sprint. 60 Figure 12. Modified Scrum ceremony model for hybrid project management. Adapted from Lu- cidhart template by Leo Barnes (Lucidchart, n.d.). Figure 13. Modified Scrum workflow for hybrid project management. Adapted from a Lucidchart template by Leo Barnes (Lucidchart, n.d.). The hybrid project management model will follow the so-called Water-Scrum-Fall method, which emphasizes detailed planning at the beginning of the project, Agile ele- ments during the development phase, and then shifts back to Waterfall methodologies when transitioning into production. The early Waterfall methodology allows the project 61 to plan in a way that the end customers get a preliminary estimate of the costs and over- all project duration. When the execution phase begins, the backlog will be created and updated throughout the project, but the steps for the actual production release remain structured, following Waterfall once again. In network infrastructure projects, there are typically clear guidelines on how services are transitioned into production. 6.3.3 Tools During the interviews, several tools were mentioned. The majority of interview partici- pants noted Jira as the preferred solution for Agile implementations, but other tools were also highlighted. One participant described using a customized Excel document to manage sprints within their team, while Microsoft Project and Microsoft Planner were also mentioned. Based on these insights, the author began analyzing various tool options to determine the most suitable solution for the customer projects targeted in the thesis. The author had prior experience with Jira and recognized it as one of the most effective tools for Agile. However, the author considered Jira better suited for dedicated teams with stable, routine workflows and low turnover rates. In such teams, the features of Jira, such as burndown charts and velocity tracking, can be fully utilized to provide detailed work metrics. In contrast, customer projects in the network infrastructure projects are often different. Project teams are typically formed of members who may not have worked together before, making collaboration and adaptation a priority. The complexity of Jira might be a challenge, especially since the aim is to keep the model as simple as possible in the piloting stage. Based on the idea that Jira was not the primary tool to use, the author looked at other options as well. The author got familiar with Trello which is an Agile project management tool provided by Atlassian and also investigated the possibilities of using visualization tools such as Miro and Lucidchart to guide the work within the model. Trello proved to be a suitable tool to organize Agile work, but Miro and Lucidchart lacked the needed features. The author also assessed Microsoft Planner, a lightweight project management 62 and team collaboration tool provided by Microsoft. Planner seemed like a reasonable tool due to its ease of use even though it lacks certain features. Next, the author investigated Microsoft Project. The author already had some experi- ence of working with the software, but mainly for Waterfall-type projects. Today, Mi- crosoft Project includes Agile features as well, and after testing, it appeared to be the best solution for hybrid project management. The software provides features that allow tracking both long-term planning (traditional) and short-term planning (Agile), making it useful for projects that require a mix of methodologies. Microsoft Project also scales easily, can be used in projects of diverse sizes, and offers a flexible way to switch between traditional and Agile methodologies within the same project. Another reason for choos- ing Microsoft Project is that Elisa and its customers typically use Microsoft ecosystem. Since the goal is to implement hybrid project management practices and create a sup- porting model, Microsoft Project is a suitable choice. It provides traditional project man- agement components, mainly Gantt charts, which can be used to track linear and se- quential tasks in the project, while also offering high-level timeline views to communi- cate progress to stakeholders. Network infrastructure projects often involve phases that require clear sequential activities, such as planning, procurement, hardware delivery and installation, and transfer into production. In addition to traditional methods, Microsoft Project also supports Agile methodologies, with in-built Agile boards to organize the it- erative parts of the project. Many projects include activities that benefit from an itera- tive approach, particularly when introducing modern technologies, as the design of the solution might not be fully defined and requires iterative refinement. In Microsoft Project, work is divided into tasks that follow either a traditional approach or an Agile methodology. In the view below, tasks in the initiation and planning phases are carried out sequentially, as indicated by the column “Show on Board,” which specifies that these tasks are not included on any Agile boards. In contrast, tasks intended for execution in sprints are included on the board. Microsoft Project enables easy navigation 63 between these different views, allowing for efficient management of both traditional and Agile workflows. Figure 14. An overview of MS project and task distribution between traditional and Agile meth- odologies. With Agile boards in Microsoft Project, sprint progress can be tracked visually in a board view, showing the status of tasks within a sprint. In the board view, sprint tasks can be tracked and moved through various stages, assigned to specific resources, and updated with notes. With the help of Scrum ceremonies and efficient task tracking, teams can keep a structured and organized workflow. Once tasks are completed and moved to “completed” stage in the board view, their status is automatically updated in the Gantt chart view. 64 Figure 15. Sprint board view on Microsoft Project. 6.4 Overview of the hybrid project management model The core of the new model is built around Microsoft Project, which will be the primary tool for high-level planning, visualizing project milestones and dependencies through Gantt charts and roadmaps. These traditional elements provide an overall picture of the project, outlining clear timelines for key deliverables. The built-in sprint functionality in Microsoft Project will be used to divide the execution phase into time-boxed sprints, breaking tasks into smaller, manageable work items. While overall project tracking is managed in a traditional way, the execution phase is driven by Agile sprints and ceremonies, ensuring flexibility, continuous value creation, and effective collaboration. At the start of each sprint, tasks are pulled from the high- level Gantt chart to be completed within the sprint. The sprint functions of Microsoft Project ease the process, enabling teams to plan and track tasks efficiently. During each sprint, daily standups are held to monitor the progress, manage possible blockers, and ensure alignment with the overall project timeline. At the end of each sprint, sprint re- view sessions demonstrate the completed work, and retrospectives provide an oppor- tunity to reflect on success and identify areas for improvement. 65 To ensure the project remains aligned with strategic goals while adding Agile practices, the Stage-Gate model will be adapted into Agile Stage-Gate approach, meaning that Ag- ile practices are applied between the gates. This hybrid model offers a good balance be- tween structured decision points (gates) and the flexibility of Agile. It enables long-term high-level planning while still maintaining adaptability in the short term. Agile ceremo- nies increase collaboration and feedback, while traditional charts in Microsoft Project provide stakeholders clear visibility into overall progress and project objectives. 66 7 Hybrid project management model validation After the new hybrid project management model had been developed, the next step was to confirm its feasibility and applicability in a simulated project environment. Since pi- loting the model in a real-life project was not possible at the time due to not having a suitable project available, the validation was conducted through a simulation. The ob- jective of the session was to evaluate how well the model could be applied to customer projects within the company, focusing on a recently completed SD-WAN (software-de- fined wide area network) implementation project as a case example. The session pro- vided an opportunity to identify any challenges in the current model and highlight areas that needed improvement before the model would be piloted in a real-life project. 7.1 Validation setup and process The session was designed as a simplified simulation session of the hybrid project man- agement model with the necessary participants to discuss and evaluate the model. In addition to the author, there were four participants in the session: Business Lead for project deliveries, Business Lead for technical consulting services, Team Lead for project management office, and one technical consultant. In the simulation, the author repre- sented the role of the project manager, and also adapted the role of the Scrum Master, facilitating the Scrum process. The technical consultant presented both the development team and the Product Owner and had previously worked with the project manager in the SD-WAN implementation project and was therefore well familiar with the example context. The other roles were present to observe and provide feedback on the model. While participants did not execute actual project tasks, they took part in discussions that simulated decision-making processes within an Agile framework. The selected example project was an SD-WAN implementation recently completed by the business unit. The project was an ideal candidate for Agile practices, as it had all the elements suitable for Agile environment. The work was conducted by a small, dedicated team, there was close collaboration with the end customer, and it was possible to divide 67 the project work into modular components. Both the project manager and the technical consultant had been working on the project and could reflect on how Agile practices might have increased efficiency. Additionally, the session aimed to identify other pro- jects that would be suitable for the hybrid project management model. Due to limited availability of the resources and competing priorities, the simulation ses- sion was time-boxed to 2 hours and the aim was to cover all aspects of the model briefly while allowing for discussion at each stage. Given the constraints, the focus was primarily on the Agile aspects of the model, rather than the transition from the traditional ap- proach to Agile. The session followed a structured format where each ceremony was introduced, followed by an open discussion and feedback by the participants. Microsoft Project was used to support the discussion, and author facilitated the process by modi- fying the tasks on the Agile board as needed. The purpose of the simulation was to sys- tematically walk through each ceremony of the Agile model, discussing key points and gathering feedback at each stage. The aim was to assess how well the participants con- sidered the model could be applied to customer projects. The session began with an introduction to the topic and the background of the study, followed by structured dis- cussions on each Agile ceremony. Approximately 20 minutes were allocated for each cer- emony and at the end 20 minutes were dedicated for the overall feedback on the model and possible next steps for its adoption. 7.2 Results The introduction to the topic already generated initial discussion as the author asked whether participants had previously used Scrum practices in their projects. The technical consultant shared their experience of using Scrum in earlier positions when their team organized work into sprints. The consultant noted that they did not follow the Scrum process as suggested by the framework, instead they adapted the practices that were most suitable for their team. The author highlighted that this flexibility is a core feature of Agile, allowing teams to choose practices that work best for them. 68 When discussing the proposed roles in the model and particularly the idea of a shared Product Owner responsibility, the Business Lead for project deliveries mentioned having experience in software development projects where the Product Owner was responsible for deciding the tasks for the upcoming sprint, and the development team worked ac- cordingly. The participant wanted to clarify whether this model would follow the same principle or if there would be a different approach. In response, the author explained that the roles would need to be tailored to suit the network infrastructure projects, high- lighting that the role of the Product Owner was also one of the most discussed aspects during the interviews. The challenge with the role is that it does not exist in the network infrastructure projects, therefore the suggestion was to make it a shared role, at least in the piloting stage of the model, to ensure efficient implementation. The other partici- pant, Business Lead for consulting services, pointed out that the role of a Product Owner can vary from project to project. In some projects, it might be the most effective solution if the customer takes the role, while in some projects the project manager and network architect could share the responsibility. The author suggested that the hybrid project management model could be especially suitable for projects that have high uncertainty, strong collaboration with the end cus- tomer, and work that can be divided into modules. One participant emphasized the value of the model in the planning phase, mentioning that it could increase efficiency when different sub areas of the project are being structured. There was also discussion about its applicability in network infrastructure projects, where the transition to production follows predefined steps. While the model may not be ideal for all activities, it was rec- ognized as a valuable tool for improving the efficiency and monitoring of daily planning work. The technical consultant highlighted potential challenges in the model. They shared their past experience working in Scrum environment, where a dedicated team of network en- gineers and IT specialists worked on multiple projects simultaneously, benefiting from the capability to divide tasks between individuals. In the current environment with 69 several projects ongoing at the same time with different teams, they pointed out that attending several daily standups, along with other meetings, would create much over- head and reduce efficiency. They noted that dedicating all working time to a single pro- ject would require an exceptionally large project. Another participant shared the same idea that splitting time between multiple daily standups might not be practical. After the introduction, the discussion continued by walking through each ceremony in the model. The author began by presenting the backlog and how it can be used for col- lecting all the tasks while enabling prioritization based on urgency and importance. The author illustrated how typical tasks in an SD-WAN implementation project could be structured, with each location divided into subtasks for easier tracking and monitoring. The backlog would form the foundation for sprint planning, and the author presented how tasks could be easily added and how to manage the process using various function- alities available in Microsoft Project. After the backlog presentation, participants asked several questions. One participant pointed out that while the demonstration used Microsoft Project, a similar board could also be created in Microsoft Planner where all team members have easy access. This generated more discussion about alternative tools and author noted that Microsoft Plan- ner was one viable option that was considered while creating the model. However, au- thor chose Microsoft Project, primarily because of its ability to support both traditional Gantt charts and Agile boards, making it suitable for hybrid project management. An- other participant highlighted that the core principle of Agile is that team members up- date their tasks independently, eliminating the need for a project manager to update the tasks. The author noted this and mentioned that ideally all team members should take responsibility for the updates, but interviews revealed mixed practices. In some projects, individual team members actively maintained task updates, but often the primary re- sponsibility fell on the Scrum Master. The technical consultant added that based on their earlier experience, tasks updates were mainly managed by the Scrum Master, even though some team members occasionally updated them independently. 70 Next the sprint planning ceremony was introduced. The author explained the principles behind sprint planning and why it would be beneficial to agree and confirm the targets for the upcoming weeks. Using the SD-WAN implementation project as an example, it highlighted how changing priorities had often disrupted efficiency, making structured planning necessary. The technical consultant also shared similar experiences and noted that the model could help address such challenges, however there was uncertainty about how well the customer would commit to the process. This generated additional discussion about commitment and one participant shared that in their past projects, planning was done collaboratively, and there was a voting included in the process to clarify if the proposed plan was realistic. If even one person disagreed, the planning would restart to reach a consensus. The key takeaway from the discussion was that com- mitment to goals is essential, and each team member must agree on the plan for it to be effective. Another participant noted that the model effectively visualizes the team’s goals and commitment for a specific sprint, while also making it clear that any urgent tasks arising during a sprint will affect the final outcomes. About the previously mentioned voting process, the author added that as Agile team matures, there are several different task estimation techniques that can be used to improve planning accuracy. Some of these techniques were also mentioned in the interviews. One participant emphasized that the model clearly illustrates how weekly planning should be conducted in a project and saw significant potential in the model. Next the author introduced the concept of sprint execution in the model, focusing on daily standups and tracking of work in Microsoft Project. The author demonstrated how tasks can be moved across boards and efficiently tracked throughout the sprint. The daily meetings were explained as being structured around three questions: What has been done since the last meeting? What will be done before the next meeting? Are there any impediments blocking progress? The author also showed how blocked tasks can be easily marked on the board, simplifying status tracking. When asking for feedback on the 71 execution phase, one participant highlighted the expected potential of short daily standup meetings. Based on their experience, regular collaboration and active discus- sion save time overall as issues can be prevented early. Another participant pointed out that direct conversations are typically more effective than chat messages or emails, sup- porting the idea of clear communication and ensuring that all team members are fully committed to the goals. The technical consultant mentioned that based on their earlier experience with daily meetings, noting that while it felt unusual and even like a form of micromanagement in the beginning, they later proved to be an efficient way of sharing information. Over time, as the team adapted to the routine, the meetings became highly beneficial. Following the discussion on execution, the sprint review and retrospective were intro- duced. The author explained the principles behind the ceremonies and how at the end of each sprint, the completed work should be presented. The author demonstrated how tasks can be marked as complete on the board, how unfinished tasks can be moved to the next sprint, and how different sprints can be archived in Microsoft Project to main- tain historical records. Additionally, the author highlighted the importance of retrospec- tives after each sprint and achieving lessons learned. Participants responded positively to the idea of gathering lessons learned more often, contributing to continuous improve- ment. One participant noted that a key strength of Scrum is that the team learns as they progress, which increases efficiency and adaptability. After covering the sprint review and retrospective, the author presented the concept of a continuous sprint cycle. In the cycle, once the existing sprint has ended, the next one begins directly after. The author used Microsoft Project to visualize the progress on Agile board and show the transition into the next sprint. The last step of the session involved gathering overall feedback on how participants con- sidered the model’s suitability for the current project portfolio of the business unit. Over- all, the response was positive, and participants considered the elements of the model to be highly beneficial for managing customer projects. Many participants saw potential in 72 applying the methods and began considering upcoming projects where the model could be piloted, especially projects with dedicated teams and modular work structures. In addition to positive feedback, some challenges were also identified. One concern was the difficulty of finding a project that perfectly aligns with the model’s framework. Addi- tionally, the roles within the model and especially the role of a Product Owner remained somewhat unclear. However, there was a shared understanding that these challenges could be addressed easily, and the model adapted to network infrastructure projects. Participants agreed that clarification of the roles is essential for successful implementa- tion to prevent confusion regarding responsibilities. 73 8 Discussion 8.1 Key findings This study explored the potential application of Agile project management methodolo- gies in network infrastructure projects at Elisa Oyj by creating a hybrid project manage- ment model tailored to this specific context. The main research question of the thesis was: How well do Agile methodologies fit into the implementation of customer projects, and what potential benefits could their adoption bring to the business unit? To address this, it was necessary to investigate the current project management practices in the organization and understand how Agile practices are currently being used in other areas within the organization. To support the investigation, a secondary research question was formulated: How have other business units and departments within the organization im- plemented Agile methodologies, and what lessons and best practices can be applied to the development of a hybrid project management model for customer project imple- mentations? To understand how Agile practices are used in other areas within the organization, the author conducted six semi-structured interviews, aiming to form an understanding of the current practices. The interviews showed that Agile practices were already in use in several areas within the organization, but their implementation varied significantly. Agile practices were most common in internal development teams where the teams run the weekly operations using Scrum, focusing not only on projects but also on other opera- tions. All interviewed project managers reported that at Elisa, projects still mainly follow traditional project management approaches due to contractual constraints and prede- fined scope, budget, and timeline requirements. While there have been some positive experiences using Agile, its application in customer projects remain limited. This is pri- marily because of the above-mentioned constraints and lack of dedicated projects teams, as almost all employees work on multiple projects simultaneously. 74 Based on the findings, a hybrid project management model was developed. It includes Agile elements without removing the structured approach required for customer project implementations. The model suggests dividing project execution into sprints while main- taining a high-level project plan. Key aspects of the model include using Scrum and sprints for specific execution phases, while keeping traditional project management as- pects in planning and transition into production. Microsoft Project was proposed as the preferred tool to support both methodologies due to its suitability for both Agile and traditional methods. Overall, the model offers increased flexibility by defining the scope of work for each individual sprint, while ensuring alignment with contractual require- ments. However, successful implementation requires careful planning, stakeholder en- gagement, and proper training. The model was validated through a simulation, which showed potential, even though real-life projects and customer environments that fully support the model remain limited. The participants confirmed that the model itself looks feasible and would most likely bring several benefits, such as improved communication, better transparency, increased team spirit, and more efficiency, but it remains challenging to find a project environment where it can be used. The validation brought up similar issues as the interviews did, high- lighting that the multi-project environment in which Elisa operates is the most challeng- ing aspect. It takes a lot of commitment from both internal teams and external custom- ers to effectively use the model. However, participants of the simulation saw a lot of potential in the model and considered it suitable for network infrastructure projects, if implemented carefully and considering case-specific constraints. 8.2 Theoretical and practical contributions This study contributes to the theoretical understanding of how Agile methodologies can be utilized outside of software development, especially within network infrastructure projects. Earlier research has shown that combining traditional and Agile approaches to create hybrid frameworks can improve the responsiveness to changing requirements and enhance collaboration and efficiency (Cooper & Sommer, 2016b). This thesis 75 proposes a hybrid approach that can be used in network infrastructure projects, where traditional methodologies still dominate due to contractual constraints and strict scope definitions. This study supports the view that successful implementation of Agile and hybrid meth- odologies requires careful consideration of the organizational context, including availa- ble competencies and environmental factors (Rasnacis & Berzisa, 2017). In line with the guidance from Project Management Institute (2017), the research acknowledges that organizations typically adopt Agile by either taking a framework fully in use or selecting specific practices that fit the project needs. The hybrid project management model de- veloped in this thesis supports the latter approach, combining traditional project man- agement practices with Agile practices such as sprints and iterative phases. The study offers a practical example how principles of Agile can be adopted outside of software development. From a practical perspective, this study provides valuable insights for Elisa Oyj and other organizations that are managing customer projects within a multi-project environment. Project managers may benefit from concrete suggestions of using sprints within the tra- ditional Waterfall methodology and Stage-Gate model, supported by tools such as Mi- crosoft Project. The study also emphasizes the importance of internal commitment and stakeholder engagement when aiming to adopt Agile practices in network infrastructure projects. In addition, the results highlight the potential of using Agile practices outside of software development, providing new perspectives on how Agile could be gradually introduced in networking. 8.3 Limitations of the study While the study provides valuable insights into how Agile practices could be applied to network infrastructure projects, especially at Elisa Oyj, there are certain limitations that should be acknowledged. The research relied primarily on qualitative data collected through interviews, and the sample size was relatively small. A larger and more diverse 76 sample size could have generated broader perspectives and strengthened the findings. Additionally, the research focused on the internal context of Elisa Oyj, which limits the generalizability of the results to other organizations. The proposed hybrid model was validated through a simulation instead of an actual project implementation. The practi- cal effectiveness of the model remains theoretical at this point. As the author continues to work at Elisa, the intention is to pilot the model in a real project environment when a suitable opportunity arises. 8.4 Suggestions for future research There are several suggestions for future research. First, the hybrid project management model should be piloted in a real-life project environment to evaluate its applicability, gather feedback, and refine the framework. Quantitative metrics could be introduced to measure the impact of Agile practices on key metrics such as delivery time, cost, or team productivity. Another potential direction for additional research is to investigate how hy- brid project management can be adopted for diverse types of projects, as well as how organizational culture influences the effectiveness of adoption. In addition to this, dif- ferent project management tools could be analyzed to determine which are best suited to support Agile and hybrid practices. Comparative studies between projects using Agile versus traditional methods could also provide valuable insights into best practices and adoption strategies. 77 9 Conclusion This thesis aimed to explore the applicability of Agile project management methodolo- gies in network infrastructure projects at Elisa Oyj. The main research question investi- gated how well Agile methodologies fit into such projects and what potential benefits their adoption could possibly bring to the business unit. To support this, a secondary research question examined how other departments within the organization had imple- mented Agile methodologies and what best practices could be utilized when developing the hybrid project management model. The research questions were addressed through a combination of semi-structured interviews, design science research, and the creation of the hybrid project management model. By investigating current Agile practices within other areas of the organization, the study found that while Agile methodologies have been successfully implemented in internal development teams, their use in customer-facing projects remain limited due to con- straints such as fixed scope, timelines, and multiproject environments with lack of dedi- cated teams. However, the interviews revealed that Scrum is the preferred method for Agile implementation. The findings led to the development of a hybrid project manage- ment model, which integrates Scrum and sprints, while maintaining traditional project management methodologies to ensure alignment with the contractual requirements. The model was validated through a simulation, which confirmed its potential but also highlighted challenges related to Elisa’s organizational structure and project dynamics. In conclusion, this thesis contributes to the understanding of how Agile methodologies could be applied to network infrastructure projects, especially in organizations that are used to traditional project management environments. As a case study, the findings are specific to Elisa Oyj and provide practical insights into the adoption of hybrid methodol- ogies in similar contexts. Further research is recommended to explore the real-life ap- plicability of the model and its impact on key project performance metrics. 78 References Andrei, B. A., Casu-Pop, A. C., Gheorghe, S. C., & Boiangiu, C. A. (2019). A study on using waterfall and agile methods in software project management. Journal of Infor- mation Systems & Operations Management, 13(2), 125–135. Barnes, L. (n.d.). Sprint ceremonies [Lucidchart template]. Lucidchart. https://www.lu- cidchart.com Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Gren- ning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R. C., Mel- lor, S., Schwaber, K., Sutherland, J., & Thomas, D. (2001). Manifesto for Agile soft- ware development. Retrieved February 1, 2025, from https://agilemanifesto.org Betta, J., & Boronina, L. (2018). Transparency in project management – From traditional to agile. Proceedings of the Third International Conference on Economic and Busi- ness Management (FEBM 2018) (pp. 446–449). https://doi.org/10.2991/febm- 18.2018.103 Bianchi, M. J., Conforto, E. C., Rebentisch, E., Amaral, D. C., Rezende, S. O., & De Padua, R. (2021). Recommendation of project management practices: A contribution to hybrid models. IEEE Transactions on Engineering Management, 69(6), 3558– 3571. https://doi.org/10.1109/TEM.2021.3101179 Braun, V., & Clarke, V. (2012). Thematic analysis. In H. Cooper, P. M. Camic, D. L. Long, A. T. Panter, D. Rindskopf, & K. J. Sher (Eds.), APA handbook of research methods in psychology, Vol. 2. Research designs: Quantitative, qualitative, neuropsychologi- cal, and biological (pp. 57–71). American Psychological Associa- tion. https://doi.org/10.1037/13620-004 Brocke, J. V., Hevner, A., & Maedche, A. (2020). Introduction to design science research. In Progress in IS (pp. 1–13). Springer. https://doi.org/10.1007/978-3-030-46781- 4_1 Ciric, D., Lalic, B., Gracanin, D., Tasic, N., Delic, M., & Medic, N. (2019). Agile vs. traditional approach in project management: Strategies, challenges and reasons to intro- duce Agile. Procedia Manufacturing, 39, 1407– 1414. https://doi.org/10.1016/j.promfg.2020.01.314 79 Cisco. (n.d.). What is network infrastructure? Cisco. Retrieved March 11, 2025, from https://www.cisco.com/c/en/us/solutions/enterprise-networks/what-is-net- work-infrastructure.html Cobb, C. G. (2011). Making sense of agile project management: Balancing control and agility. John Wiley & Sons, Inc. https://doi.org/10.1002/9781118085950 Cobb, C. G. (2015). The project manager's guide to mastering agile: Principles and prac- tices for an adaptive approach. Wiley. Cooper, R. G. (1990). Stage-gate systems: A new tool for managing new products. Busi- ness Horizons, 33(3), 44–54. https://doi.org/10.1016/0007-6813(90)90040-I Cooper, R. G., & Sommer, A. F. (2016a). The Agile–Stage-Gate hybrid model: A promising new approach and a new research opportunity. Journal of Product Innovation Management, 33(5), 513–526. https://doi.org/10.1111/jpim.12314 Cooper, R. G., & Sommer, A. F. (2016b). Agile-Stage-Gate: New idea-to-launch method for manufactured new products is faster, more responsive. Industrial Marketing Management, 59, 167–180. https://doi.org/10.1016/j.indmarman.2016.10.006 Damij, N., & Damij, T. (2021). An approach to optimizing Kanban board workflow and shortening the project management plan. IEEE Transactions on Engineering Man- agement, 71, 13266–13273. https://doi.org/10.1109/tem.2021.3120984 Dybå, T., Dingsøyr, T., & Moe, N. B. (2014). Agile project management. Software project management in a changing world (pp. 277–300). Springer. https://doi.org/10.1007/978-3-642-55035-5_11 Elisa. (2024). Corporate Customers unit. Elisa Intranet. Retrieved December 27, 2024. [Restricted availability] Elisa. (2024). Elisa Project Model (EPM). Elisa Intranet. Retrieved December 3, 2024. [Re- stricted availability] Elisa. (2024). Projekti- ja kehitysmallit. Elisa Intranet. Retrieved December 27, 2024. [Re- stricted availability] Elisa. (n.d.). Home. Elisa. Retrieved February 6, 2025, from https://www.elisa.com/ 80 Ferreira, L. S., & Nobre, F. S. (2022). Agile project management under the perspective of dynamic capabilities. Gestão & Produção, 29, 1-24. https://doi.org/10.1590/1806-9649-2022v29e3122 Fitriani, A. N., Raharjo, T., Hardian, B., & Prasetyo, A. (2021). IT infrastructure agile adop- tion for SD-WAN project implementation in pharmaceutical industry: Case study of an Indonesian company. 2022 IEEE International IOT, Electronics and Mecha- tronics Conference (IEMTRONICS), 1–6. https://doi.org/10.1109/iemtron- ics52119.2021.9422650 Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004). Design science in information sys- tems research. MIS Quarterly, 28(1), 75–105. https://doi.org/10.2307/25148625 Hobbs, B., & Petit, Y. (2017). Agile methods on large projects in large organizations. Pro- ject Management Journal, 48(3), 3–19. https://doi.org/10.1177/875697281704800301 Hohl, P., Klünder, J., Van Bennekum, A., Lockard, R. D., Gifford, J., Münch, J., Stupperich, M., & Schneider, K. (2018). Back to the future: Origins and directions of the “Agile Manifesto” – Views of the originators. Journal of Software Engineering Research and Development, 6(1). https://doi.org/10.1186/s40411-018-0059-z Hron, M., & Obwegeser, N. (2018). Scrum in practice: An overview of Scrum adaptations. Proceedings of the Annual Hawaii International Conference on System Sciences, 5445–5454. https://doi.org/10.24251/hicss.2018.679 Juricek, J. (2014). Agile project management principles. Lecture Notes on Software Engi- neering, 172–175. https://doi.org/10.7763/lnse.2014.v2.117 Lei, H., Ganjeizadeh, F., Jayachandran, P. K., & Ozcan, P. (2017). A statistical analysis of the effects of Scrum and Kanban on software development projects. Robotics and Computer-Integrated Manufacturing, 43, 59–67. https://doi.org/10.1016/j.rcim.2015.12.001 Ozkan, N., & Tarhan, A. (2019). A review of scaling approaches to agile software devel- opment models. Software Quality Professional, 21(4), 11–20. Palinkas, L. A., Horwitz, S. M., Green, C. A., Wisdom, J. P., Duan, N., & Hoagwood, K. (2015). Purposeful sampling for qualitative data collection and analysis in mixed 81 method implementation research. Administration and Policy in Mental Health and Mental Health Services Research, 42(5), 533–544. https://doi.org/10.1007/s10488-013-0528-y Patil, A. V. (2019). Comparative analysis between sequential and project management approaches. International Research Journal of Engineering and Technology, 6(7), 3035–3040. Peffers, K., Tuunanen, T., Rothenberger, M. A., & Chatterjee, S. (2007). A design science research methodology for information systems research. Journal of Management Information Systems, 24(3), 45–77. https://doi.org/10.2753/MIS0742- 1222240302 Project Management Institute. (2017). A guide to the project management body of knowledge (PMBOK® guide) (6th ed.). Project Management Institute. Project Management Institute. (2017). Agile practice guide. Project Management Insti- tute. Project Management Institute. (2021). A guide to the project management body of knowledge (PMBOK® guide) (7th ed.). Project Management Institute. Project Management Institute. (2024). Pulse of the profession: The future of project work: Moving past office-centric models. Project Management Institute. Rasnacis, A., & Berzisa, S. (2017). Method for adaptation and implementation of agile project management methodology. Procedia Computer Science, 104, 43–50. https://doi.org/10.1016/j.procs.2017.01.055 Reiff, J., & Schlegel, D. (2022). Hybrid project management – A systematic literature re- view. International Journal of Information Systems and Project Management, 10(2), 45–63. https://doi.org/10.12821/ijispm100203 Sachdeva, S. (2016). Scrum methodology. International Journal of Engineering and Com- puter Science, 5(6), 16792–16799. Salameh, H. (2014). What, when, why, and how? A comparison between agile project management and traditional project management methods. International Jour- nal of Business and Management Review, 2(5), 52–74. 82 Saunders, M., Lewis, P., & Thornhill, A. (2007). Research methods for business students (4th ed.). Pearson. Schoch, K. (2020). Case study research. In G. J. Burkholder, K. A. Cox, L. M. Crawford, & J. H. Hitchcock (Eds.), Research design and methods: An applied guide for the scholar-practitioner (pp. 245–258). SAGE Publications. Schwaber, K., & Sutherland, J. (2012). Software in 30 days: How agile managers beat the odds, delight their customers, and leave competitors in the dust. John Wiley & Sons. Inc. Schwaber, K., & Sutherland, J. (2020). The Scrum guide. https://scrumguides.org Scrum.org. (n.d.). What is Scrum? Scrum.org. Retrieved January 2, 2025, from https://www.scrum.org/learning-series/what-is-scrum/ Volovyk, O., & Harmash, O. (2022). Exploring current project management methodolo- gies in the context of their best applications. Electronic Scientific Journal Intellec- tualization of Logistics and Supply Chain Management #1 2020, 14, 17– 30. https://doi.org/10.46783/smart-scm/2022-14-2 Zasa, F. P., Patrucco, A., & Pellizzoni, E. (2021). Managing the hybrid organization: How can agile and traditional project management coexist? Research-Technology Management, 64(1), 54–63. https://doi.org/10.1080/08956308.2021.1843331 83 Appendices Appendix 1. Interview questions Theme 1: Background and role 1. Can you please tell me your current role and responsibilities within the organi- zation? 2. How long have you been working in this role and within this organization? 3. Can you describe your previous experience with project management method- ologies, specifically Agile and traditional methods? Theme 2: Implementation of Agile methods 4. How are Agile methods currently implemented in your team or department? 5. What specific Agile practices or frameworks (e.g., Scrum, Kanban) does your team follow, and how are they implemented in day-to-day project activities, and what tools are in use? 6. Can you describe a recent project where Agile methods were particularly effec- tive? Theme 3: Challenges 7. Can you describe any challenges or obstacles your team has faced in imple- menting Agile practices, and how have you addressed them? 8. Are there any ongoing issues or barriers to Agile adoption? Theme 4: Benefits 9. What motivated your department to adopt Agile methodologies, and what ben- efits have you observed as a result? 10. Can you share any success stories related to Agile implementation? 11. How has Agile impacted team morale and productivity? 12. How do you measure the success or effectiveness of Agile practices within your department, and what metrics or indicators are used? 84 Theme 5: Hybrid project management models 13. Have you used hybrid project management models that combine Agile with other methodologies? 14. How do you decide when to use Agile versus traditional methods? 15. What are the challenges and benefits of hybrid models? Theme 6: Recommendations and future directions 16. In your opinion, what are the critical success factors for implementing Agile methodologies effectively, and what advice would you offer to other depart- ments considering adoption? 17. Do you have recommendations for transitioning to a hybrid model?