Masaryk University

Faculty of Economics and Administration

Field of Study: Business Management

IMPLEMENTING THE PRINCE2 PROJECT MANAGEMENT

METHOD IN AN EXISTING PROJECT ENVIRONMENT

Master's Thesis

Supervisor:

Tuck Lloyd Crawford Macrae, M. B.A.

Author:

Liliia Demianchuk

Brno, 2020

MUNIECON

MASARYKOVA UNIVERZITAFaculty of Economics and Administration

Lipová 41a, 602 00 BrnoIČ: 00216224

DIČ: CZ00216224

Master'sthesis description

Academic year: 2019/2020

Student: Liliia Demianchuk

Programme: Economy and Management

Field of Study: Business Management (Eng.)

Title of the thesis/dissertation: Implementing the PRINCE2 Project Management Method inan Existing Project Environment

Title of the thesis in English: Implementing the PRINCE2 Project Management Method inan Existing Project Environment

Thesis objective, procedure and methods used: This is a case study based thesis. It is the responsibility of thestudent to find a selection of appropriate companies on whichto base the case study. The final selection must be appro-ved by the supervisor. Approach and methods used: 1. Bac-kground research which, at a minimum, addresses what is pro-ject management, what standard methods are available to or-ganisations, comparisons of the methods, waterfall and agiledelivery methods and their impact on method implementation;2. A thorough analysis of the project management policies,procedures, processes, and methods used by the companyunder study; 3. A comparison between the PRINCE2 methodand the company’s policies, procedures, processes, and me-thods. 4. Findings and Recommendations covering, at a mini-mum, how PRINCE2 can be embedded into the organisationincluding actions required, timelines and costs, a complete ex-planation of the potential financial and non-financial benefits,and an analysis of the potential risks and possible risk miti-gation. Self-study and extensive research is required. The stu-dent is expected to expand well beyond the literature listed anddemonstrate substantial additional learning.

Extent of graphics-related work: According to thesis supervisor’s instructions

Extent of thesis without supplements: 60 – 80 pages

Literature: Agile contractscreating and managing successful projects withScrum. Edited by Andreas Opelt. Hoboken, N.J.: Wiley, 2013.xiv, 282 p. ISBN 9781118640128.

Directing Successful Projects with PRINCE2®. : Axelos,2009. 166 s. ISBN 978-0-11-331060-9.

Managing successful projects with Prince2. Sixth edition.Norwich: Axelos, 2017. 327 s. ISBN 978-0-11-331533-8.

PRINCE2 Agile® Guidance. : Axelos, 2015. 360 s.ISBN 978-0-11-331467-6.

Thesis supervisor: Tuck Lloyd Crawford MacRae, M. B.A.

Thesis supervisor’s department: Department of Corporate EconomyFaculty of Economics and Administration

Page 1 of 2

Thesis assignment date: 2019/05/15

The deadline for the submission of Master’s thesis and uploading it into IS can be found in the academic year calendar.

In Brno, date: 2020/05/09

Page 2 of 2

Name and surname of the author:

Master's thesis title:

Department:

Master's thesis supervisor:

Master's thesis date:

Liliia Demianchuk

Implementing the PRINCE2 Project

Management method in an existing project

environment

Business Management

Professor Tuck Lloyd Crawford Macrae M.

B.A.

2020

Abstract

This research is qualitative, empirical research, based on the case study of XYZ company,

in particular, one of XYZ's development teams - the FI-CA team. The primary goal of the thesis

is to test the hypothesis that PRINCE2 methodology can be tailored to the project environment

of the analyzed company and combined with agile concepts, that positively affects existing

procedures, policies, and processes, techniques of the FI-CA team. The tailoring of PRINCE2

methodology is considered in combination with Agile philosophy which is the foundation of

XYZ's development and delivery concept, and partially implemented in the FI-CA team.

The theoretical part of the thesis provides a comprehensive literature overview, particularly

PRINCE2 and its integrated elements as well as the Agile framework, to form the theoretical

foundation for the study. The practical part of the study comprises the analysis of XYZ as a

whole and the process of project handling in the FI-CA team specifically. Thereafter,

recommendations are comprehended based on the results of the PRINCE2 Agile Health Check

with the summary of identified inconsistencies and flaws of the existing methodology used by

the FI-CA team. Recommendations include improvement and deployment of existing agile

practices that are compliant with the XYZ's transformation strategy, and tailoring the PRINCE2

framework to the unique environment and conditions of the FI-CA team. The last part with the

evaluation of the performance of the FI-CA team and key benefits attained while using

PRINCE2 Agile methodology proves the formulated hypothesis.

Keywords: Project Management, PRINCE2 Methodology, Agile, Scrum, PRINCE2 Agile

Methodology, the FI-CA team, development, software solutions.

Declaration

“I certify that I have written the Master’s Thesis “Implementing the PRINCE2 PM method in

an existing project environment” by myself under the supervision of Tuck Lloyd Crawford

Macrae, M. B.A.and I have listed all the literary and other specialist sources in accordance with

legal regulations, Masaryk University internal regulations, and the internal procedural deeds of

Masaryk University and the Faculty of Economics and Administration.”

Brno, Liliia Demianchuk

Acknowledgments

Above all things, I would like to express my gratitude to my supervisor and mentor,

professor Tuck Macrae, for guiding, supporting and encouraging me throughout the study.

Also, I am grateful for the chance to work on the topic directly linked to my work, which helped

me to turn the theoretical research into a practice-oriented case study.

Besides this, I am grateful for the opportunity to join the XYZ company, in particular the

FI-CA team. I am thankful for the support, openness and professionalism of my colleagues.

Last but not the least, I express my gratitude to my family and boyfriend that walked this whole

way by my side and believed in me unconditionally.

Table of Contents

Introduction ................................................................................................................................ 9

Theoretical overview................................................................................................................. 11

Project Management Methodology: emergence, evolution and current phase ..................... 11

Project Management Methodology: definition and comparison of the most recognized

methodologies ....................................................................................................................... 17

PRINCE2 Agile Approach: complex solution suitable for the IT industry .......................... 30

Research Methodology ............................................................................................................. 36

Research Process ................................................................................................................... 36

Research object and research questions ................................................................................ 36

Literature Review .................................................................................................................. 37

Practice-oriented case-study .................................................................................................. 37

Research Hypothesis ............................................................................................................. 38

Data Collection...................................................................................................................... 38

Data Analysis ........................................................................................................................ 40

Industry and Company Overview ............................................................................................. 41

Enterprise Software Industry Overview and Growth ............................................................ 41

Software Industry Trends .................................................................................................. 43

XYZ Company: Overview .................................................................................................... 44

XYZ's Overview and Financials ........................................................................................ 44

Organizational Landscape and Corporate Culture ............................................................ 47

GS FI and FI-CA Team: Overview and Structure ............................................................. 49

Project Management Overview ......................................................................................... 51

Analysis of the XYZ PM Approach ........................................................................................... 59

Health check – PRINCE2 Agile version ............................................................................... 59

Agile Behaviors ................................................................................................................. 60

Agile Environment ............................................................................................................ 61

Agile Process ..................................................................................................................... 62

Agile Techniques ............................................................................................................... 64

Maturity model – XYZ and FI-CA level............................................................................... 65

Recommendations ..................................................................................................................... 67

Improvement of Agile ingredients ........................................................................................ 68

I: Gradual change and adaptation of agile behaviors and mindset .................................... 68

II: Improvement of the FI-CA environment ...................................................................... 69

III: Refinement of the agility of the FI-CA process .......................................................... 71

IV: Integration and granularity of the team's techniques................................................... 72

Tailoring PRINCE2 integrated elements to the agile environment ...................................... 74

Applying PRINCE2 principles in an agile context............................................................ 74

Tailoring the PRINCE2 themes in an agile context .......................................................... 75

The LC Process Model when using PRINCE2 Agile ........................................................ 76

The FI-CA performance evaluation and cost analysis .......................................................... 77

Conclusion ................................................................................................................................ 81

Reference List ........................................................................................................................... 83

Glossary .................................................................................................................................... 88

List of figures and tables ........................................................................................................... 89

Appendices ................................................................................................................................ 90

9

Introduction

Within last decade, business environment and companies have been facing various

complex challenges, including pressure from stakeholders, increased demands from labor

unions, enormously fast-moving technical progress and innovations, overstated expectation

from customers, etc., which requires from all the companies to find new solutions realigning

their thinking to strategic approach and company’s sustainability. In response to this, it takes a

vast effort and persistence for any enterprise, regardless of its size, industry, and culture, to

perform efficiently and manage to deliver a high-quality product. The majority of companies

try to cope with identified concerns by using massive cost-reduction programs, however, this

pillar is a temporary resolution. Consequently, top management and executives have realized

that the full awareness of existing corporate resources and understanding of the way how

corporate activities are managed is the long-term solution to most of the corporate problems.

Therefore, the project management becomes one of the effective techniques under

consideration, which is not limited anymore to few functional areas or just engineering-related

method and has proved its usefulness through every functional unit of the enterprise.

Nowadays, project management has been implemented in different business fields and

also used by various entities from start-ups and small-sized companies to multinational

corporations. In a nutshell, a wide variety of traditional and modern project management

methodologies has been emerged and evolved since the late 1950s when it was initially used

by the aerospace and defense industry (Kerzner, 2005). This paper gives a comprehensive

review of most recognized methodologies, established and implemented in the project

management practice, with the emphasis on the PRINCE2 Methodology (AXELOS, 2017). The

mentioned methodology is the leading process-based project method in Europe, originated in

the UK, and widely-adopted and practiced all around the globe due to its tailoring nature and

versatility.

Generally, a lot of academic works and papers were dedicated to the theoretical

fundamentals of project management methodologies, including PRINCE2, and its

problems, although this paper is a case-study based research, that brings practical value into it.

The object of the research is the project management environment of the software company,

referred to as XYZ, located in Brno, the Czech Republic. Important to notice, that there is a

great space in the project management field for research, especially in the Czech

Republic. According to the findings of IPMA CZ and EY, in the last few years, a reasonably

wider range of organizations including multinational companies are orientating more towards

activation and full utilization of different project management approaches (Hrůzová & Hodžić,

2018).

The subject of the thesis is one of the development teams, namely the FI-CA team,

which belongs to one of the XYZ's key modules – Finance under engineering unit -

Globalization Services. The specific nature of the software industry and a dramatic increase in

the use of technology have created a paradigm shift in terms of how quickly enterprises want

things such as information and products. According to this fact, the tailoring of PRINCE2

methodology is essential to fit in the industry and the specification of their products – software

solutions, which presented and analyzed in the practical part of the work. Thus, the PRINCE2

10

methodology should not be analyzed in isolation and combined with Agile behaviors, concepts,

frameworks, and techniques, which prevails in the company.

The primary purpose of the study is to examine project management processes of one

of the company's teams, analyze their current state and determine possible gaps and flaws which

can be potentially modified or improved by the implementation of the PRINCE2 Agile

methodology. The above-mentioned goal of the paper could be extended to the following

objectives, which have facilitated the achievement of the purpose:

• to conduct the overview of key project management methodologies with further in-

depth analysis of the PRINCE2 project management methodology, highlighting its integrated

elements, namely themes, processes, principles, and environment;

• to explain the Agile philosophy as the delivery method, which is the common practice

for the software industry and its integration with PRINCE2 methodology;

• to analyze project management procedures, policies, processes, and techniques, which

are used by the analyzed company and the FI-CA team;

• to identify key inconsistencies of the existing practices applied in the FI-CA team

comparing to the Agile framework and PRINCE2 methodology;

• to provide recommendations on how to implement the PRINCE2 Agile method for the

FI-CA team, including improvement and deployment of existing agile practices that are

compliant with the organization's transformation strategy; and tailoring the PRINCE2 project

management methodology to the unique environment and conditions of the team;

• to evaluate the performance of the FI-CA team and key benefits attained while using

recommendations.

Overall, this research is an analytical, qualitative, empirical research, based on the case

study of XYZ company, operating in the industry of enterprise software. This approach and

usage of various research methods for data collection and analysis enable the author to fulfill

the objectives and reach the main goal of the thesis.

The study comprises one theoretical and two practical parts. This research starts with a

comprehensive literature overview to form the theoretical foundation for the study. After the

literature review, the research methodology is discussed, and the research process is explained.

Thereafter, the description of the analyzed company with a brief overview of the XYZ’s

development and delivery concept is provided. Upon this, the practical part contains the in-

depth analysis of project handling in the FI-CA team, including process overview for the Legal

Change as the most common type of the project carried out by the FI-CA team. The last part of

the research presents the result of the analysis based on the PRINCE2 Agile Health Check with

the summary of identified inconsistencies and flaws of the existing methodology used by the

analyzed team. Finally, the recommendations for the FI-CA team are presented, addressing the

improvement of Agile ingredients and tailoring PRINCE2 integrated elements to the existing

agile environment of the organization.

11

Theoretical overview

Project Management Methodology: emergence, evolution and current phase

Project Management (hereinafter in the text: PM) methodologies have been developed

and modified significantly by different researchers and practitioners. As a result, it explains the

fact that numerous definitions of PM and PM methodology can be found in academic literature

and the business environment. This section is about the brief overview of the evolution of the

PM concepts from traditional approach into rethinking one, development of the project iron

triangle into comprehensive project success criteria (Głodziński & Marciniak, 2018), with

further elaboration about some most applicable methodologies.

Although one might argue that PM dates back to the construction of the Egyptian

pyramids, most scientists regard the period of the Second World War as the starting point for

consideration of PM as the complex and independent area of study (Morris 2011; Shenhar and

Dvir 2004; Stretton 2007; Verzuh 1999, etc.). As Shenhar and Dvir (2004) notices, while

projects as an organized activity of humankind could be found in every civilization, as a formal

managerial discipline, PM is still relatively young. (Shenhar & Dvir, 2004).

Figure 1 depicts the gradual evolution of management in relation to innovations key

periods (Fig. 1).

Figure 1 The correlation between management evolution and innovations Source: based on (Lepadatu, 2010)

12

Morris claims that there is not much evidence of the language of contemporary PM until

the early 1950s. However, some important findings, which appeared as its precursors, should

be taken into consideration (Morris, 2011). Particularly, Adamiecki introduced his

harmonogram in 1903, Gantt's bar chart followed in 1917. Regarding formal roles, project

coordinator roles appear in the US Army Air Corps in the 1920s, project engineers and project

officers emerged in Exxon and other process engineering companies in the 1930s. (Johnson,

2002).

Nevertheless, according to Eric Verzuh, the turning point that marks the transformation

of the PM into the discipline and separate area of studying is the Manhattan Project, undertaken

in 1942-46 (Verzuh, 1999). In essence, this project is the US program about the construction of

the Atom Bomb. The initiative of such scale required an organized and well-managed human

and material efforts, together with a systematic approach to management methods. Although

this project may not have used network scheduling or Work Breakdown Structures, it certainly

displayed the principles of organization, planning, and direction that typify the modern practice

of managing projects.

Figure 2 is a brief visual guide to the history of modern PM from the moment of its

genesis, which dates back to World War II when various defense projects were initiated and

implemented. It reflects the sequential progression of the evolution of the PM, its concepts, and

practices, composed and structured by decades (Fig. 2). This historical overview is the

consolidation of findings from different academic studies and works conducted by following

scientists, researchers, and organizations: AXELOS (2017), Cleland and King (1968), Fowler

and Highsmith (2001), Kerzner (1992), Morris (2011), Stretton (2011), Wells (2012), Wysocki

(20130), and some others.

Regarding the 1950s, the proper start point would be consideration of Bechtel, one of

the most respected engineering, construction, and PM companies in the world, that first used

the term Project Manager. However, it is essential to highlight that this application did not entail

a PM managing in a matrix organization as we have it today in most of the cases. As Stephen

D. Bechtel Jr. points out in his book “…rather it was the assignment of a great deal of

responsibility to an individual operating in a remote, strange and often hostile environment,

usually with a self-contained autonomous team.” (Bechtel, Jr., 1989). So, it should be viewed

as the concept, and initiation of the practice, that Project Manager is the individual, that is

having total responsibility throughout the entire project, from inception to completion.

Another business entity that has made a great contribution to PM is Civil & Civic

(C&C), recognized as the leader in PM in the Australian building industry. They are the

pioneers in the practice of managing the design process, value analysis, and designing

efficiency/effectiveness. Starting from the mid-50s, C&C appointed its own "project engineers"

to manage the design phases of all its development projects (Stretton, 2007). After a few years

of successful management practices done internally, the company started to supply "PM

services" to the market.

13

Figure 2 The evolution of modern PM from the 1950s to today *The list of acronyms with its explanations is available in the Glossary

Concerning the management techniques and tools in the 1950s, Morris (2011) notices,

that it appears as primary technical development in PM, initially linked to planning and control

facets of project time management (Morris, 2011). Three critical management techniques,

Critical Path Method (CPM), Project Evaluation Review Technique (PERT) and Precedence

Diagramming Method (PDM), were developed independently by different groups of

researchers and practitioners in the US. Regarding CPM, it was developed to address du Pont’s

“construction scheduling problem”. As Kelley & Walkers states “the CPM development was

capped with the results of applying it to turnarounds at du Pont's Louisville plant....by cutting

average turnaround downtime by some 25% through CPM” (Kelley & Walker, 1989).

1950s

•First introduction of the term Project Manager (by Bechtel)

•Establishment of "PM services" by Civil & Civic (C&C)

•The development of CPC/PERT/PDM as basic techniques for project planning and control

1960s

•Conception of project cost management

•Extensions to CPC/PERT/PDM

•Formation of professional PM Bodies (IPMA and PMA)

1970s

•Proliferation of PM application areas

•Extensive researches and writings on PM "Applications" by academia and introduction of "Professional Definitions" by practitioners

•Key findings about Projects and the System Approach by Cleland & King, and Kerzner

•PM in Matrix Organizations and evolution of conflict management

1980s

• Introduction of standards: PMI's ESA Report and PMBOK

•Movement towards: "Front End" of projects; "Product" (versus Project) LCC; External Factors

•PM through the paradigm of change

• Influence of Computer Technologies

•Certification/Registration Programs for PM by professional bodies and its world-wide recognition

1990s

•Development and release of PRINCE2 Methodology by CCTA in 1996 , a UK government support agency

•Rapid increase of the relevancy of PM and its methodologies in business environment

•Creation and introducing of CCPM as a contrast to PERT/CPM

2000s up untill now

•Release of "the Agile Manifesto" by APM (Assotiation for PM) in 2001 and further evolution of APM (Agile PM) as contrast to traditional "waterfall" delivery approache

•Significant revision of PRINCE2 Methodology in 2009 and further revamping in 2017

• Increasing development of toolkits and software solutions (Stakeholder Circle, Pertmaster, SalesForce and others)

•comprehend and in-depth research works and accumulation of categorizations

14

Another well-known management method, named PDM, was developed by the group

of researchers at Stanford University in conjunction with the US Bureau of Yards and Docks in

1958, trying to tackle the same type of “time-cost tradeoff” issue. In essence, the proposed time-

cost procedure features the use of “Precedence” matrices and utilizes the concept of "Lag"

values (Stretton, 2007). Meanwhile, the US Navy was developing its project and program

management practices. Particularly, another network technique, called PERT, was created in

1957 by the US Navy while they were working on Polaris (Morris, 2011). In this network, the

approach was different, as it emphasizes rather on project events or milestones than the project

activities. In other words, some certain key progress points should be used for overall

management control.

The further extension of PM transpired in the next decade. 1960-s are marked with the

introduction of project cost management and its associated project resource scheduling. This

concept was added to project time management as a distinctive PM technique, and integration

of the two was proceeding. As professor R. Archibald notices in one of his works “In the mid-

1960s, there was such a negative reaction by defense contractors to the "onerous" requirements

of PERT/Cost that the whole concept of network planning and critical path scheduling was

almost killed off … The development of the Cost/Scheduling Control System Criteria

(C/SCSC) approach by the government followed this setback, and over the years this has been

made to stick and has produced good results.” (Archibald, 1987). Besides this, some significant

extensions were done to three key network techniques (PERT/CPM/PDM). One of those

upgrades was resource leveling; besides this, the integration of cost control into network

scheduling happened back there.

At the same time, the two major professional PM bodies were established in the 1960s.

The first one - International PM Association (IPMA - formerly INTERNET), was formed in

1965 in Europe, and another one - North America's PM Institute (PMI) was created in 1969.

The next period, the 1970s, is considered by researchers as the time of unprecedented

expansion in PM application areas, as well as in the development of PM as an individual

discipline. At the first place, the major change happened with the borders of the PM application.

Particularly, Harold Kerzner notices “…the concept behind PM has spread to virtually all

industries, including defense, construction, pharmaceuticals, chemicals, banking, accounting,

advertising, law, state and government agencies, and the United Nations.” (Kerzner, 1992).

Simultaneously, this decade is characterized by intensive writings on PM and its

applications. At that time, the experience started to replace ideas, and captured results started

to reinforce concepts. Also, some researchers and professional bodies, including PMI, focused

on various “professional definitions”, as the result the introduction and refinement of a much

wider range of tools and techniques took place, including Work Breakdown Structure (WBS),

Organization Breakdown Structure (OBS), responsibility assignment matrices, and "earned

value" methods.

In the 1960-70s, two most influential authors of that time, Harold Kerzner and the

cooperation of Cleland & King, have made a valuable contribution to the development of PM.

They specifically approached their analyses of project engineering from a systems perspective.

Particularly, Cleland & King has stated in one of their main works, that “… modern analytical

approach to the strategic planning aspects of management is most often termed systems

15

analysis. In the execution process, similar ideas are applied under the label PM (alternatively

systems management, program management, or product management, depending on the

environment)" (Cleland & King, 1968). Another substantial aspect that was addressed by these

two authors is project planning and control. At the same time, they referred to the PM through

the prism of organizational concepts and structures, including matrix organizational structures,

which were considered by many people as a synonymous with PM.

The following period, the 1980s, after the intense proliferation of individual

applications of PM and the introduction of various tools and techniques, is characterized by the

integration of it into some generic practices and principles. Thus, one of the most noted PM

concepts, known as the Project Triangle or Iron Triangle, was created by Dr. Martin Barnes in

the mid-1980s. This approach demonstrates the interrelations between quality, cost and time of

a project and possible trade-off decisions when not all the objectives are regarded as

equal/balanced. As Lock points out, many more extensions of the triangle have since been

developed by different researchers, including Lock’s amalgamated version with people shown

at its center (Lock, 2013).

Besides this, PMI played an important role with the release of two comprehensive

documents, namely the Ethics, Standards and Accreditation project (ESA) in 1983 and its PM

Body of Knowledge (PMBOK) in 1986. So, the first attempt to professionalize PM

systematically has resulted in ESA, which considered as the early version of the PMBOK. The

main finding is the introduction of six PM “functions,” which are project cost, time, quality,

scope, human resources, and communication. Thus, the traditional PM, a trade-off between

time, cost and quality, was extended by three new additions. The next PMI’s contribution is

published PMBOK, which is a substantially more developed version of the previous ESA

Report. As professor Stretton says, this standard tried “to represent PM as a structured discipline

and approach, rather than as a collection of tools and techniques” (Stretton, 2007).

Also, in the course of the 1980s, growing attention was focused on needs determination,

feasibility studies, value analysis, risk management, and project startup generally, rather than

its execution and implementation. As a result, it pushed the attention to the “product” life cycle

costing (LCC), rather than just project LCC. Together with this, greater attention was directed

toward a constantly increasing number of stakeholders and any other “interested parties”. So,

project managers became more concerned with finding a solution that would be a reasonable

compromise between all the involved parties (Lock, 2013). Excepting this, PM methodology

started to be viewed as the most appropriate vehicle for initiating and achieving change, as well

as responding to change.

A significant step forward was the development of computer technologies, which

resulted in new and powerful programs used for coordination and control of projects. Another

great initiative was the introduction of the first certification program for project managers by

PMI (Project Management Institute, 2019). As a result, the PMI Board approved a developed

certification program in 1983. Consequently, other professional bodies had started planning for

certification/registration of project managers too.

During the 1990s, further evolution of PM took place. The most important contribution,

which is the subject of the thesis, is the introduction of the Projects in Controlled Environments,

mainly known as PRINCE2 Methodology. This structured approach was developed and

16

championed by the UK government. Initially, it was intended just for the management of IT/IS

projects, although the methodology was significantly modified and relaunched in 1996 for use

in a wider range of project situations (AXELOS, 2017).

Nowadays, PRINCE2 is being used in most government projects as well as some private

organizations with internal and external clients at different levels of contractual engagement.

Although AXELOS does not publish any official statement with the total number of certified

practitioners due to the data security issues (reference to the Freedom of Information Act 2000),

professor Wells estimates in his paper that there were more than 300 thousand PRINCE2-

certified project managers worldwide by the end of 2012. Thus, any relevant study of PM

methodology cannot be conducted without consideration of PRINCE2 (Wells, 2012).

Regarding PRINCE2 methodology, a substantially significant revision was made in 2009. The

main result is simplified PRINCE2 methodology and the introduction of seven basic principles,

which will be addressed in the following sections.

Another finding of that time derives from the research conducted by Standish Group.

The results showed that PM methodologies had been firmly placed as one of the top ten

contributing factors toward project failure (Standish Group, 2010). So, the further constant

search of new methods, principles, and concepts of PM has been one of the key characteristics

starting from the late 1990s till nowadays. One of such great innovations was CCPM (Critical

Chain PM), which is opposite to traditional methods PERT and CPM, as it focuses mainly on

the resources needed to execute project tasks rather than rigid planning and task order.

Another significant development was the establishment and introduction of the agile

project delivery method, which formally came on the scene in 2001 with its published “Agile

Manifesto” (Fowler & Highsmith, 2001). It represented a marked formal departure from the

systems development life cycle (SDLC), or the Waterfall Model, which was applied in

traditional PM. Flora and Chande (2014) state that the agile development methodology is a

conceptual framework for undertaking any software engineering project (Flora & Chande,

2014). In essence, the agile approach can provide a shorter development cycle, higher customer

satisfaction, and quicker adaptation to rapidly changing business requirements. Thus, the agile

method is considered more like a concept, but not a systematic PM methodology, that could

be tailored to any industry’s specifications. However, Robert K. Wysocki claims that there are

four quadrants of PM methodologies, namely traditional PM (TPM), agile PM (APM), extreme

PM (xPM), and emertxe PM (MPx) (Wysocki, 2013). Thus, constant innovations and changes

in PM and the external environment provide enough space for a whole new group of PM

concepts, methodologies, standards and frameworks. So, any ongoing disputes and

justifications of different approaches are vital components of the further development of PM.

To conclude, within the last half of the 20th century and the beginning of 21st, PM as

the individual discipline, and its landscape has changed significantly and continues to improve

constantly. Mainly, the key fundamentals and concepts are established and accepted by most

practitioners and academia since then. However, a lot of open questions and new challenges are

left to be resolved. So, the next chapter will represent the overview of the main approaches to

the definition of PM methodology. Upon this, the paper will focus on the review of a few best-

known PM methodologies, which are successfully implemented by various companies and

recognized by multiple international PM associations and bodies.

17

Project Management Methodology: definition and comparison of the most recognized

methodologies

PM is a relatively new discipline, although it could be characterized by considerable

diversity and richness of its expansion within the last 60 years. Bredillet (2013) notices in his

work that at least one-fifth of global economic activity has taken place as projects for the last

decade (Bredillet, 2013). Thus, the significance of the PM and the development of various

traditional and modern PM methodologies cannot be overestimated. The theoretical overview

of the academic works and literature proves that numerous definitions of PM methodologies

were presented by different professional bodies and academia (Charvat, 2003; Chin &

Spowage, 2010; Cockburn, 2000; Gane, 2001; Introna and Whitley, 1997; Kerzner, 2001; PM

Institute, 2008).

In the modern PM community, findings of the PM Institute, which is the most prominent

not-for-profit membership association, PM certification, and standards organization, are highly

