This document provides an overview of how ITIL best practices can help managed service providers deliver valuable services to clients. It discusses how ITIL has become more relevant to external service providers and the different types of managed service providers. The document also covers key topics for managed service providers like service strategy, designing offerings that add value, different resourcing models, service level agreements, and driving continual improvement. Adopting ITIL provides benefits like a common language between providers and clients, more compatible processes, and the flexibility to work with multiple partners and clients.

1. White Paper
August 2013
ITIL®
for managed service providers
Brian McCabe
© The Stationery Office 2013

2. 2 ITIL®
for managed service providers
© The Stationery Office 2013
Contents
Synopsis 3
1 Managed service providers and ITIL 3
2 Service strategy 6
3 Service design 8
4 Service transition 9
5 Service operation 12
6 Continual service improvement 14
7 Summary 15
References 16
About the author 16
Reviewers 16
Acknowledgements 16
Trade marks and statements 16

3. ITIL®
for managed service providers 3
© The Stationery Office 2013
Synopsis
This White Paper provides a practical review of real-world
challenges, ideas and techniques to help managed service
providers deliver services aligned with ITIL®
. The paper focuses
on the core ITIL lifecycle stages and how all stakeholders can
maximize the business benefits of adopting a structured service
governance approach.
Many managed service providers use ITIL as a marketing badge
of industry compliance or, in some cases, claim to be formally
ITIL-accredited, which is simply not possible (only individuals
can be accredited – organizations as a whole cannot). Most
service providers rarely realize the true benefits of introducing
best practice in a pragmatic, commercially sensible and client-
focused manner. Others adopt a highly mechanistic approach,
following the five core ITIL publications (Cabinet Office, 2011) to
the letter and – in the process – alienating and restricting their
clients who may not be totally on board with the finer detail of
these books.
This White Paper will aid service providers in realizing those
business benefits by encouraging them to follow the underlying
ethos of ITIL to ‘adopt and adapt’ the principles, thus adding
value to their clients’, and their own, business operations.
The intended audience of this White Paper is primarily product/
service design specialists and senior operational management
within managed service provider organizations. The paper
will also be of interest to prospective purchasers of those
services who wish to be informed of the challenges faced by
the managed service provider and to understand how best to
maximize the value to their own business of engaging in such a
third-party relationship.
Topics covered include:
■■ Constructing service offerings that are commercially viable,
deliverable and add value to the receiving client organization
■■ The blending of the managed service provider’s service
delivery approach with that of the client – and potentially
other concurrent service providers – while maintaining a
consistent and effective set of processes, functions and tools
■■ The various staff resourcing models (dedicated, shared,
on-site, remote, onshore/offshore/near-shore) adopted by
managed service providers
■■ Service level management and the risk of poorly considered
service level agreement (SLA) or operational level agreement
(OLA) targets being achieved at the expense of client
satisfaction and long-term service relationships
■■ Aligning inter-company SLAs with the client’s business
requirements
■■ The impact of cloud computing on traditional IT service
delivery and how managed service providers must adapt
their service delivery approach to stay relevant and
competitive in the ‘everything-as-a-service’ world
■■ Ensuring financial controls are in place to protect the
managed service provider while still delivering true business
value to the client
■■ Driving continual service improvement in a commercially
constrained environment, such that all parties are ‘winners’.
This White Paper looks at the governance considerations
involved in planning for the deployment of the core ITIL
disciplines across the managed service provider organization,
and also the specific management considerations that can be
involved in individual client engagements.
The distinction between management and governance is often
overlooked. In ITIL terms, management deals with making
decisions and executing processes, whereas governance deals
only with making sound decisions.
Looking at ITIL and its adoption from the perspective of the
managed service provider, this White Paper addresses each
of the challenges head-on, clarifying some of the myths and
misconceptions regarding best practice. It contends that ITIL can
be deployed by managed service providers of all types and sizes,
and within most budgets.
1 Managed service providers
and ITIL
Prior to Version 3 (the 2007 edition of ITIL published by the
Office of Government Commerce), ITIL was primarily designed
for internally delivered IT services, providing guidance for the
internal help desk and associated support functions.
Following the ITIL Refresh, ITIL V3 became far more relevant
to external service providers, acknowledging the plethora of
sourcing approaches available to the modern-day IT executive.
ITIL Service Strategy (Cabinet Office, 2011) provides high-level
views of IT sourcing approaches, as described in Table 1.
As can be seen from the standard ITIL definitions in Table 1,
managed service providers come in many shapes and sizes,
and it is near impossible to provide a one-size-fits-all
delivery approach to encompass this breadth of offerings.
Fortunately, ITIL’s ethos of ‘adopt and adapt’, coupled with
its modular nature, provides an ideal baseline from which
any managed service provider can construct its own service
governance model.
Full ITIL roll-outs have typically been the domain of the larger
systems integrators, but this does not need to be the case, and
many small-to-medium-sized service providers are currently
missing out on the benefit of this proven best practice.
This White Paper aims to dispel many of the myths that are
frequently used to justify the reluctance to adopt ITIL, and
provides guidance and encouragement for those who are
unsure whether ITIL is appropriate for their business.

