PRINCE2® and

DevOps, a successful
marriage or recipe for
divorce?
Henny Portman

White paper
November 2020
Contents
1
Introduction 03

2
The PRINCE2 governance structure 03

3
DevOps in a nutshell 05

4 A permanent DevOps team versus a temporary PRINCE2 delivery team 08

5 How to cope with DevOps teams from a PRINCE2 project manager 08

perspective

6 How to cope with the PRINCE2 governance from a DevOps team 09

perspective

7
Blending PRINCE2 and DevOps 11

8
Summary 11

9
About the author 12

10
Endnotes 13

11
About AXELOS 15

12
Trade marks and statements 15

02 PRINCE2® and DevOps, a successful marriage or recipe for divorce? AXELOS.COM

1 Introduction
More and more organizations are incorporating DevOps into their working practices in order to get more
done. With DevOps, a single team composed of collaborative, cross-functional members will:

z deliver features faster and continuously

z have more time to innovate
z enjoy a stable operating environment
z be happier and more engaged
z solve production issues faster.

In DevOps a business perspective1 the author Oleg Skrynnik provides the following definition for DevOps:

‘DevOps is an evolution of the ideas of agile software development and lean manufacturing,
applied to the end-to-end value chain in IT, which allows businesses to achieve more with
modern information technology due to cultural, organizational and technical changes.’

Does this mean that having a DevOps team is the silver bullet that would solve all your problems?

I wish it was, but life is not that easy. What if you need more than one DevOps team to develop the
solution? No problem, you can use scaling frameworks like Scaled Agile Framework (SAFe), Large-scale
Scrum (LeSS), Nexus, and many more. This will probably solve several of your collaboration or dependency
problems, but what if the initiative needs more than IT or product related changes? What if there are no
permanent (DevOps) teams who have the necessary skills to deliver what is needed? In that case, you will
probably need to implement a temporary project organization to combine the DevOps pieces with a project
manager, who manages the dependencies between teams and performs stakeholder management, budget
management, and so on.

In this white paper I will explore how PRINCE2®, Agile2, and DevOps can work together. I will start with
an explanation of the PRINCE2 governance structure, followed by a brief introduction of DevOps. Next,
I will compare a temporary PRINCE2 delivery team with a permanent DevOps team. I will then explore
the relationship between the DevOps team and the project manager and how a DevOps team deals with
PRINCE2 governance. In the last section I will combine the two approaches.

2 The PRINCE2 governance structure

In PRINCE2, the division between accountabilities and responsibilities in a project is clear. Where needed,
the segregation of duties is safeguarded. Moreover, the effectiveness of delegating project work is crucial to
a project’s success.

The project board has authority and responsibility for the project. Corporate, programme management, or
the customer sets the boundaries within which the project board can act.

The executive is accountable for the project and has ultimate decision-making authority, within the project
board.

The senior supplier (supplier representative) represents the interests of those designing, developing,
facilitating, procuring, and implementing the project’s products. This role is accountable for the quality of
products delivered by the supplier(s) and is responsible for the technical integrity of the project.

AXELOS.COM PRINCE2® and DevOps, a successful marriage or recipe for divorce? 03

The senior user (or customer/user representative) specifies the benefits. They are held to account by
demonstrating to the business (such as corporate, programme management, or the customer) that the
forecast benefits that supported project approval, have been realized or are in the process of being realized.
The senior user is responsible for ensuring that the product is driven by the need to deliver the stated
benefits. These benefits may not be realized within the project’s lifetime.

Day-to-day management of the project is delegated to the project manager. The project manager manages
the project on a stage by stage basis, based on an approved stage plan. As long as the project manager can
deliver the stage within the planned tolerances, there is no need for the project board members to maintain
close contact with the project work. The end of a stage represents a major milestone in the project and
gives the project board the opportunity to review the previous stage and the next stage plan. Based on this
review and whether there is still a viable business case (delivering value to the customer), the project board
can decide to continue with the project.