appreciated and considered as golden standards. This professional body defines the PM

methodology as “a set of methods, techniques, procedures, rules, templates, and best practices

used on a project” (PMI, 2017). Important to notice that other definitions do not differ

significantly. As an example, Charvat (2003) outlines PM methodology as “set of guidelines

and principles that can be tailored and applied to specific situation, where guidelines could be

as simple as task list, or it could be specific approach to project with defined tools and

techniques” (Charvat, 2003). Similar to the previous approaches is the explanation of the term

presented by Chin and Spowage (2010). They define PM methodology as “a specific approach

to managing every aspect of the project in the form of general and specific procedures, rules,

regulations, and standards”. Besides this, these authors elaborated on the critical components

of the PM methodology, namely 1) PM processes, 2) selection of tools and techniques, 3)

consolidated and aggregated set of appropriate best practices and values, and 4) reference list

of terminology and language of PM (Chin & Spowage, 2010).

In contrast, another author explains PM methodology from the knowledge perspective

in his work. Particularly, Gane (2001) suggests that it is “a knowledge set about tasks,

techniques, deliveries, roles, and tools used during the project paired with knowledge about

adjusting all of that to specific project” (Gane, 2001). At the same time, there are few more

generic approaches to the term that specifies and focuses on its purpose. For instance, Introna

and Whitley (1997) define PM methodology as “a structured set of techniques and tools used

for solving a specific problem” (Introna & Whitley, 1997), while Cockburn (2000) defines it

“as any principle PM team relies on to successfully deliver project result” (Cockburn, 2000).

PM methodology could also be specified in terms of its goals and scope. For instance,

Kerzner defines this through “the increase of the probability for successful project delivery”

(Kerzner, 2001). This notation is extended and presented in more detail by another collaboration

of researchers. Namely, Ghods and Nelson (1998) points out that the final goals of the

methodology are “reaching high quality of the project results, simplification, control and

process improvement” (Nelson & Ghods, 1998).

To conclude, there is no universal agreement regarding what constitutes a PM

methodology, although most of the given definitions, descriptions, and discussion within the

literature agree on its central concept. Thus, the PM methodology could be articulated as a set

18

of methods, techniques, procedures, best practices, etc., used on the project to help the project

manager and the project team manage the project in the most effective manner and bring it to

the desired completion. But, a methodology by itself is not a sufficient prerequisite for project

success. Furthermore, inappropriate PM methodology can complicate the process of managing

a project or even have a negative impact on it (Nelson & Ghods, 1998). It means that PM

methodology must provide a set of practices, tools, and techniques which can be customized or

adapted as to project characteristics such as size, complexity, scope, and specific environment.

Nowadays, mainly process methodologies prevail in the PM environment, which

include certain subprocesses or phases in PM (Jovanovic, 2017). Considering the fact of vast

number of evolving PM methodologies with more or less successful applications, this paper

focuses on four best-known PM methodologies with the highest level of usage and cross-

industrial implementation. All of them are mainly suggested by national or international PM

associations as well as by individual organizations and institutional bodies, namely PM Institute

(PMI), Association of PM (APM), International PM Association (IPMA) and AXELOS

(created in 2013 by the Cabinet Office on behalf of Her Majesty’s Government (HMG) in the

United Kingdom). Hence, the list of PM methodologies chosen for further analysis comprises:

1) PMI Methodology;

2) Projects in Controlled Environment Version 2 (PRINCE2) Methodology;

3) APM Methodology;

4) IPMA Methodology.

All the listed methodologies are global best PM methodologies and applied by

professionals in various fields and industries. Based on the literature overview and foundational

standards of each methodology, this paper summarizes the results of findings in appendix A.

The primary purpose was to compare chosen methods by identifying its distinguishing

characteristics through the analysis of foundational standards and its structures, concepts,

definitions and defined roles and responsibilities.

The first methodology, PMI methodology, is developed and introduced by PM Institute,

which is nowadays the world’s leading PM organization with over 500 thousand Global

Members and around 300 Local Chapters Internationally (PMI, 2019). This methodology is

presented in the PM Body of Knowledge – PMBoK handbook. Although PMI was established

in 1969, the first standard guidebook was not introduced until 1987, with few further updated

versions and latest enhancement released in 2017, which is called the PMBoK 6

(Sixth Edition). This Body of Knowledge is considered to be a “best practice guide” and is

widely acknowledged as the standard of PM knowledge (Chin, Yap, & Spowage, 2010). In a

nutshell, the PMBoK approach applies a framework which contains several major components,

namely five process group with 49 processes or sub-processes, ten knowledge areas, and

various set of input, output, tools, and techniques. The five significant groups of PM processes

are initiating, planning, execution, monitoring & controlling, and closing (PMI, 2017).

The initiation group of processes is about to facilitate the set-up and authorization of the

project. Mainly, it defines the general direction, high-level goals as well as major deliverables,

which are ultimately used to determine the successful closure of the project. The next is the

planning group processes, which aim to devise and maintain a workable scheme to accomplish

19

the project goals within the project's constraints in terms of scope, schedule, cost, and quality

as the key parameters. Within the execution group of processes, activities, resources, including

human resources, are managed to carry out the project plans efficiently. Important to notice,

that there is no hierarchy of plans in the PMBoK because the method does not recognize that

the needs of those in governance roles or team managers may be different to those of the project

manager. In other words, it declares that all the requirements are unified and aligned, although

it might work differently in a real commercial environment. During the execution process, the

project progress against established project plans is monitored with the application of the PM

monitoring and control process group. The project manager usually conducts monitoring

through such techniques as interactions, communication, and other engagements with

stakeholders to ensure the project is still feasible. The controlling processes confirm that the

project objectives are successfully met with possible changes to the project plans in case if any

corrective measures or actions are needed. Finally, once the project activities are fully

accomplished, and the project received formal acceptance, the project is brought to an orderly

conclusion using the closing group processes. Relevant that central processes groups, excluding

initiation and closure, are iterative throughout each phase of the project (PMI, 2017).

The second component of the framework is the list of 10 knowledge areas which can be

mapped to the process groups and provides the expertise to conduct the specific processes.

Consequently, PMBoK is usually viewed as a knowledge-based methodology that proposes

managing a project along with defined knowledge areas, namely project integration

management, project scope management, time management, cost management, quality

management, human resources management, communication management, negotiation in

procurement management, risk management, and project stakeholder management. Each of the

mentioned areas is classified either as core or facilitative, aimed to explain the key

competencies that project managers must develop to be effective and deliver the desired result

in terms of cost, time, scope, and quality, which are viewed as core aspects of the project.

PMBoK focuses on knowledge areas of PM, and thereby pays a little attention to techniques

and approaches, and how or when to use them.

Regarding terminology and defined roles and responsibilities, the project being the

central element viewed as “a temporary endeavor undertaken to create a product, service or

result singular” (PMI, 2017). The nature of a project is distinctive and shows the focus on the

successful delivery and quality. A more profound difference between PMBoK and other

methodologies relates to the philosophies implicit in the methods. In general, the PMI

methodology identifies three leading roles: the project manager, the sponsor, and the PMO

(PMI, 2017). Important to notice that the PMBoK indicates that “Project Management” is the

work of a project manager, thus project manager is the one who is fully accountable for the

success of a project. Nevertheless, some users of PMI Body of Knowledge find it unsatisfactory

in the way how this methodology limits decision making merely to project managers, making

it difficult for handing over aspects of the management to other involved parties and senior

managers (Rankins, 2013).

To conclude, PMBoK is a comprehensive and structured knowledge-based PM method

covering proven practices which can be applied for a wide variety of project. Despite all

strengths and advantages, it has some certain drawbacks, many of which mainly relate to its

application in practice. For instance, PMBoK does not include any template or checklist needed

20

to construct a project plan, although it is very prescriptive in its nature. As a result, it requires

a lot of documentation and reports as the primary mean of communication within its framework.

Therefore, the administrative burden might be considered as too overwhelming, especially for

smaller and less complex projects, and may meet some resistance from the side of project team

members and parties involved (Raziq, 2006). Besides this, nowadays, many markets,

customers, and stakeholders are seeking more in terms of quality, value for money, and rapid

delivery at the same time. To respond effectively to these requests, PM methodologies and its

approaches should be more streamlined, which means that processes could be easily adapted to

better fit the complexity and context of the project and its environment. Yet the nature of

PMBoK is mostly silent about this matter, as it does not adequately address the creative and

changeable project environment.

Another widely recognized and used PM methodology is PRINCE2. This structured

method for effective PM derives from an earlier method called PROMPTII and from PRINCE

PM method, which was initially developed by the Central Computer and Telecommunications

Agency (CCTA) in 1989 as a UK Government standard for information systems (IT) PM.

However, it started regularly being used outside the purely IT environment, so a newer version,

called PRINCE2, has released in 1996 as a generic and business-focused PM method. The

significance and usage of the methodology have increased noticeably over time, and it has

resulted in being a de facto PM standard used extensively across all the sectors, in the UK and

globally (AXELOS, 2019).

PRINCE2 is a generic process-based method for managing projects in an existing

project environment. This is an integrated framework of principles, processes, and themes that

addresses the planning, delegation, monitoring, and control of six key aspects of project

performance, namely cost, time, quality, scope, benefits, and risk. The concept of the

methodology could be interpreted as the creation of an easily tailored and scalable method for

the management of all types of projects. As it is mentioned in the handbook, “PRINCE2 is not

a “one size fits all” solution”, rather it is a flexible framework that is ready to be customized to

any sort or size of the project (AXELOS, 2017).

The first integrated element of the methodology is PRINCE2 principles, which are

viewed as the guiding requirements and good practices used to determine whether the project

is genuinely being managed applying PRINCE2. This means that a project must focus on

continued business justification, together with a clearly defined organization structure for the

PM team and its product-centered approach. Moreover, it also highlights the importance of

breaking down a project into manageable and controllable stages with clearly defined tolerances

at each level, so then such processes as directing, managing, and delivering are done effectively

and by proper level of management. This helps to assure the efficient use of senior management

time and ensure that decisions are made at the right level in the organization. Also, PRINCE2

requires project teams to seek out lessons and learn from experience throughout the life of the

project. Unless all of the abovementioned principles are applied, it cannot be considered as a

PRINCE2 project. To address this firm regulation, there is the last principle which states that

the method is tailored to suit the project environment, size, complexity, importance, team

capability, and risk and can be used for any project type, geography, or culture. It means that

the PM team, particularly the Project Board and Project Manager, should make proactive

choices and decisions on how PRINCE2 will be applied.

21

PRINCE2 does not address every particular skill or technique required to manage a

project, although it provides some recommended techniques, tools, that might be a good fit for

a specific project. This methodology concentrates more on processes, which are a structured set

of activities designed to accomplish a particular objective. Thus, the nature of this methodology

could be considered rather prescriptive and process-driven than descriptive. As it is conveyed

in the handbook: “PRINCE2 has been designed to be generic so that it can be applied to any

project regardless of project scale, type, organization, geography or culture….focusing on

describing what needs to be done, rather than prescribing how everything is done” (AXELOS,

2017).

The second integrated component of the methodology is its processes and developed

process model. These describe a stepwise progression through the project lifecycle, from

getting started to project closure. Mainly, the process model covers activities from setting the

project off on the right track, through controlling and managing its progress to completion.

Important to highlight that the process model gives the flexibility to establish several stages that

are customized to form a distinct unit for management purposes, at least must be two sequential

stages. Each management stage comprises products, activities, which are recommended actions

designed to achieve a particular result, required resources, and an organization structure with

related responsibilities. The completion of each stage is defined by the satisfactory delivery of

the agreed products.

Following the latest version of its foundational standard, there are seven processes,

namely starting up a project, directing a project, initiating a project, controlling a stage,

managing product delivery, managing stage boundaries, and closing a project (AXELOS,

2017). These stages are very much like the phases of the PMBoK process model, which consists

of five process groups: initiating, planning, executing, monitoring and controlling, and closing

group (PMI, 2017). The PMBoK process groups are generally applied to every phase of a

project. In contrast, using the PRINCE2 processes is a little more complicated method. By

definition, the PRINCE2 process of Starting Up a Project is a set of pre-project activities that

check that the proposed project is a viable and worthwhile project that must be continuously

justified throughout the project. Upon this, the first stage is the Initiation stage, in which the

Initiating a Project process ensures high-level delivery planning, and the outcome of Managing

a Stage Boundary process is the stage plan for the first delivery stage. The processes of

Controlling a Stage and Managing Product Delivery apply to every delivery stage of a project.

The former process stipulates the Project Manager’s day-to-day activities, and the latter defines

the interface between the Project Manager and each Team manager. Besides this, at the end of

every delivery stage except the final stage, the Managing a Stage Boundary process is in place.

Firstly, it examines that the current stage will finish as planned. Secondly, this process ensures

proper planning of the next delivery stage. Described sets of processes are then repeated in each

delivery stage, depending on the complexity of the project and the number of identified products

to be delivered by the end of the project. The Closing a Project process is applied in the final

delivery stage of a project. The most distinctive element is the Directing a Project process,

which has no equivalent in the PMBoK. This process defines the work of the Project Board

over the life of the project, and its key decision points at the end of every stage.

Based on the results of a global survey of project managers conducted by a group of

scientists, the value of the PRINCE2 methodology was intensely highlighted in terms of the

22

robustness of its processes comparing to other methods. Thus, one of the most outstanding

findings was that none of the PRINCE2 project managers expressed serious concerns about the

scope of their projects. In contrast, almost all of the “other” group (applying any other methods

different from PRINCE2) said that uncertainty about their projects’ scope resulted in future

problems, that affected key project performance aspects (Sargeant, Hatcher, Trigunarsyah,

Coffey, & Kraatz, 2010). The research proves that the pre-project process of Starting Up a

Project, and the Initiation Stage as a whole, both help to eradicate uncertainty and gain

consensus about project scope and to dismiss poorly conceived ideas before the project moves

on to its delivery stages. This well-constructed mechanism of “self-insurance” is not covered

by PMI methodology.

The next component of the methodology is PRINCE2 themes, which describe aspects

of PM that must be addressed continually and in parallel throughout the project. The seven

themes explain the specific treatment required by PRINCE2 for various PM disciplines and

why they are necessary (AXELOS, 2017). Projects are kept on track by continually addressing

the following themes: business case, organization, quality, plans, risks, changes and progress.

Thus, within the PRINCE2 framework, these aspects underpin the effective utilization of

project processes and provide a means to keep track and review the different project processes.

However, some researchers criticize that these components are not described sufficiently and

in such a comprehensive way as it is done with PMBoK knowledge areas (Chin, Yap, &

Spowage, 2010). For instance, the PMBoK knowledge area on integration management covers

the integration of all aspects of PM. In PRINCE2, this aspect of integration is covered partially

by the workflow though the Start-up, Initiation and Planning processes, and by the change and

progress themes. Also, PMI methodology specifies the knowledge area on procurement, which

has no equivalent in PRINCE2, albeit the Work Package product and the processes associated

notably overlap with the respective knowledge area.

On the contrary, PRINCE2 suggests significant guidance on benefits, in its principles,

themes, processes, and roles, whereas the PMBoK is silent on benefits. This critical

differentiator between the methods reflects that the latter methodology view that the Business

Case is only significant outside the project. However, the business case appears to be a

fundamental element for another method, as PRINCE2 identifies the project as “a management

environment created for the purpose of delivering one or more business products according to

a specified business case” (AXELOS, 2017).

Another peculiarity of the methodology that should be considered is one of the

PRINCE2 themes - plans and its hierarchy. PRINCE2 recommends three levels of the plan to

reflect the needs of the different management levels involved in the project, stage, and team,

presented by such management products as Project Plan, Stage Plans, and Team Plans,

respectively. Thus, the Project Plan is at a high level of detail and meets the needs of those

governing the project, namely the Project Board. A Stage Plan is produced before the start of

that stage and with the proper level of granularity required for effective control of that stage by

the project manager. A Stage Plan may contain one or more Team Plans, which are used for

effective control of a team’s work by a team manager. Concerning previously analyzed

methodology, there is no hierarchy of plans in the PMBoK, because the method does not

recognize that the needs of those in governance roles or team managers may vary with those of

the project manager (Rankins, 2013).

23

The last aspect, which should be addressed in the analysis, is the flexible nature of the

PRINCE2 methodology. It recalls the fourth integrated element, which stands for the tailoring

PRINCE2 to the Project Environment. According to the handbook, this addresses the need to

tailor PRINCE2 to the specific context of the project, which means that it is a flexible

framework that readily being tailored to any type or size of the project (AXELOS, 2017). The

methodology repeatedly conveys the message that it focuses rather on PM processes, rather

than specific tools and techniques. It means, that if a project requires to use a tool or technique

not covered, or insufficiently addressed in PRINCE2, a project manager should seek out more

detailed information from sources such as various PM bodies of knowledge, including the

PMBoK, APMBoK, IPMA Competence Baseline (ICB), or any other.

To summarize, PRINCE2 is a structured process-based methodology that provides

organizations with a standard approach to PM. Importantly the nature of the method enables its

tailoring to suit the requirements of a specific organization. Thus, the probability of delivering

satisfactory results is optimized. PRINCE2 also enables a high level of engagement from

management and stakeholders. Notably, this involvement can be addressed at the optimal time

through the strategic positioning of tolerances and management stages, which serve as “gateway

points”. Also, the appropriate use of PRINCE2 processes, especially its pre-project stage,

secures the project against scope creep. Upon this, the methodology provides a controlled start,

progression, and end to projects, including regular reviews of the project’s progress and

managerial control of any deviations from a plan. It also distinguishes management activities

from technical activities, so the methodology does not cover all the specialist products and

related information. However, each type of management product required by PRINCE2 is

supported with templates that are comprehensive, standardized, and easy to complete. Despite

all the advantages of implementation of this methodology, it involves a lot of documentation,

which adds little value to the overall performance of the project. On the other hand, the holistic

approach to the documentation certainly benefits traceability and accountability throughout the

project cycle. Thus, with these perceived weaknesses and the heavy administrative workload

involved, PRINCE2 is criticized for its inability to suit small projects (Sargeant, Hatcher,

Trigunarsyah, Coffey, & Kraatz, 2010).

The next methodology to be analyzed in the paper is APM methodology. It is developed

by another influential UK based professional PM body, called Association of PM (APM). APM

is the chartered body for the project profession, with over 30 thousand individual members and

more than 500 organizations, making APM the leading professional body for PM in Europe

(APM, 2019).

APM methodology is presented in the handbook under the title of APM Body of

Knowledge (APMBoK), initially published in 1992. APM then updated and refined its

foundational standard resulting in six following editions, with the latest APMBoK 7th Edition

released in 2019. As Mike Clayton, eminent PM practitioner, says in his overview of the last

edition of the Body of Knowledge “while the PMBoK Guide is a textbook for learners, the

APMBoK is an annotated reading list” (Clayton, 2019). In other words, it is not a “how-to”

guide, rather it is perceived as a foundational knowledge resource. Thus, written by the

profession, for the profession, APMBoK is a foundational resource about concepts, functions

and activities that set up professional PM.

24

With the updated version, APM focused to reflect on developments in the PM trends

and practices, new terminology, research and publications. As Dr. Murray-Webster, editor of

APMBoK 7th edition, points out in one of her interviews “The 7th edition is very different from

all previous ones…This reflects the reality of project-based working in 2019” (Yanjuan, 2019).

Particularly, one of the key changes in the revamped handbook was the need to recognize and

consolidate the variety of delivery options available across all project types, starting with more

traditional, linear and deliberate life cycles up to more iterative and adaptive ones. The overall

layout of the 7th edition of APMBoK was fundamentally restructured and instead of having 7

general sections consisting of 52 topics, it evolved into 4 chapters with 80 topics overall. Thus,

the handbook consists of the next generic components: “Setting up for Success”, "Preparing for

Change", “People and behaviors” and “Planning and Managing Deployment”. Important to

highlight, that new chapter called "Preparing for change" is a significant addition. This part

serves as a bridge between the organizational perspective, addressed in the first chapter, and

the delivery phase, presented in the third chapter (Editorial Team: APM, 2019). No less

importantly, it highlights the need to start up projects properly, and have a well-defined line of

sight of the intended benefits. Thus, the approach of the APM methodology was modified in

order to provide information to a wider group of people involved – from the strategic tier

presented by senior management who needs to decide how to use projects, programmes and

portfolios to deliver strategy – to all people working in PM teams.

Basically, the first chapter “Setting up for Success” places projects in context and is

written predominantly for those leaders in organizations who have decisions to make about the

role of projects, programmes and portfolios in implementing a strategy. Thus, it provides the

strategic tier of the project regarding such topics as the role of project-based working,

governance of the project and delivery options and choices. In regard to governance, section B

"Governance" of APMBoK states that good governance can be demonstrated through

“establishing clearly defined roles, responsibilities and performance criteria for governance”,

that is similar to one of the key principles of PRINCE2 Methodology. The primary roles and

responsibilities for a project are Project Steering Group, Project Sponsor, Project Manager,

Team Members, Users (Customers) and Project Office (APM, 2019). However, it is noted in

the handbook that these may vary across different organizations and at times even across

different projects within the same organization.

The next chapter “Preparing for change” addresses a collection of topics that can be

seen as the points of interface with the organization commissioning the project. This part is

written primarily for those leaders in organizations responsible for creating and leading teams

to shape, fund and assure projects, programmes and portfolios and to ensure that project outputs

are transitioned to the business and adopted to realize the intended benefits. Thus, the chapter

encompasses three main sections, which are "Shaping and funding" on the level of project,

programme and portfolio with the concept of best-fit contracting strategy; "Assurance, learning

and maturity" providing ground for assurance performance, knowledge management together

with models to measure maturity in terms of culture, process, capabilities; "Transition into use"

dedicated to the closing stage of a project, programme or portfolio and following adoption and

benefits realization. Thus, this is the consolidation of all the topics within certain sections which

are important when shaping and funding investments in a change in the early life cycle, and

when transitioning the outputs created into business operations so that benefits can be realized

25

(Editorial Team: APM, 2019). One of the advantages of the APM framework is the emphasis

on the benefits, as it is clearly addressed and communicated through the project life cycle.

Following chapter “People and behaviors” is written primarily for those leaders in

organizations who need to build and lead teams to shape and deliver projects, programmes and

portfolios. Thus, the main target audience of this part is those individuals that are assigned to

be project and team managers. It explains the process of working together through the definition

of teams and their involvement, an overview of possible stakeholders, highlighting also the

cultural and social aspects of the project environment and its diversity. Next sections could be

viewed as the comprehensive guidebook about required people skills, including leading,

teamworking, communicating, negotiating, conflict resolving and stress tackling practices, and

APM Code of Conduct, which identifies the traits of professional. In comparison to other

methodologies, APM assesses this human aspect of effective PM as one of the key areas,

whereas PRINCE2 is almost silent regarding this with no communication and behavioral

practices and techniques. Concerning PMBoK, human and communication aspect is broadly

addressed in its knowledge areas, namely human resources management, communication

management and project stakeholders’ management.

The last chapter “Planning and Managing Deployment” is put down mainly for project

managers and their teams. This chapter is focused on projects – which may be managed in the

form of standalone initiatives, or as part of wider programmes and portfolios. It represents three

interconnected sections concerning defining products, integrated planning and reporting, and

managing the delivery (APM, 2019).

The APMBoK, as APM foundational standard, covers a wider range of topics, that

serves different readers well. The newly expanded structure of the Book of Knowledge makes

it even more relevant not just for decision-makers and senior leaders, established professionals

but also for those starting their careers. Thus, the front end is now very specifically aimed at an

executive level of understanding; the following parts of the handbook are about the day-to-day

process of grinding out a project and are useful to newbie project managers. As Dale Shermon,

managing consultant in QinetiQ advisory services, notices “it’s valuable because it spans right

from the top of the organization all the way down to the bottom” (QinetiQ, 2019).

Hence, the APM handbook is a comprehensive manual that covers a large number of

areas and topics important in an effective PM implementation, although it is less method-

oriented approach than PMI PMBoK. From one side, it is beneficial, as it means that

methodology is more flexible and can be adapted regardless of industry or sector. On the other

hand, the emphasis is on breadth rather than on depth. It means that APM does not provide a

specific method with ready to use templates, unlike PRINCE2 methodology.

The last methodology is the IPMA methodology, which is introduced and developed by

the International Association of PM, the oldest PM institution in the world. This institutional

body started out as a forum for the exchange of experiences among international project

managers, organized in Vienna in 1965 (Algeo, 2008). Over five decades the IPMA evolved

into a federation of the leading PM associations with over 70 member nations (IPMA, 2019).

Basically, each member, Member Associations (MAs), serves the specific needs of PM

professionals in their own country while IPMA addresses those needs at the international level.

In fact, the APM is a member of the IPMA in the United Kingdom.

26

IPMA initiated the establishment of its foundational standard, called IPMA Competence

Baseline (ICB), in 1993 with further amplification of the content via continuous improvement

process. Primarily, the fundamental elements of IPMA ICB were based on the third version of

APBoM, released in 1996. As a result, the first version of compiled ICB was only published in

1998. The main purpose of ICB was harmonization of previously existed European bodies of

knowledge. Alongside this, it also intended to provide an official statement of competence

expected from individuals involved in PM through IPMA certification.

The latest edition, namely the IPMA “Individual Competence Baseline” Version 4.0,

was released in 2015. It is developed upon the prior editions and gives the new insights together

with a redefinition of the competence elements (CEs) integrated into the “Eye of Competence”

(IPMA, 2015). This visualization tool represents all elements of project, programme and

portfolio management as seen through the eyes of the project managers in evaluating specific

situations with clarification and vision in mind. This handbook is considered as type of generic

recommendation and guidance for individuals, teams and organizations. As it is declared in the

baseline “the IPMA ICB is not a “how to” guide or a cookbook for managing projects,

programmes or portfolios... While it offers more in competence development of individuals

involved in projects, programmes and portfolio management, it can be used alongside other

global process-oriented standards.” (IPMA, 2015). Thus, ICB not only describes the knowledge

areas, recognized as competence areas, but also serves as the managerial model to evaluate PM

competence. IPMA recognizes competence as a function of the individual, the team and the

organization. However, the primary focus of the baseline is the individual.

The main concept of IPMA methodology is about individual competence, which viewed

as the application of knowledge, skills and abilities in order to achieve the desired results.

According to IPMA ICB Version 4.0, competence in the project environment is broken down

into 29 competence elements, which are grouped into perspective competencies (5 elements);

people competencies (10 elements); and the practice competencies (14 elements). Each

competence element provides a definition and description of the content, experience criteria,

including knowledge, skills and abilities, and a list of key competence indicators. All

competencies in the IPMA ICB are interconnected as well as the processes in PMBoK and

principles in PRINCE2. Particularly, an output from one process in PMBoK can be applied as

an input to another process and equally in the IPMA ICB the information from one competency

can link or relate to another one.

These three areas of competence form the IPMA “Eye of Competence” and apply

equally to all three domains, namely project, programme and portfolio management. In turn, it

shows the extension of the focus on PM including programme and portfolio management,

unlike other methodologies. PMBoK and PRINCE2 primarily emphasize on PM and execution

excellence for a single project. Thus, IPMA extends the scope of PM not just with contextual

and behavioral aspects but also covers all competencies within the frames of three domains.

The perspective competence area, previously called contextual competence, was

reshaped and broken down into 5 elements, namely the strategy of the organization;

organizational and external governance, structures and processes; compliance, standards and

regulations; the informal power and interest; and culture and values. This area covers the

context within which the initiative is run and provides the link to what needs to be achieved. It

27

means that hardly any project or programme is executed in a vacuum, thereby they are

influenced by their organizational, societal and political context. Meanwhile, PMBoK and

PRINCE2 methodologies do not analyze how economic and social environment affect PM.

Next competence area “People”, derived from behavioral competence, consists of 10

elements focusing on the personal rapport between individuals and groups in the projects,