4. 4 ITIL®
for managed service providers
© The Stationery Office 2013
Table 1 Main sourcing structures (delivery strategies)
Copyright © AXELOS Limited. Reproduced under licence from AXELOS Limited – ITIL Service Strategy, Table 3.20
Sourcing structure Description
Insourcing This approach relies on utilizing internal organizational resources in the design, development, transition,
maintenance, operation and/or support of new, changed or revised services.
Outsourcing This approach utilizes the resources of an external organization or organizations in a formal arrangement
to provide a well-defined portion of a service’s design, development, maintenance, operations and/or
support. This includes the consumption of services from application service providers (ASPs) described
below.
Co-sourcing or
multi-sourcing
Often a combination of insourcing and outsourcing, using a number of organizations working together
to co-source key elements within the lifecycle. This generally involves using a number of external
organizations working together to design, develop, transition, maintain, operate and/or support a portion
of a service.
Partnership Formal arrangements between two or more organizations to work together to design, develop,
transition, maintain, operate and/or support IT service(s). The focus here tends to be on strategic
partnerships that leverage critical expertise or market opportunities.
Business process
outsourcing (BPO)
The increasing trend of relocating entire business functions using formal arrangements between
organizations where one organization provides and manages the other organization’s entire business
process(es) or function(s) in a low-cost location. Common examples are accounting, payroll and call
centre operations.
Application service
provision
Involves formal arrangements with an application service provider (ASP) organization that will provide
shared computer-based services to customer organizations over a network from the service provider’s
premises. Applications offered in this way are also sometimes referred to as on-demand software/
applications. Through ASPs, the complexities and costs of such shared software can be reduced and
provided to organizations that could otherwise not justify the investment.
Knowledge process
outsourcing (KPO)
KPO is a step ahead of BPO in one respect. KPO organizations provide domain-based processes and
business expertise rather than just process expertise. In other words the organization is not only required
to execute a process, but also to make certain low-level decisions based on knowledge of local conditions
or industry-specific information. One example is the outsourcing of credit risk assessment, where the
outsourcing organization has historical information that they have analysed to create knowledge which in
turn enables them to provide a service. For every credit card company to collect and analyse this data for
themselves would not be as cost-effective as using KPO.
‘Cloud’ Cloud service providers offer specific pre-defined services, usually on demand. Services are usually
standard, but can be customized to a specific organization if there is enough demand for the service.
Cloud services can be offered internally, but generally refer to outsourced service provision.
Multi-vendor sourcing This type of sourcing involves sourcing different sources from different vendors, often representing
different sourcing options from the above.

5. ITIL®
for managed service providers 5
© The Stationery Office 2013
ITIL has also been traditionally viewed as being more
appropriate to IT infrastructure and telecommunications rather
than software applications management providers. Again, this is
a myth – ITIL is relevant to all aspects of IT service delivery.
Managed service providers generally fall into the following high-
level categories:
■■ Application management outsourcers (AMOs) AMOs
manage off-the-shelf and custom software applications. This
category includes application service providers as described
in Table 1, but it is broader in definition. AMOs can also
manage applications that reside on client’s premises or in
third-party data centres; such applications include off-the-
shelf and custom developed solutions.
■■ Information technology outsourcers (ITOs) ITOs
manage desktops, servers, networks, printers and other
supporting infrastructure.
Niche providers may deliver only one of the above service
types, whereas larger managed service providers will offer
both – either directly or through the use of partners. The term
‘outsourcing’ is used in its most generic form above and refers
to any external service provider. Clearly the overall service
portfolio will vary greatly between managed service providers,
where the focus may be on specific technologies, delivery
methods or particular market sectors.
In many cases, the managed service provider will itself
sub-contract services to a third-party supplier as part of an
aggregated service delivery model, or partner with other service
providers in a consortium. ITIL, when deployed effectively,
provides a highly efficient framework for such multi-faceted,
multi-sourced environments.
Service providers can significantly broaden their service
portfolios by adopting a robust service governance model as a
catalyst to partake in multi-sourced arrangements. In expanding
its portfolio the managed service provider also expands the
size of the available market for its services. Even in cases where
the managed service provider has limited appetite to partner
or sub-contract services, an effective service management
approach will reduce process inefficiencies and generate
opportunity for growth. As a commercial enterprise, these are
clearly attractive propositions.
A study by Gartner (2009) showed that just over half of the
surveyed companies selected a single managed service provider
for both infrastructure and applications. Managed service
providers who are able to provide a greater breadth of services
– either directly or through effective partnership with other
service providers – will have access to a far broader share of the
available market than those who do not.
By adopting ITIL, the service providers will also communicate
using a common language and have more compatible core
processes than those who adopt a purely home-grown
approach to service management. From a client’s perspective
– and also that of other service providers who may be working
as part of a partnership – ITIL adoption builds confidence and
reduces any potential resistance to engage with the managed
service provider. The time taken to transition services is reduced
due to the use of a common language; ongoing communication
and collaboration are also far less ambiguous.
From a personnel resourcing perspective, managed service
providers deliver service using a range of models, including:
■■ Dedicated resources Where one or more named
individuals are dedicated to work on a single client
engagement. Such engagements result in a close affinity
between the managed service provider’s resources and the
client’s IT systems. Depending upon the ratio of client staff
to managed service provider staff, this can often result in one
of the following situations:
–– Where the client staff outnumber the managed service
provider staff, the managed service provider augments
the client’s own team while adopting the client’s
processes, tools and methodology. In such cases the
managed service provider may feel that it is restricted in
its ability to influence improvement and standardization of
approach, with managed service provider personnel
potentially ‘going native’ within the client organization
–– Where the managed service provider staff outnumber the
client staff, the managed service provider has greater
influence over the introduction of its own standard
processes, thus driving a level of consistency for its own
services but at the risk of isolating that provider from the
rest of the client organization unless the integration of the
two approaches is relatively seamless.
■■ Shared resources Where the managed service provider’s
staff can work on multiple clients in parallel, thus passing on
the commercial economies of scale and breadth of
experience to the client in the form of reduced costs and
potentially broader technological experience. The
methodology challenge for the managed service provider in
this model is to construct an approach that is familiar to its
own staff, regardless of which client they are working with,
while not forcing the client into a totally unfamiliar way of
working. ITIL provides the flexibility required to strike this
balance but will require some creative thinking at times to
arrive at a ‘mix and match’ portfolio of service processes,
functions and tools.
■■ Blended resources Where a single contract is fulfilled by a
combination of dedicated and shared resources, often in a
flexible model, where the headcount can go up or down
based on client demand. This combination clearly carries the
pros and cons of both the dedicated and shared resourcing
models and, if not managed correctly, can lead to confusion
within the service provider’s own teams regardless of how
the client operates.
In the dedicated model, the resources may be physically located
at the client’s premises or they may be located remotely, as is
usually the case with the shared model (see Figure 1). Some
managed service providers (for example, break-fix hardware

6. 6 ITIL®
for managed service providers
© The Stationery Office 2013
engineers) will deliver mobile services, visiting the client location
only when required. These can also be delivered using either a
dedicated or shared approach.
Figure 1 Resourcing matrix for managed service
providers
The challenge of building a robust service management
approach that works in harmony with client operations is
further complicated in multi-sourced engagements. Common
sense dictates that having a common language can vastly
simplify the creation of a coherent, multi-party service
governance model. That common language is provided within
the ITIL framework.
Additional challenges can arise for managed service providers
when their organization provides a mixture of offerings to the
same client base – for example, consulting or project-based
services – alongside ongoing managed services. The interplay
between project- and service-based delivery can be a significant
hurdle to service quality and client perception if not addressed
correctly. Section 4 relating to service transition focuses on
these challenges.
The sourcing and delivery strategies mentioned above do
not apply solely to IT services. Business process outsourcing
(BPO) can also deliver value to end-user organizations by sub-
contracting specific – typically back-office – processes to a
third party. Those services are outside the scope of this White
Paper but we would expect the lines between ITOs, AMOs and
BPO to become even more blurred as time progresses and the
move to cloud delivery of commodity services begins to drive a
convergence of application management and business process
management.
The remainder of this White Paper will focus on several of the
key discussion points that impact on the adoption and positive
contribution of ITIL within the external managed services
sector. These topics will be covered under the framework of
the ITIL service lifecycle stages, and in the form of responses
to commonly held misconceptions regarding such service
adoption, accompanied by some critical success factors specific
to managed service providers.
2 Service strategy
Service strategy for managed service providers is primarily a
commercially focused exercise in determining the business
case for both the managed service provider and its prospective
customer(s). Figure 2 provides a summary of the service strategy
stage of the lifecycle. Depending upon the target customer
profile and engagement size, the managed service provider
may define a strategy around a single large account or, more
usually, create a portfolio of standard service offerings that can
be tailored (typically during service design) to fit with individual
customer needs.
Key considerations for managed service providers are:
■ Which services to take to market
■ How to structure those services
■ The delivery methodology (staff resourcing approach, on-site
versus remote etc.)
■ What type of organization will buy the service, and why
■ The market appetite for such services, the size of the target
sector, and the expected market penetration rate
■ How much the service will cost to deliver
■ How to charge clients, and what approach to adopt to arrive
at such pricing (for example, value-based or cost-plus) while
still demonstrating a tangible return on investment for the
client
■ What charging model(s) to offer – for example, pay-per-use,
fixed price, time and materials, shared risk/reward model?
Figure 2 Lifecycle summary – service strategy