The PRINCE2 project management team structure is illustrated in Figure 2.1.

Corporate, programme management or the customer

Project board

Senior Senior
Executive supplier(s)
user(s)

Project
assurance: Change
business, user authority
and supplier
assurance
Project
manager

Within the project management team

Project
support From the customer

Team From the supplier

manager(s)
Lines of authority

Project assurance responsibility

Team members Lines of support/advice

Figure 2.1 The PRINCE2 project management team3

Management jobs do not need to be allocated to people on a one-to-one basis. PRINCE2 defines roles,
each of which comes with an associated set of responsibilities. These roles might be allocated, shared, or
combined according to the project’s needs.

The project board members each have a specific area of focus for project assurance, namely business
assurance for the executive, user assurance for the senior user(s), and supplier assurance for the senior
supplier(s). This can be delegated to one or more people (project assurance).

It is the project board’s responsibility to agree to each potential change before it is implemented. For
example, if the project is likely to exceed the tolerances agreed by the project board to the project manager.
This responsibility can be delegated to the change authority.

The project manager will run the project on behalf of the project board. The project manager can delegate
the responsibility for delivering the project’s output to team managers and can delegate some of the
support work, such as creating progress reports, to project support. Project support is a project information

04 PRINCE2® and DevOps, a successful marriage or recipe for divorce? AXELOS.COM

repository and provides potentially useful reports.

In cases where the project manager uses self-organizing delivery teams (agile teams), the project
management team structure could change slightly.

Figure 2.2 illustrates a PRINCE2 project management team structure that contains one or more agile and
traditional teams. Compared to Figure 2.1, there are the additional roles of customer subject matter expert
(customer representative), supplier subject matter expert (supplier representative), team quality assurance
(customer and supplier), and coach. The team manager role could be created, omitted, or someone in the
team could act as a single point of contact for the project manager. If there is no team manager, the project
manager is responsible for allocating the team’s work with the customer (for example the team’s product
owner or customer representative) and/or team representatives.

Figure 2.2 The PRINCE2 project management team4

3 DevOps in a nutshell
3.1 INTRODUCTION TO DEVOPS
DevOps is not a method or a framework; instead it is a mindset or
culture and a set of principles and technical practices. It provides “DevOps is not a
automation to facilitate continuous integration, automated testing,
and continuous deployment (CI/CD). It supports communication
method or a framework;
and cooperation between all people who plan, develop, test, instead it is a mindset
deploy, release, support, and maintain a product or service.
or culture and a set of
DevOps can be used to bridge the gap between developers and
operations, by bringing both together into one team, to deliver principles and technical
value to the end-user and eliminate indirect involvement between
development and operations silos. In other words, to blur the
practices.”

AXELOS.COM PRINCE2® and DevOps, a successful marriage or recipe for divorce? 05

lines between development and operations, so that new functionalities flow easier from development into
production.

The DevOps concept reduces the tension between the developers, who create the new functionality, and
the operations staff who maintain the stability of the solution in production.

DevOps helps organizations to1:

z Reduce time to market: perform business idea testing and hypothesis evaluation by using Eric Ries’
concept of the minimum valuable product.
z Reduce technical debt: debt occurs when a programmer chooses a nonoptimal way to solve a problem
to reduce the development time.
z Eliminate fragility: fragile systems need stability and must therefore be changed as little as possible; any
changes that are made must be checked before and after the intervention.

DevOps is based on five principles1:

z Value stream: creating value in response to a customer’s request.

z Deployment pipeline: the most automated transition step of the value stream, starting from the
completion of development to deployment into operations, which includes continuous integration,
delivery, and deployment.
z Everything is stored in a version control system: this includes, source code, tests, scripts, artefacts,
libraries, documentation, configuration files, and development tools.
z Automated configuration management: any changes to an environment can only be made by scripts
stored in a version control system.
z The definition of done: the creation of new functionality is achieved only when the application is
running in the production environment and all the assembly, testing, and deployment activities are done
automatically.