programme and portfolio. It addresses the personal and social competences, which are

prerequisites for the individual working in the project, programme or portfolio to be able to

release success. Importantly, all personal competence starts with the ability to self-reflect and

self-manage, which, in the end, is proven by the successful realization of the agreed tasks. Other

competence elements are defined and placed between these extremes.

“Practice” area, previously defined as technical competence, comprises 14 elements that

deal with project, programme or portfolio matters. It requires considering all contextual

influences and demands, that come along when the organization initiates a new project,

programme or portfolio. Initially, the individual prioritizes and explains all contextual and

social aspects into a project, programme or portfolio design, which is seen as the cornerstone

element. According to the IPMA methodology project, programme or portfolio design “drafts

a ‘chartcol sketch’ – a blueprint or overall architecture of how the project, programme or

portfolio should be set up, laid out and managed.” (IPMA, 2015). It could be the equivalent of

the Project Charter, which is developed in accord with the PMI methodology. This management

product considers a broad range of PM aspects such as resources, funds, stakeholder’s

requirements and objectives, benefits and organizational change, risks and opportunities,

governance, delivery, priorities and urgency. The main goal is to derive the most beneficial

approach that best serves the organizational objectives and considers all formal and informal

factors that might support or disrupt successful delivery. Although the ICB gives the description

of each competency element, which presents all the PM aspects, it does not support it with the

integrated process model and explicit management stages, management products,

recommended techniques and processes, generic templates (Rehacek, 2017). Thus, it is

primarily set up to address the competence development of individuals involved in projects,

programmes and portfolio management, and evaluate their PM competence, unlike PMI and

PRINCE2 methodologies.

Comparing to other methodologies, the only explicit role, that is mentioned in IPMA

foundational standard is project manager, all the rest is optional. The project manager needs to

continually develop the team and its members, from an initial phase of team building to a team

working throughout the life of the project, to the conclusion of the project, when team members

are released to return to their organizational units. Where the project manager and/or team are

very experienced, it may be sufficient and acceptable to interested parties to “report by

exceptions”, which correlates with one of the PRINCE2 principles. Importantly, the project

manager is not responsible for achieving the business benefits of the project, which accrue to

and are largely realized by the organization once the project is delivered. In most organizations,

the project owner is held accountable for the realization of the benefits, while the Senior User

is responsible for this within the PRINE2 framework. Concerning applied terminology, the

project is being defined as “a unique, temporary, multi-disciplinary and organized endeavor to

realize agreed deliverables within predefined requirements and constraints” (IPMA, 2015).

Thus, the IPMA approach highlights the main characteristics of the project’s nature and

28

translates the successful delivery of a project in terms of stakeholder’s requirements, including

multiple constraints such as time, cost, resources and quality standards or requirements.

To conclude, IPMA methodology is a competency-based approach aiming to provide a

holistic model for individuals, teams, organizations involved in project, programme or portfolio

management with a primary focus on individuals. Within its concept, IPMA ICB offers access

to the knowledge, experience and personal attitudes in project attitudes in PM. Moreover, it is

the foundation for all certification programmes established by the national associations-

members and their certification bodies that are validated by IPMA. In comparison with other

analyzed methodologies, the IPMA competence baseline extended its focus from narrowly PM

to programme and portfolio domains, as well as external, organizational and behavioral aspects.

However, this methodology is mainly indecipherable in terms of techniques, tools and certain

processes, thus individual involved in PM should seek out this information from other standards

and methods.

By reviewing concepts of chosen PM methodologies, examining its structures, key

components and integrated elements of each of these leading best practices, the main

differences were revealed. Thus, based on the findings, compiled in Appendix A and discussed

above, this paper presents the list of all the analyzed attributes and how each of the

methodologies differs in terms of these comparison elements (Table 1).

Table 1 Result of Gap Analysis between PM methodologies Comparison elements PMBoK PRINCE2 APMBoK ICB

Knowledge area ✓ +/- ✓ ✓

Project phases ✓ ✓ ✓ ✓

Project processes ✓ ✓ ✓ ✓

Inputs and outputs ✓ ✓

Benefits and Business Justification ✓ ✓ +/-

Tools and techniques ✓ ✓ ✓

Available templates and checklists ✓

Hints and tips ✓ ✓

Terms and definitions ✓ ✓ ✓ ✓

Structured approach ✓ ✓ ✓ ✓

Flexible and scalable +/- ✓ +/- +/-

Industry application ✓ ✓ ✓ ✓

Project types (Small, Medium, Large) L S-L M, L M, L

Adoption level (High, Moderate, Low) H H M M

Defined organization structure and responsibilities ✓ ✓ ✓ +/-

Certifications and examinations ✓ ✓ ✓ ✓

Source: developed by the author based on appendix A and revision of (APM, 2019), (AXELOS, 2017), (IPMA, 2015) &

(PMI, 2017)

It is apparent that all of the above-mentioned methodologies are structured and

organized approaches presented in comprehensive guidebooks or manuals, although gap

analysis shows some noticeable distinctions. As indicated in table 1, PRINCE2 meets the vast

majority of criteria with the only exception of partial fulfillment of the first criterion. However,

this methodology introduces an integrated element called PRINCE2 themes, which are viewed

as the equivalent of knowledge areas addressed by other methodologies. In turn, these themes

29

describe aspects of PM that must be addressed continually and in parallel through the project,

however, some professionals argue that these components are not as comprehensively covered

as PMBoK knowledge areas. For instance, PRINCE2 is silent about the procurement

knowledge area, although the Work Package product and the processes associated considerably

intersect with the PMBoK's area. As Rankins (2013) asserts this might be simply the reflection

of the different heritages of compared methodologies (Rankins, 2013). While the PMBoK

essentially arose in the private sector, PRINCE2 derives from the public sector. Thus, the first

one considered the need to have the method provide guidance on procurement when the second

approach saw no necessity to cover something that was described in detail in public sector

procurement policies and procedures. Importantly, the PMBoK coverage of procurement is

considered to be simplistic and outmoded, thereby more advanced modes of procurement are

predominantly applied in reality, namely outsourcing or Public-Private Partnerships.

Importantly, each of the reviewed PM methodologies is mostly complete with

appropriate project processes, phases, tools, and techniques, although it is grouped or divided

by different means. For instance, five key processes identified in PMBoK are presented by

seven processes in accord to PRINCE2. Also, all practices provide their assessment systems

and competency examinations using multiple levels of certifications for project managers in the

industry. For instance, APM training and qualifications, as well as the IPMA baseline, are

designed to ensure that individuals, teams, and organizations have the appropriate generic

knowledge and understanding in the key areas and principles of PM. Such pieces of training

are appropriate for anyone involved in PM, thereby it provides the foundation for using PM

methods such as PRINCE2 or PMI methodology.

The most common missing elements are hints and tips as well as available templates

and checklists. The only methodology, which is truly elaborated, is PRINCE2. The

methodology contains product descriptions outlines for its defined management products, as

well as some recommended techniques and checklists. However, the methodology highlights

its recommendatory nature, as all outlines and its format examples are not exhaustive, thereby

it emphasizes the significance of tailoring, as a principle. Thus, PRINCE2 proves to be a flexible

and fully scalable methodology to suit the project environment, size, complexity, importance,

team capability, and risk (AXELOS, 2017).

There are also other critical disparities between the methods. Firstly, PRINCE2, as well

as APMBoK, provide sufficient guidance relating to the externalities of projects by having a

strong focus on governance and benefits, about which the PMBoK is essentially silent.

Regarding IPMA ICB, benefits are omitted in the project domain but clearly conveyed in

program and portfolio areas. Particularly, PRINCE2 identifies ways how to establish an

effective project governance structure and the use of the Business Case as the primary control

over the life of the project. Secondly, methodologies have different depth of description of the

roles and responsibilities involved in the project. For example, PRINCE2 requirement for role

clarity for everyone involved in a project together with the project assurance function, the

concepts of management stages and tolerance around estimates, and Product Descriptions, are

viewed by professionals as valuable and useful concepts for organizations.

Thus, an overview of chosen PM methodologies and analysis of differences proves that

each method has its strengths and weaknesses. Methodologies that have subsequently been

30

established, including PRINCE2, APMBoK, and IPMA ICB, are based upon the same ground

as the PMBoK, although each has a list of distinctive characteristics. For this reason,

professionals and practitioners view these methodologies as complementary to each other rather

than exclusive methods to be used. While PRINCE2 remains a better choice as the basis for an

organizational PM method due to its descriptive, process-oriented and flexible nature, all

methods are better regarded as complementary, and not competing ones. In other words, their

distinctive characteristics make each attractive to different stakeholder groups. Particularly,

PRINCE2 declares that if a project manager needs to use a tool or technique not covered by

PRINCE2, or inadequately covered, the project manager should seek out more detailed

information from sources such as the various PM bodies of knowledge, including the PMBoK,

the APMBoK, the IPMA ICB or any other suitable methodologies and frameworks.

PRINCE2 Agile Approach: complex solution suitable for the IT industry

The essential feature of PRINCE2 Methodology is that this is not a body of knowledge

that just declares and prescribes certain PM techniques. PRINCE2 viewed as a consistent

methodology that can easily be tailored to different projects. As the seventh PRINCE2 principle

states "it should be tailored for a project's particular circumstances", which means to adapt a

method or process to suit the situation in which it will be used (AXELOS, 2017). Thus, the way

to use it is to tailor PERINCE2 to different project environments.

The tailoring of PRINCE2 is about adapting the approach to the project environment.

For example, changing the language to industry terminology. The aim is to apply an appropriate

level of governance and control without overburdening the project, at an acceptable level of

risk. According to Hodge (2017) and his study, the following environmental and project factors

should be considered:

1. Organization related factors such as organization culture, sector differences, organization

maturity, multi-organization, and its geography;

2. Project/Program-related factors as project scale, project priority, solution complexity,

project type;

3. Stakeholders related areas such as commercial customer/ supplier environment, team

maturity;

4. Existing PM toolkit such as applied PM bodies of knowledge, projects in a programme

environment, recognized best practices (Hodge, 2017).

Hence, all the abovementioned areas should be taken into consideration to find the

proper way how PRINCE2 is tailored. The process of tailoring can be applied to processes,

themes, roles, management products, terminology/language, but not principles, which are

essential to the PRINCE2 project and cannot be changed or eliminated. As the BoK states

PRINCE2’s principles should not be tailored as they are universal and always apply (AXELOS,

2017).

Particularly about elements that can be tailored, processes may be combined or adapted.

It means that tailoring of responsibilities and activities is acceptable. The same rule applies to

terminology, it is possible to change the words if the meaning stays the same. This should be

31

done to comply with standards and organization policies. Regarding products, this can be also

combined or split into a different number of documents and data sources. Even though it usually

takes the form of formal documents, slide decks, wall charts, or data held on IT systems would

not be a problem in case if more appropriate to the project and its environment. Also, these can

be adapted using techniques that are appropriate for the project. For example, in the

organization theme, it may be suitable to have one person performing two roles due to project

size and its requirements. Although while combining roles, it is important to assure that

accountability is maintained and there is no place for conflict of interest.

Thus, the practitioner should evaluate the pros and cons of the tailoring process once

they relate to the specific project and environmental circumstances and ensure that tailoring is

compliant with the PRINCE2 principles and any overriding corporate standards and policy. The

specific nature of the industry and a dramatic increase in the use of technology have created a

paradigm shift in terms of how quickly people want things such as information and products.

According to this fact, the tailoring of PRINCE2 methodology is essential to fit in the industry

and the specification of their products – software solutions, which presented and analyzed in

the practical part of the work. Thus, the PRINCE2 methodology should not be analyzed in

isolation and combined with Agile behaviors, concepts, frameworks, and techniques.

As the brief introduction to Agile PM, the word Agile means to move fast, lightly and

easily. The main goal of Agile is to deliver the operating functionality of the software as fast as

possible, starting with the components that are most important for the business. Being able to

demonstrate software in operation quickly creates understanding and enthusiasm. Thus, it

becomes a perfect way how to respond faster to market demands these days (Haworth, 2019).

The configuration of PRINCE2 to Agile has become a well-known practice, as Agile

has a very strong focus on principles, shown in appendix B (Beck, K., et al., 2001). Thus, this

principle-oriented approach appears to be a common ground for both methodologies. Important

to highlight, that some of the PRINCE2 principles are “very much agile”, namely continued

business justification, learn from experience, focus on products, manage by stages, and manage

by exceptions. Particularly, the last one is synonymous with the Agile principle of giving people

autonomy and empowerment, which stands for self-organized and collaborative teams.

Also, PRINCE2 management stages can be aligned with a series of sprints or releases,

which enables fast detection of possible failure of products (AXELOS, 2017). Such elements

as product descriptions in the form of epics or user stories, quality criteria, and quality

tolerances can be prioritized and split into smaller and clear issues to enable flexibility in what

is being delivered. PRINCE2 process journey, depicted in figure 3, can work in an agile way.

The process model consists of a set of processes, which can easily be scaled and tailored to suit

the requirements of all types of projects. All the activities are performed to enable directing,

managing and delivery of a project.

Figure 3 The life of a PRINCE2 project Source: based on (AXELOS, 2015)

Pre-projectInitiation

stage

Subsequent delivery stage(s)

Final delivery

stagePost-project

32

At the very beginning, the pre-project stage, someone has an idea or a need. It can be

triggered by new business objectives, respond to competitive pressures, changes in legislation

or a recommendation in a report or an audit (AXELOS, 2017). If the project runs as agile, then

project-level planning focuses on sets of features, also called functions, and intended

Releases/Sprints. During the planning and estimating the strong engagement from all levels of

the team is expected. Also, the stage-level planning is conducted in collaboration with the

customer. It results in a more accurate formulation of requirements and helps to achieve the

most benefit. Regarding the project approach, mandating or recommending the use of specific

agile approaches, for instance, Scrum or Kanban may be explicitly defined as its part. Also, an

important process is to define what is meant by the Minimum Viable Product (MVP). Regarding

products, the project product description (PPD) is most likely to have been defined to show

mandatory requirements. Initially, the PPD is captured in the form of a user story or epic, which,

eventually, will be refined and broken down into several user stories or requirements. At the

end of the stage, the backlog is prepared, which contains a list of new features for a product.

Then the project proceeds to the subsequent delivery stage(s) when the project board

delegates day-to-day control to the project manager. At this point, products may be transitioned

into operational use by corporate, programme management or the customer. The activities to

control each management stage are covered by controlling a stage process. During this stage,

team members execute assigned work packages focusing on the iterative way of working and

incremental deliveries. The agile approach involves a high level of trust and self-organization

of the team. Progress may be visualized on a burn chart and supported by the use of reviews

and demonstrations (‘Demos’). Scope and quality criteria are the primary focus of any

tolerances used. Concerning products, quality tolerances are defined in such a way that allows

the change without compromising the product’s purpose (AXELOS, 2015). As a useful tool to

collaborate and track the progress, teams can work with the facilitation of Kanban or Jira board,

which visually depicts work in the system framed as the timebox. Also, such activities as Stand-

up meetings help to assess the progress of a project. During these short team sessions, team

members can describe work that has been done, work still to be done and any blockers being

encountered.

As a project moves towards the end of the final management stage, it is time for the

closing a project process. Once the recipients of the project product confirm the ability to own

and use it on an ongoing basis, the product is transitioned into operational use and the project

can be closed. Typically, if agile takes place, some of the products that were intended to be

delivered may not be developed or may be replaced, modified. However, it was all well

communicated throughout the project, so none of the stakeholders are surprized. Regarding

processes involved at the final stage, project closure is held as a Retrospective. The main goal

is to understand how the process of doing work can be improved, thus teams can continually

improve their working practices over time (AXELOS, 2015). The last stage is the post-project

stage, while the project is typically contributing towards the benefits defined by corporate,

programme management or the customer.

The above described agile approach to controlling, managing and delivering the project

helps to react faster and meet most of the customer’s expectations. Thus, one of the most

relevant and used techniques that exist within PRINCE2 Agile is being flexible with what is

33

delivered. It means that it focuses on flexing what is being delivered to get the quick realization

of value predictably, sustainably and with high quality. The concept of flexing what is delivered

can be viewed as prioritization of what is delivered. In other words, applying an agile mindset

company should deliver early, regularly and incrementally to increase customer confidence and

be better off on the marketplace. Indeed, the thinking behind flexing is built upon five targets,

which provide a compelling case for moving to this way of working. These five targets are

described below:

1. Be on time and hit deadlines – it should be seen not just like the desirable but essential

outcome. Also, this applies to any timescale, starting from short-term 2-weeks sprint up to long-

term 6-month projects;

2. Protect the level of quality – ensuring that the level of quality is secured and viewed

as vital, which results in a lower cost of ownership throughout the lifetime of the final product.

For instance, acceptance criteria are commonly used in agile to assess whether a user story has

been completed, can be interpreted as quality criteria in PRINCE2. It means that the emphasis

is on delivering less scope or applying lower-quality criteria rather than compromising the

overall quality level of the final product. If a company does not preserve this rule, that it can

result in such situations as reduced testing, incomplete documentation, sub-optimal design, lack

of appropriate training (e.g. for end-users, customers, support teams). Thus, Agile recommends

reducing the amount delivered by the project but do not reduce activities that ensure that the

quality level is met;

3. Embrace change – change is inevitable when working on anything difficult, so it is

best to expect it and prepare for it. It may be even in the form of misunderstanding where an

assumption proves to be incorrect. However, it is important to distinguish between minor and

major changes, as just minor ones can be handled dynamically and with little overhead. This

illustrates the significance of setting the project baseline in the PID at the correct level;

4. Keep team stable – do not add people to a team to try to go faster. Generally, if a

project falls behind schedule a traditional reaction would be to consider the option of increasing

the number of people involved to speed up progress. However, when the work is challenging it

most likely will not, particularly in the short term. Thus, expansion of a team can have a more

detrimental effect due to following reasons: time is spent bringing new team members up to

speed; the number of communication lines in the team grows exponentially; the team dynamics,

which is the interpersonal interactions between the individuals on a team, change and need to

be re-established;

5. Accept that the customer does not need everything – it explains an agile concept that

features of a product are the safest and most sensible area to compromise on. This results in the

early delivery of an MVP, and in general terms, the project delivers what the customer

wants/needs more quickly (AXELOS, 2015).

It is essential to understand that all five targets will not work in isolation from each

other, they all are interwoven and the integrity of it provides a lot of the reasoning behind the

agile way of working. It can be briefly summarized by the following Agile tip ‘To deliver more,

deliver less!’. Thus, PRINCE2 Agile is a new, practical PM methodology that allows

organizations to implement operating functionality/features in short iterative cycles (Karthick,

34

2013). Starting with the most important one, enables the generation of faster results, gain

immediate insight into the value, increase the flexibility of the implementation and improve

progress monitoring.

Important to mention that agile concepts, based on the ‘lean’ principles can use different

implementation methodologies such as an Adaptive Software Development (ASD), Crystal,

Dynamic System Development Methods (DSDM), eXtreme Programming (XP), Feature

Driven Development (FDD), Lean Software Development, Kanban and Agile Scrum

Methodology (Cprime, 2019). The outlined Agile methodologies share much of the same

overarching philosophy, as well as many of the same characteristics and practices. From an

implementation standpoint, however, each has its unique mix of practices, terminology, and

tactics (Bernardino, 2016).

The DSDM provides an overall industry framework of the software project

developments with rapid delivery. Since 1994, the DSDM methodology has evolved to provide

a comprehensive foundation for planning, managing, executing, and scaling the Agile process

and iterative software development projects. Another method, Extreme Programming (XP),

originally described by Kent Beck, has emerged as one of the most popular and controversial

Agile models. It takes its name from the idea that the beneficial elements of traditional software

engineering practices are taken to “extreme” levels. XP is a disciplined approach for high-

quality agile software development, focused on speed and continuous delivery. It is intended to

improve software quality and responsiveness in the face of changing customer requirements

(Blueprint, 2020). There are also few lightweight, adaptable approaches to software

development, namely Crystal, Kanban, and Scrum. For instance, Kanban is a highly visual

workflow management method that is popular among Lean teams. In fact, like Scrum, Kanban

is a process designed to help teams work together more effectively (Hron, 2018).

In a yearly conducted “State of Agile Report”, Scrum or hybrid version is again reported

as the most widely-practiced "Agile methodology" with around 70 % of the total number of

respondents (CollabNet VersionOne, 2019). In a nutshell, Scrum is a lightweight agile PM

framework with broad applicability for managing and controlling iterative and incremental

projects of all types. This approach has garnered increasing popularity in the agile software

development community due to the following reasons: its simplicity, proven productivity,

ability to act as a wrapper for various engineering practices promoted by other agile

methodologies. Within the frame of Scrum methodology, the Scrum Team is created consisting

of a Product Owner, a Scrum Master and Development Team fostering flexibility, creativity,

and productivity. This type of teams is based on self-organization and its cross-functional

nature. (Schwaber & Sutherland, 2017). Product Owner works closely with the team to identify

and prioritize system functionality in the form of a Product Backlog. The Product Backlog

consists of features, bug fixes, non-functional requirements, etc. - whatever needs to be done to

successfully deliver a working software system. Once a Sprint's Product Backlog is committed,

no additional functionality can be added to the Sprint except by the team. Once a Sprint has

been delivered, the Product Backlog is analyzed and reprioritized, if necessary, and the next set

of functionalities is selected for the next Sprint. Usually, the duration of one Sprint varies from

2 to 4 weeks depending on the specification of the software development and its specifications

(CollabNet, 2018).

35

To conclude, neither PRINCE2 nor Agile provides a comprehensive, step-by-step guide

to ensuring project success. As a common ground, both can be viewed as flexible, adaptable

frameworks that provide role descriptions, sets of practices and management

documents/products. While PRINCE2 focuses on the role of the project manager in planning,

organizing and adjusting the transformation of project inputs into product outputs, agile aims

to encourage the self-organized nature of teams involved on the project, enabling a more

responsive and creative, as well as a more vulnerable, environment. Therefore, a bridge between

PRINCE2 and Agile makes it possible to leverage the benefits of both approaches. PRINCE2

Agile concept enables an organization to gain both the benefits of a more predictive and

structured approach, meaning PRINCE2, with the benefits of a more adaptive approach,

presented by agile concepts, techniques, and frameworks.

36

Research Methodology

Research Process

Based on the literature review, including works of Gerrish & Lacey, 2010, Igwenagu,

2016, Mishra & Alok, 2018, etc., this research should be regarded in terms of its typology. In

general, this work is an analytical, qualitative, empirical research, based on the case study of

one company, operating in the industry of enterprise software. The primary purpose of the study

is to examine PM processes of one of the company's teams, analyze their current state and

determine possible gaps and flaws which can be potentially modified or improved by the

implementation of the PRINCE2 Agile methodology.

This research has its research process, which serves as a guide to research and how it is

conducted (Igwenagu, 2016). The chart shown in Figure 4 represents a research process for the

conducted research, which is crafted by the author based on the theoretical overview of existing

generic approaches.

Figure 4 The Flow chart of the research process Source: developed by the author based on (Mishra & Alok, 2018) & (Gerrish & Lacey, 2010)

Important to highlight, that in the depicted research process, each step is specific, and

they are separate and distinct from each other. Thus, figure 4 shows that the first step is to

identify the research problem. It means the development of research questions based on the

identified research problem, which are suitable for the empirical, also called experimental, type

of research.

Research object and research questions

The object of the research is the PM environment of a software company located in

Brno, the Czech Republic. Due to confidentiality requirements, the name of the company cannot

be disclosed. For the purpose of this thesis, the company shall be referred to as “XYZ”. The

subject is the development team FI-CA, responsible for Financial Accounting: Contract

Accounts, which belongs to one of the company's key modules – Finance under engineering

unit - Globalization Services (from now on in the text: GS FI). The main goal of the thesis is to

suggest how PRINCE2 methodology could be tailored to fit in the existing environment,

Identify Research Problem

Broad Literature Survey

Choice of Methodology and Research Design

Formulation of Hypothesis to be

Tested

Data Collection through carrying out a Research

Data Analysis and Hypothesis

Testing

Results' Dissemination and

Implementation

37

culture, and product specification of the company. Following research questions are addressed

throughout the paper to achieve the above-stated goal:

1. What PM procedures, policies, processes, and techniques, are used by the analyzed

company?

2. What are the key inconsistencies of the practices applied in the company comparing

to the PRINCE2 methodology?

3. How could PRINCE2 be tailored to fit into the project environment of the company

and improve its deliveries?

Literature Review

Important to notice, that PM is a 'young' discipline comparing to other management

fields (Turner, 2013). As a result, the academic and theoretical knowledge base is not developed

to the full extent. Notably, the PRINCE2 methodology has been investigated partially by

academia and practitioners, although there is still plenty of undiscovered within the framework

of this methodology and its applicability within the industry of enterprise software.

Primarily, the theoretical foundation of this research based on the in-depth overview of

the development of PM as an academic discipline together with the analysis of key project

methodologies, suggested by national and international project associations, namely PMA,

APM, IPMA methodologies and PRINCE2 as the core one. Indeed, the manual "Managing

Successful Projects with PRINCE2" plays a critical role and the paper provides a full overview

and clear understanding of its four integrated elements of principles, themes, processes and the

project environment (AXELOS, 2017). Another fundamental resource is “PRINCE2 Agile”,

which describes the PM solution, combining the flexibility and responsiveness of agile with the

world’s most practiced PM method, PRINCE2 (AXELOS, 2018). This handbook explains how

PRINCE2 methodology is tailored to Agile delivery method as opposite to Waterfall approach.

Besides this, paper covers the process of PRINCE2 tailoring and based on the chosen industry,

enterprise software, gives a brief overview of the leading best practices applied these days,

namely agile concepts and related lean frameworks.

Practice-oriented case-study

Gerrish and Lacey (2010) claim that the choice of research design is the most crucial

stage of the research process (Gerrish & Lacey, 2010). Thus, the author chose the methodology

that fits the research problem, the formulated hypothesis and can address it.

This research should be viewed as qualitative research, because the author used

narratives, words, documents and graphical materials of the XYZ company and FI-CA team, in

particular, as the data source. Upon this, the researcher analyzed all the available data to identify

PM processes, relationships, and concepts. This research approach helped to explore and

experience the culture of the FI-CA team in-depth, taking account of context and complexity.

Also, the noteworthy feature of the research is its empirical nature, as the author is regarded as

part of the FI-CA team, performing the role of the Scrum Master. It means that this research

relies on real experience and observations. Mishra and Alok (2018) state that it is an effective

38

way of gaining knowledge through direct and indirect observation or experience (Mishra &

Alok, 2018).

This research is the case-study based on the FI-CA team, according to Sturman (2013),

"[a] case study is a general term for the exploration of an individual, group or phenomenon",

which means that the author conducted an in-depth and detailed examination of a subject of

study in real-life conditions (Starman, 2013). One of the key advantages of carrying out the

case study is that the author was able to examine the operation of causal mechanisms in

individual cases in detail, meaning the PM process for certain projects. Important to notice, that

this research is classified as a practice-oriented case study due to its primary purpose. This rule

is highly applicable to business-related topics, which is the case of this research. Thus, it aims

to contribute to the knowledge of specific practitioners, namely the FI-CA team, responsible

for a particular software development area.

Research Hypothesis

The primary goal of the exploration of the identified subject is to understand the

problem, its root causes and what type of knowledge is required for practitioners to be able to

tackle issues and to mitigate its consequences. In terms of this research, the author observed the

FI-CA team to understand its concerns and be able to propose a solution to improve existing

PM methodology and delivery concept. Consequently, the author was able to formulate a

research hypothesis based on exploration. As Mishra and Alok (2018) say "the formulation of

working hypotheses is a necessary step in any research process" (Mishra & Alok, 2018). The

hypothesis of the research paper should be formulated in the following way:

PRINCE2 methodology can be tailored to the project environment of the company and

combined with agile concepts, that positively affects existing procedures, policies, and

processes, techniques of one of the company's teams.