7. ITIL®
for managed service providers 7
© The Stationery Office 2013
■■ How to ultimately drive business value for the managed
service provider’s organization and for the client business;
and how to measure and report this value.
Many managed service providers will launch services without
considering all of these aspects, often resulting in a sub-
standard and/or failed service offering. The service strategy
processes ensure that the managed service provider thoroughly
qualifies a service offering before committing precious
marketing and service development funds to the initiative.
Some popular misconceptions
‘The IT services my company delivers will not work with ITIL.’
All IT service delivery models can benefit from ITIL-aligned
service governance. ITIL’s philosophy of ‘adopt and adapt’
provides a flexible framework of best-practice guidance which
the managed service provider can tailor to fit with its own
operations, introducing ITIL in a phased and pragmatic manner.
This is true whether the managed service provider is delivering
support for a commoditized product or managing a highly
customized solution, or whether it is resourcing the service with
dedicated personnel or using a shared pool of people resident
on the other side of the world. It makes no difference whether
the managed service provider is charging for the service on a
pay-per-use or fixed-price basis, or any combination of these; a
pragmatic adoption of ITIL best practice will undoubtedly deliver
benefit to the managed service provider and its clients.
The same rules of ITIL adoption apply to managed service
providers as they do to end-user organizations. The managed
service provider must:
■■ Create an achievable, detailed and measurable plan for
process adoption. Without such a plan the managed service
provider will not know when it has been successful
■■ Obtain senior management buy-in to the plan and the
required resources (monetary, effort, tooling etc.). Otherwise,
the risk is that the scope may be changed or, worse still, the
programme may be cancelled if such a commitment has not
been received
■■ Nominate an owner who is responsible and accountable for
the introduction of this best practice. A focal point is vital for
measuring progress against the plans and also to act as
mediator in the case of any uncertainty
■■ Clearly communicate the plans to all stakeholders, ensuring
that all parties are aware of the plans and the progress made
against those plans
■■ Perform a post-implementation review and embark on a
programme of continual service improvement. Lessons can
always be learnt from any programme of work. These should
be documented and communicated to relevant parties. The
review also forms the baseline for future enhancements.
This does not have to be a sizeable programme of work for
a smaller managed service provider wishing to adopt, for
example, a best-practice incident management process. There
is a wealth of public domain knowledge and advice available,
backed by an ever-maturing and affordable set of tools to assist
the managed service provider on this journey.
‘Cloud computing signals the end of ITIL for service providers’
Technological advancements will inevitably move at a pace with
which the best-practice methodologies appear unable to keep
in step. ITIL is no exception to this and the pure logistics of
regularly updating such a significant body of work should not
be underestimated.
That said, The Stationery Office – the publisher of the five
core ITIL publications – recognizes this and regularly produces
complementary materials to ensure that the content remains
current. Additionally, the core publications are structured in
such a way that they will continue to be highly relevant to a
broad array of existing and emerging technologies.
A commonly held misconception is that the apparent paradigm
shift towards cloud computing renders the rigour of ITIL
redundant. Nothing could be further from the truth, although
a level of interpretation and updating of the underlying
‘common sense’ approach may be necessary to cater for such
technological evolution.
At a time when service components are being supplied from
disparate and often faceless web-service providers, core
business applications are being rented in multi-tenanted
deployments, and data can reside on the other side of the
world from the end-users, the need for a strong service
governance model, backed by flexible service management
processes, is more important than ever. Cloud computing
introduces many benefits to end-user organizations who need
to be agile, have few capital assets and pay only for what they
consume. That said, the risks of moving to this new service
approach are plentiful. A strong service governance approach
may not solve all of these, but at least the organization will have
an understanding of where such risks lie and will be able to
mitigate them in the most appropriate manner.
In a world where cloud-based managed service providers will
probably never meet with their end-users there is a temptation
for the managed service provider to feel isolated from the user
base. As a result the managed service provider may not feel
as obligated to deliver against those users’ expectations as
they were in the traditional pre-cloud delivery model. This is
a dangerous attitude to adopt, especially as the marketplace
for such services continues to expand exponentially on an
almost daily basis. Competition will be strong and only those
managed service providers who do not overlook the continued
need for robust and business-grade service governance models
will survive. Collaboration in the cloud not only requires
common technology platforms, it also requires common
delivery methods. The need for managed service providers to
communicate with their clients using a common language and
for their predominantly remote clients to feel comforted by the
adoption of such methods is possibly more important in the
cloud environment than it has ever been before.