3.2 DEVOPS DIMENSIONS (CALMS)

DevOps can be divided into five dimensions, often represented by CALMS5 or CALMR, which stands for:

z Culture: the most important dimension of the DevOps movement. Key practices in this area are system
thinking, continuous improvement (Kaizen), fail-fast to learn fast, agile ways of working (for example
Scrum, Kanban), reduction in silo mentality, reduction of technical debt, and the usage of retrospectives
to adapt.
z Automation: this will help to accelerate the time to market by creating a continuous delivery pipeline
(continuous integration, automated testing, and continuous delivery), and by using the concept of
infrastructure as code.
z Lean: to achieve a continuous flow of delivery of new functionality by using small batches, manage/
reduce queue lengths, and visualize and reduce the work in progress (WIP) limit.
z Measurement: measures are key as decisions must be made based on facts and data, not opinions.
How long will it take to deliver a requested function? What is the mean time to repair a bug? How
many open tickets, number of users, response time, and so on? Therefore, on the developer side, it is
very important that they provide onboard monitoring services or application telemetry in the provided
applications.
z Sharing: this is based on three components: visibility, transparency, and knowledge transfer.

06 PRINCE2® and DevOps, a successful marriage or recipe for divorce? AXELOS.COM

3.3 PLANNING HORIZON
DevOps teams (sometimes called manufactory teams) use a high- “The most widely
level uncommitted roadmap to achieve midterm or long-term goals.
This roadmap gives an idea of when a piece of work (project, epic, or used way of working
feature) could be developed. The roadmap is uncommitted, to make
it possible for the team to react on new more value-added customer
to meet short-term
demand. goals is Kanban.
The most widely used way of working to meet short-term goals is Scrum is also used.”
Kanban. Scrum is also used.

Gene Kim describes in his book The Phoenix Project6 the four types of work for a DevOps team (classes of
service). These are:

z business projects
z internal IT projects
z changes
z unplanned work or recovery work.

Kim explains that development, quality assurance, compliancy, and operations must work closely together
in the DevOps team. Within this team, three ways of working must be integrated by using a Kanban
system:

z The first way is a left-to-right flow of work from development to IT operations to the customer. This flow
needs to be maximized by managing the WIP and have continuous build, integration, and deployment
practices (CI/CD).
z The second way is about the constant flow of fast feedback from right-to-left at all stages of the value
stream.
z The third way is about creating a culture that fosters two things:
z continual experimentation, which requires taking risks and learning from success
z failure and understanding that repetition and practice are the prerequisites to mastery.
When using Scrum, the requested features must be included in the DevOps team product backlog, together
with changes, and unplanned or recovery work.

AXELOS.COM PRINCE2® and DevOps, a successful marriage or recipe for divorce? 07

4 A permanent DevOps team versus a temporary PRINCE2
delivery team
If we compare a temporary PRINCE2 delivery team and a permanent DevOps team, we see similarities as
well as differences. Table 4.1 shows the comparison.
Table 4.1 Comparison between a PRINCE2 delivery team and a DevOps team

PRINCE2 delivery team DevOps team

Strategy Team is moved to the work Work is moved to the team

Appearance Temporary Permanent

Management Team manager Self-organizing

Assignment Work package Customer demand (epic, feature, user story)

Composition Multidisciplinary Multidisciplinary, multiskilled ‘generalizing specialists’

Balanced To be structured by the project manager (for Team is in place and is effective. To become a high
example, Belbin team role inventory) performing team, they can still perform retrospectives

Team member Part-time or full-time Full-time

availability
Team size Small to large Small: 5-8 people, “If you can’t feed a team with two
pizzas, it’s too large.” Jeff Bezos, Amazon15
Generic scope Change Change and run

Ways of working Any Lean, Agile, Scrum, Kanban, IT&SM

