Keep up-to-date with ITIL news. Low volume to-the-point bulletins...
ITIL V3 Service Portfolio and Lifecycle
Within the ITIL Service Design book you will find the Service Portfolio. The ITIL Service Portfolio contains the status of all services that IS currently offers, have offered in the past and also those that maybe simply 'pipe dreams', 'nice to have' or ideas for the future. The Portfolio is comprised of three sections:
  • Service Pipeline
  • Service Catalogue
  • Retired Services
As a service progresses through the Service Lifecycle it is allocated a relevant status. The statuses are described below:
  • Requirements - set of outline requirements received from the business / IT for a new or changed service
  • Defined - set of requirements for a new service are being assessed, defined and documented and the Service Level Requirements (SLRs) being produced
  • Analyzed - set of requirements for a new service are being analyzed / prioritized
  • Approved - set of requirements for a new service being finalized / authorized
  • Chartered - new service requirements are being communicated, resources and budget allocated
  • Designed - the new service and its constituent components are being designed and procured as required
  • Developed - the service and its constituent components are being developed or harvested as required
  • Built - the service and its constituent components are being built
  • Test - the service and its constituent components are being tested
  • Released - the service and its constituent components are being released
  • Operational - the service and its constituent components are operational within the live environment
  • Retired - the service and its constituent components are being retired
A service at any time can be 'retired', especially when it is progressing as a 'project' in the pipeline phase. During the 'Credit Crunch' it has been necessary for many organizations to review their current Service Portfolio and in some cases 'shelve', 'moth-ball' or in other words 'retire' a service(s). In the future these services may well be re-initiated and follow the Service Lifecycle again.
Regarding the capturing of 'requirements' the Request for Change (RFC) element of Change Management would be ideally positioned.
From the 'defined' through to the 'test' service statuses a project management methodology (for example Prince2) could be utilized. In organizations where the number of services is considerable, the introduction of a Project Office facility may be beneficial to ensure the Service Portfolio is kept up to date.
The figure below illustrates where the various Service Status items fit in the Service Lifecycle.


2014-09-11 by "anna"

When reading the service design itil book 2007 it says that the service catalogue phase is between "chartered" and "operational", not only "released" and "operational" as the picture above shows.

2014-11-17 by "nadim.ahmed"

While the above defines the Service Portfolio well enough, what's not said is how a Service Portfolio is used and what benefits it provides. For instance, how are services to be authorized before they go on the list? In order to keep a portfolio from becoming a loose or overlapping wish list of services, what's a good decision rule for adding to the pipeline? What are the required data elelments in a portfolio, etc...?
Reply on 2014-11-21
Many thanks for your question. The article referred to was not intended to outline the uses and the benefits of the Service Portfolio, but to simply illustrate the lifecycle a service may well undertake.

A question worthy of consideration for any organization before adopting the Service Portfolio is what audience will have visibility of its contents.

The reason for raising the question is that strategic decisions undertaken at Board level regarding existing and potential services may need to be kept restricted until a decision is taken to release some or all information. The question mentioned then leads into your question 'how are services to be authorized before they go on the list?'.

From my experience Change Management would manage this aspect of the Service Portfolio together with the removal from the Service Portfolio.

Regarding the data elements in the portfolio they will vary, for instance the example above regarding the Board strategic decisions may culminate initially in a code word being used to represent a service in the portfolio, later it may be renamed again using the services of Change Management. As a Service progresses through the Service Portfolio more information will be attributed to the Service until it reaches the 'Operational' or 'Released' stage whereby certain key information must be provided. For more information on this aspect please refer to the following article:

How to produce a Service Catalogue

I hope the above assists when considering the introduction of a Service Portfolio.
There is 2 comment awaiting publication.

Please submit any comments you have about this article.

Your feedback will help add value to the content for other visitors and help us develop the content for the benefit of all.

You will need to provide and verify your e-mail address but your personal information will not be published or passed on to others. To identify each post we take the part of your email address before the @ sign and use that as the identifier, so if you are your post will be marked "by john.smith".

NB: We respond personally to every post, if it calls for it.

If you prefer to respond without posting your comment please use our contact form.

Click the REVIEW button below to preview your comments.

Tags; ITIL V3,Service Portfolio and Lifecycle,ITIL Service Design,Service Portfolio
This article has been viewed 67851 times.
NB: This page is © Copyright and / or the relevant publishing author. You may copy this article only in it's entirety, including any author bio and / or credits, and you must link back to

Keeping up-to-date with ITIL...

Keep up-to-date with ITIL news. Low volume to-the-point bulletins...