Upon this, the author's goal to test and prove or refute the proposed hypothesis by the

end of the research process.

Data Collection

During the study, the author had applied a wide range of methods and techniques,

starting from searching for literature sources among a wide range of media finishing with

shadowing meetings to gain knowledge and expertise from experienced and skilled

practitioners in the company. In a nutshell, the author focused on following qualitative research

methods:

1) semi-structured interviews:

During this study, a semi-structured interview with the Local Product Manager (LPM)

was planned and executed. This type of interview combines several predetermined questions

and/or special topics, but also allowing freedom to digress and improvise. (Berg & Mutchnick,

1996) Also, as the prerequisite to this interview was the engagement with the FI-CA team and

understanding of all the processes inside the team. The interview was handled as one session

with a duration of one hour and following-up communication via email (Appendix C, compiled

39

by the author). The organized interview aimed to fulfill several tasks. The primary objective

was to comprehend the holistic approach to PM which is used for the most common type of

project - Legal Change. Particularly, it helped to understand and cover PM processes,

principles, delivery methods, toolkit, etc. Alongside this, the informal interviews and

communication with the team helped to analyze the working environment, tools, corporate

atmosphere and other implicit details that can be noticed through the real interactions.

2) document reviews:

In the framework of this research, various documentation was examined to apprehend

the company- and the team-level policies, procedures, structure and PM approach. Different

information repositories, including open sources - the official website, integrated reports,

audits, and customer portal; and restricted sources - internal portal, knowledge platform,

internal JAM-pages, SharePoint were analyzed. This helped to gain more knowledge and

comprehend processes, procedures more deeply and in a structured way. Also, it enabled the

researcher to analyze critically the corporate culture and environment on the level of a certain

team – the FI-CA team.

3) observations:

Observation as the method was applied because the author was enabled to study and

understand people within their natural environment. As Kawulich (2005) identifies, there are

different scales of the researcher's engagement (Kawulich, 2005). The role of the researcher

depends on the scale of its engagement. In this case, the researcher had the chance to take the

role of a complete participant, performing the role of Scrum Master in the FI-CA team.

Mainly, the researcher had a chance to be fully involved in all the processes, to

understand the PM approach and see how it operates in the environment of the FI-CA team.

Particularly, the author attended all team meetings and sessions, which are compliant with

Scrum methodology as one of the most common agile implementation methods. Besides this, a

set of workshops, shadowing sessions with knowledge experts were conducted. This all

contributed to a better understanding of the PM approach, its limitations and the significance

of the human factor.

4) gap analysis:

To be able to derive the key gaps and differences of the PM methodology, the author

conducted gap analysis through the comparison of actual performance with potential or desired

performance. In this research, a current state is presented by the current PM processes,

techniques and principles which are adopted on the level of FI-CA team. The desired future

state is presented by the set of adopted agile behaviors, processes and techniques with tailored

PRINCE2 methodology to fit into the existing agile environment. Using the checklist, namely

PRINCE2 Agile Health Check, the author identified main gaps and inconsistencies between

company current state and PRINCE2 Agile framework. The results of the conducted gap

analysis are visualized to highlight the key identified areas for the improvement in terms of the

FI-CA's techniques, process, behaviors, and environment.

To summarize, the author collected a rich range of qualitative data for the case-study

applying various qualitative research methods. Those methods were chosen to provide both, a

40

broad scope as well as an in-depth insight into XYZ's PM environment and processes on the

level of the FI-CA team.

Data Analysis

According to Gerrish and Lacey (2010), this is 'also the phase that is most demanding

from an intellectual point of view' (Gerrish & Lacey, 2010). It is entirely the researcher's

responsibility to lead and guide the process and do a thoughtful analysis of the collected data.

For qualitative data, which prevails in the research, corresponding data analysis techniques have

been used. The exact methods applied in the research varied according to the qualitative

methodology adopted in the study.

Thus, for each piece of the data, the author applied corresponding techniques to derive

meaningful conclusions presented into recommendations. After this, the researcher was able to

proceed to the last phase of the study, which aims to disseminate and implement research

results. There is little point in researching if the results are never shared with anyone excepting

the researcher. In this case, the research results are presented to the faculty's board at the

university, also the author shared it with the FI-CA team. As the purpose of the research is to

improve existing PM practices used by the team, the author was empowered to implement some

changes, which resulted in better performance of the team.

To summarize, this research is a qualitative and practice-oriented case-study of the FI-

CA development team in XYZ company, that operates in the enterprise software industry. As

the industry is growing and evolving with high speed, every company is searching for new ways

how to keep leading positions and retain a competitive advantage, it explains the relevancy of

the conducted research. Thus, the author examined and analyzed the team's PM processes,

techniques and methods to estimate their current state. Upon this, the researcher revealed

determined possible gaps and flaws in the team's PM methodology by applying the gap analysis.

Ultimately, the author provided a set of recommendations that addressed identified issues in

terms of the team's behaviors, techniques, processes and environment. Also, the research

summarized the process of tailoring PRINCE2 and its integrated elements into the agile

environment.

41

Industry and Company Overview

Enterprise Software Industry Overview and Growth

The first modern enterprise software born in 1985 with the introduction of the well-

known corporate operating system Microsoft Windows and the first software solutions allowing

automation of some specific tasks traditionally executed manually (Gulla, 2004). Over a few

decades, the enterprise software industry has been developed tremendously and keeps evolving

more and more rapidly than ever before. Driven by increasing global competition and rising

awareness regarding enterprise software across the globe, the world enterprise software market

is ready to reach new heights.

According to the findings of Statista Research Department, the enterprise software

market is the fastest-growing segment in the IT industry with expected 10 percent of year on

year growth. Meanwhile, the overall IT industry is expected to grow only by 3.4 percent,

totaling around USD 3.87 trillion (Statista Research Department, 2020). The results of the

research conducted by Shanhong (2020), supported by Statista, evaluate enterprise software's

total worldwide expenditure over the last ten years with the prediction for the upcoming 2021

(Shanhong, 2020).

Figure 5 Enterprise software total global expenditure 2009-2021 Source: Retrieved from statistics database (Shanhong, 2020)

Firstly, figure 5 demonstrates the steady growth of the enterprise software industry. The

graph shows that the market revenues have more than doubled in the decade between 2009 and

2019, reaching USD 456 billion at the end of 2019. In 2020, IT spending on enterprise software

is estimated to total around USD 503 billion worldwide. Moreover, the research revealed that

nearly all sub-segments of the enterprise software market had experienced high levels of growth

in recent years. Thus, according to Statista's estimations, this trend of rapid expansion will

continue in the coming years with market revenues expected to amount at USD 556 billion by

2021. Such a positive tendency to grow is also foreseen by other market surveys, particularly

42

Market Research Future (MRFR) speculates that "the global enterprise software market is

expected to grow at approximately USD 634 billion by 2023, at 8 % of CAGR between 2017

and 2023". The key factor propelling the growth of the enterprise software market is the rising

need for big data analytics and analytics and cloud computing. Moreover, growing demand for

business intelligence and analytics together with increasing adoption of database management

systems are other primary factors driving the growth of the enterprise software market (Market

Research Future, 2020).

The segmentation of the global enterprise software market is done based on organization

size, type and vertical. Mainly, enterprise software is used by organizations of any size – small,

medium, and large – in various industry verticals such as manufacturing, media and

entertainment, healthcare, retail, public sector, banking, financial services, and insurance,

telecom, transportation, energy and utilities, and distribution. Also, the market is broken down

according to the type of software, namely enterprise resource planning (ERP), business

intelligence (BI), supply chain management (SCM), customer relationship management

(CRM), web conferencing collaboration and others. According to the report published by GP.

Bullhound, the technology investment bank, the enterprise software market is fragmented. (Fig.

6).

Figure 6 The segmentation of the enterprise software industry in 2018 Source: Retrieved from (GP Bullhound, 2019)

Figure 6 demonstrates six key sub-segments, namely ERP, CRM, BI, SCM, ECM and

Web-conferencing and collaboration solutions, which make up to 33 percent of the market

volume. Mainly, the ERP market is the largest with a market share of 10 percent. Although

ERP solutions have been predominantly provided by three major players - Oracle, SAP and

Microsoft Dynamics, it is currently going through a phase of rapid diversification. According

to the report published by Statista Research Department, CRM software is expected to bring in

over 28 billion dollars in sales in 2019 owing to its focus on analyzing and improving business

interactions with both current and future customers. Meantime, ERP software, which focuses

more closely on corporate data collection and interpretation, is estimated to account for another

84 billion dollars in overall market revenue (Statista Research Department, 2020). The

43

remaining market is divided between smaller subsegments and solutions specifically developed

and offered to specific industries or verticals.

As for ERP market, such business suites as Oracle JD Edwards EnterpriseOne, SAP

Business ByDesign, Sage ERP X3, SYSPRO 7, Microsoft Dynamics ERP, Infor ERP Syteline,

IQMS, NetSuite OneWorld, Epicor ERP 10 and IFS Applications are ranked as leading ERP

solutions by the latest edition of the SelectHub ERP Leaderboard (SelectHub, 2020). These top

systems scored highest amongst 60 top ERP solutions from the customer due to high

compliance with the critical requirements identified by organizations seeking an ERP system.

Important to highlight that the diversification of the market map indeed takes place, as it is

filled with not just such well-known big names as Oracle, SAP, Microsoft, but also many

emerging players. As Gero Decker, founder and CEO of Signavio, notices "if a small leading

software provider like Signavio is the preferred company to develop a decision management

platform from scratch for a leading investment bank, it shows how the strong need for specialist

expertise can win over track-record and potential continuity concerns" (GP Bullhound, 2019).

In other words, the competition gets more intense and to gain a competitive advantage becomes

harder than ever before due to rapidly changing trends and innovations. It leads to a clear

understanding that proper PM methodologies and its agile core become crucial to software

companies.

Software Industry Trends

Paul Roche, a Senior Partner in McKinsey & Company, claims "software leaders

contend with a growing array of challenges as the shift to subscription business models and the

Cloud prompt changes across the organization. New commercial models, AI and digital

technologies raise the competitive bar, even as companies need to deal with rising talent gaps

and cybersecurity threats." (McKinsey & Company, 2019). Indeed, the enterprise software

industry is in the turbulent period, and it is vital to keep up with key trends that continuously

change on the market. Analysis of results of the recent market researches and industry-related

articles, published by McKinsey & Company, Accenture, GP. Bullhound, Delloite, etc. enables

to identify following edge-cutting trends in the enterprise software development industry, that

should be considered by every company specialized in enterprise solutions and applications:

1. Cloud-based enterprise software is a new norm.

Currently, almost every company that provides software development services includes

cloud version to clients versus on-premise solutions. Cloud computing offers significant

improvements for used solutions and enables achieving great business agility with relatively

low costs. The case-based study of Accenture reveals that Cloud is the future of most business

applications, including ERP. Results of their CIO survey discovers that around 80 % of UK

CIOs believe that "cloud is critical to their IT strategy and corporate strategy, and 50% say they

are already running a hybrid cloud ERP and reaping its rewards of Total Cost of Ownership

(TCO) reduction and increased agility." (Accenture, 2019) For instance, one of the enterprise

software market leaders SAP points cloud subscription as the main driving factor in their 2019

revenue as mentioned in the annual report (SAP SE, 2020).

2. Growing demand for more personalized solutions.

According to the latest trends, more and more end-users are looking for configurability

of the enterprise software solutions that are designed and developed with the specifics of the

44

industry kept in mind (Briggs, Henry, & Main, 2020). Such personalized software solutions

delivered by software development companies can significantly reduce time and money losses

on modernization. As analysts from McKinsey & Company notice "the software industry is

being challenged to reconsider its entire approach to professional services." If in the past the

software companies focused purely on installing, customizing, and deploying their enterprise

solutions for customers, nowadays they must help customers to design, implement, and adopt

new technologies and customized solutions (Gnanasambandam, Mangla, & Shah, 2018). In

brief, software companies are now called on to be partners, not just vendors.

3. An AI-fueled and innovative approach to enterprise software.

Such advanced modern technologies as AI and machine learning can enable enterprise

software to reach a whole new level of performance. As Accenture Research Group stresses out

"today's systems of record are fast being replaced by new systems of intelligence. These new

systems of intelligence retain the core "systems of record" capabilities while layering in new

automation and predictive intelligence capabilities." (Accenture, 2019). Application of this

approach means that intelligence, enabled by AI, machine learning, and analytics is not

considered as 'add-on' but becomes integral to the core part of the platform.

4. Investment in Product Management.

CEOs and technology leaders frequently identify the role of the product manager as one

of the crucial talent priorities. Nevertheless, results from the McKinsey Product Management

Index proves the opposite, as companies are underinvesting in this vital talent pool

(Gnanasambandam, Harrysson, Srivastava, & Srivathsan, 2018). Following the results of a new

survey of product managers, fewer than half of the product managers feel prepared to play the

roles expected of them or grow into future product leaders. Nowadays, companies that are

writing software understand their overlook and the importance of product management. As a

result, CEOs and leaders heavily invest in a multipronged approach under a holistic talent-

management program to have a world-class product management function.

To conclude, the global enterprise software market is presently evaluated as being at a

blooming stage. This market holds enormous potential for growth in the coming years. A need

for enterprise software is growing because of rising awareness, fierce competition, and

increasing disposable income. Accordingly, market analysis reveals that software companies

should be highly adaptive and flexible to be able to catch up with fast-changing edge-cutting

trends. Thus, proper PM with an agile core is key to surviving and thriving in an era of rapid

innovation. It enables continuous modernization and the ability to leverage progressive

improvements in edge-cutting software technology.

XYZ Company: Overview

XYZ's Overview and Financials

XYZ is a global company headquartered in Germany that provides enterprise

application software and software-related services worldwide (XYZ, 2020). The company is

recognized as the market leader in enterprise application software and one of the leading

experience management, analytics, and business intelligence company. These days XYZ has a

global presence totaling in over 425 thousand customers in over 180 countries and is a

component of the Euro Stoxx 50 stock market index. Over nearly 50 years, the company has

evolved into a global giant with coverage of over 25 industries. Nowadays, XYZ's CEO claims

that "we have the broadest portfolio of modular and suite solutions in the market, available on-

premise, in the cloud, and hybrid." (Klein, 2020).

45

The XYZ's purpose is to "help the world run better and improve people's lives" by

empowering customers to create a better economy, society, and environment for the world

(XYZ, 2020). This goal has been driving the company for almost half the decade starting from

1972. Important to highlight, that the company leads the evolution of technology, keeping in

mind that the focus remains on taking responsibility for its outcomes and societal effects.

Taking into consideration the latest trends and its fast-changing nature, the company

established its strategy in accordance to the experience economy. It resulted in the strategy of

becoming the "Experience Company powered by the Intelligent Enterprise (IE)". The last one

is viewed as "an event-driven, real-time business powered by technology that includes machine

learning, blockchain, the Internet of Things, and analytics capabilities to help scale innovations"

(XYZ, 2020). This concept of Intelligent Enterprise incorporates three essential components to

help customers achieve their business outcomes (Fig. 7). This Intelligent Enterprise Framework

illustrates a high-level view of the company product portfolio.

Figure 7 The Intelligent Enterprise Framework Source: retrieved from (XYZ, 2020)

Briefly, XYZ's software, technologies, and services address the three core elements of

the IE, namely experience, operations, and intelligence, for the 25 industries and the 12 lines of

business (LoBs). In particular, the company serves:

- An intelligent suite of LoB applications divided into five portfolio categories: ERP and

Finance, Digital Supply Chain Management, CRM and Customer Experience, Network

and Spend Management, HR and People Engagement. Each intelligent suite is

integrated and differentiated through industry-specific business processes for end-to-

end scenarios;

- A Business Technology Platform, the last one in the portfolio category, was introduced

in 2019. It aims to help customers manage data composition across their entire

application footprint. Nowadays, it provides solutions across four key technology

areas: database and data management, analytics, application development, and

integration;

- An Experience Management (XM) platform, bringing together experience data (X-

data) and operational data (O-data) to help organizations manage their four core

experiences, namely customer, employee, product, and brand. This means using an

application programming interface (API)-based integration between XM and the

intelligent suite to connect X-data with relevant O-data.

46

Overall, XYZ focuses on 25 industries and six industry sectors, which are process

industries, discrete industries, consumer industries, service industries, financial services, and

public services. It offers integrated product sets for large enterprises, mid-sized companies and

small businesses (Forbes, 2020). The company operates through the On-Premise and Cloud

segments together with some hybrid solutions. The On-Premise segment comprises of on-

premise software products and on-premise services, while the Cloud segment comprises of

cloud applications and Ariba divisions. Important to highlight the robust corporate taxonomy.

It aims to define a common language for describing how they manage the company, position

their portfolio, develop their software products, go to market with solutions, and report their

results. It has been introduced in 2012 on a global scale as a consistent framework to ensure

collaboration across the company and get the simplicity, which is so needed in this fast-growing

industry (XYZ, 2017).

For instance, the company has a clear and understandable product hierarchy. The

product hierarchy defines the structure of the Software Product portfolio. The top-level is

formed by the Software Product Categories (Financial Management), which group Software

Product Lines (ERP), which, in turn, consists of concrete Software Products (ERP Core

Component, ERP Financial Accounting, and Operations). The hierarchy is unambiguous, and

each Software Product appears precisely once. The same structure and hierarchical nature

applied to services provided by the company.

Regarding XYZ's business model, the company creates value by identifying the

business needs of customers, then developing and delivering software, services, and support

that address these business needs. The development and delivery of the product are done

through close collaboration with the customer and partners trying to ensure that the software

creates value for customers. By obtaining customer feedback, the company strives to

continuously improve its solutions, recognize further business needs, and deliver enhanced

value to the customer. Applying such a business model enables the company to generate

positive results, such as growth, profitability, employee engagement, and customer loyalty.

Despite macroeconomic uncertainties, XYZ demonstrates resilience, sustained growth

and continued market adoption. As a result of the ongoing innovative digital transformation of

its customers, the rich portfolio of solutions, innovative and advanced technologies, together

with the freedom for customers to choose between cloud, on-premise and hybrid model,

company resulted in a remarkable full-year performance (table 2).

Table 2 Company's Results, 2015-2019

Financial Indicator\Year 2019 2018 2017 2016 2015

Total revenue, € millions, including 27,553 24,708 23,461 22,062 20,793

Cloud, € millions 6,933 4,993 3,769 2,993 2,286

Software licenses, € millions 4,533 4,647 4,872 4,859 4,835

Software support, € millions 11,547 10,981 10,908 10,571 10,093

Services, € millions 4,541 4,086 3,912 3,639 3,579

Gross margin (in % of total revenue) 69,7 69,8 69,9 70,2 70,0

Operating profit, € millions 4,473 5,703 4,877 5,135 4,252

Operating margin (in % of total revenue) 16,2 23,1 20,8 23,3 20,5

Source: retrieved from (XYZ, 2020)

Over the last five years, the total revenue of the company has a trend to grow steadily

together with stable results of gross margin. Notably, total revenue increased from €24,7 million

in 2018 to almost €27,6 million, representing an increase of €2,9 million or 12%. Considering

segmentation, it is evident that the growth in revenue resulted primarily from a €1,9 million

47

increase in cloud revenue to €6,9 million. Cloud and software revenue make up to 84% of total

revenue in 2019, comparing to 82% in 2015. Service revenue combines revenue from

consulting services, premium support services, and other services such as training services and

messaging services. This revenue stream increased €0,455 million, or 11%, from €4,1 million

in 2018 to around €4,5 million in 2019.

Operating profit decreased €1,2 million, or 22%, from €5,7 in 2018 to almost €4,5 in

2019. The growth of operation cost decreased its operating margin in 2019 by 6,9pp, to 16,2%.

Mainly it was caused by the recognition of restructuring provisions. The cash outflow related

to restructuring was €0,9 billion in 2019 comparing to €0,1 billion in 2018. This company-wide

restructuring program aims at further simplifying its structures and processes and ensures that

XYZ's organizational setup, skillsets, and resource allocation continue to meet evolving

customer demand.

Another specification of the company is its seasonality. The business has historically

experienced the highest revenue in the fourth quarter of each year, due primarily to year-end

capital purchases by customers. Such factors have resulted in 2019, 2018, 2017 first-quarter

revenue being lower than revenue in the prior year's fourth quarter. Unlike on-premise software

revenues, on-premise support revenues and cloud revenues are less subjected to seasonality.

Organizational Landscape and Corporate Culture

The company uses a two-tier structure of boards, with an executive board and a

supervisory board, which is depicted in figure 8. In a nutshell, the Executive Board is the

governing body of XYZ and subject to the requirements of stock corporation law. It provides

the Supervisory Board with regular, prompt, and comprehensive reports about all essential

issues of business, corporate strategy, and potential risks. The Supervisory Board, in its turn,

advises and supervises the Executive Board. For now, XYZ's Supervisory Board comprises

nine members elected by the shareholders at their General Meeting and nine members

representing the European employees of the XYZ group.

Figure 8 Corporate Governance Structure Source: (XYZ, 2020)

Such a two-tier system helps to prevent a conflict of interest and too much power being

concentrated in the hands of one person. This ensures a distinction between management by the

executive board and governance by the supervisory board and allows for clear lines of authority.

Particularly, the executive board comprises eight members in total, namely 2 Co-CEOs,

48

Customer Success Leader, Leader of XYZ Digital Business Services, Chief Financial Officer,

Chief Technology Officer, Chief Human Resources Officer, and XYZ Product Engineering

Leader. The last functional area, Product Engineering, supervises various engineering units, in

particular, Globalization services (GS) including development teams accountable for LoB

Finance in GS.

In terms of functional units of the company, there is a split across different

organizational units for R&D needs, field activities and customer support. XYZ Labs are mainly

responsible for product development, whereas the field organizations spread across each

country are responsible for field activities such as sales, marketing and consulting.

Headquarters is responsible for overall management as well as core engineering activities

related to product development. Worldwide customer support is not provided by the field

organizations but by a unified organization called Active Global Support (AGS).

The team, used for this case study, belongs to one of XYZ Labs, which are R&D

locations that develop and improve the company's core products. There are seven labs in total,

among the latest XYZ Labs are labs in the Czech Republic, Slovakia, and Poland. All three labs

were established in 2016. XYZ Labs Network (SLN) was created as a global unit that manages

regional Labs and shares best business practices. It coordinates and distributes development

projects among individual Labs locations, accelerates product delivery, gives the company full

access to talent, and drives the company's corporate strategy regarding innovation and business

growth.

As the subject of the conducted research is the development team FI-CA located in

Brno's office, it is essential to have an overview of XYZ Labs Brno Development Center.

Officially the branch of the company was established in early 1998, and in 2017 it received the

status of Development Lab. The XYZ Brno Development Center focuses on the localization of

products for Central and Eastern Europe and direct participation in the development and

subsequent maintenance of new products. All development teams are in close direct cooperation

with development teams at the company's headquarters in Germany (XYZ Labs, 2018).

Important to highlight the significance of corporate culture, which is highly maintained

and feels through every process and every action of every single employee. The set of behavior

is simple and clear; the visualization is shown in figure 9.

Figure 9 "How We Run": set of core values Source: (XYZ, 2019)

Core values called "How We Run" is a set of behaviors that explains how the company

and its people get things done and what makes the culture unique. It helps to understand and

find the right direction for making decisions and driving their work every day. Following such

values, XYZ managed to create a distinctive atmosphere, where everyone is seriously

49

productive without being too serious. Such great perks as flexible hours, tuition reimbursement,

mentorship programs, and healthy exercise initiatives create an environment that balances

freedom with accountability. That is one of the key reasons why the company is consistently

recognized as one of the world's best places to work by many global, national, and regional

awards.

The company's management chooses the right leadership approach. All employees

support, challenge and inspire one another every day. Such type of camaraderie, combined with

training, mentoring, abundant international opportunities and flexible work schedule, leads

everyone to accomplish more than seems to be possible. Referring to Liz Wiseman, recognized

as the top leadership thinker in the world in 2019, and her business book "Multipliers: How the

Best Leaders Make Everyone Smarter", the company's environment could be viewed as space

of "Multipliers" - leaders who encourage growth by choosing right behaviors (Wiseman, 2019).

GS FI and FI-CA Team: Overview and Structure

One of the most in-demand areas in enterprise software is its financial module (from

now on in the text: FI) as every company needs a system for accounting department reporting

and business processes. This module is incorporated in various business suites and available as

Cloud, but also on-premise. XYZ FI is considered as a core component of an integrated XYZ

system since everything that has a financial impact in the modules will result in flowing to FI

in real-time. Thus, XYZ FI provides organizations with well-structured and effective financial

as well as controlling mechanisms. The analyzed development team works on the part of

financial accounting called Contract Accounts Receivable and Payable.

The local development teams under FI are engaged in the engineering unit called

Globalization Services. XYZ Globalization Services - an engineering unit within Product

Engineering (functional area) which is in charge of software localization worldwide at the

company. Software Localization means product features (including content) and underlying

technical capabilities that enable customers to use and get value from, their core business

applications in different locations, adapting to local needs.

The mission of XYZ GS is "to empower all businesses to run compliant locally and

compete globally." (XYZ, 2020). Key localization areas include the following:

- Tax (Tax Service, Tax Reporting (ACR), Tax Compliance);

- Digital Compliance (Document Compliance, Reporting (ACR), PEPPOL, Nfe, GST,

HCM Reporting);

- Internationalization (Multi-language support, Code pages / Unicods, Time zones,

Multiple currencies, Calendars);

- Languages ( XYZ Translation Hub, Natural Language, Conversational AI);

- HR & Payroll (Social Media Integration, Learning Reports, e-Permit, Payroll);

- Payments (Local Formats, Reconciliation, Digital Security).

GS represented across the world enabled through leveraging a global network of

software localization experts – unique across the software industry. For now, GS consists of:

1) 9 Development Locations (Engineering Teams) including Brno Lab. Engineering

teams aim to build localized high-quality Cloud and On-Premise products, also

specialize in products (S/4, SFSF, SCP…) and domains (tax, e-documents…).

Particularly, FIN Area Team consists of 4 teams, responsible for:

a. FIN Payments: Cross-countries;

50

b. Treasury: CZ and SK;

c. DMEE and Mapping Tools;

d. FI-CA and Industries (Insurance, Public Sector Collection and Disbursement

(PS-CD), Industry Solutions for Utilities and Telecommunications (IS-U/IS-T).

This team is taken as the subject of this research paper (Demianchuk, 2020)1.

2) 40 Localization Product Managers (LPM) & Language Experience Teams (LET).

These teams aim to monitor local legislation, analyze all requirements, create

specifications and hand them over to the engineering team, after what connects with

customers, governments, user groups and tax advisors to be able to provide high-

quality multilingual products, solutions, and content.

The subject of the research is the development team called "FIN Scrum Team CZ BQ6",

which is an internal naming convention. Unofficially, the team and its members are referred to

as the FI-CA team due to the supporting component FI-CA. Briefly, contract accounts

receivable and payable (component FI-CA) is a sub-ledger in Financials which focuses on mass

data processing in industry solutions such as Utilities, Telecommunications, Insurance, and

Public Sector. FI-CA is a central component in Hybris Billing, aka Billing and Revenue

Innovation Management (BRIM). FI-CA is part of the company’s ERP as well as S/4HANA

On-Premise and Cloud edition, which affects the scope of programs and projects covered by

the team.

The team was established in November 2019. Formerly, all its members were part of

the FI team (FIN Scrum Team CZ BQ3). Due to the enablement of the FI-CA component and

growth of the scope of supported accounts, the split of the FI team was agreed on. The main

aim was to set up clear scope and accountability for each team and its members. Nowadays, the

FI-CA team consists of 7 members led by the Product Owner (Fig. 10). The team develops new

functionalities, cooperates with customers and core team to help them to implement it, and

maintain enabled software development. By now, the team supports and works with 30

countries and hundreds of customers around the globe.