Quality Independent project assurance (of the team) Within the DevOps team (passing quality criteria,
assurance using retrospectives)

Approach PRINCE2: scope is fixed during this stage, budget Budget (team set-up) is fixed, duration can be fixed
and duration can fluctuate depending on delivery (scrum) or flexible (Kanban), scope can change
issues

PRINCE2 Agile: scope is flexible, duration, and

budget (team set-up) are fixed

5 How to cope with DevOps teams from a PRINCE2 project

manager perspective
The DevOps team is a permanent team, so there is no need to build the team. DevOps teams are
cross-functional, and every individual team member has a responsibility for the quality of the product.
Consequently, each team member has individual ownership in the end result. The team members have
common goals and have the same prioritization of system value. Collaboration and continual feedback
mean that everyone knows what is going on in every step of the process. Team members are working
together for the common goals.

With DevOps, no one is blamed when things go wrong. Failure is anticipated and used to achieve
better quality products or services in the future. DevOps requires value-driven behaviours from the team
members, where there is continuous learning with an end goal in mind. This practice enables fast delivery

08 PRINCE2® and DevOps, a successful marriage or recipe for divorce? AXELOS.COM

and a higher level of quality, because the team is adaptable and changes with the project’s needs7.

When creating teams, the project manager must decide if they want to appoint a team manager or if they
will be performing this role. A DevOps team does not ordinarily have a team manager, but the project
manager still needs a single point of contact. This single point of contact could be anyone from the DevOps
team. Most likely, it will be the scrum master or it might be the product owner (if these roles are used).

The project manager uses a work package as a vital interface/link to blend the project environment
with the DevOps team. This work package will be collaboratively defined between the project manager
and the DevOps team, as a single point of contact. It contains the agreed levels of detail, formality, and
transparency with respect to reporting, tolerances, and product descriptions. These are defined at the right
level and quality criteria, guidance on behaviours, risk and the frequency of releases, as well as guidance
on quality checking techniques. The work package helps the DevOps team to understand the wider project
context. Furthermore, the work package must be flexible to make management by exception easier and to
enable rich communication (for example, using workshops, face-to-face meetings, and visualizations).

The project manager builds a high-level project plan (roadmap) around features. If some or all of these
features have to be delivered by the DevOps team, these features have to be part of the work package
(product descriptions).

The project manager must understand that the DevOps team has a responsibility to manage customer
product demand. The DevOps team must also maintain the stability of the product, service, or solution in
production, which includes changes and unplanned work or recovery work.

For the DevOps team, the demand from the project manager will be positioned as a business project (see
section 3.3). The project manager must agree where on the DevOps team’s roadmap the project will fit
and how much work they can handle in a given time period (the WIP limit). This means that the project
manager must accept that the DevOps team will not be constantly available for the project manager and
the agreed utilization will be part of the work package. If needed, timing conflicts can be escalated to the
project board and/or portfolio committee.

To control a stage and more specifically the DevOps team’s work package, the project manager focuses
on what is being delivered in terms of scope (the features and quality criteria) and they will monitor the
risks. The features could be divided into user stories by a product owner or customer representative. The
customer representative or product owner in the DevOps team can decide to change user stories if the
feature itself will be delivered (in-line with the described tolerance levels in the work package). Where
possible, this work package control will be a joint or collaborative empirical inspect and adapt exercise. For
example, meetings, ceremonies or events between the project manager and the DevOps team, making use
of information radiators, stand-up meetings, and demos.

6 How to cope with the PRINCE2 governance from a DevOps

team perspective
DevOps teams prefer to be led and coached as opposed to managed. They will not accept that a project
manager assigns a team manager role to manage the DevOps team. Common agile guidance does not
have a project manager role, but PRINCE2 sees this role as mandatory within a project. The DevOps team
has to understand that the project contains more than the product, service, or solution the DevOps team
is responsible for. The DevOps team must accept that a project manager will coordinate work between the
DevOps team and other teams and stakeholders. To make this possible, the project manager needs a single
point of contact.