8. 8 ITIL®
for managed service providers
© The Stationery Office 2013
The view that ITIL will become more rather than less important
as IT continues to evolve at such a rate is not confined to cloud
computing. It is equally applicable to other hot topics such as
bring-your-own-device (BYOD), Big Data and other hype-curve
resident technologies.
Critical success factors for service strategy
The factors that will make a managed service provider’s service
strategy successful centre around the identification of a viable
market need and the production of a service package that:
■ Has the support of the key stakeholders within the service
provider organization
■ Is marketable and attractive to the target client sector
■ Is commercially viable for the managed service provider, and
any partners or sub-contractor organizations who may be
involved in the eventual delivery of the service
■ Adds business value to both the managed service provider
and the receiving client’s business operations
■ Is capable of being successfully delivered.
3 Service design
For managed service providers the service design lifecycle stage
is where ideas turn into reality, whether this is the instigation
of a new service or service line, or the review of enhancements
to existing services. Figure 3 provides a summary of the service
design stage of the lifecycle.
Key activities for managed service providers as part of service
design include:
■ Using the service package as input to the process; this
ultimately results in one or more detailed service design
packages
■ Registering the services within the service catalogue, or
noting them for future registration, depending upon local
policies
■ Recruiting third-party suppliers where required
■ Constructing baseline SLAs, OLAs and underpinning
contracts
■ Addressing any specific service management requirements
■ Considering the key requirements of availability, capacity,
security and service continuity
■ Considering systems and event management requirements
and specifying measurement, alerting and reporting systems.
Some popular misconceptions
‘My clients have their own processes so they won’t use mine.’
A blended service management approach is often required in
commercial engagement models. By adopting the core ITIL
principles the managed service provider is better positioned
to engage in such discussions with its client from a position
of knowledge and strength. Elements of both the client’s
and the managed service provider’s processes can then be
engineered to work in harmony during the service design and
service transition stages for the specific client engagement.
Simply because a client has its own service governance model
does not exclude the introduction of ITIL-aligned managed
service provider processes – quite the opposite, in fact. Service
strategy actively encourages client organizations to engage with
providers who are compliant with ISO/IEC 20000 standards.
Doing so helps clients minimize the risk from outsourcing of the
affected services.
Managed service providers who follow ITIL are more likely to be
successful in the supplier selection process of those clients than
those who do not.
‘Customers always complain – if I’m hitting the SLAs it can’t be
that bad.’
SLAs need to be aligned to the critical success factors of the
business. If there is a mismatch when the SLAs are agreed
during service design then the service will invariably fail to meet
the overall business objectives.
Figure 3 Lifecycle summary – service design

9. ITIL®
for managed service providers 9
© The Stationery Office 2013
Focusing too much on mechanistically adhering to SLAs can be
damaging to the client relationship and the end-user service as
a whole if (a) the service is not viewed in its entirety, and (b) if
the SLAs themselves do not adequately align with the overall
business objectives.
SLAs vary greatly depending upon the services being offered.
For product-based managed service providers or providers who
deliver largely commoditized services, these are typically rigid
agreements leaving little room for negotiation. These providers
generate value for their own businesses by having a large
number of near-identical client engagements.
At the other end of the scale, managed service providers who
provide highly customized services combining a range of service
components into a bespoke offering for a single client will
inevitably need to negotiate a specific set of SLAs for that one
engagement. Internal OLAs and underpinning contracts with
sub-contractors need to be negotiated in parallel to ensure the
risk profile remains acceptable. At the same time, managed
service providers should not lose sight of the need to remain
commercially competitive and deliver value to all stakeholders.
This is a difficult balance to strike and is the first point in the
relationship where the sales pitch can easily turn into far more
challenging discussions. These negotiations generally set the
tone for the lifetime of the service, and it is vitally important
that they are undertaken in a professional and consultative
manner. They should not promise too much nor devalue the
overall service proposition.
The managed service provider must ensure all SLA targets
adhere to the SMART acronym (Specific, Measurable,
Achievable, Relevant and Time-bound), and avoid being
inadvertently coerced into continuing the inevitably more
ambiguous messaging that may have shrouded the sales cycle
up to that point.
The key business benefits communicated during that sales
process need to be reflected in the SLA. If the SLA bears little
or no resemblance to the business case then it will either
be dismissed out of hand by the client or, even worse, the
managed service provider and client will be working to totally
different agendas. Poorly constructed SLAs can result in the
situation where a managed service provider is measuring and
reporting on metrics that have no direct influence on the
success (or otherwise) of its client. This is where one of the
core doctrines of ITIL – to align IT with the business – has been
disregarded and the relationship between the managed service
provider and the client will undoubtedly suffer as a result. The
construction of SLAs can be time-consuming, and rightly so.
It is dangerous to view the SLA as part of the clerical activities
of drawing up contracts, under the misconception that these
things will be corrected later.
The managed service provider should also review the SLAs,
OLAs and underpinning contracts on a regular basis during
service operation, especially during periods of significant
business change or IT system change, to ensure that the
business alignment remains. In this way, continued
consistency of the IT services and the business objectives is
maintained and, for the managed service provider, it also
generates opportunities for incremental revenue. Section 4
highlights how a clear service scope, coupled with a structured
change management process, can make the difference
between commercial success and failure for the managed
service provider.
Critical success factors for service design
The factors that will make a managed service provider’s service
design successful are:
■■ A successful translation of the business case from service
strategy into a more tangible service design package
■■ The construction of a consistent set of agreements that align
with the intended services, and protect the managed service
provider while delivering value to all stakeholders
■■ Measurement and management systems, with supporting
processes, to ensure that a baseline for continual service
improvement can be defined
■■ Buy-in from all stakeholders and confirmation that
the business objectives defined in service strategy are
still attainable as the process moves to the service
transition stage.
4 Service transition
Service transitions come in various guises for managed service
providers, each of these bringing its own specific considerations
and opportunities. Figure 4 provides a summary of the service
transition stage of the lifecycle.
The three most common types of transition in a managed
service provider business are:
■■ New systems coming into service for the first time. These
break down into two sub-categories:
–– Those that have been developed or constructed by the
managed service provider’s own organization and are
now moving into the service operation stage. We will
term these build-and-run transitions for the purposes of
this paper.
–– A new system that has been developed by the client or
another third-party organization for which the client is
now requesting service from the managed service
provider.
■■ Existing systems for which the managed service provider is
inheriting support responsibilities, either from another
third-party provider or from an insourced team as part of a
(selective) outsourcing arrangement
■■ Major change to systems already supported by the managed
service provider.