Figure 10 FI-CA Team: organizational structure Source: data from my research

The team consists of the Product Owner, the Development Team, and the Scrum Master.

This is aligned to the framework proposed by Scrum implementation methodology, as one of

the key agile methodologies. The essence of this approach is to work in small teams of people,

such structures are highly flexible and adaptive. In the ideal scenario, the Scrum team functions

1 Information is retrieved from the WIKI Page - part of the author responsibility as Scrum Master.

Product Owner

3 Senior Developers

Junior Developer Quality Enginner

Scrum Master

Tester

51

as a self-organizing and cross-functional body. There are three significant roles in the FI-CA

team, which are described below:

1. Product Owner, who represents all the stakeholders and customers. He is ultimately

accountable for maximizing the value of the product resulting from the work of the

development team. It is exclusively his responsibility to manage the Product Backlog,

including clear identification of Product Backlog items, understanding the Product

features, prioritizing the task, together with the assurance that the Product Backlog is

visible, transparent, and clear to all team members.

2. The Development Team consists of professionals with the required expertise needed

for delivery of a potentially releasable Increment of "Done" product at the end of each

Sprint. Only members of the Development Team create the Increment. They are

structured and empowered by the organization to arrange and manage their work.

Even though they are self-organizing, the team is not cross-functional because a

certain set of skills belongs to a particular team member. For instance, Tester performs

a set of duties like setting up systems, writing special codes for automatized tests,

which cannot be done by other team members. Thus, it violates the SCRUM

framework, which recognizes no titles for Development Team members, regardless

of the work being performed by the person. However, accountability belongs to the

Development Team as a whole.

3. The Scrum Master can be considered as a servant-leader for the Scrum Team. The

primary responsibility is to promote and support Scrum as defined in the Scrum Guide,

although taking into consideration specific needs, the company's environment and

established patterns through years of experience by the team members. The Scrum

Master serves the Product Owner, to the Development Team, and the Organization.

However, the key role is to serve the Development Team through helping them to

create high-value products, removing blockers to the team's progress, and coaching

the team in areas in which Scrum is not yet entirely accepted and understood. Besides,

the Scrum Master facilitates Scrum events when it is requested and needed.

In general, the establishment of small self-organized and empowered teams started as

XYZ was looking for a faster and more effective way of delivering the software to the customers

to meet the market demands. This agile, in other words, the iterative method, is based on 'Lean'

principles of software development and uses elements from Scrum as implementation

methodology. However, the new approach encountered some difficulties, which will be

analyzed in the next part of the research.

Project Management Overview

Traditionally the company used to run projects on Waterfall methodologies, generally

hybrid versions of PRINCE2 and that was justified by the environment and trends of the ERP

industry back in time. Over a few decades, Waterfall-based software engineering frameworks

were mostly taught to software professionals and subsequently adopted as ‘best practice’, which

became the dominant way to implement configuration-driven package software. However, the

introduction of Agile in 2001 and its steady popularization started to change the way how

companies operate and deliver products. The transition of the company had started since 2010

when XYZ began adopting an Agile mindset, ways of working and its values and principles.

Especially the organization launched a rigid transformation to achieve the next level of Agile

as enablement for higher quality and productivity and as a prerequisite for cloud delivery. It

52

Bu

ildin

g o

n e

ach

oth

er f

rom

bo

tto

m t

o t

op

means that XYZ started applying Agile organizationally and technically across various

functional areas and lines of businesses. The overview of how the company enables continuous

delivery based on the agile principles and lean thinking summarized in figure 11.

Figure 11 Company’s development and delivery concept Source: data retrieved from (XYZ, 2018)

The integrity of the approach through the combination of team processes and

development practices enables the company to achieve higher quality and productivity. Agile

principles, values, and mindset together with the Lean philosophy are taken as the foundation.

Then it is translated into the context of specific implementation frameworks, predominantly

Scrum. After this, it is advanced with the development practices starting from Agile Software

Engineering (ASE). It comprises the values, principles and concrete practices that a developer

needs to know to work successfully in a lean and agile context. It is the technical complement

to Scrum, as Ken Schwaber, who co-developed the Scrum process with Jeff Sutherland in the

early 1990s, stated: "Scrum alone is not enough, you need technical practices to make it work"

(XYZ, 2017). Thus, all the teams and product areas are acquainted with this generic approach

and currently working on achieving higher levels of maturity with regards to ASE, DevOps and

Cloud Engineering resulting in Continuous Delivery.

Besides this, to tackle the issues that are holding the organization back in cloud

engineering, the Product Engineering group has kicked off the CORE transformation program,

which fits the strategy of Intelligent Enterprise (XYZ, 2019). This transformation framework

looks at the company's core products together with their core engineering processes (e.g.

development productivity, product management), and the changes that need to be implemented

to win in the core mission of the Intelligent Enterprise. The program comprises 15 key

workstreams, and two enablers are Product Portfolio Management and Product Management,

which will lead to improved integration and architecture modernization of the company's

products. The new approach is more agile, far more transparent and customer-centric.

Continuous Delivery Principles & DevOps

Cloud Development Patterns

Agile Software Engineering (ASE) as set of Development Practices

Process Frameworks (Scrum, Kanban, etc.)

Agile Paradigm & Lean Philosophy

53

After summarizing the generic approach introduced on the corporate level, it is essential

to understand the FI-CA team environment, their scope, and how projects are handled. FI-CA

manages different activities, which are comprised in table 3.

Table 3 Scope of the FI-CA team

Type of Activities Description

Development of

new functionality

The development of a new distinct element of functionality which can provide capabilities

to the customer. It can be triggered by the LC or CCI/ICI.

Legal Change

(LC)

Adjustment of released functions in all releases due to the commitment of the company to

keep its customers legally compliant (including legal change announcement note, legal

change note, regression tests, etc.).

Strategic

Portfolio (STP)

Strategic board-initiated developments (e.g. S/4 HANA, SuccessFactors, ByDesign,

Concur, etc.); GS strategy investments (GS Domains, SCP services); or Investments related

to the Intelligent Enterprise.

Customer-Driven

Continuous

Improvement

(CCI)

Creation of new or adjusted functions due to legal demand of the customers or consolidated

customer feedback, for example, to make legal compliance easier or user group feedback.

Selection and shipment according to Customer Connection rules. Customer-triggered

continuous improvement topics – generating business value for the customers and XYZ.

Used in exceptional cases, needs additional approval to be carried on.

Internally-Driven

Continuous

Innovation (ICI)

Re-designed solutions, for example, to decrease TCO for internal development teams

(reduced maintenance efforts due to higher quality of code, etc.). Typically, it does not

include new functionality. XYZ-internally triggered continuous innovation topics –

generating business value for XYZ development teams. Used in exceptional cases, needs

additional approval to be carried on.

Maintenance All activities related to corrections and quality measures for a product that has been released

and respectively in ramp-up, including communication with customers.

Source: data from my research

Important to notice that not all of them could be classified as a project, maintenance

activities are the exception. Maintenance activities can be referred to as "business as usual"

caused by its routine and ongoing nature. The rest of the activities are divided into five

categories. However, the FI-CA team predominantly works on Legal Changes (LC), which can

turn out to be a trigger for the development of new functionality. Another significant area is the

Strategic Portfolio (STP) initiatives, which are undertaken in case of deployment or upgrade of

FI-CA components as part of the business suite (essential/extension) or new solution. For

instance, the enablement of payment formats as part of the S/4HANA On-cloud version through

its quarter country-specific releases. This type of strategic board-initiated development is part

of the company's strategic portfolio. The other two categories of activities, which are internal

or customer-driven initiatives, are used in exceptional cases and need additional approval to be

carried on. Important to highlight that all the Legal Changes are country-specific and delivered

locally when other projects can be part of the strategically driven innovations and functional

upgrade of certain software solutions, where FI-CA appears as one of the software components.

Considering that the FI-CA team supports around 30 countries and business customers

in different industries, mainly the team carries on Legal Change's projects which has temporary

nature and a certain level of uncertainty with time limitations. In a nutshell, a Legal Change

(LC) in the context of the company's applications is a change or addition in the currently valid

legal texts in an already localized country, that affects the behavior of legally-defined existing

54

functionality. In other words, when a change in the laws of a country makes the specification

(and design) on the existing functionality to become obsolete or inconsistent. Thus, this LC

process can be profoundly and thoroughly analyzed based on the interview with Program

Manager (Appendix C) and observing FI-CA team processes and analyzing documentation.

Globalization Services, as an engineering unit, provides a set of guidelines and

templates, together with tools, systems, and processes that are aligned to the company's

approach of continuous delivery. Thus, the overview of the process model for Legal Change as

a project is depicted in figure 12. When implementing legal changes, every phase follows the

lean development model. The legal change process is part of the Innovation Cycle, which is the

standard Development Process Framework for cloud, on-premise, and mobile deliveries with

an end-to-end view from idea generation to market. It covers all product-related activities from

the first idea to maintenance. It leverages benefits like short-cycle delivery and a delta-driven

approach for all scenarios across all deliveries. It is based on the synergy of corporate

requirements, process framework, and program management.

Figure 12 Legal Change Process Overview Source: data from my research

Overall, the LC process model comprises three phases or stages, although the second

phase – development – work in iterations, so usually divided into few iterative Sprints. Each

stage has certain steps, which have mandatory or optional nature, together with identified

responsible roles and necessary deliverables. The analysis of each phase is presented below:

Setup Phase: LC Roll-in and evaluation

This initial stage of the project starts with the assessment of the legal change by LPM,

which is a local product manager. They are the company’s “front line”, those that are in contact

with the field, by which meant either legal authorities, companies, organizations or government.

The company has adopted a series of decision rules to decide when a requirement is an LC or

not, called “Golden rules”. These rules define the fundamental criteria to accept a requirement

as an LC. If any of these rules is not accomplished, the requirement will not be considered as

an LC.

After this LPM together with Area Product Owner (APO) have to decide upon small

LC or big LC, depending on whether the total planned effort is equal or higher than 50 person-

days. The next step is to manage requirements when LPM must deliver two key deliverables:

Market Requirement Document (MRD); and create the Country Backlog Item in XYZ Jira,

which is the company’s backlog management tool. Then LPM in cooperation with APO should

decide upon delivery stage considering the particularities for legal changes in the Cloud and

On-Premise.

55

Consequently, APO can approve development start for LC with the precondition, that

GS investment readiness check is done. Upon this, APO is required to create a new separate or

pool cPro Task in cProjects/EPPM, the tool platform for project and program management in

the innovation cycle. The next step involves the Quality engineer function, who is responsible

for defining the quality strategy for an LC project. A quality strategy defines, which quality

measures are taken to ensure the successful delivery of the legal change. After this, the project

handed over to Product Owner of the FI-CA team – the assigned project team, PO creates

requirements in Jira. Requirements are summarized in Epic, which is linked to corresponding

Country Backlog Item (Fig. 13).

Figure 13 LC Requirement management process Source: ‘best practices’ in GS retrieved from (XYZ, 2020)

The creation of Epic with requirements in Jira is an essential step, as it is recognized as

the child of the country-backlog item previously prepared by LPM and APO. Upon this, the

project team is notified and assigned, so they can proceed to the next stage - development.

Development Phase: LC Execution

This stage is carried out by the assigned project team, the FI-CA team. It comprises

three key steps, which are: 1) create a technical design; 2) implement backlog and requirements;

3) verify the fulfillment of Done criteria. The XYZ Jira is the tool, which is used by the team

for requirements engineering, agile backlog management, and supports collaborations on

backlogs. It is called XYZ JIRA because of the company’s added features and configuration.

For instance, the tool is also integrated into the development tool landscape, namely

BCP, cProjects, Sirius, Test Workbench, Wiki Platform. This eases the end-to-end process,

artifacts and entities flow to deliver desirable, feasible and viable products. Besides, it also

supports corporate requirements like IP compliance and traceability. The Hierarchy and

Ranking Plug-in view, which was developed by the company enables product owners to build

up and structure their backlog.

56

This stage is about LC execution, where the development of product code and

automated tests are its core. Important to highlight that these are the Corporate Requirements

that are mandatory for all development:

1. Create technical designs that satisfy functional- and non-functional requirements

while following product standards and architecture guidelines;

2. Store all innovation/design artifacts (i.e. user interface designs, technical designs, etc.)

in one of the IP safe storages designated by a development program;

3. Implement the backlog/requirements according to 'Done' criteria and guidelines

defined by a development program;

4. Satisfy transparency/traceability of test results.

Besides this, there is the company’s “Best Practices” guidance, that strongly

recommends an overall agile/iterative development model, utilizing such agile technical

practices like unit testing, test isolation, clean code, refactoring, test-driven development

(TDD), continuous integration, pair programming/review and so on. Together, these practices

form what is called Agile Software Engineering (ASE). While an ASE development model is a

matter of efficiency for On-premise product development, it is essential for Cloud products

where a much higher quality level is needed while being able to deliver fixes and features in

short cycles. Also, important to highlight that Agile technical practices are built upon and

complement the agile team practices like Scrum. Upon the development, the responsible

developer must ensure that all committed backlog and requirement deliverables are available at

the Sprint end.

Consequently, PO and QE can proceed and verify the fulfillment of done criteria based

on the results of the Test Evaluation Report, which should be finished before the Sprint Review.

At the end of the phase, if all backlogs and requirements are implemented for LC, the project

can proceed to the last Release Phase. If it is not completed yet and pushed to open backlog,

then the team starts another iterative Sprint Phase or few, which might be the case of Big LC.

Release Phase: LC Deployment

The closing phase of the project, when LC is ready to be deployed. It means that

functionality being developed, downported, and tested in compliance with XYZ Development

standards and guidelines. At this point, PO or LPM should notify customers about the

availability of LC implementation with a prerequisite in the form of the solution acceptance

test. Important to notice, that at first place the development is released to pilot customers for

testing. Upon this, customers are assisted to be able to implement developed LC. The process

is done through specific XYZ Notes with supporting packages, which should be installed

following the instruction given by the development team. Regarding Jira, a country backlog

item, assigned by LPM to APO, and the corresponding requirements, summarized by PO for

the development team, should have the status “Completed”. Upon this, the epic can be closed

and archived.

Important to highlight the comprehensiveness of the toolkit, offered by the company in

the area of Program and PM and all related areas. All the tools are interconnected and integrated

into one another, summarized in table 4.

57

Table 4 Overview of the company’s toolkit

Area Tool Description

Portfolio &

Capacity

Management

Lucid Capacity This is an internal tool for simplified Capacity Management in

development. It is designed to support mainly line managers and operations

in their daily work when it comes to capacity planning.

XYZ Enterprise

Portfolio and PM

(EPPM)

It allows the company’s units to reflect and steer their portfolio.

EPPM provides seamless financial and capacity transparency on high-level

strategic topics, but also on a single operation project level. EPPM is

connected with relevant tools like Lucid Capacity and ISP, the company’s

internal ERP system.

Program & PM Sirius Sirius is the Program Management tool, which supports all product teams in

their compliance activities during development. Based on this central

repository, further processes are triggered, and it is used as one entry point

for an overview regarding product development activities. The integrated

SecurityHub supports the Secure Development Lifecycle.

cProjects EPPM cProjects is the internal tool platform for project and program management in

the innovation cycle. It is used for IP compliant storage of documents.

cProjects is integrated into the activity recording tool CATS / Bridge in ISP.

This means that staffing via cProjects enables time tracking in CATS or

Bridge, which is important for the identification of product costs. cProjects is

connected to the backlog management tool XYZ JIRA.

Requirement

Engineering

XYZ Jira It is the backlog management tool. It is integrated into the tool landscape to

support the agile methodology. XYZ Jira has within this tool landscape

different interfaces to other like cProjects, Sirius, Test Workbench to ensure

the E2E process, artifacts and entities flow to deliver desirable, feasible and

viable products. Besides, it also supports corporate requirements like IP

compliance and traceability (test of new requirements).

Build &

Deploy

GitHub GitHub is a web-based hosting service for source code version control based

on the Open Source tool (git). The company is running its own (SLC

approved) instance to host code. It provides access control and several

collaboration features such as bug tracking, feature requests, task

management, and wikis for every project.

Product and Production

Management

System (PPMS)

PPMS is the central knowledge repository for technical information on the

company’s software components and software products and the foundation

for more than 100+ internal and customer tools, services and processes.

Export Control

Classification Manager

The ECCN Manager Tool is used as part of the Export Control Classification

process. The tool allows storing export control relevant data for the PPMS

entities Software Component Version, Product Version, and Free and Open

Source Software (FOSS) Version. The result of the tool usage is a

classification of the product, component or FOSS version as unclassified (no

export restrictions) or with Export Control Classification Number (ECCN).

Test & Defect

Management

Test Workbench The Test Workbench is the central company’s tool to prepare, organize,

execute, report and document test activities.

The Test Workbench in the system GTP focuses mainly on manual tests.

Internal Incidents (BCP) It helps to report, and process product-related incidents detected internally.

The BCP Internal Incidents enable the operational support to analyze, solve

and verify incidents across the whole organization.

Source: retrieved from the company’s blogging portal (XYZ, 2019)

To summarize, the company has established an innovative approach to project handling,

which is agile, transparent and customer-oriented. Chosen iterative methodology, called Agile,

is based on the ‘lean’ principles for software development and uses elements from ‘Scrum’ as

58

implementation methodology. The focus is on simplicity and new functionalities for the

solution are delivered step by step in so-called ‘sprints’. In particular, the FI-CA team, analyzed

development team, is secured with a set of guidelines and templates, together with tools,

systems, and processes that are aligned to the company's approach of continuous delivery.

Although there are still some grey areas and misconceptions which affect the FI-CA team and

its successful PM experience.

59

Analysis of the XYZ PM Approach

The overview of the company’s development and delivery concept showed that XYZ

builds its software products and solutions on agile and lean principles aiming to reach

continuous delivery and DevOps. These findings framed the further analysis and application of

the PRINCE2 Agile, which describes how to configure and adapt PRINCE2 so that PRINCE2

can be used most effectively when combining it with agile behaviors, concepts, frameworks,

and techniques.

Health check – PRINCE2 Agile version

Although buy-in and support for agile continue to grow across the company, it is

noticeable that not all XYZ’s teams have fully adopted agile practices. In particular, the agile

adoption by the FI-CA team is still in flight. The author performed the Agile Health Check to

evaluate how the FI-CA team and their PM processes are aligned with agile. Briefly, the

PRINCE2 Agile checklist helps to assess how well the project is going from an agile perspective

(AXELOS, 2018). This tool indicates where agile is working well and what could be improved

in respect of behaviors, environment, processes, and techniques, displayed in figure 14. The

period from December till February should be considered as the timeframe for the collection

data for the analysis. Within these three months, the author screened the team's behaviors and

company's environment, evaluated project processes, and discovered applied techniques. A

simple rating system of "yes or no", which corresponds to 1 and 0 scores, was applied by the

author.

Figure 14 Results of the PRINCE2 Agile Health Check for the FI-CA team Source: calculated based on the author’s research (Appendix D)

50%

28%

57%

20%0%

10%

20%

30%

40%

50%

60%

Behaviour

Environment

Process

Techniques

60

Figure 14 shows that the FI-CA team has adopted agile partially. Particularly, when

processes and behaviors appear being fairly adopted components that count for 57% and 50%

correspondingly, techniques and environment of the analyzed team are not on a sufficient level

of agility. It means that such fundamentals as agile principles, values, and mindset are already

working well, but practices and tools could be improved. Important to take a closer look at each

component.

Agile Behaviors

The estimation of the FI-CA team in terms of behaviors resulted in an average of 0,5,

which means that around half of the checklist criteria are met by the analyzed team. Important

to highlight, that the use of self-organizing approach and people-centric values such as

empowerment is constantly growing within the team. Also, agile meets XYZ’s corporate

values, which states "tell it like it is" and "build bridges, not silos". Even though the team's

members try to be compliant with trust and a no-blame culture, transparency as the agile

characteristic was evaluated negatively.

The observation showed that significant aspects of the development and delivery

process are mostly not defined by a common standard so the team cannot share a common

understanding of what is being seen. Even though planning and work assignments are being

carried out collaboratively by the team, it cannot diminish the “silos mode” preferred by some

of the developers. 3 out of 7 members would choose to play solo and do work the way they

used to do being in isolation from others and sticking to "old-school methods". To the question

of why to behave in such a way, one of the developers responded: “every developer has to find

his way and there is no place for collaboration or change”. This attitude has become the main

blocker for the Product Owner, Tester, and Scrum Master, who are more positive and do not

resist the core agile ideas such as “people over processes” and “responsiveness to changes over

adherence to a rigid plan”.

The development of a new country-specific function, named payment transaction QR-

Bill, for businesses with operations in Switzerland is one of the key FI-CA projects. This project

could be taken as an explicit example of rigid repercussions caused by the resistance to change

of the main developer assigned for this task. It resulted in escalation from the customer and

frustration of the whole team. As a result, the developer had no other choice rather than to give

a try to a new approach and way of getting work done. This example will be further explained

in the next section with the recommendations and which agile techniques and methods were

used to fix the situation and manage successful delivery.

Although the problem with the developer was not the only discovered issue that took its

toll on the solution and QR-Bill delivery. Another core idea of agile is "customer collaboration

over contract negotiation". However, all stakeholders impacted by the project were not kept up

to date and engaged in the process. Product Owner, that should speak on behalf of the customer,

could not enable effective and consistent communication with the front-line, represented by

LPM and customer. This was caused by the lack of knowledge and expertise in effective agile

practices.

Besides this, joining the team consisting of people that have years of experience helped

to give a new critical perspective. Thus, another missing component is regular discussions about

the delivery of value and benefits. Team members do not have the vision and understanding of

the value and benefits as a result of their fruitful work. Moreover, the Pastor of Fun has never

61

existed in the team. Even though the idea behind it is simple, to create and make sure that the

team socializes and it is done organically without the idea of enforced corporate fun.

To summarize, it is noticeable that the XYZ “agile transformation” started not with

people and culture. Thus, the real experience with the FI-CA team helped to identify critical

problems and pinpoint missing aspects of agile values and principles. It gives a clear

understanding that business culture and people's challenges sit at the heart of any change. To

create operational efficiencies and reach the desired continuous delivery based on agile and lean

principles, important to focus on people’s perception of agile and its value.

Agile Environment

Results of carried out Health Check show that the existing environment does not work

well in agile respect. Most of the characteristics were rated with 0 due to absence or poor

execution, which lead to 0,28 on average. The set of criteria helped to indicate the key obstacles

from the perspective of the mindset of the team and their communication.

The positive scores were given to a few criteria, which describes the nature of the team

and some of the implemented basic agile practices, which are applied by FI-CA. Particularly,

the team can be viewed as stable, ring-fenced, and working well together. Because team

members used to work together and cooperate for a while. On average, employees have worked

for the GS FIN unit for 6-7 years. Also, project product descriptions in the form of epics are

well-defined and able to show which requirements are mandatory and which are not. As a result,

the team has a clear vision of the output, although the outcome is less articulated and understood

by the team. The observation showed that team members understand which part of the code

should be produced or which functionality developed, but they do not understand the result of

the change and benefits gained by the customer.

Important to notice, that XYZ's transformation strategy emphasizes the customer-

oriented approach, thus encourage and empowers teams to seek out for feedback. In the case of

the FI-CA team, the Product Owner is pursuing this strategy, although some team members are

not interested in what the customer wants. However, the attitude is gradually changing due to

the effort of the Product Owner and Quality Engineering colleagues. At the same time, the

commitment of each team member is high and they truly care about their image and the

company's reputation which they represent. Thus, the attitude 'musts are really musts' appears

as one of the team's qualities. Always core functionality is delivered on time and with high

quality, although the process itself was not done in the most efficient and optimized way.

Regarding the process framework, the FI-CA team uses Scrum as the implementation

methodology. The observation and engagement with the team showed that excepting deliveries

in Sprints, which are known as 2-4 weeks’ time-boxes, nothing else from Scrum is implemented

and understood by the team. In practice, the most common answer was 'there is no value in

Scrum, and it is just taking time to attend all the meetings and maintaining Jira'. As a result,

frequent releases happen, but no expertise and absence of relevant pieces of training resulted in

poor execution. Thus, Scrum is perceived as 'cheesy' word with no real value behind it. It truly

proves that Scrum as a methodology is simple to understand but difficult to master as it is

written in 'The definitive guide to Scrum' (Schwaber & Sutherland, 2017).

62

As a result, team members are not content and work does not appear to be enjoyable. In

other words, the team feels overwhelmed and irritated because of the overload and never-ending

product backlog. It is all consequences of poorly adapted Agile as the corporate philosophy and

Scrum as its recipe. The root cause of this is that the team is just 'doing agile' and not

‘understanding agile’. To some extent, it could be explained by the fact that no sufficient

training, workshops, knowledge sharing sessions were offered.

In terms of communication, the communication flows are insufficient and it slows down

all the processes within the workflow. Also, the customer as one of the key stakeholders is

involved only during the set-up phase of the project, with no fruitful collaboration and

engagement during the following stages. Thus, the view of the customer on the project is

limited, which has a negative impact during the release phase. For example, referring to the

case of QR-Bill, even though the functionality was developed following all quality and

engineering standards, the release stage turned out to be the key impediment. All pilot

customers failed the implementation of the software package and supporting correction

instructions. The key reason is the lack of communication with the customer, thus the technical

perspective prevails without taking into consideration customers and their business-oriented

mindset.

Another important agile technique is that it focuses on being flexible with what is

delivered. The five targets of what to fix and what to flex are not introduced and used by the

FI-CA team. One of these targets is to embrace change, which is not the case in practice. In

other words, team members do not see change as an inevitable aspect, which makes a positive

influence on a project.

To conclude, the overriding mindset of the people and the existing environment could

not be described as an agile one. In practice, the FI-CA team perceives the agile philosophy and

applied process framework as 'something that corporate dictates' without understanding how

useful, effective, and at the same time easy it might be.

Agile Process

As seen in figure 14, team processes are estimated with the highest result of 57 %. This

means that the FI-CA team has certain processes that are working according to agile philosophy.

The overview of processes and how work is done by the team leads to the conclusion that it is

mostly contradictory in its nature and not organized in a comprehensive way.

As an example, management by exception is working fully. Team members are granted

autonomy and empowerment. Thus, there is allowed tolerance on what is delivered and

restriction of the tolerance on time and cost. At the same time, the FI-CA team has no clear

definitions of ‘done’ and ‘ready’, and working agreements are not transparent and can be easily

misunderstood. This approach is very irrational, and it results in poorly performed sprints. For

example, the developer formulates a work package, named product backlog, on a very generic

level and with no estimation of the needed capacity. Upon this, the team member works in a

‘silo’ and does not provide sufficient updates to the rest of the team regularly. Once the task is

developed and tested, it is delivered for validation to the Product Owner. Thus, such process

flow reminds more waterfall approach, rather than collaborative and flexible agile.

Also, important to highlight that the work package interface does not work efficiently.

As a result, it leads to communication problems. In practice, the FI-CA team struggles because

63

there is no unified standard of how work packages are maintained by team members. Jira as the

main tool used for tracking the project's progress and serves as the team dashboard is not used

efficiently. Important to highlight, that requirements that are provided by the Product Owner

are given in the way of epic, and not user stories. Requirements are used by the development

team without further exploration and user stories have not been practiced at all. Such an

approach emphasizes insufficient communication with the customer and between the team

members as one of their key problems. Another discovered misconception is the benefits and

its delivery. However, the way of working is typically iterative and incremental, benefits are

not delivered at several points throughout the project. Even though the team works in Sprints

once new functionality is delivered, benefits are usually not realized.

Also during the setup phase, one of the key activities is planning. The Product Owner

tries to keep the planning and work represented in a feature-focused and timeboxed way. When

work packages, so-called Product Backlog, are created and assigned, "estimates" as attributes

are added sometimes, although the correctness can be questioned. In practice, the development

team ignores and does not give much importance to the estimations as they have never been