AXELOS.COM PRINCE2® and DevOps, a successful marriage or recipe for divorce? 09

The DevOps team members expect servant leadership and a good understanding of the overall project
objectives from the project manager. The project manager is to be its servant. The focus of the project
manager must be on empowerment (empower to self-organize), collaboration, and facilitation. Fortunately,
there is nothing in PRINCE2 that limits the use of servant
leadership.
“The focus of the
The project manager must manage by exception with the emphasis
project manager must
on empowerment, the amount being delivered, rich information be on empowerment
flows, and the value being delivered. This means the project
manager will be pulling information from the information radiator (empower to
(pull) rather than having it delivered by means of additional regular
progress reports (push). The project manager trusts the DevOps
self-organize),
team, focuses on collaborative working, and avoids a blame collaboration, and
culture, to promote experimentation and a learning culture.
facilitation.”
The information radiator shows the Kanban board, including the
swimlane with the business project. This is also the place where the DevOps team members draw their
burn-up and burn-down charts, visualizing the actual status of the business project’s progress. The project
manager can use these graphs to understand if the DevOps team is on track, behind, or ahead of the
agreed schedule.

The DevOps team8 expect that the project manager will use the feedback from testing, staging, and
deployments from real customers to re-plan: “scope may need to be added and/or removed frequently
based on the new information.9”

The DevOps team expects the project manager to finds ways to break a large project into smaller
parts, which enable the business to gain incremental value (for example, based on prioritized business
requirements and corresponding business value). If needed, the DevOps team can deliver features
accompanied by feature flags, to launch a feature to a subset of users or postpone the go live stage to the
right moment.

When talking about governance you must also think about risk management10. A popular risk management
framework used when considering governance is The Three Lines of Defence Model 11 (developed by the
Institute of Internal Auditors). The three lines of defence are:

z 1st Line: who owns the risk? The DevOps team members.
z 2nd Line: who sets policy and monitors the risk? The senior supplier in the project board and risk
functions that set policy and monitor risk daily. When the project is part of a programme, the 2nd line of
defence is the programme board.
z 3rd Line: independent assurance. Internal audits that provide independent insurance and report directly
to the audit committee or the board.

In addition to this enterprise risk management model is an informal 4th line that is external to the
company, but works with them hand-in-hand to properly implement governance. It is the responsibility of
the senior supplier in the project board to act as the intermediary.

z 4th Line: external partners. Auditors and regulators who must be brought into the conversation and
given full transparency on development processes and risk management.

10 PRINCE2® and DevOps, a successful marriage or recipe for divorce? AXELOS.COM

7 Blending PRINCE2 and DevOps
DevOps offers plenty of good working practices, but, it is not a silver bullet for business success12.
Command-and-control leadership is not the way forward. Leaders are engaging more with their teams.
Leadership is moving towards a facilitating, delegating, and long-term strategy-focused way of working.
DevOps teams are not autonomous, they must know what is happening in the organization, and they must
understand their part in the product lifecycle. Gartner released a Product Management Framework13, which
lists 22 areas to reduce risk and maximize benefits. DevOps is only related to a few steps in the process,
for example, in building compelling CX and accelerating time to market.

This means that the DevOps team needs to bridge the gap across various functions and groups in the
organization. The project board members as described in PRINCE2 can help to overcome this gap. The
project executive or project sponsor can help to align the DevOps team with the company’s strategy and
ensure that the DevOps team is aware of strategic changes.

The senior user in the project board plays a very important role in the creation and maintenance of a
solid product management strategy. For further information, see the product planning section of Gartner’s
Product Management Framework.

The technology stack and how the product is organized in terms of components or microservices are key
factors to drive the right team topology, DevOps efficiency, and deployment effectiveness. This is also one
of the reasons that many organizations are moving away from big, monolithic applications. This is typically
the area of focus for the senior supplier in the PRINCE2 project board.