10. 10 ITIL®
for managed service providers
© The Stationery Office 2013
Without doubt, the most challenging of all the above is
the build-and-run transition. There are many reasons for
this, including:
■ The client believes, quite correctly, that it is receiving
continuity of services from a single service provider for both
the ‘build’ and ‘run’ elements.
■ In the majority of cases, however, the project to build the
solution will have been executed by a separate division of the
service provider organization from the one that is destined to
run it for the longer term.
■ The project team’s objectives are typically to complete the
work as promptly and efficiently as possible so that it can
move to the next engagement as soon as user acceptance
has been achieved. The support organization aspires to
inherit a system that has been rigorously tested, is fully
documented and will attain a steady support state in record
timing. There is clear scope for a misalignment of objectives
here.
■ The client, as mentioned previously, is dealing with a single
organization so does not anticipate a handover of
responsibilities between groups and is unlikely to want to
fund such a handover as part of its service transition fee.
■ To add further risk, the client’s perception is often that,
because the service provider is not simply walking away, it
does not need to undertake a rigorous level of user
acceptance testing as the managed service provider will still
be around to fix any issues after the go-live date.
If the service is not correctly designed earlier in the lifecycle and
managed appropriately during the actual transition, all of these
factors will combine to make a very dangerous situation where
the client’s first impressions of the managed service provider are
irreparably damaged at the outset. A formal and transparent
service transition project is vital for the successful navigation of
this lifecycle stage.
ITIL dictates that value can only be delivered when both utility
and warranty are present (see ITIL’s value formula depicted in
Figure 5).
Warranty ensures that a service is fit for use and utility
ensures that it is fit for purpose.
Without warranty, for example, a payroll system may calculate
people’s salaries correctly, but that is of no value if the system is
unavailable each pay day, or performs so slowly that people are
not paid on time. Conversely, if a system is technically robust
but functionally flawed, this is also of no overall benefit.
In build-and-run transitions the two phases can sometimes
concentrate too heavily on one aspect of the value function,
only for the service transition phase or, worse, issues with
the production system to highlight this imbalance too late in
the day.
There is no single ‘silver bullet’ to ensure success on build-and-
run transitions. However, some combination of the following
techniques will help minimize the risk of major failure:
■ Ensure that the service transition activities are agreed,
documented and clearly communicated during the service
design stage.
Figure 5 Services are designed, built and delivered with
both utility and warranty
Copyright © AXELOS Limited. Reproduced under licence from AXELOS Limited
– ITIL Service Transition, Figure 2.2
Figure 4 Lifecycle summary – service transition