explained for what it is needed. Regarding planning horizons, the planning is done by the team

based on monthly Sprints and quarter deliveries (Cloud/On-Premise) recognized as Versions in

Jira.

Also, observation and cooperation with the FI-CA team helped to identify another

lacking agile process, which is the minimum viable product (MVP) and its delivery. The team

does not practice the delivery of MVP, which is usually a great tool to learn. As a matter of

fact, it is hard to develop and deliver MVP with the type of functionalities the team works on.

Another criterion to measure the agility of the processes is the interface of requirements. The

requirements, prepared by the Product Owner, address key features and conditions of the new

functionality with no unnecessary and burdening details. After this, the Product Owner also

performs the role of project assurance by representing the interests of the customer with a value-

oriented approach. Observation of the FI-CA team and their agility showed, that PO is the most

experienced and resilient to agile, which helps team to adopt new processes and transform

gradually.

Another relevant aspect is to establish the appropriate quality technique or method for

the existing environment. The observation showed, that quality management and quality

planning are put in place following agile philosophy, the FI-CA team uses a test-driven

development approach. It means, that quality checking and tests are happening continually and

sometimes even drive the building of the products. In the case of Internally-Driven Continuous

Innovation (ICI), quality is the main driver of change of the functionality or its architecture.

Important to point out, that the chosen quality method includes independent quality checking

and testing as well. Thus, the quality check and tests are done multiple times during each stage,

the final one is done in the pilot mode by the customer.

To summarize, the FI-CA team has already adopted some processes which could be

seen as done in an agile way. However, the further optimization of existing techniques and tools

is needed. Also, the team should pursue further transformation to agile mode through the

gradual learning and understanding of existing agile practices.

64

Agile Techniques

The results of the Agile Health check showed that the agility of techniques used by FI-

CA has the lowest score and stands at 20 %. In brief, the team has a set of basic techniques that

are implemented to be compliant with the XYZ transformation strategy, but the appropriate

setup and execution are deficient.

From the given checklist just three statements match the way how FI-CA team works

and acts. Firstly, the FI-CA team is aware of the foundational agile terminology. Particularly,

team members are aware of such terminology as ‘requirement’, ‘user story’, ‘feature’, and

‘epic’ due to the Product Owner's effort. Secondly, product descriptions in forms of epics have

been written at the appropriate level and with flexibility concerning quality criteria. In practice,

the Product Owner is responsible for and prepares a description of a functionality purpose, its

composition, key features, and quality criteria. Thirdly, prioritization is happening continually,

and timeboxes are not being extended. Primarily the prioritization of the product backlog is

done by the Product Owner, then it is communicated to the development team and the duration

of sprints is always decided collectively.

Other statements do not reflect the reality of the FI-CA team, which means that agile is

not done properly in those areas, and techniques are ignored or not used correctly. One of the

key identified flaws is the information breach, meaning its visibility, communication flow

within the team and with other stakeholders. The XYZ Jira, which is the company's backlog

management tool, was incompetently used by the team. The team dashboard was not updated

and actualized, also tasks were too generic without relevant description or insight. It leads to

another existing issue concerning the documentation. Observation showed that documentation

is not Lean, and there is no clarity about channels that should be used for each type of message.

For instance, the usage of SharePoint was done mainly by Tester, which had its own structure

and order. Other team members are used to working in silos, so every time collection of

information and the latest updates were time-consuming processes. The same problem existed

with Jira, which was solely used by the Product Owner without proper contribution from the

development team. Also, user stories have not been used to stimulate conversation and

communication.

All of the above mentioned proves once again that Scrum is used by the team, but the

integral approach is not adopted. In particular, the Jira dashboard was maintained with the "must

to" approach, but no understanding of the real value being added. Regarding Acceptance

Criteria, which are referred to as the definition of "Ready" following the agile concept, it is not

articulated. In practice, just the delivery scope is identified. Thus, there is no clear

understanding when epic can be viewed as completed. Besides, such a useful technique as burn

charts was not used, so progress was difficult to see.

Another important finding, which shows that Agile and Scrum as its implementation

method works incorrectly is the absence of regular events which are formal opportunities to

inspect and adopt something (Schwaber & Sutherland, 2017). For example, stand-ups used to

take place in an old team before the FI-CA team was separated, but team members were not

willing to comply with the existing agile practice. As a result, Sprints did not contain properly

organized events such as the Sprint Planning, Daily Scrums, the development work, the Sprint

Review, and the Sprint Retrospective, excepting the development work.

Thus, the FI-CA team could not enable critical transparency and inspection, which are

core pillars of empirical process control. As a result, there was no common standard that shows

65

that team members share a common understanding of what is being seen. Also, Demos used to

happen from time to time, but not documented and stored properly. It is a critical ingredient of

successful agile practice, as Demos help to learn and exchange knowledge with other

colleagues. Besides this, no prototyping or experiments were done by the development team,

or at least it was not shared on the level of the team.

Figure 15 Results of the Agile Health Check for the FI-CA team Source: compiled based on the author’s research

Thus, the Agile Health Check helped to identify crucial problems in each area, that could

be improved or transformed in the FI-CA team (Fig. 15). To summarize, most questions proves

that the team is below a high level of competency with agile practices, revealing opportunities

for enhancement of its agility through the implementation of supportive practices and tailoring

PRINCE2 methodology, where it would be complementary with an existing agile environment.

Maturity model – XYZ and FI-CA level

Maturity model such as AXELOS Limited’s Portfolio, Programme and PM Maturity

Model (P3M3) provides a way of baselining organizational capability against a maturity scale,

diagnosing weaknesses and planning for improvement (AXELOS, 2017). Figure 16

summarizes the P3M3 Model and it characterizes an organization’s maturity using the

following 5-point scale. The analysis of the XYZ PM concept and evaluation of the FI-CA team

performance and their maturity enables to place them on level 4 and 3 correspondingly.

The conducted research shows that XYZ as the organization has reached the 4th level,

which means managed processes. On this level of maturity, the organization is actively

intervening to improve performance. The organization launched a rigid transformation to

achieve the next level of Agile as enablement for higher quality and productivity and as a

prerequisite for cloud delivery. It means that XYZ started applying Agile organizationally and

technically across various functional areas and lines of businesses. For now, XYZ obtains and

retains specific measurements on its PM performance and run a quality management

66

organization to better predict future performance and improve the existing development and

delivery concept.

Figure 16 FI-CA and XYZ’s maturity levels according to P3M3 Maturity Model Source: own analysis based on (AXELOS, 2017)

Regarding the FI-CA team, the analysis of the processes, environment, behaviors, and

techniques proves that a single structured approach is in use, meaning the level of a defined

process. Even though the FIFA team has been operating as a separate unit starting since

November, all team members used to be part of other teams and follow certain ways of doing

work and delivering solutions. It means that the FI-CA team has a formalized process for

planning, managing, delivering, and controlling their new developments and functionalities.

Thus, there is the opportunity for improving the team’s agility and the possibility to tailor

PRINCE2 Methodology where it might strengthen and comply with an existing agile culture.

Level 1: Awareness of process

Level 2: Repeatable process

Level 3: Defined process

FI-CA Team

Level 4: Managed Process

XYZ Level

Level 5: Optimized Process

67

Recommendations

The primary goal of this section is to build a PRINCE2 Agile PM method which is the

hybrid concept combining the strong side of each methodology. The strength of PRINCE2 lies

in the areas of project direction and PM, while agile has a very strong focus on product delivery.

Thus, PRINCE2 and Agile complement each other and create a holistic approach to managing

projects in an agile way, which will fit into the company’s existing project environment.

PRINCE2 Agile regards agile as a family of behaviors, concepts, frameworks and techniques

(AXELOS, 2018).

As the company has a very strong agile culture and uses Scrum as the delivery method,

the tailoring of the hybrid method would be the most suitable solution. The conducted analysis

identified the key existing gaps which must be addressed. However, important to avoid the

introduction of significant changes and overburdening additional activities.

Figure 17 Tailoring PRINCE2 by blending in the agile ingredients Source: (AXELOS, 2018)

To implement the PRINCE2 Agile method, two essential activities should be

considered. First, improvement and deployment of existing agile practices that are compliant

with the organization's transformation strategy. Second, tailoring the PRINCE2 framework to

the unique environment and conditions of the FI-CA team. However, it is vital to embed this

tailored method into the working processes of the company by ensuring that the team members

and managers understand and support the changes and apply the PRINCE2 Agile method

appropriately. Also, this section contains the showcase of how introduced changes affected the

team performance and which milestone has been already achieved.

68

Improvement of Agile ingredients

Agile philosophy and Lean principles are the pillars of the transformational

development and delivery concept of the analyzed organization. Thus, it is important to align

and adapt the way how the FI-CA team works to the organization's standards and industry

needs. Essential to highlight that all the steps described below are the initial setup that has

already shown interim results. The outlined agile principles and chosen delivery methodology

are evolving as the team grows and adapts. First of all, joining the team as the Scrum Master

required to enrich the empirical knowledge and solid theoretical foundation. So, the first step

taken was the cultivation of the knowledge from other teams, which are more experienced and

adapted to the agile as practice, and Scrum as the implementation methodology. Thus, the

process of the analysis and evaluation of the FI-CA team was carried on simultaneously with

continuous learnings, virtual training and workshops, sessions with experts, attendance of agile

conferences, and "shadowing" sessions of various Scrum events.

One of the very simple tools which were applied for the analysis and understanding of

how to articulate and bring changes to the team is the flower theory of persuasion. It gives step-

by-step guidance on how to persuade people and open their minds for the changes. In a nutshell,

it consists of six steps, namely understand, prepare the ground, sow the seed, water, weed, and

harvest (Kilboy, 2018).

I: Gradual change and adaptation of agile behaviors and mindset

The first foundational value in the Agile Manifesto states that individuals and

interaction must be placed over processes and tools (Beck, K., et al., 2001). Thus, the first agile

area to be unfolded in terms of implemented improvements is agile behaviors. At the heart of

any agile project lies an agile team, thus the transformation of the FI-CA team member’s

mindsets is the main goal. It means to build a self-organized, collaborative, and accountable

team of skilled and knowledgeable individuals. Important to understand, that people and change

of their mindset are the basic and the hardest part, which takes time to give results (Table 5).

Table 5 generalizes the way how the author utilized the learned theory, which helped to

enrich collaboration and open people's minds to the culture of agility and adaptation. As an

example, the establishment, gradual embedding, and acceptance of the practice of daily Stand-

up meetings, which helped colleagues to step out of their 'silos' and collaborate. From the very

beginning, the Scrum Master triggered and held stand-ups as casual coffee breaks. These

meetings started working as a catalyst for easier understanding team members, their daily

blockers and helped to shape the further transformation and alignment with the Scrum

Methodology. Upon this, the Scrum Master proposed solution to certain issues, so team

members started seeing the value in such brief and simple discussions. Consequently, the

gradual transformation of the standup meetings from coffee corner talks to interactive 10-15

minutes’ lean meetings took place.

Thus, the FI-CA team has fully accepted daily Stand-up meetings after a few months of

practicing. By now, the regular meeting is arranged in the way when all team members stand

in the circle, interact with the team visual dashboard to understand how the team moves towards

the Sprint goal through exchanging their progress and emphasizing blockers if there are any.

69

Important to highlight, that the FI-CA team has faced various common problems before

optimized their meetings. For instance, the team tended to run too long discussions due to

insufficient preparation of the team members, vague updates and not actualized team dashboard

or deep dive into Problem-solving or Storytelling.

Table 5 The application of the flower theory of persuasion with the FI-CA team

Following steps

of the Theory

Description of the step

Understand Understand the current drives and pain points of each colleague during informal lunches,

coffee breaks to be able to set up the proper conditions for the transition.

Prepare the

ground

To dig in deeper and offer for colleagues some simple solutions for their everyday needs to

establish the rapport and plant the trust.

Sow the seed

For each gradual change to find a suitable moment when ideas and concepts can resonate

with colleagues. It will enable minimal resistance from colleagues individually and as a

whole.

Water Periodically drip the information and develop introduced ideas to understand better and

move toward full commitment.

Weed Identified obstacles and weed it out by offering support for the team, solving problems, and

letting new agile values to grow steadily.

Harvest All previous steps lead to improved performance of the team, better collaboration, and rich

communication. Source: based on my own experience and conducted work

Over time, more practice and better commitment from the team help to master

implemented practice and maximize the value. Another important tactic that has been used by

the Scrum Master is to spice Stand-up meetings with some sort of fun and interaction. For

instance, gamification and facilitation of the meeting with the tennis ball which is passed by

one colleague to another team member. On one hand, it helps to keep order and assure that

everyone stays tuned. On the other hand, it adds the element of fun and makes the environment

more informal and friendly.

The given example demonstrates how the transformation of the team's values and

mindset has started from setting up such simple techniques as Stand-up meetings. Face-to-face

communication has proved to be the most effective and efficient method of conveying

information to and within the development team. However, important to highlight that this is a

continuous process, so further ways of adapting agility in the FI-CA team will be explored and

practiced.

II: Improvement of the FI-CA environment

The analysis revealed that the overriding mindset of the FI-CA team and the existing

environment could not be described as an Agile. The key concern is the way how the team

operates where instead of 'understanding agile' everyone is just 'doing agile'. However, as the

organization and all of XYZ's software solutions are moving towards the cloud, it becomes

essential that the foundation layer of “Agile” is understood and implemented by every team.

To address the team’s issues, one of the XYZ GS "best practices" was applied (appendix

E). The Team Health Check is the tool, which is made to be used by scrum teams for self-

assessment to understand team health in terms of Agile. The FI-CA team agreed to conduct the

assessment as everyone comprehends the need to embed a flexible and agile environment to

correspond to the organization and industry trends. Important to highlight, that the implemented

70

exercise was done after the initial set-up and adaptation of agile behaviors and should be seen

as the logical continuation of working on the integrity of the Agile philosophy and Scrum

methodology being used (Fig. 18). The analysis was carried on during the team meeting when

every member voted (Green, Yellow, Red) on Health Indicators. In particular, green does not

mean perfect, it means that the team members are happy with the attribute, and see no major

need for the improvement. Yellow, in turn, means that some important problems should be

addressed, meanwhile red color identifies aspects that require immediate actions, as it is viewed

by the team as a complete failure.

Figure 18 The results of Team Health Check: FI-CA Team Source: data from my own research based on Appendix E

The Health Check identified that mostly the FI-CA team is contented with its quality

practices, also a collaboration with other teams and stakeholders. Besides this, the team

members feel empowered enough to work in a self-organized way. At the same time, it helped

to understand that such areas as stability, skills and tools, fast customer value, team spirit, and

also continuous improvement should be addressed and refined based on existing XYZ “best

practices” and other well-known internal methods and practices.

Thus, the analysis helped the FI-CA team to evaluate the existing environment and

contemplate on what should be improved to achieve better flexibility and agility. For now, the

Scrum Master together with the team pinpointed three main focus areas on which the FI-CA

team will be concentrating:

1) Team Manifesto which identifies core team values, principles and environment,

including an overview of the Jira approach and how it is used by the development team;

2) Gradual refinement of the toolkit and work on the integral approach that would enable

better efficiency and faster delivery of the software development;

0

1

2

3

4

5

6

7

8

Positive Neutral Negative

71

3) The continuous growth of the team spirit through the culture of rich communication

and transparency.

To conclude, the FI-CA team has started reevaluating Agile as the philosophy, which

results in steady steps toward the adaptation of the team environment. Three key areas are

identified and each team member has been contributing and working on its enhancement for

the last few months.

III: Refinement of the agility of the FI-CA process

The Agile Health Check showed that the FI-CA team has a certain approach to the

development and delivery of software solutions that are working according to agile philosophy.

However, the main drawback of the process is the insufficient engagement with the customer

as well as with Local Project Managers, who usually introduce interests of the customer/filed.

In March, the FI-CA team together with others under GS FIN received the results of the

customer survey, which served as another proof of the identified problems. The survey showed

that the satisfaction of the customers dropped and the deployment of the solution becomes more

complicated. Particularly, “XYZ’s quality of products and services is better than that of its

competitors” for GS FIN totaled around 72 %, which is a significant decrease of 10 %

comparing to the previous year.

Consequently, the FI-CA team must focus on tackling this concern to be aligned with

one of four principal agile values which states "customer collaboration over contract

negotiation" (Fowler & Highsmith, 2001). Particularly, to address the quality issue two

measures were taken over the last two months:

1) Quality Perception interactive workshop in Mural with Product Owners, Scrum

Masters, Quality Engineers/Testers and Software Architects of CEE2 team (FI Module);

The focus was on finding possible reasons and proposing measures/actions to improve

the quality of delivered software solutions. As a result, participants managed to derive the list

of measures that could improve the current quality concern. For instance, such activities as a

new usable automation test tool for the Cloud, and regular teams’ training in the delivery of the

product were prioritized through the voting session. Thus, it proved once again the need to react

and adapt faster and enrich the existing toolkit.

2) Organization of the User Story Mapping (USM) Workshop specifically for the FI-

CA team to learn a new proven method of User Stories.

The second activity was organized due to the mutual effort of the Product Owner and

Scrum Master of the FI-CA team. The aim of the USM Workshop moderated by the internal

agile expert for USM in the GS unit was to learn a new method of deriving high-quality software

requirements. As the pilot project for the team to work on was used one of the projects which

should be developed and delivered for various countries in Cloud version in consecutive

upcoming quarter Releases. Briefly, this workshop aimed to understand and visualize the

software Product Backlog from a user perspective. This includes identifying gaps, white spots,

relationships, dependencies, and risks. Besides, collaboration and communication of the FI-CA

team with other stakeholders, including LPM and consultant, became a great advantage. As the

main outcome, the FI-CA team derived all possible User Stories which helped to understand

the requirements to the fullest and prioritize the Product Backlog afterward. Thus, the USM

72

methodology provided better clarity of the project requirements and helped to compose the

"big" picture of the project for all involved parties.

As a result, two virtual sessions took place involving Product Owner, Developers,

Scrum Master, User Assistant, Local Product Manager, and Consultant. Even though the first

impression of the team members regarding the planned workshop was not certainly positive, it

exceeded their expectations. Thus, one of the team members said that "This virtual workshop

was definitely a keystone for our development team - and I think also for some of our main

internal stakeholders (LPM) - to perceive USM and clear the way to understand how beneficial

it is to both requirements clarification and subsequent mapping to the development features and

tasks."

To summarize, the process refinement through collaboration and learning new methods,

practices, tools become critical for the team. Also, the main achievement for the author as

Scrum Master of the FI-CA team is to see the readiness and enthusiasm of the team, which just

a few months ago would not agree to any interactive workshop.

IV: Integration and granularity of the team's techniques

The empirical observation and engagement with the FI-CA team helped to identify key

pain points when it comes to techniques used and its agility. The Scrum Master together with

the team focused on two main directions:

1) Derivation of the unified and simple approach to the Scrum as the main implementation

method used by the Team, including XYZ Jira as the main company's backlog tool;

2) The development of communication strategy, which has been optimized through the

integrity of three main components and their interconnections.

Starting from November one of the key tasks is to work on the team-specific approach

to Scrum, including its main ingredients such as events, terminology, activities. Important to

highlight, that the gradual implementation and extension of the Scrum methodology has been

done, which started from having daily standups and understanding how to interact with XYZ

Jira and derive the team's personalized and optimized way of working with the tool. From the

very beginning, almost every team member saw no value in any of the Scrum events and the

whole approach of working in Sprints. Thus, each Sprint helps the team to learn and understand

the need for each component due to the effort and enthusiasm of Product Owner and Scrum

Master, and readiness of the development team to adapt.

For example, before the Scrum Master was able to document and specify how Sprint

Planning works and what its aim, it took time for the team to get familiar, try, contemplate and

identify the value. Briefly, it was a way of attempts and failures, which helped to learn, improve

and derive the optimized way of having Sprint Planning meetings. Initially, the first session

was organized more as a one-way conversation, when only the Product Owner was talking to

the team, which continued with a too generic split of epics and no estimations. It was caused

by multiple causes, such as the development team is, in fact, a group of individuals and not a

team; lack of understanding of the benefits of the pull principle; definition of Ready and Done

are missing/ignored, etc. Thus, it took for the FI-CA team a few iterations to work on forming

a true team and collaboration, partially encouraged by setting up a concrete sprint goal and

understanding what is meant by "Ready" or "Done" criteria. This, in turn, helped to improve

73

the technique of story points (SP), so-called "estimations" in Jira. Consequently, team velocity

can be roughly identified and measured. However, the estimation of the amount of work to be

done measured in SP is not always correct, which is caused by bearing in mind such aspects as

risk, uncertainty, and complexity.

Consequently, the Scrum Master worked on the scheme of the Sprint Process in

collaboration with every team member, which might be modified and optimized in the future

(Fig. 19). It is documented on the internal knowledge page called Wiki. It contains a concise

description of Scrum Ceremonies, namely Sprint, Planning, Demo, Refinement/Grooming,

Sprint Retrospectives and Standups, plus its team-related features. Besides this, there is an

explanation of the Backlog structure, starting from External Backlog - Unit Portfolio Item and

up to Team Backlog with described issue types and additional Jira elements used. Besides this,

it covers the Jira workflow which is optimized by the unit administrators of XYZ Jira for GS,

which helped to make the process more transparent and communicate more effectively.

Besides, as a result of the teamwork, there is the articulated definition of "Done" (FI-CA Team,

2020). As this is sensitive information and intellectual property of the FI-CA team, specific

details cannot be disclosed.

Figure 19 The visualization of the FI-CA Scrum Process Source: data from the internal knowledge platform (FI-CA Team, 2020)

Important to understand, that this is just the interim result, which will be extended and

optimized to enable the team to develop and deliver software solutions following agile

philosophy and lean principles. Also, the organization's strategy constantly evolves adding new

methods, tools, approaches, techniques, etc., which should be taken into consideration too.

The second mentioned improvement is the communication strategy, which helps the

team to establish a set of suitable tools to interact and maintain lean documentation. Thus, for

now, it is facilitated through the integration of three main components, forming SharePoint -

Jira - Wiki integrity. In brief, SharePoint - central consistent team's repository, Jira - team

dashboard and main tracking tool, serves as an input for Wiki Page, which is the FI-CA internal

searchable live space. Also, this is not the final approach as it might change affected by internal

and external factors. For example, the full shift to the remote way of working, caused by the

74

pandemic, also highlighted the need for such an approach. Moreover, it increased the use of

Microsoft Teams and Mural, which are communication and collaboration platforms, used as

substitutes for face-to-face communication.

To summarize, the noticeable progress done by the FI-CA team towards the agility and

flexibility of its processes, techniques together with the constant evolution of the environment,

people's mindset and values. It helped to improve the team performance and have better

performance in Sprints, which will be analyzed later in the research.

Tailoring PRINCE2 integrated elements to the agile environment

The PRINCE2 Manual states that "PRINCE2 is designed so that it can be applied to any

type of project, taking account of its scale, organization, geography and culture. It is designed

to contribute to the success of a project without burdening it with bureaucracy." (AXELOS,

2018). This section shows how PRINCE2 integrated elements of principles, themes, processes

can be tailored and embedded into the FI-CA's way of working and existing agile environment.

Applying PRINCE2 principles in an agile context

Agile has a very strong focus on principles that are clearly defined in the Agile

Manifesto, and they do not conflict with any of the PRINCE2 principles. It means that all the

principles can be applied for the FI-CA team which follows agile philosophy, specifically:

1) Continued business justification. The business case is transformed into a minimum

viable product (MVP) which is less formalized and does not require much of upfront work.

MVP is introduced to the development team by the Product Owner as an Epic or User Story.

This epic should specify the prioritization of the feature, for example, by applying the MoSCoW

technique;

2) Learn from experience lays in the heart of agile. Thus, the FI-CA team started

retrospectives and also launched the cross-teams learning sessions, which are documented and

stored to improve the engineering culture of the GS FI development teams. Particularly, the

Scrum Master applies some sort of learning log, which is very simplified and fitted into the

communication strategy of the team;

3) Defined roles and responsibilities are “must to” principle as the team should have an

explicit understanding of each role and responsibilities. The typical PRINCE2 PM team

structure cannot be used for the FI-CA team, although such primary stakeholders as an

executive, senior user and senior supplier could be aligned with roles of Product Owner, Local

Product Manager/Consultant, and the Development team correspondingly. The role of Scrum

Master is unique and this person is seen as the servant leader. Thus, it cannot be compared with

the role of Project Manager or Team Leader as the team members are empowered and self-

organized;

4) Manage by stages, which is presented by setup, development and release stages in

case of Legal Chance, which is the most common requirement for the development of new

functionality/features for the FI-CA team. Particularly, the development stage runs in Sprints;

75

5) Manage by exception should be implemented correctly when self-organization and

empowerment are combined with the appropriate level of governance. Thus, the FI-CA team is

the self-organized development team, but the lean system of governance exists, which is

moderated by the Scrum Master for the Area Product Owner.

6) Focus on product, which is realized through the prioritization of the product backlog

for the FI-CA team. Besides this, the significance of acceptance criteria is presented through

the common understanding of "Done", which is documented and stored on the team's internal

communication platform – Wiki;

7) To tailor PRINCE2 to suit the project environment such a tool as the Agilometer

could be applied, which helps to assess the context that a project exists in concerning the

environment and the working relationship (AXELOS, 2018). For the FI-CA team, this tool can

help to determine key risk areas while using agile and where to bring in the strength of

PRINCE2 PM methodology.

Tailoring the PRINCE2 themes in an agile context

PRINCE2 methodology uses themes to describe aspects of a PM that must be addressed

continually (AXELOS, 2017). For such themes as a business case, organization, quality and

plans all the needed tailoring of PRINCE2 for the FI-CA team was pointed out in the subsection,

which addressed principles. The focus is placed on risk connected to progress theme, and

specification of the change theme in the agile environment.

Regarding risk, the agile way of working addresses many risk areas by preferring the

detail to emerge later rather than sooner, and thereby reducing the impact of changes. Further

to this, the FI-CA team has no formal role responsible for managing it. However, the risk theme

in PRINCE2 provides a certain level of formality to the management of risk, which might be

effective in the existing agile environment. Important to notice, that the formalization of risk

management does not require the creation of processes or documents that are bureaucratic

(AXELOS, 2018). For example, for the FI-CA team, it would be useful to have some type of

an informal visualized risk register that could be done during the Refinement/Grooming or

Retrospective sessions. Later it could be useful input for better planning and estimations of the

Product Backlog for the next Sprint. Ultimately, it results in a more precise measure of the team

velocity, which is a description of the rate of progress a team is making. For instance, for the

FI-CA team, the average velocity is 35-40 SP, where SP stands for 1 full-time working day,

which is not sufficient for the team of 7 members. It happens due to ignorance of estimations

or bad estimations without further refinement.

When it comes to change, agile embraces changes. One of four core values of the Agile

Manifesto says 'responding to change over following the plan'. It means that agile perceives

change as inevitable and normal situation while changes are identified as "issues' in PRINCE2.

Thus the agile philosophy is more "change friendly', whereas the second methodology is more

cautious and tries to "control it" (AXELOS, 2018). As a result, the reasonable blend of

controlling significant changes, while giving freedom to allow for responsive change at the

detailed level could be applied for the FI-CA team. Also, a change control approach and good

76

configuration management could be taken into consideration by the team as a good PRINCE2

practice.

The LC Process Model when using PRINCE2 Agile

PRINCE2 provides a process model for managing a project, which can be tailored to

suit the requirements of any type of project. All the processes, namely pre-project, initiation

stage, subsequent delivery stage(s), final delivery stage and post-project, consist of a set of

activities that are required to direct, manage and deliver a project (AXELOS, 2017). In the case

of the FI-CA team, the author analyzed the process model for the most common type of project

- Legal Change. In practice, the model, which is the GS 'best practice' corresponds to the

PRINCE2 model. Particularly, the roll-in stage and evaluation contain pre-project and initiation

stage, then subsequent delivery stages are done in form of Sprints, and then the release stage is