The role of the project manager will change in comparison with a more traditional project manager.
Behaviours, relationships, and responsibilities might be emphasized differently. The project manager needs
to adopt a servant leadership approach to be seen as a friend of the DevOps team and not just a figure of
authority. Within a DevOps team, there can be a level of coldness and technicality when working with this
streamlined, analytical system of product development, bug fixes, QA testing and launch14. But it is the
project manager’s job to add that human element that technology can sometimes miss.

8 Summary
PRINCE2 is already enabled to work with Agile and can be very effective in an agile context. Tailoring, as
one of the seven principles, is about creating an appropriate blend of the two. The use of Agile is always a
question of ‘how much can be used according to the situation?’

Like marriages, success cannot come from just one side. But if both parties, in this case a PRINCE2
project management team and DevOps team members, have the right (agile) mindset to work together
to make this work, the results could be outstanding. DevOps should be blended with a proper PRINCE2
project management team structure with shared goals, the right leadership mindset, a comprehensive
product management strategy, and an overarching application architecture to contribute to timely customer
value generation. Finally, the project manager can provide the DevOps teams with a human goal.

AXELOS.COM PRINCE2® and DevOps, a successful marriage or recipe for divorce? 11

 9 About the author
Henny Portman is partner of HWP Consulting. He has 40 years of experience in project
management. He was the thought leader within NN Group of the PMO domain and
responsible for the introduction and application of the PMO methodologies (portfolio,
programme, and project management) across Europe and Asia. He trains, coaches, and
directs (senior) programme, project, and portfolio managers and project sponsors and has
built several professional communities.

Henny Portman is accredited in a variety of qualifications, including: P3O, PRINCE2, MSP,

MoP, PRINCE2 Agile, AgilePM, AgilePgM, and AgileSHIFT trainer and is also a SPC4 SAFe consultant
and trainer. He is a P3M3 trainer and assessor and PMO Value Ring Certified Consultant (PMO Global
Alliance). On behalf of IPMA, he assesses mega and large projects for the IPMA Project Excellence Award.
In addition to this, he is an international speaker and author of many articles and books in the PM(O) field
and a blogger at hennyportman.wordpress.com.

12 PRINCE2® and DevOps, a successful marriage or recipe for divorce? AXELOS.COM

10 Endnotes
1 Skrynnik, O., (2018). DevOps - A Business Perspective. Van Haren Publishing, s’-Hertogenbosch

2 Note that for those wishing to learn more about how to combine the governance structure and
tailorability of the PRINCE2 method with the flexibility and responsiveness of agile ways of working,
AXELOS has developed the supporting guidance and certfication PRINCE2 Agile (2015)

3 AXELOS (2017) Managing Successful Projects with PRINCE2. The Stationery Office (TSO), London

4 AXELOS (2015) PRINCE2 Agile. The Stationery Office (TSO), London

5 CAMS acronym was invented by Damon Edwards and John Willis, presenters of the famous
Podcast DevOps Café (2010). Jez Humble added the L for Learning and Lean.

6 Gene Kim, Kevin Behr, George Spafford, (2013) The Phoenix Project. IT Revolution Press, Portland.

7 Introduction to DevOps for business managers (2020). Available at: https://www.cprime.com/

resources/blog/devops-methodology-business-analysts/ [Accessed 27 October 2020].

8 How to rethink project management for DevOps (2017). Available at: https://enterprisersproject.
com/article/2017/10/how-rethink-project-management-devops [Accessed 27 October 2020].

9 ibid

10 Governance in a DevOps Environment (2018). Available at: https://medium.com/capital-one-tech/

devops-and-governance-56f6ecae1181 [Accessed 27 October 2020].

11 The three lines of defence (2015). Available at: https://www.iia.org.uk/policy-and-research/position-

papers/the-three-lines-of-defence/ [Accessed 27 October 2020].