11. ITIL®
for managed service providers 11
© The Stationery Office 2013
■■ Ensure that the client is fully informed of the complexities in
any service transition of this type. It is tempting to
oversimplify this process, especially during the sales cycle,
but well-informed and mature clients will be supportive of
the challenges if they feel part of the project rather than
being left ill-informed of the risks to their business and
personal reputations.
■■ The managed service provider should ensure that the client
fully understands its own responsibility to undertake an
appropriate level of user acceptance testing and due
diligence of the system before permitting it to go live. This
can be encouraged through the introduction of ‘as built’
clauses (where the client pays for any remedial actions for
defects which were not highlighted in its acceptance of the
solution), SLA amnesties and other such techniques.
However, these can appear punitive if not positioned in the
overall context of striving for joint success.
■■ Do not underestimate the elapsed time or resource
requirements to enable a knowledge transfer between the
different parts of the service provider organization.
■■ Well in advance of the project actually commencing, agree at
what point the project team will be released from its
obligations. That trigger point is often the end of user
acceptance testing and the managed service provider
becomes responsible for a system of which it has limited
knowledge before it has even gone live. One way to avoid
this is to include service transition and early life support (ELS)
as integral phases within the ‘build’ project plan and not to
allow the project team to exit the client engagement until
such time as the system has attained pre-agreed service
performance targets (volume and severity of defects raised,
number of incidents logged etc.).
■■ Provide financial incentives for the stakeholders to work
collaboratively during the service transition:
–– Clients may benefit from a reduced project or service fee
if they actively participate
–– In larger service providers the ‘build’ and ‘run’ teams may
operate under separate internal profit-and-loss controls
and this can frequently drive incorrect behaviours unless
checked. All parties must be encouraged to work toward
the single shared goal of successful transition.
■■ Promote a one-team approach by seeding members of the
support organization into the project team, or rotating staff
members from projects into support on a project-by-project
basis. This also helps to transfer knowledge into the ongoing
support functions.
■■ Ensure that the key foundations for achieving warranty are
not overlooked in the ‘build’ phase. A business application
may deliver utility, but it should not enter into production if:
–– It is not being proactively monitored by an effective event
management system
–– It has not been load-tested to ensure sufficient capacity
–– Failover to the secondary data centre has not been tested
to confirm business continuity
■■ Clients who are not actively involved in the transition process
may focus their testing primarily on the utility aspect. The
warranty aspects of the solution should be considered at the
design stage and built into the transition plan so as not to be
inadvertently overlooked or intentionally bypassed.
Other non-build-and-run transitions are much less complicated
to manage into service and generally include a sub-set of the
considerations above.
Some popular misconceptions
‘Service transition is the responsibility of the managed
service provider.’
This is incorrect. As with all aspects of a multi-party service,
all stakeholders have a joint responsibility to ensure success.
A single-team approach with clear objectives and cross-party
responsibilities is vital to the success here. A RACI model
showing who is responsible, accountable, consulted and
informed is an excellent technique to help govern service
transition activities.
‘Change management is a bureaucratic and time-consuming
process that is normally circumvented in some way.’
This is also clearly incorrect. The statement above applies
if the change management process is badly designed and
implemented, but change management should form a vital part
of a strong service management ecosystem.
As a managed service provider is a commercial organization,
the change management (and also request fulfilment) process
can help it to achieve incremental revenue. In most cases, the
managed service provider can charge more money for changes
and enhancements to systems. A client will be happy to fund
these changes as long as they are adding measurable value to
its operations.
On the other hand, when individuals circumvent the change
management process (typically by including it as part of incident
management or problem management), not only do they risk
damaging the overall stability of the solution but they also
give the client free incremental benefits for which they could
be charging more money. An effective change management
system, backed by a well-structured education campaign, can
often make the difference between the success and failure of a
service engagement between the managed service provider and
the client.
One way of making the change management process
more usable and streamlined is to actively encourage the
development of a library of standard service requests for
more commonly occurring system changes. The managed
service provider can then potentially automate these activities,
promoting such features as self-service provisioning, to minimize
risk for the client and maximize its own commercial benefit.

12. 12 ITIL®
for managed service providers
© The Stationery Office 2013
‘The customer has its own change management process so we
don’t need our own.’
The choice of whose system and processes are to be used is
not clear-cut and is not necessarily a simple discussion about
whether to use one or the other.
There will indeed be cases where clients have mature and
robust change management processes already in place. Using
these can be the logical choice from a client governance
perspective, especially in multi-sourced arrangements where the
client has to consider a broader impact footprint than the single
service that the managed service provider may be delivering.
However, such processes will have been designed by the client,
for the client, and may not take into consideration the service
provider’s requirement to manage its own risk and control its
own commercial implications.
Hence, the managed service provider must undertake a
gap analysis of the client’s processes in the light of its own
requirements and either augment this with its own additional
processes or, in some situations, work with both change
management systems should the need arise. Of course, there
will be occasions when one or other system fulfils all the
stakeholders’ requirements, in which case the single-system
approach is fine. The managed service provider must not,
however, settle for a single system which fulfils most but not all
of its own internal governance requirements.
This is a key decision which affects the commercial balance of
an agreement, so it should be considered during the service
design stage when contracts and SLAs are being constructed.
‘Release management is part of the change management
process.’
ITIL correctly states that a release comprises one or more
change requests so, by definition, these are two distinctly
separate but related processes. Unfortunately, this concept is
not upheld by the majority of the software tool vendors who
provide IT service management products. Consequently the
process evolves into one where release management is either
dropped as a separately defined discipline altogether, or into
a one-to-one mapping between change requests and
release results.
Such compromises can introduce issues whereby, for example,
one change needs to be released into multiple environments
and is not accurately tracked, or where a release could
legitimately be partially rolled back due to the failure of a
single change.
The lack of granularity in tracking such activities can cause
confusion and increases the risk of incorrect results being
assumed and catalogued as such in the configuration
management system (CMS). The ability to track the status of
all configuration items (CIs) accurately through the change
management and release management processes is vitally
important to the integrity of the overall service.
‘To manage change effectively you must have a single,
consolidated configuration management system.’
This is incorrect on two footings.
Firstly, the lack of a formal CMS can, if permitted, be used
as an excuse for bypassing the change management process
and introducing the resultant issues described above. Change
management is still a mandatory discipline and can function,
albeit to a more limited extent, without the presence of a CMS.
Secondly, the once-held view that configuration management
was predicated on having a single master database, the
configuration management database (CMDB) that contains all
CI metadata, is no longer represented in ITIL best practice. A
federated model, whereby configuration data is maintained
in an array of controlled sources (paper files, spreadsheets,
databases, version control systems etc.), is equally compliant
with best practice. What is more important is that the content
of those repositories is maintained in a controlled manner that
accurately reflects the real-world status of the systems in which
those CIs are used.
Critical success factors for service transition
The factors that will make a managed service provider’s service
transition successful are:
■■ A clearly defined service transition process where all
stakeholders share the same goals and are actively
encouraged to achieve them in a collaborative manner
■■ A usable, non-bureaucratic, yet enforced change
management process, supported by an effective CMS
■■ A clear set of acceptance tests for the service being agreed
during the service design process and managed under a
robust validation and testing process.
5 Service operation
The service operation lifecycle stage contains those processes
most commonly associated with the work of managed
service providers. This is particularly so in the case of incident
management, which is where most providers start on their ITIL
adoption journey. Figure 6 provides a summary of the service
operation stage of the lifecycle.
Clearly there is more to ITIL and good service management than
the reactive management of incidents.
Service operation begins where service transition leaves off
and, as mentioned in section 4, a successful transition can
itself continue well into production, running in the form of
early life support (ELS). It is, however, vitally important that
ELS is managed in accordance with the service operation
framework, with all potential defects being tracked through
incident management and problem management (where
required), potentially also looping back into change and release
management. Without this, the perception of the service will be