aligned to the final delivery stage. Thus, the enhanced LC process model also takes into

consideration the post-project stage (Fig. 20).

Figure 20 The Enhancement of Legal Change Process Model Source: developed by the author based on the (AXELOS, 2018)

Practice showed that in reality the post-project stage should be embedded in the LC

process model. For instance, the QR-Bill, which was mentioned in the research multiple times

before, delivered some of the features after the LC deployment. Some of the features were not

implemented at handover to the pilot customers. Thus, the FI-CA should consider the

refinement of the process and include the post-projects reviews. Also, these reviews could be

used for the analysis of the customer feedback by analyzing the results of the implemented

Measure Points into the developed functionality. This technique is one of the recent standards

during the development process for the GS unit.

The presented recommendations address the previously identified gaps based on the

conducted Agile Health Check in terms of Agile as the philosophy and PRINCE2 as the PM

methodology. To summarize, the Agile concept can live within the PRINCE2 framework which

is shown through the synergy of their principles, themes and processes. Important to highlight,

that some of the above-mentioned recommendations have already enriched the performance of

the FI-CA team or might do it in the future.

Setup Phase: LC Roll-in and

evaluation

Development Phase (Sprint 1,2,..n):

LC Execution

Release Phase: LC Deployment

Post-project Phase: Realization of

benefits + Analytics

77

The FI-CA performance evaluation and cost analysis

This section of the research is devoted to the analysis of the implemented changes

together with the forecast of the future changes, and a cost estimate measured in an effort based

on the interim available analytics. Firstly, the author analyzed and summarized the results of

the FI-CA team based on their current performance impacted by the implemented changes.

To be able to visualize the performance of the FI-CA team and to understand the effect

of all the implemented agile techniques and practices, the research shows the overview of the

completed Sprints. The analytics of the team performance was extracted from the XYZ Jira,

which is the main XYZ's backlog management tool (Fig. 21).

Briefly, figure 21 summarizes the FI-CA performance and its delivery during four

consecutive Sprints. The duration of the Sprint is one month, starting from January 2020. The

red variable represents the total number of story points, known as estimations, given to the

assigned Product Backlog at the start of the Sprint, which is agreed during the Sprint Planning

meeting. However, important to emphasize, that the vast majority of the tasks from the product

backlog had not been estimated, thus the velocity of the team cannot derive from the available

data yet.

Figure 21 The Overview of four Sprints completed by the FI-CA team Source: the data from my research (BQ6 - XYZJIRA, 2020)

Figure 21 portrays the gradual enhancement of the performance of the FI-CA team

within the frame of the Sprint. It means that the understanding of the PM techniques and

application of certain practices helped to achieve improved Product Backlog management,

which resulted in better delivery of the team. The positive trend can be noticed starting from

Sprint 2 when the team organized a Retrospective session to understand and contemplate what

could be enhanced for next iterations. However, the results of Sprint 3 demonstrates that the

team made an over-commitment, which could not deliver. Nevertheless, the failures and

experiments are encouraged by the company's corporate culture and existing agile environment.

In the next Sprint 4, the performance was gradually better as the Development Team managed

to deliver most of the committed Product Backlog Items.

To provide the holistic picture, table 6 comprises the main implemented changes for

each significant PM focus area together with key achieved milestones for each completed sprint.

Besides this, the author provides an approximate estimation of the total effort based on the

78

empirical data. In general, the table identifies key steps and activities taken by the FI-CA team

to improve existing PM practices. Each Sprint enabled specific processes, techniques and tools,

that addressed certain problems and blockers identified by the team. Gradual implementation

of Agile philosophy and Scrum methodology provided following benefits for the team:

1) enhanced ability to manage changing priorities, which means improvement of team's

adaptivity;

2) accelerated software delivery through the excellence of techniques and processes;

3) increased productivity and establishment of the team morale;

4) enhanced software quality and engineering culture of the team;

5) improved transparency of processes and rich communication within the FI-CA team.

Table 6 The overview of implemented changes and key milestones achieved

Sprint Key implemented changes in related focus areas Main milestones achieved

Total

effort

(hours)

Sprint

1

Process: setting up of the Sprint with prioritized

Product Backlog.

Communication: the establishment of an internal

knowledge base, namely Wiki, and derivation of

key focus areas.

Agile Techniques: 1) arrangement of the Planning

and Reviewing meetings with the planned timeline

and agenda coordinated by Scrum Master; 2)

practice of daily Stand-up meetings.

1. First attempt to arrange and split

the Product Backlog to deliver a

product to the customer;

2. Derivation and clarity of the

team scope;

3. Steady improvement of

communication within the team

members.

180

Sprint

2

Process: the practice of Retrospective meeting;

Communication: organizations of Demos with

recordings in the team repository; steady

enrichment of the knowledge base and lean

documentation;

1. Identification of key

impediments within the Sprint;

2. Better collaboration and

transparency of communication;

3. Understanding of such

practice as Demo;

170

Sprint

3

Techniques: 1) planned the Sprint with estimations

and identified goals; 2) Stand-up meetings with

visualized team dashboard (Jira).

Process: 1) integration of BCP system into the Jira

for integrity; 2) Split of Backlog Items to improve

the granularity of the Product Backlog;

Behaviors: conducted workshop to set up basic

foundations of the FI-CA Team as Scrum Team.

1. First more realistic input for

the analysis of team velocity;

2. Primary agreement on the

approach to Scrum (input for the

Team Manifesto);

3. Arranged and documented

process of the integration of

customer incidents (BCP) into Jira;

4. Activation of usage and better

engagement with Wiki.

200

Sprint 4

Techniques: the arrangement of the Refinement/Grooming session due to newly

emerged requirements.

Process: 1) simplification of the process of activity

recording for the team - shift to Bridge tool; 2)

enhancement of Wiki with the Lessons Learned

section.

Communication: Creation of the Standard for the

development and delivery of functionalities

including Done criteria.

1. Almost full delivery of assigned tasks by the end of Sprint;

2. Better actualization of the Jira

by the development team resulting

in improved team traceability;

3. Enablement of Measure

Objects into delivered

functionalities for better feedback

from a customer;

4. Improved team morale and

engineering discipline;

150

Source: the data from my research and author’s calculations

79

The overview of accomplished Sprints with identified total effort enables to provide the

cost estimate for future periods. As all the resources used are internal no cost was incurred, so

the author presents the cost analysis measured in an effort (hours) with no monetary recognition.

Important to highlight, that the given estimation has a short-term horizon, which means for the

following 2-3 months, due to the agility and fast-changing nature of the XYZ's environment.

Thus, table 7 specifies the average forecasted effort for each type of attribute depending on the

performed role in the FI-CA team.

In general, estimations provided in the table shows the average effort invested into various

PM methods, events, activities by each of the team members. The Scrum Master as the servant

leader responsible for coaching and leading the team is expected to be entirely dedicated to the

process of adaptation of the suitable approach for project handling. As a result, his full available

capacity, which is equal to 0.5 of full-time equivalent (FTE), should be utilized. The assumption

about the effort distribution for the Scrum Master is as follow: approximately 10 hours to be

spent on Scrum Events, namely daily standups, Sprint Planning and Review meetings,

Retrospective, Refinement/Grooming meeting if needed, plus an organizational setup of all

Scrum events; around 20 hours from the total capacity should be dedicated for workshops and

learning activities; and the rest, which is approximately 50 hours should be invested into lean

documentation and maintenance of the integrity through SharePoint connected with Jira and

Wiki.

Table 7 The cost forecast for the FI-CA team for future periods, monthly

FI-CA Team

Attribute

Scrum Master

/ 0,5FTE

Product

Owner / 1FTE

The Dev

Team /1FTE

Scrum Events, hours 10 8 8

Workshops, hours 10 10 8

Demos, hours 2 2 2

Documentation: SharePoint-Jira-Wiki, hours 50 30 6

Learnings & Training, hours 10 4 4

% from the Total Capacity (FTE) 100 % 33,75 % 17,5 % Source: based on the author’s calculations

Regarding the Product Owner, the analysis of four Sprints showed that the Product Owner

invests a significant part of the total capacity into the PM activities. Thus, the PO's effort

estimation amounts to around 34 % of the capacity (1 FTE) for upcoming periods. The vast

majority of effort is expected to be invested into documentation, particularly Jira, as the Product

Owner is responsible for the arrangement and prioritization of the Product Backlog. Concerning

learnings activities, the given time estimation is relatively low taking into consideration the

wide range of responsibilities of the Product Owner and limited capacity.

Concerning the development team, which consists of four developers and one quality

engineer/tester, the effort expectation is to be optimized to 17,5 % of the total capacity. Mainly,

the development team will be involved in certain Scrum Events, as well as prepare demos and

share expertise within the team. Besides this, the intense team's workload due to the priority of

the customers' needs places the estimation of time invested into learning on a relatively low

level for a few upcoming Sprints.

80

Thus, the FI-CA team has already achieved noticeable results in terms of adapting the

Scrum implementation method and tailoring PRINCE2 Agile PM methodology. Analysis of the

accomplished Sprints with the overview of key implemented areas and achieved milestones

served as the basis for the forecast in future periods. In the short-term framework, the

anticipated improvement of the PM practices for the FI-CA team will be focused on the

following activities:

1) Implementation of the User Story method and the pilot run for one of the FI-CA

projects for Belgium. It aims to address the quality problem and enable better customer

engagement;

2) Enhancement of the Team Manifesto, specifically focusing on the engineering culture;

3) Gradual integration and optimization of SharePoint-Jira-Wiki to achieve more

transparent and effective communication within the team.

81

Conclusion

The primary goal of the thesis is to examine PM processes of one of the company's

teams, analyze their current state and determine possible gaps and flaws which can be

potentially modified or improved by the implementation of the PRINCE2 Agile methodology.

To achieve the above-stated goal the author raised and focused on three main research questions

and answered each of them throughout the study.

The study was conducted as qualitative, empirical research, based on the case study of

XYZ company, operating in the industry of enterprise software. During the study, the author

had applied a wide range of methods and techniques for data collection and analysis, including

interviews, document reviews, observations, gap analysis and others.

The first research question regarding PM procedures, policies, processes, and

techniques used by the analyzed company was fully answered through the overview of

organization landscape, corporate culture, and in-depth analysis of the FI-CA team and their

approach to project handling. The paper described the transition of the XYZ and the

introduction of the transformation concept for development and delivery of their software

solutions. The new approach is based on the adoption of Agile mindset, ways of working and

its values and principles. Especially the organization launched a massive alteration to achieve

the next level of Agile as enablement for higher quality and productivity and as a prerequisite

for cloud delivery. Regarding the FI-CA team, the organization of the team is aligned to the

framework proposed by Scrum implementation methodology, as one of the key Agile

methodologies. Based on the overview of the teams' scope, the author identified and analyzed

the most common type of project - Legal Change, which requires the development and delivery

of the new functionality. The analysis of the LC process model is provided, describing three

key phases, namely setup phase, development and release. The author compiled the overview

of each stage of the process together with identified responsible roles and necessary

deliverables.

The second research question was addressed through the gap analysis of the practices

used by the FI-CA team comparing to the PRINCE2 Agile methodology. The application of the

Agile Health Check helped to identify key problems concerning behaviors, techniques, process

and environment, that could improve the delivery of high-quality software solutions in the

future. Briefly, the conducted analysis proved that the FI-CA team is below a high level of

competency with Agile practices, revealing opportunities for improvement of its agility through

the implementation of supportive practices and tailoring PRINCE2 methodology, where it

would be complementary with an existing agile environment.

Recommendations section addressed the findings of the research and summarized the

key ways how to tailor PRINCE2 PM methodology and its integrated elements to the existing

agile environment of the company together with the enhancement of the agility and adaptivity

of the FI-CA team. Firstly, the author introduced the main improvement of processes,

techniques, constant evolution of the environment, people's mindset and values attained by the

FI-CA team. Secondly, the paper summarized how PRINCE2 integrated elements of principles,

themes, processes can be tailored and embedded into the FI-CA's way of working and existing

agile environment with the presented enhancement of the LC process model. Besides, the

research demonstrated the analysis of the implemented changes together with the forecast of

82

the future changes, and a cost estimate measured in an effort based on the interim available

analytics.

In general, the conducted research has tested the formulated hypothesis that PRINCE2

methodology can be tailored to the project environment of the company and combined with

agile concepts, that positively affects existing procedures, policies, and processes, techniques

of one of the company's teams. The analysis of all PRINCE2 integrated elements and provided

suggestions for the FI-CA team has proved the research hypothesis.

To conclude, this thesis contributes not only to the academic field of project

management by overview and in-depth comparison of best PM practices but also brings new

knowledge and expertise to practitioners from the industry. Thus, the FI-CA team has already

significantly improved the existing practice of project handling through the implementation of

PRINCE2 Agile methodology. Due to the time limitation, the complete explanation of the

potential financial benefits, together with the potential risks and possible risk mitigation is out

of the scope of the thesis. Thus, further research could be dedicated to addressing the specified

areas.

83

Reference List

1. Accenture. (2019). Unleashing exponential revolution: 2019 ERP Trends. Retrieved from

Accenture Web site: https://www.accenture.com/_acnmedia/pdf-90/accenture-unleashing-exponential-

evolution-pdf.pdf

2. Algeo, C. (2008). PM as a Profession: are we there yet? PM Australia (PMOZ) Conference (pp.

1-12). Canberra: PM Australia Press.

3. APM. (2019). APM PM Body of Knowledge. UK: The Association for PM.

4. APM. (2019, October). Association for PM: About Us. Retrieved from Association for PM:

https://www.apm.org.uk/about-us/

5. Archibald, R. (1987). Key Milestones in the Early PERT/CPM/PDM Days. PM Journal, 29-31.

6. AXELOS. (2015). PRINCE2 Agile® Guidance. Norwich: The Stationery Office.

7. AXELOS. (2017). Managing Successful Projects with PRINCE2. Norwich: The Stationery

Office.

8. AXELOS. (2018). PRINCE2 Agile. Norwic: The Stationery Office.

9. AXELOS. (2019). What is PRINCE2®? Retrieved from AXELOS Global Best Practice:

https://www.axelos.com/best-practice-solutions/prince2

10. Bechtel, Jr., S. (1989). PM - Yesterday, Today, and Tomorrow. PMNETwork, 6-8.

11. Beck, K., et al. (2001). The Agile Manifesto. Retrieved from Agile Alliance:

https://agilemanifesto.org/

12. Berg, B., & Mutchnick, R. (1996). Research Methods for the Social Sciences: Practice and

Applications. Boston: Allyn and Bacon.

13. Bernardino, R. (2016). The use of Software Enterprise and Development in the Organization.

HOAQ -teknologi informasi, 35-43. Retrieved from

https://www.researchgate.net/publication/293331682_The_use_of_Software_Enterprise_and_Develop

ment_in_the_Organization

14. Blueprint. (2020). Agile methodologies. Retrieved from Blueprint Web site:

https://www.blueprintsys.com/agile-development-101/agile-methodologies

15. BQ6 - XYZJIRA. (2020, April). Reports. Retrieved from XYZ Jira:

https://xyzjira.wdf.xyz.corp/secure/RapidBoard.jxyz?rapidView=19631&projectKey=GSFINCEEBQ6

&view=planning.nodetail&epics=visible

16. Bredillet, C. (2013). Exploring Research in PM: Nine Schools of PM Research. PM Journal,

39-60.

17. Briggs, B., Henry, N., & Main, A. (2020). Tech Trends 2019: Beyond the digital fronties.

Deloitte Insights. Retrieved from

https://www2.deloitte.com/content/dam/Deloitte/br/Documents/technology/DI_TechTrends2019.pdf

18. Charvat, J. (2003). PM Methodologies: Selecting, Implementing, and Supporting

Methodologies and Processes for Projects. Hoboken, NJ: John Wiley & Sons, Inc.

19. Chin, C., & Spowage, A. (2010). Defining and classifying PM methodologies. PM World

Today, 1-9.

20. Chin, C., Yap, E., & Spowage, A. (2010, November). Reviewing Leading PM Practices. PM

World Today, pp. 40-59.

21. Clayton, M. (2019, July). APM Body of Knowledge: What is it, Do You Need it? Retrieved

from Online PM courses: Build your PM career: https://onlinepmcourses.com/apm-body-of-knowledge-

7th-edition/

22. Cleland, D., & King, W. (1968). Systems Analysis and PM. New York: McGraw-Hill.

23. Cockburn, A. (2000). Selecting a Project's Methodology. IEEE Software, 64-71.

84

24. CollabNet. (2018). What Is Agile Methodology? Retrieved from CollabNet:

https://resources.collab.net/agile-101/agile-methodologies

25. CollabNet VersionOne. (2019). 13th State of Agile Report. Retrieved from

https://www.stateofagile.com/#ufh-i-521251909-13th-annual-state-of-agile-report/473508

26. Cprime. (2019). What is Agile? What is Scrum? Retrieved from Cprime:

https://www.cprime.com/resources/what-is-agile-what-is-scrum/

27. Demianchuk, L. (2020). FIN APO Area Team CZ2. Retrieved from WIKI Employee Network:

https://wiki.wdf.xyz.corp/wiki/x/fKCwc

28. Editorial Team: APM. (2019, October). APM Body of Knowledge 7th edition An evolving

structure: Progress report. Retrieved from APM: https://www.apm.org.uk/media/24069/bok7-whats-

changed-akt11950-with-links.pdf

29. FI-CA Team. (2020, March). Scrum: FI-CA Experience. Retrieved from Wiki Employee

Network: https://wiki.wdf.xyz.corp/wiki/x/PqGdgww

30. Flora, H., & Chande, S. (2014). A Systematic Study on Agile Software Development

Methodologies and Practices. International Journal of Computer Science and Information Technologies,

3623-3637.

31. Forbes. (2020, February). The World’s Largest Public Companies in 2019. Retrieved from

Forbes: https://www.forbes.com/global2000/list/#industry:Software%20%26%20Programming

32. Fowler, M., & Highsmith, J. (2001, August 8). The Agile Manifesto. Software Development

9, pp. 28-32.

33. Gane, C. (2001). Process Management: Integrating PM and Development. Boca Raton, FL:

Auerbach Publications.

34. Gerrish, K., & Lacey, A. (2010). The Research Process in Nursing. Nottingham: John Wiley

& Sons.

35. Gibson, N. (2003, January). A Step-by-Step Guite to Qualitative Data Analysis. A Journal of

Aboriginal and Indigenous Community Health, pp. 64-90.

36. Głodziński, E., & Marciniak, S. (2018, June 2). Between Practice and Academic Study:

Competitiveness and Complementary Character of PM Research. Przedsiębiorczość I Zarządzani , pp.

149-163.

37. Gnanasambandam, C., Harrysson, M., Srivastava, S., & Srivathsan, V. (2018, November). The

product management talent dilemma. Retrieved from McKinsey&Company Web site:

https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/the-

product-management-talent-dilemma

38. Gnanasambandam, C., Mangla, R., & Shah, J. (2018, February). Reimagining software

services for the cloud and the digital world. Retrieved from McKinsey & Company Web site:

https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-

insights/reimagining-software-services-for-the-cloud-and-the-digital-world

39. GP Bullhound. (2019, November). Enterprise Software: Revolutionising the Modern

Workplace. Retrieved from GP Bullhound LLP Web site: http://www.gpbullhound.com/wp-

content/uploads/2016/11/GP-Bullhound-Research-Enterprise-Software-2016.pdf

40. Gulla, J. A. (2004, April). Introduction to Enterprise Systems. Trondheim, Norway. Retrieved

from https://www.idi.ntnu.no/emner/tdt4175/pdfs/ERPIntro.pdf

41. Haworth, S. (2019, November 10). The Agile Manifesto And How To Really Apply It To Your

Projects. Retrieved from The Dogital PM: https://thedigitalprojectmanager.com/agile-manifesto/

42. Hodge, B. (2017, February 7). How to tailor PRINCE2. Retrieved from Project News Today:

http://projectnewstoday.com/how-to-tailor-prince2/

43. Hron, M. (2018). Scrum in practice: an overview of Scrum adaptations. Hawaii International

Conference on System Sciences, (pp. 5445-5454). Hawaii. Retrieved from

85

https://www.researchgate.net/publication/323379652_Scrum_in_Practice_an_Overview_of_Scrum_A

daptations

44. Hrůzová, H., & Hodžić, M. (2018). A Study of PM Practices in the Czech Republic. Journal

of Entrepreneurship, Management and Innovation, pp. 7-34.

45. Igwenagu, C. (2016). Fundamentals of research methodology and data collection. Saarbrücken:

LAP Lambert Academic Publishing.

46. Introna, L., & Whitley, E. (1997). Against methodism: Exploring the limits of the method.

Information technology & People, 31-45.

47. IPMA. (2015). IPMA "Individual Competence Baseline" Version 4.0. Netherland:

International PM Association.

48. IPMA. (2019). About IPMA International. Retrieved from IPMA: International PM

Association: https://www.ipma.world/about-us/ipma-international/

49. Jennings, M. (2015). Gap analysis: concepts, methods, and recent results. Landscape Ecology,

5-20.

50. Johnson, S. (2002). The Secret of Apollo: Systems Management in American and European

Space Programs. Baltimore: The Johns Hopkins University Press.

51. Jovanovic, P. (2017). PM development - contemporary tendencies and methodologies. PM

Journal, 49-72.

52. Karthick, K. (2013, February). SAP Implementation Using Agile Methodology. Retrieved

from Hexaware: https://hexaware.com/blogs/sap-implementation-using-agile-methodology/

53. Kawulich, B. (2005, May). Participant Observation as a Data Collection Method. Retrieved

from Forum: Qualitative Social Research: http://www.qualitative-

research.net/index.php/fqs/article/view/466/996

54. Kelley, J., & Walker, M. (1989). The Origins of CPM: A Personal History. PMNETwork, 7-

22.

55. Kerzner, H. (1992). New York: Van Nostrand Reinhold.

56. Kerzner, H. (2001). Strategic Planning for PM using PM Maturity Model. New York, NY:

John Wiley & Sons.

57. Kerzner, H. (2005). PM: a systems approach to planning, scheduling, and controlling.

Hoboken, New Jersey: John Wiley & Sons, Inc.

58. Kilboy, L. (2018, April). The Flower Theory of Persuasion. Retrieved from XYZ Media Share

Employee Network: https://video.xyz.com/media/t/1_v7ohvej5

59. Klein, C. (2020, February). Integration in the Cloud: XYZ’s Way Forward. Retrieved from

XYZ Corporate Portal: https://blogs.wdf.xyz.corp/xyznews_en/2020/02/integration-in-the-cloud-xyzs-

way-forward/

60. Lepadatu, L. (2010, January). PM – the contrast between. E u r o E c o n o m I c a, pp. 79-89.

61. Lock, D. (2013). PM. Farnham, England: Gower Publishing Limited.

62. Market Research Future. (2020, March). Enterprise Software Market Research Report- Global

Forecast 2023. Retrieved from Market Research Future Web site:

https://www.marketresearchfuture.com/reports/enterprise-software-market-2442

63. McKinsey & Company. (2019). Enterprise software: An industry in transformation. Retrieved

from McKinsey & Company web site: https://www.mckinsey.com/industries/technology-media-and-

telecommunications/our-insights/enterprise-software-an-industry-in-transformation

64. Mishra, S., & Alok, S. (2018). Handbook of Research Methodology: A Compendium for

Scholars & Researchers. In S. B. Mishra, & S. Alok, Handbook of Research Methodology: A

Compendium for Scholars & Researchers (pp. 1-17). India: EDUCATION PUBLISHING.

65. Morris, P. (2011). A Brief History of PM. Oxford: Oxford University Press.

86

66. Nelson, K., & Ghods, M. (1998). Measuring the effectiveness of a structured methodology: a

comparative analysis. The Thirty-First Hawaii International Conference on System Sciences (pp. 492-

499). Kohala Coast: HI.

67. PMI. (2017). A Guide to the PM Body of Knowledge (PMBOK Guide): Sixth edition.

Newtown Square: PE: PM Institute.

68. PMI. (2019, October). PM Institute: Membership. Retrieved from PM Institute web site:

https://www.pmi.org

69. PM Institute. (2019). PMI Standards Development. Retrieved from PM Institute:

https://www.pmi.org/pmbok-guide-standards/about/development

70. QinetiQ. (2019, May 8). QinetiQ Fellow contributes to the Association for PM Body of

Knowledge (APMBoK) 7th edition. Retrieved from QinetiQ - Global Defence and Security Company:

https://www.qinetiq.com/blogs/2019/05/qinetiq-fellow-contributes-to-the-association-for-project-

management-body-of-knowledge-apmbok-7th-edition

71. Rankins, G. (2013). Comparing PMBoK and PRINCE2 in 2013. Retrieved from Inspiring

Projects: http://www.inspiringprojects.com.au/docs/comparing-pmbok-and-prince2-in-2013.pdf

72. Raziq, M. (2006). PM and PRINCE2 methodology. School of Management, 60-75.

73. Rehacek, P. (2017). Application and Usage of the Standards for PM and their Comparison.

Journal of Engineering and Applied Sciences, 994-1002.

74. Rodrigo, Silva. (2020, March). GS Engineering Excellence. Retrieved from XYZ: SharePoint:

https://xyz.sharepoint.com/sites/121327/SitePages/Team-Health-

Check.aspx?csf=1&e=UK7oBu&cid=56bf2e20-40bb-4920-a514-88e62c6e4c5e

75. Sargeant, R., Hatcher, C., Trigunarsyah, B., Coffey, V., & Kraatz, J. (2010). Creating value in

PM using PRINCE2. London: Office of Government Commerce. Retrieved from

https://eprints.qut.edu.au/52853/1/Final_Report__v1.0e%5B1%5D.pdf

76. Schwaber, K., & Sutherland, J. (2017, November). The definitive guide to Scrum. Retrieved

from ScrumGuides: www.scrumguides.org

77. SelectHub. (2020). Top ERP Software Comparison List. Retrieved from SelectHub Web site:

https://www.selecthub.com/erp-software/

78. Shanhong, L. (2020, January 15). Information technology (IT) spending on Enterprise software

total worldwide expenditure 2009-2021. Retrieved from Statista.com:

https://www.statista.com/statistics/203428/total-enterprise-software-revenue-forecast/

79. Shenhar, A., & Dvir, D. (2004, July 14). PM evolution: past history and future research

directions. Retrieved from PM Institute: https://www.pmi.org/learning/library/project-management-

evolution-research-directions-8348

80. Sönmez, S. (2018). "11 Steps" Process as A Research Method. Universal Journal of

Educational Research 6 (11), pp. 2597-2603.

81. Standish Group. (2010). Chaos summary for 2010. Technical report. Boston: MA: Author.

82. Starman, A. (2013, January). The case study as a type of qualitative research. Journal of

Contemporary Educational Studies, pp. 28-43.

83. Statista Research Department. (2020, March). Projected yearly growth in information

technology (IT) spending worldwide from 2016 to 2021, by segment. Retrieved from Statista Web site:

https://www.statista.com/statistics/268940/percent-growth-in-it-spending-worldwide-by-segment/

84. Stretton, A. (2007, October). A Short History of Modern PM. PM World Today, pp. 1-18.

85. Turner, J. A. (2013). Perspectives on research in PM: the nine schools. Global Business

Perspective, 3-28.

86. Verzuh, E. (1999). The Fast Forward MBA in PM. New York: John Wiley & Sons, Inc.

87. Wells, H. (2012, December). PM Journal, 43-58.

88. Wells, H. (2012, December). How effective are PM methodologies?: An explorative evaluation

of their benefits in practice. PM Journal, pp. 43-58.

87

89. Wiseman, L. (2019). Multipliers: How the Best Leaders Make Everyone Smarter. Moscow:

Alpina Publisher.

90. Wysocki, R. (2013). Effective PM: Traditional, Agile, Extreme, Hybrid. New York: John

Wiley & Sons.