12 3 problems DevOps won’t fix (2020). Available at: https://enterprisersproject.com/article/2020/2/

devops-wont-fix-3-problems [Accessed 27 October 2020].

13 Gartner Priorities Navigator™ for Product Management Teams (2020). Available at: https://www.
gartner.com/en/industries/high-tech/trends/product-management-framework [Accessed 12 October
2020].

14 Project Managers Role in a DevOps World (2020). Available at: https://www.techwalls.com/project-

managers-role-devops-world/ [Accessed 27 October 2020].

15 Inside the Mind of Jeff Bezos (2004). Available at: https://www.fastcompany.com/50541/inside-

mind-jeff-bezos-4 [Accessed 27 October 2020].

AXELOS.COM PRINCE2® and DevOps, a successful marriage or recipe for divorce? 13

 Further reading
The CAMS model to better understand the DevOps movement (2018). Available at: https://medium.
com/@brunodelb/the-cams-model-to-better-understand-the-devops-movement-ffe6713c3fd7
[Accessed 26 October 2020].

ITIL® 4 and DevOps White Paper (2020). Available at: https://www.axelos.com/case-studies-and-

white-papers/itil-4-and-devops-white-paper [Accessed 27 October 2020].

ITIL 4 and DevOps: a cultural perspective Discussion Paper (2019). Available at: https://www.axelos.
com/case-studies-and-white-papers/itil-4-and-devops-a-cultural-perspective [Accessed 27 October
2020].

14 PRINCE2® and DevOps, a successful marriage or recipe for divorce? AXELOS.COM

11 About AXELOS
AXELOS is a joint venture company co-owned by the UK Government’s Cabinet Office and Capita plc.

It is responsible for developing, enhancing and promoting a number of best practice methodologies used
globally by professionals working primarily in project, programme and portfolio management, IT service
management and cyber resilience.

The methodologies, including ITIL®, PRINCE2®, PRINCE2 Agile®, MSP®, RESILIA® and its newest
addition AgileSHIFT® are adopted in more than 150 countries to improve employees’ skills, knowledge
and competence in order to make both individuals and organizations work more effectively. 

In addition to globally recognized qualifications, AXELOS equips professionals with a wide range of content,
templates and toolkits through the CPD aligned My AXELOS and our online community of practitioners and
experts.

Visit www.AXELOS.com for the latest news about how AXELOS is ‘Making organizations
more effective’ and registration details to join AXELOS’ online community. If you have specific queries,
requests or would like to be added to the AXELOS mailing list please contact
Ask@AXELOS.com.

12 Trade marks and statements

AXELOS®, the AXELOS swirl logo®, ITIL®, PRINCE2®, PRINCE2 Agile®, MSP®, AgileSHIFT®, M_o_
R®, P3M3®, P3O®, MoP®, MoV®, RESILIA® are registered trade marks of AXELOS Limited. All rights
reserved.

Copyright © AXELOS Limited 2019.

Image credits: Front cover ©/Getty/Tara Moore

Figure 2.1, 2.2 ©/AXELOS Ltd

Reuse of any content in this White Paper is permitted solely in accordance with the permission terms at
https://www.axelos.com/policies/legal/permitted-use-of-white-papers-and-case-studies

A copy of these terms can be provided on application to AXELOS at Licensing@AXELOS.com

Our White Paper series should not be taken as constituting advice of any sort and no liability is accepted
for any loss resulting from or use of or reliance on its content. While every effort is made to ensure the
accuracy and reliability of information, AXELOS cannot accept responsibility for errors, omissions or
inaccuracies. Content, diagrams, logos and jackets are correct at time of going to press but may be subject
to change without notice.

Sourced and published on www.AXELOS.com

AXELOS.COM PRINCE2® and DevOps, a successful marriage or recipe for divorce? 15

WWW.AXELOS.COM @AXELOS_GBP AXELOS Global Best Practice AXELOS