13. ITIL®
for managed service providers 13
© The Stationery Office 2013
that it is not truly ‘live’, and introducing a formal process will be
much more difficult at a less clearly defined later stage in
its evolution.
From a client perspective, the key processes of event
management, incident management, problem management
and request fulfilment are all present to ensure that value is
delivered to their end-users. This statement also stands in the
case of the managed service provider and, additionally, the
correct application of these disciplines enables the managed
service provider to commercially manage the account in a far
more effective manner. ITIL’s definitions of these processes (see
the glossary in ITIL Service Operation) provide a framework
within which the managed service provider can draw clear
demarcation lines between those elements of the service that
are included and those that are not. By adopting and, where
necessary, liberally quoting ITIL processes, the managed service
provider can successfully navigate discussions which might
otherwise have been far more challenging had the processes
appeared to be the managed service provider’s own policy
rather than industry best practice.
Adopting an effective problem management approach can
reduce the amount of labour the managed service provider
is required to provide to service the client and allows them
to potentially redeploy that resource on other revenue-
generating activities.
Once a managed service provider has a clear library of service
requests it can subtly encourage the client to use these, thereby
cutting down on any unnecessary administrative overhead from
processing such changes through change management and
release management. The managed service provider can then
benefit from automation and self-service techniques to further
reduce the resource demand and associated operating costs.
Although these actions may appear slightly underhand, they
would not be successful if the managed service provider did
not deliver value to the client’s business as a result. Both parties
also benefit from continual service improvement and, when the
agreement eventually becomes due for renewal, are more likely
to wish to continue the relationship and look at more creative
ways of ensuring that the services evolve rather than become
static and wither in the light of business change.
Some popular misconceptions
‘It’s just a ticketing system.’
To managed service providers, an effective ITIL implementation
is clearly more substantial and more beneficial to all parties than
simply taking a standard helpdesk application and renaming the
‘ticket’ entity as an ‘incident’.
Any managed service provider who thinks that by introducing
incident management and using the correct terminology it will
be instantly aligned with ITIL is sadly mistaken. Although this
is undoubtedly a step in the right direction, it is by no means
where the managed service provider should be aspiring or
planning to be. Only by coupling incident management with the
other processes is the true benefit realized.
Although IT systems naturally tend to excite technologists,
choosing the correct service management tool should be the
final step in determining the managed service provider’s service
approach. The overriding business case, the core processes,
the desired outcomes and the marketability of the approach
need to be considered prior to starting to look for platforms to
help fulfil these. Rest assured, there are many tools out there to
choose from once the managed service provider has decided on
its own service governance approach.
Another common tools-based consideration for the managed
service provider is whether it should integrate its own service
management systems with those of the client and potentially
other third-party providers. The benefits of such integration are
clear in that it provides a single, consistent view of the service
and eradicates the effort and risk of double-keying data into
multiple systems. However, the challenges of achieving such a
seamless integration should not be overlooked and these are
rarely considered in sufficient detail before embarking on such a
project. Common failings include:
Figure 6 Lifecycle summary – service operation

14. 14 ITIL®
for managed service providers
© The Stationery Office 2013
■ Systems having conversations with each other without any
human involvement. For example: ‘Thank you for your
request. Here is your incident ID.’ ‘Thank you for your
request. Here is your incident ID’ and so on
■ Tightly integrated systems limiting agility and restricting
future development of the core service management
application
■ Underestimating the complexity of mapping the different
workflows and request status changes between the systems
■ Complex systems interfaces being developed and maintained
for a relatively low volume of actual transactions.
As with all projects, the user requirements and business case
for change should be clearly documented and agreed prior to
embarking on any form of development activity.
With the increase of multi-sourced service engagements and
the upsurge in cloud-based service management tools, there is
undoubtedly a business case for a common standard or hub for
integrating such applications. Until then, the basic rules of any
software project undertaking should apply.
‘Problem management is just incident management
without SLAs.’
Problem management and incident management are
fundamentally different both in their reasons for being and the
way in which they operate. Primarily through ignorance of the
very tangible benefits which an effective problem management
process can bring to a service, two things can happen:
■ Managed service providers can unscrupulously redesignate
incident records as problem records to avoid any related SLA
targets
■ Clients can demand artificial time-bound restrictions on the
resolution of problem records, thus turning them back into
incidents and not actually addressing the root cause.
More appropriate key performance indicators can be used to
help guide problem management without negating the benefit
that it brings. These generally measure the overall problem
management process rather than individual incidents, and are
calculated over an extended period of time when compared
to incident management. This has a key positive influence on
continual service improvement.
Critical success factors for service operation
The factors that will make a managed service provider’s service
operation successful are:
■ A clear and conjoined set of processes governing each of the
core service operation processes. Each must comply with the
underlying ITIL principles
■ An event management solution that tests and reports on
metrics which are aligned with the SLA and business
objectives of the IT service
■ Proactive service operation in the form of an effective
problem management approach.
6 Continual service
improvement
The two underpinning principles of ITIL are to align IT with
the business and to drive continual service improvement
(CSI). These remain just as relevant in commercial service
management relationships as they are in traditional insourced
delivery operations. Figure 7 provides a summary of the CSI
stage of the lifecycle.
To improve a service you first need to be able to measure it
and report against a relevant set of metrics. Accurate and
timely measurement is dependent upon deploying tools
and reports that not only review the system being managed
(performance times, availability etc.) but also report on the
service management processes (SLA adherence, incident ageing,
problem management ratios etc.).
Additionally, the subjective measurement of client perception
is of equal, if not greater, importance to the more mechanistic
measurement of system and process metrics. In a managed
service provider/client relationship, SLA compliance levels
count for little if the key client contacts do not actually enjoy
working with the managed service provider. Gauging customer
satisfaction is a vital component in ensuring that the service is
continuing to deliver value in the eyes of the individuals who
will ultimately have a say in whether the service agreement is
renewed when it has run its term.
Figure 7 Lifecycle summary – continual service improvement