91. XYZ. (2017). Agile Software Engineering. Retrieved from XYZEDIA Employee Network:

https://xyzedia.int.xyz/wiki/Agile_Software_Engineering

92. XYZ. (2017, January). XYZ Corporate Taxonomy. Retrieved from Wiki Employee Network:

https://wiki.wdf.xyz.corp/wiki/x/jJmLMQ

93. XYZ. (2018, September). Quality talk: The Agile Journey at LoB Finance and how to ensure

high-quality software. Retrieved from Media Share Employee Network:

https://video.xyz.com/media/t/1_wk90c6jv

94. XYZ. (2019). How We Run. Retrieved from XYZ JAM:

https://jam4.xyzjam.com/groups/NRiyeS3ovvrz3cFFmRK5Cl/overview_page/iLMTRp5t4Bs0PIUhcU

XJqj

95. XYZ. (2019). Intelligent Enterprise Group. Retrieved from XYZEDIA Employee Network:

https://xyzedia.int.xyz/wiki/Intelligent_Enterprise_Group

96. XYZ. (2019). The Tools Team. Retrieved from XYZ Jam:

https://jam4.xyzjam.com/groups/uH5dGdf6wJ0S9zC44tHNKb/overview_page/sjreR3I7JAGXKJ6YX

Yg13W

97. XYZ. (2020). 2019 XYZ Annual Report on Form 20-F. Walldorf: XYZ. Retrieved from

https://www.xyz.com/docs/download/investors/2019/xyz-2019-annual-report-form-20f.pdf

98. XYZ. (2020). Global News. Retrieved from XYZ Corporate Portal:

https://portal.wdf.xyz.corp/home

99. XYZ. (2020, March). How do we: Requirement Management Guide. Retrieved from WIKI

Employee Network: https://wiki.wdf.xyz.corp/wiki/x/yZ8Ka

100. XYZ. (2020). Newcomer's Tutorial. Retrieved from WIKI Employee Network:

https://wiki.wdf.xyz.corp/wiki/x/byc4hQ

101. XYZ. (2020). Our Purpose. Retrieved from XYZ Corporation Web site:

https://www.xyz.com/corporate/en/purpose.html

102. XYZ. (2020). XYZ SE Corporate Governance. Retrieved from XYZ Corporation Web site:

https://www.xyz.com/investors/en/governance.html

103. XYZ Labs. (2018). About Us. Retrieved from XYZ Labs Offical Web site:

https://xyz.jobs.cz/about-us/

104. XYZ SE. (2020, February). XYZ Annual Report 2019 on Form 20-F. Retrieved from XYZ SE

Web site: https://www.xyz.com/docs/download/investors/2019/xyz-2019-annual-report-form-20f.pdf

105. Yanjuan, Y. (2019, April 8). Ruth Murray-Webster: Future of PM Will Be Exciting, Varied

and Fast-faced. Retrieved from PM Review:

http://www.pmreview.com.cn/english/Home/article/detail/id/361.html

88

Glossary

APM Association of Project Management

APMBoK APM Body of Knowledge

APO Area Product Owner

BI Business Intelligence

CCPM Critical Chain Project Management

CCTA Central Computer and Telecommunications Agency

CPM Critical Path Method

CRM Customer Relationship Management

ERP Enterprise Resource Planning

ESA Ethics, Standards and Accreditation project

IPMA International Project Management Association

LC Legal Change

LCC Life Cycle Costing

LPM Local Product Manager

MRD Market Requirement Document

MVP Minimum Viable Product

PDM Precedence Diagramming Method

PERT Project Evaluation Review Technique

PM Project Management

PMBoK Project Management Body of Knowledge

PMI Project Management Institute

PO Product Owner

SCM Supply Chain Management

SM Scrum Master

89

List of figures and tables

Figure 1 The correlation between management evolution and innovations.......................................... 11

Figure 2 The evolution of modern PM from the 1950s to today............................................................ 13

Figure 3 The life of a PRINCE2 project ................................................................................................ 32

Figure 4 The Flow chart of the research process .................................................................................. 37

Figure 5 Enterprise software total global expenditure 2009-2021 ....................................................... 42

Figure 6 The segmentation of the enterprise software industry in 2018 ............................................... 43

Figure 7 The Intelligent Enterprise Framework.................................................................................... 46

Figure 8 Corporate Governance Structure ........................................................................................... 49

Figure 9 "How We Run": set of core values .......................................................................................... 50

Figure 10 FI-CA Team: organizational structure ................................................................................. 52

Figure 11 Company’s development and delivery concept ..................................................................... 54

Figure 12 Legal Change Process Overview .......................................................................................... 56

Figure 13 LC Requirement management process.................................................................................. 57

Figure 14 Results of the PRINCE2 Agile Health Check for the FI-CA team ........................................ 61

Figure 15 Results of the Agile Health Check for the FI-CA team ......................................................... 67

Figure 16 FI-CA and XYZ’s maturity levels according to P3M3 Maturity Model................................ 68

Figure 17 Tailoring PRINCE2 by blending in the agile ingredients ..................................................... 69

Figure 18 The results of Team Health Check: FI-CA Team.................................................................. 72

Figure 19 The visualization of the FI-CA Scrum Process ..................................................................... 75

Figure 20 The Enhancement of Legal Change Process Model ............................................................. 78

Figure 21 The Overview of four Sprints completed by the FI-CA team ................................................ 79

Table 1 Result of Gap Analysis between PM methodologies................................................................. 29

Table 2 Company's Results, 2015-2019 ................................................................................................. 47

Table 3 Scope of the FI-CA team ........................................................................................................... 54

Table 4 Overview of the company’s toolkit ........................................................................................... 58

Table 5 The application of the flower theory of persuasion with the FI-CA team ................................ 71

Table 6 The overview of implemented changes and key milestones achieved ....................................... 80

Table 7 The cost forecast for the FI-CA team for future periods, monthly ........................................... 81

90

Appendices Appendix A

Methodology

Attribute PMI Methodology

PRINCE2

Methodology

APM

Methodology

IPMA

Methodology

Foundational

Standards The Project

Management Body of

Knowledge (PMBoK):

The first standard

guidebook, named

PMBoK, was introduced

in 1987, with few further

updated versions. As

PMI BoK and other

global standards

continually and

accurately reflect the

evolving profession, the

latest enhancement, its

sixth edition, was

released in 2017.

Managing

Successful Projects

with PRINCE2:

PRINCE2 was

originally based on

PROMPT, which

was created in 1975

and used by the UK

for its IS projects.

PRINCE2 was

finally published in

1996 with a few

following

enhancements. The

latest sixth edition

of manual

“Managing

Successful Projects

with PRINCE2”,

published in 2017,

provides the

definitive

explanation of

PRINCE2.

The APM Body of

Knowledge

(APMBoK):

APM methodology

is presented in the

handbook, called

APMBoK. The first

release in 1988, the

latest 7th edition of

the BoK from 2019,

which was “set to

address the

increasingly

volatile, complex

and unpredictable

world we live in

today”.

The IPMA

Individual

Competence

Baseline (IPMA

ICB):

The IPMA

developed an

IPMA ICB in

1999. The latest

edition, namely

the ICB Version

4.0, was released

in 2015. It is

developed upon

the prior editions

and gives the new

insights together

with a redefinition

of the competence

elements (CEs).

Nature of

methodologies

and its

standards

Prescriptive, knowledge-

oriented nature: “PMI

defines PMBoK as a

term that describes the

knowledge within the

profession of project

management…PMBoK

Guide identifies a subset

of the project

management body of

knowledge that is

generally recognized as

good practice.”

Descriptive,

process-oriented

nature: “PRINCE2

has been designed

to be generic so that

it can be applied to

any project

regardless of

project scale, type,

organization,

geography or

culture….focusing

on describing what

needs to be done,

rather than

prescribing how

everything is

done”.

It is a pragmatic

approach to project

management. As

APM claims “APM

chooses not to

describe ‘how-to’ in

terms of methods,

tools,

and techniques in

the APMBoK but

rather uses it as a

foundational

knowledge resource,

and a pointer to

other sources of

information”.

APMBoK is a scope

statement for the

profession and a

sourcebook for all

aspiring, new, and

experienced project

professionals

offering common

definitions,

references, and a

comprehensive

glossary of terms.

Type of generic

recommendation

and guidance:

“the IPMA ICB is

not a “how to”

guide or a

cookbook for

managing

projects,

programmes, or

portfolios...

While it offers

more in

competence

development of

individuals

involved in

projects,

programmes, and

portfolio

management, it

can be used

alongside other

global process-

oriented

standards.”.

ICB serves more

as a managerial

model to evaluate

project

management

competence.

91

Individual

competence

viewed as the

application of

knowledge, skills,

and abilities to

achieve the

desired results.

Structure of

foundational

standards,

including main

recognized

components

The first part addresses

key knowledge areas

(10 in total), and the

second part, the

standard for PM,

elaborates on 5 process

groups with 49

processes.

The ten Knowledge

Areas are part of the

PMBOK Guide and all

are present in every

project management life

cycle (PMLC). They

define the processes

within each Process

Group and often are part

of more than one Process

Group. This section

covers all ten

Knowledge Areas.

The five process groups

are initiating, planning,

executing, monitoring &

controlling, and closing

process group, which are

simply groupings of

processes by project

phases. These Process

Groups are the building

blocks of every PMLC.

A specific PMLC is

defined using these

processes.

The method

addresses project

management with 4

integrated

elements, namely

themes, principles,

processes and the

project

environment. There

are 7 principles, 7

themes, 7 processes

with recommended

activities, products

and related

responsibilities and

the existing project

environment.

Principles are

viewed as guiding

obligations and

good practices that

identify whether

the project is

genuinely being

managed using

PRINCE2. The

following element,

named themes,

describes the

business case,

organization,

quality, plans, risk,

change and

progress as aspects

of project

management that

must be addressed

continually and in

parallel throughout

the project. The

processes show the

progression from

the pre-project

activity of getting

started, through the

stages of the project

lifecycle, to the

final act of project

closure. The last

element, the project

environment,

addresses the desire

of organizations to

have a consistent

The APM Body of

Knowledge is

structured into 4

chapters, each of

which has three main

sections. Each

section has between

5 and 10 Topics –

there are 80 in total.

The first chapter

“Setting up for

Success” places

projects in context

and is written

primarily for those

leaders in

organizations who

have decisions to

make about the role

of projects,

programmes and

portfolios in

implementing a

strategy. The next

chapter “Preparing

for change”

addresses a

collection of topics

that can be seen as

the points of

interface with the

organization

investing. Following

chapter “People and

behaviors” is written

primarily for those

leaders in

organizations who

need to build and

lead teams to shape

and deliver projects,

programmes and

portfolios. The last

chapter “Planning

and Managing

Deployment” is

written primarily for

project managers

and their teams. This

chapter is focused on

projects – which

may be managed as

standalone

initiatives, or as part

Competence in

the project

environment is

broken down into

29 competence

elements, which

are grouped into

perspective

competencies (5

elements); people

competencies (10

elements); and the

practice

competencies (14

elements).

Thus, ICB

contains three

areas of

competence that

form the IPMA

Eye of

Competence,

which is the ICB

appropriate

symbol. These

areas apply

equally to all

three domains,

namely project,

programme and

portfolio

management.

IPMA recognizes

competence as a

function of the

individual, the

team and the

organization.

However, the

primary focus of

the baseline is the

individual.

Each competence

element includes

a title, a

description of the

content, a list of

possible process

steps and

experience

criteria required

per level.

92

approach to

managing projects,

which can be done

through tailoring

PRINCE2 to create

their own project

management

method.

of wider

programmes and

portfolios.

Definition of

project

The project is a

temporary endeavor

undertaken to create a

unique product, service,

or result.

The project is a

management

environment

created to deliver

one or more

business products

according to a

specified business

case.

The project is a

unique, transient

endeavor undertaken

to achieve planned

objectives, which

could be defined in

terms of outputs,

outcomes or

benefits. Projects

bring about change

and project

management is

recognized as the

most efficient way of

managing such

change.

The project is a

unique,

temporary, multi-

disciplinary and

organized

endeavor to

realize agreed

deliverables

within predefined

requirements and

constraints.

Roles and

Responsibilities

The PMBoK identifies

three main roles: the

project manager, the

sponsor and the PMO.

The project manager’s

role is specified in great

detail in the knowledge

areas and the process

model, the PMO’s in an

abbreviated manner and

the sponsor’s only in a

cursory manner.

PRINCE2

identifies four main

roles and several

optional roles. The

main roles are the

Project Executive,

supported on the

Project Board by

Senior User(s) and

Senior Supplier(s),

and the project

manager. The

responsibilities of

these main roles are

specified in

detailed role

descriptions and are

elaborated at

relevant points in

the process model.

Other roles include

assurance roles

supporting the

Project Board,

project support (a

project office

function), team

managers, and an

optional change

authority.

The APMBoK

identifies Project

Steering Group,

Project Sponsor,

Project Manager,

Team Members,

Users (Customers)

and Project Office.

Section ‘1.1

Governance’ states

that good

governance can be

demonstrated

through

“establishing clearly

defined roles,

responsibilities and

performance criteria

for governance”.

Comparing to

other

methodologies,

the only explicit

role, that is

mentioned in ICB

is project

manager, all the

rest is optional.

The project

manager needs to

continually

develop the team

and its members,

from an initial

phase of team

building to a team

working

throughout the

life of the project,

to the conclusion

of the project,

when team

members are

released to return

to their

organizational

units.

Source: compiled by author based on (APM, 2019), (AXELOS, 2018), (Bechtel, Jr., 1989), (Clayton, 2019), (Charvat, 2003), (IPMA, 2015),

(Jovanovic, 2017), (Kerzner, 2005), (PMI, 2017), (Stretton, 2007).

93

Appendix B

Agile Manifesto

Source: retrieved for (Beck, K., et al., 2001)

94

Appendix C

Interview with Program Manager (PMn)

PMn: Localization of Legal Change. Let’s overview the process of new software solution for one

country that is triggered by legal change. Normally, it starts with the country, from LPM, which is a

local product manager. They are our “front line”, those that are in contact with the field, by which we

mean either legal authorities, company, organization, government, etc. Also, another focal point for the

field is sales guys, those who know the demand, the business case and the latest situation from the legal

point of view.

Lilia: Who approaches whom in this case? And how communication is organized?

PMn: Usually, authorities or other representatives from the “field” contact SAP, but together with this

our guys already have the networks with all the contacts, so it is not strictly one-way communication. It

may vary from case to case.

Lilia: So, what are their main responsibilities of such LPM and sales guys?

PMn: They should collect enough info to be able to analyze if it is really the legal change or some type

of customer-specific requirements. For instance, if it is investigated that the trigger is an internal upgrade

or customer-driven modification, we will not roll it out, as our specialization is solutions that are

triggered by legal changes. That means that the requirement is the same on the level of industry, country

or state, the scale may vary. Thus, LPMs collect and filter requirements and should address them to the

development.

Lilia: How is it documented? Which approaches are used? Tools?

PMn: The documentation of requirements may be presented differently, usually it depends on

complexity. For bigger and more complex LCs, we may use some type of template how requirements

and to which level of details it should be provided. After this, the communication is organized with the

development team through Jira.

Lilia: So, Jira enables us to run the project and deliver the solution to the field?

PMn: Yes, there are a few steps, I will share also relevant “best practices” which we have inside the

company. Briefly, the first step is the responsibility of LPM to create the country backlog item with all

the important info filled in, which is assigned to APM. In our case, it’s Tomas, the area product manager

for Czechia.

Lilia: For LPMs we have some descriptive methodologies on how the evaluation of the business case

should be done, or some other approach is used?

PMn: From my experience, every LPM works differently, they have their ways or practices. There is no

standardized approach. Also, a lot is done with external help, type of third parties, namely legal advisor,

etc. But a lot is available through our corporate knowledge platforms. For example, as I mentioned “best

practices” or expertise from previous projects. For us, a lot also depends on the country, as we work

with globalization services, which are delivered locally.

Lilia: What type of details are added to the CBI?

PMn: The vital is RDD, which stands for the required delivery date. So, for example for the Q-Bill, we

have the delivery by the end of June, and it is the goal to deliver by that time. And of course, after the

development team is aware of the RDD, they can prioritize it properly in the current team backlog chosen

for the current sprint. Together with RDD, LPM should give a detailed description of the LC, plus such

parameters as Module, Classification, Product, Affected Objects, and other technical moments. On the

level of LPM, this person appears as “reporter” and APO as “assignee”. Then there is the tab for APO

95

which uses all the info from LPM as the input for further processing. APO must identify the delivery

way (usually SAP Note), measure Risk Impact and Implementation Effort.

Lilia: Okay, so this is the piece of information that is passed to the PO of the team, yes?

PMn: Yes, it is right, once the country backlog item is created by LPM and processed by AOP, it goes

to the Product Owner. He is responsible to create the corresponding epic, which is recognized as the

child of the CBI. This is the way how the requirement reaches the development team. Then it is the

responsibility of PO independently, or cooperation with the team to break it down to proper tasks, that

are prioritized and assigned to the assignee. Then as a Scrum Master you know all the further details.

Lilia: Yes, true, then we do estimates and make sure that Jira is up-to-date and we follow established

workflow, even though we are in progress with figuring it out. A lot is resolved with the help of Scrum

methodology, particularly organized scrum ceremonies, such as Daily Stand-ups, Planning and Review

sessions, plus sometimes grooming.

PMn: Exactly, so this is the overview of one type of project that we run, Legal Change, for Cloud. Also,

it is relevant to know if this is the Cloud or On-Premise solution, as they have bit different approaches

on the Program Level.

Lilia: Could you please elaborate on this?

PMn: Yes, I will also provide you the link to the Cloud Program, that shows the generic timeline and

deliveries, plus the main milestones for each quarter release. Also, it gives a summary of weekly or bi-

weekly meetings that are organized to track the progress and emphasize on main upcoming milestones.

Lilia: Okay, so this is the generic level of the programs with Cloud releases. What about controlling

process, how it is done?

PMn: You just have to look at Jira from another perspective. This is exactly the way how APO can

direct projects and manage them by exceptions. At the same time, LPM and field can control APO. So,

this is very useful. Another important tool used is cPro. This is the tool used by APO to estimate and

measure effort and have the review of teams to be able to control all the teams and projects that belong

to one area and one module.

Lilia: Okay, in case of Tomas it means that cPro enables him to track the progress of 4 teams and also

get more insights with the latest updates through the team’s Jira dashboards. Am I right?

PMn: Yes, this is correct.

96

Appendix D

Results of Agile Health Check

Behavior 50%

Environment 28%

Process 57%

Techniques 20%

Behaviors dimension:

1 Collaboration, trust and a no-blame culture exist 1

It meets corporate values "tell it like it is" and "build bridges, not silos". In general, the team's members comply with this behavior.

2

Self-organization is predominant and is supported by the project management team. 1

The backlog items are divided and then the team works based on their preferences with no micro-management and prescriptive work packages.

3 There is a culture of inspect and adapt and continual improvement. 0

It significantly varies across the company, the FI-CA team is less adaptive and more resistant in its nature.

4 Transparency prevails. 0

Most significant aspects of the process are not defined by a common standard so observers can not share a common understanding of what is being seen.

5 Teams are regularly talking about the delivery of value and benefits. 0 It is not articulated and discussed by the team.

6 There is an attitude of keeping things simple. 1

Team rather maximizes the amount of work they do, then tries to maximize the outcome of the done.

7 All stakeholders impacted by the project are being kept up to date. 0

Communication with front-line, LPM or customer, is rare and not effective.

8

The project board is frequently interacting with the people involved on the project. 1

The Area Product Manager and Product Owner as prototypes of Executive and main Supplier, actively involved in the project with frequent interactions.

9 Planning and work assignment are being carried out collaboratively. 1

Planning of Sprint and backlog is done collaboratively during the Sprint Planning, although very time-inefficiently.

10 The Pastor of Fun is well-organized. 0 The Pastor of Fun has not existed at all in the team.

97

Environment Dimension:

11 People are happy and work is enjoyable. 0

Due to poorly adapted agile, the team feels overwhelmed. In particular, the PO has significant overtime.

12 The team is stable, ring-fenced and working well together. 1

Team members used to work together and cooperate for a while, 6-7 years working for XYZ on average.

13 The project is responsive to change and is change-friendly. 0

Hard to accept and respond fast to changes. Example, LC for Switzerland.

14 The customer is involved and engaged at all levels. 0

Usually, the customer is involved actively during the roll-in stage, then they are not engaged much.

15

A blended view prevails that takes into account the diverse views of the customer on a project. 0

Mainly new functionalities/features are industry- or country-specific, and further configuration is done by customers.

16 The desired outcome and output are clear to everyone. 1

The requirements usually give a clear idea of the output, which is not the case of the outcome.

17

There is a thirst for feedback and a collective desire to find out what the customer really wants. 1

XYZ's transformation strategy emphasizes the customer-oriented approach, thus encourage and empowers teams to seek out for feedback.

18

Agile learnings are being moved around the organization (e.g. by project support). 0

Not much of agile learning is done, and Scrum as an implementation method is poorly performed due to lack of expertise.

19 Communication is very good and fast-moving. 0

"Build bridges, not silos" is the company's behavior, which is hard to follow. Team members are used to working in an isolated mood.

20 Control has a light touch and people are empowered. 0

Even though people are empowered, but the controlling function is too tight.

21 Musts really are musts. 1 Always core functionality is delivered on time and with high quality.

22

The project management team and the delivery teams are ‘understanding agile’ and not just ‘doing agile’. 0

The understanding of agile and its concept is partial. No sufficient training, workshops, knowledge sharing sessions done.

23 The overriding mindset of the people on the project is an agile one. 0

The bureaucratic type of mindset is still prevalent, as people do not understand the essence and the value of agile.

24

Frequent releases are happening that are ideally put into operational use (or a staging area if the live environment is not ready). 1

Monthly releases happen, and agile software engineering practices are applied.

25 The five targets of what to fix and what to flex are understood by all. 0

They are not introduced and understood by the team. The analysis of LC for Switzerland is explained.

26

Significant events become routine because they happen frequently (e.g. stage boundaries or release reviews). 0

Releases are frequent but planning and reviews are poorly performed. So, the team feels frustrated and perceives it as a waste of time.

98

27

All roles are clearly defined and understood (taking into account that the mapping of the agile roles to PRINCE2 is not necessarily straightforward). 0

Not fully, mainly the role of the Product Owner is explicit, although it includes way more than should be. Thus, the team is not compliant with the Scrum Guide and agile concept.

28 PRINCE2 is seen as agile. 0 The team is not familiar with PRINCE2 much.

Process Dimension:

29 Management by exception is working fully. 1

Team members are granted autonomy and empowerment. The company's approach is to allow tolerance on what is delivered and restrict the tolerance on time and cost.

30 The level of control is appropriate to the level of uncertainty. 1 Good risk management practice is arranged.

31

The work package interface is working well. It is smooth, is clear and does not lead to communication problems. 0

There is no unified standard of how work packages are maintained by team members. Thus, Jira is not effective properly and can not help to resolve the communication problem.

32

Requirements and user stories are explored and not just followed blindly. 0

Requirements are used without further exploration. User stories have not been practiced.

33

The way of working is typically iterative and incremental, and benefits are being delivered at several points throughout the project. 0

Even though the team works in Sprint, the committed work packages are not delivered and benefits are not realized usually.

34

There are clear definitions of ‘done’ and ‘ready’, and working agreements are transparent. 0

There is no agreement on "done" and "ready" which leads to miscommunication and poor performance of Sprints.

35 Planning and work are feature-focused and timeboxed. 1

Each backlog item reflects a particular feature or part of the development. Also "estimates" are added as attributes sometimes, although the correctness can be questioned.

36

The MVP is clear to everyone, and it is understood that its role on the project is to help with learning. 0

The team does not practice the delivery of MVP, as it is hard to do that with the type of functionalities. However, the functionality can be developed and after testing send back to be enhanced or recoded.

37

Quality checking and testing includes independent quality checking and testing. 1

The quality check and tests are done multiple times during each stage, the final one is done in the pilot mode by the customer.

38

Quality checking is happening continually and sometimes even drives the building of the products. 1

Quality checks and tests run continuously. In the case of Internally-Driven Continuous Innovation (ICI), quality is the main driver of change of the functionality or its architecture.

39

Planning is happening well in relation to all planning horizons (i.e. short term, medium term and long term) and with respect to the appropriate level of uncertainty. 0

Planning is done by the team based on monthly Sprints and quarter deliveries (Cloud/On-Premise) recognized as Versions in Jira.

99

40 A lot of planning is being done empirically. 1

The approach to planning is empirical and the velocity of the team is mostly known, although it has not been properly measured.

41 Early requirements are based at a level that avoids unnecessary detail. 1

The requirements address key features and conditions of the new functionality with no unnecessary and burdening details.

42 Project assurance is adding value from an agile perspective. 1

The PO represents the interests of the customer with a value-oriented approach. In terms of agile practices, the PO is the most experienced and resilient to agile.

Techniques Dimension:

43

Prioritization is happening continually, and timeboxes are not being extended or having people added to them. 1

Primarily the prioritization is done by PO. Once the backlog item is assigned, the estimate might change over time due to newly discovered attributes.

44 Information is very visible (e.g. on the walls) and is kept up to date. 0

The XYZ Jira, the company's backlog management tool, was poorly used by the team. The dashboard was not updated and actualized, also tasks were too generic without relevant description or insight.

45

When prioritizing, teams are looking at both scope and quality criteria. 0

Mainly the prioritization was based on the scope, not always quality criteria were met. Moreover, the team did not have an aligned approach to the "Done" criteria. It resulted in the poor deployment of the functionality. The case of Qr-Bill.

46 Acceptance criteria always exist and are well written. 0

Acceptance Criteria, which is referred to as the definition of "Ready" following the agile concept, are not articulated. Just the delivery scope is identified. Thus, there is no clear understanding when epic (a type of user story used by the team) can be viewed as completed.

47 Estimation is a team-based activity. 0

Estimates/story points were not used or too rough, thus the velocity and capacity of the team were unidentified.

48

Documentation is Lean, and the right channels are being used for each type of message. 0

Documentation flow was abrupt with a lot of gaps. The usage of SharePoint was done by Tester, which had its own structure and order. The rest of the team used to work in silos, so every time collection of information and the latest updates were time-consuming processes.

49 Demos take place frequently. 0 Demos used to happen from time to time, but not documented and stored properly.

50

Some risks are being mitigated by the use of spikes, prototypes and experiments. 0 No prototyping or experiments were spotted.

51 Burn charts are being widely used and progress is clear to see. 0

Burn charts are not used due to the absence of estimations and too generic approaches to the formulation of tasks. Thus the progress was hard to measure and track.

100

52

User stories are being used to stimulate conversation and communication. 0 User stories have not been used by the team.

53

When Kanban is used, a holistic approach is adopted, not just a Kanban board. 0

Scrum is used by the team, but the integral approach is not adopted. Only the dashboard was maintained with the "must to" approach, but no understanding of the real value being added.

54

Workshops are a regular occurrence and are being used appropriately. 0

Usually, workshops were not organized starting from project kick-offs and finishing with reviewing meetings.

55

Stand-ups are happening daily and are taking place quickly (i.e. lasting 15 minutes or less, perhaps 10). 0

Stand-ups used to take place in an old team, but team members were not willing to comply with the existing agile practice.

56

People understand terms such as ‘requirement’, ‘user story’, ‘feature’ and ‘epic’. 1

Team members are aware of such terminology as ‘requirement’, ‘user story’, ‘feature’ and ‘epic’ due to the Product Owner's effort.

57

Product descriptions have been written at the appropriate level and with flexibility with regard to quality criteria. 1

PO is responsible for and prepares a description of a functionality purpose, composition, derivation, and quality criteria. It is all briefly introduced in the created epic.

101

Appendix E

“XYZ Best Practice”: Team Health Check

Source: retrieved from (Rodrigo, Silva, 2020)