15. ITIL®
for managed service providers 15
© The Stationery Office 2013
The managed service provider should also be reporting metrics
for its own internal continual service improvement, with a focus
on ‘doing more for less’, driving improved services to the client
with a lower cost base for delivering those services. Process and
technology efficiencies can often make the difference between
commercial success and failure for a managed service provider.
The client should encourage the managed service provider to
succeed as, without that success, there will be no service and all
stakeholders will suffer.
The managed service provider and the client should regularly
discuss improvement initiatives in the form of service
improvement plan review sessions. These discussions may form
part of the normal service review cycle or they may be held
during a periodic specific improvement-focused session.
The accurate measurement of, and striving for improvement
in, service metrics has taken on added significance with the
advent of performance-based payment incentives. In this
model, managed service providers are either rewarded for
improved service levels or penalized for lack of improvements
as promised. This kind of risk/reward model, where the service
provider is rewarded based on delivering real business benefit, is
only possible when the measurement system aligns IT with that
business, and is trusted by all parties.
Any managed service provider who is unable to measure
service metrics at such a level will disqualify itself from
potential business, as event management and reporting
capabilities are now critical not only to technological wellbeing
but also to the future growth and success of the managed
service provider’s business.
The Deming Cycle of Plan-Do-Check-Act (see Figure 8) and
the ITIL seven-step improvement process have never been as
important as they are today in a modern relationship between a
client and its managed service provider.
Effective quality
improvement
CHECK
PLANACT
DO
Timescale
Maturitylevel
Consolidation of the level reached
i.e. baseline
Business
IT
alignment
Plan Project plan
Do Project
Check Audit
Act New actions
Continual quality control and consolidation
Figure 8 Plan-Do-Check-Act cycle
Copyright © AXELOS Limited. Reproduced under licence from AXELOS Limited
– ITIL Continual Service Improvement, Figure 2.8
To help drive CSI, many service providers now reward their
personnel with a bonus payment or other such incentives based
on these measurements. This can be a highly effective way of
delivering value to the client while also protecting the managed
service provider’s continued relationship with the customer.
A popular misconception
‘Continual service improvement? It must be monthly
report time.’
Continual service improvement – the production of service
reports and the overall review of service performance – should
not just be a daily activity that is performed solely because it
is a contractual commitment between the managed service
provider and the client. It must focus on acting on the findings
of the service performance reports, communicating actions
and progress against these to all involved parties, and driving a
steady rate of controlled, forward-momentum change.
Critical success factors for continual
service improvement
The factors that will make a managed service provider’s CSI
successful are:
■■ A measurement and reporting solution that is trusted and
aligned with business goals
■■ A communications and education programme based on
encouraging continual service improvement, with shared
goals for all parties
■■ Client buy-in to allow the managed service provider to
benefit from driving improvement.
7 Summary
In recent years ITIL has become far more applicable to
commercial service management engagements and, when
introduced in a considered manner, will actively contribute to
the success and wellbeing of all stakeholders.
Managed service providers who fail to adopt this best
practice will find themselves being disqualified from business
opportunities, becoming incompatible with other providers
who deliver to the same clients, and failing to capitalize on the
delivery efficiencies of the common-sense approach of ITIL.
Managed service providers who have previously paid lip service
to ITIL, using it primarily as a marketing badge, are now being
exposed by better-educated buyers who are demanding
tangible evidence of robust service management discipline
and showing a willingness to reward those providers based on
shared business success.
There are potential pitfalls along the road to deployment, but
a pragmatic and staged approach leveraging the wealth of
knowledge available in the ITIL publications and other public
domain sources will ensure a rewarding path to opportunity and
service success.

16. 16 ITIL®
for managed service providers
© The Stationery Office 2013
References
Cabinet Office (2011). ITIL Continual Service Improvement. The
Stationery Office, London.
Cabinet Office (2011). ITIL Service Design. The Stationery Office,
London.
Cabinet Office (2011). ITIL Service Operation. The Stationery
Office, London.
Cabinet Office (2011). ITIL Service Strategy. The Stationery
Office, London.
Cabinet Office (2011). ITIL Service Transition. The Stationery
Office, London.
Gartner (2009). User Survey Analysis: Economic Pressures Drive
Cost-Oriented Outsourcing, Worldwide, 2008–2009. Available
from www.gartner.com
About the author
Brian McCabe is a chartered IT professional with over 25
years’ experience of delivering IT systems. Originally from a
technical background, Brian is an ITIL Version 3 Expert and
an official reviewer of ITIL Continual Service Improvement
(Cabinet Office, 2011). Brian specializes in building and
growing service delivery organizations and is a director of the
London-based Oracle specialist consulting and services firm,
Mokum Change Management.
Reviewers
AXELOS Limited and TSO would like to thank Lou Hunnebeck
(Third Sky Inc.) and Jonathan Wright for reviewing this
White Paper.
Acknowledgements
Sourced by TSO and published on
www.best-management-practice.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 use of or reliance on its content. While every
effort is made to ensure the accuracy and reliability of the
information, TSO 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.
© Copyright TSO and Crown. Reuse of this White Paper is
permitted solely in accordance with the permission terms at
http://www.best-management-practice.com/Knowledge-
Centre/White-Papers/
A copy of these terms can be provided on application to Best
Management Practice White Paper Permissions, TSO, St Crispins,
Duke St, Norwich, Norfolk, NR3 1PD, United Kingdom.
Trade marks and statements
ITIL®
is a registered trade mark of the AXELOS Limited.