Eating an Elephant: Service Catalog vs. Service Portfolio

Share twitterlinkedinmail

During my recent BrightTalk webinar, “Five PDG (Pretty Darn Good) Reasons to Define a Service Catalog”, I was asked for my thoughts regarding starting the Service Catalog when the Service Portfolio was not in-place or defined.

The Service Portfolio is made up of three components:

  • Service Pipeline – Services that are being discussed or designed, but are not yet available for deployment
  • Service Catalog – “Live” services or services that are available for deployment
  • Retired Services– Services that are or were in-use, but are now no longer available for deployment

As you can see, the Service Portfolio represents every Service within an organization.  It is a significant commitment by an organization, moving from a mentality of “my component” to “our services”.  Many organizations struggle even to define their “live” services, much less those services that are (should be) retired or in the pipeline.   “Services” are often confused with “products” or “activities”; both of which may be components of a services, but in and of themselves, are not “services”.

From my perspective, defining and maintaining a Service Portfolio is much like the proverbial “eating of the elephant”. You can’t eat an elephant in a single bite.  Likewise, you won’t be able to define a Service Portfolio in a single bite.   So which to do first–Service Catalog or Service Portfolio?  My advice–start with the Service Catalog.


First, this will force you to come to grips with the definition of “service” – the valuable outcome(s) that customers want without having to own the specific risks and costs of delivering and supporting that outcome.  So what is a “service”?  To use a simple analogy, consider an oil change.  The customer simply wants the oil changed in their car—they don’t want to worry about the disposal of the used oil, the maintaining of the inventory of oil and oil filters, being trained on how to change the oil, and all of the other things that are needed to deliver that outcome—having fresh oil and a new filter for their car. Defining what is and is not a service is the crucial first step.

Secondly, it allows you to focus on those things that should be known and familiar – the things the IT organization is doing today – as you start to win hearts and minds in the cultural shift to an outcome-based, value-added, service-oriented IT organization. It helps the organization recognize and understand how their specific contributions enable those outcomes to be realized by the customer.

Okay, so now “how”?

First, establish the “boundaries” for the Service Catalog. A service is either “in” or “out”.  As you identify services, determine whether those services are “in” – as in “in use”- or not.  If a service is “in”, it goes into your Service Catalog.  If a service is “out”, then this service should appear somewhere else in the Service Portfolio.

Then, for those services that are “out”, or somewhere within the other parts of the Service Portfolio, the choice is either “coming” or “going”. Simply put, if the service is “coming”—under development, being discussed – then that service definition should be included in the Service Pipeline.  If the service is “going”, then the service definition should appear in Retired Services.

Once you’ve completed this exercise, you’ve developed the basics of a Service Portfolio. Keep in mind that you won’t get this done in “two weeks”—it will take some time, thought, planning, and discussion.  To really exploit and embed the concept, you’ll need to decide things like how and when new projects are represented in the Service Pipeline.  Likewise, you’ll need to decide when and how Services move from the Catalog to Retired Services.  Use of the Portfolio for evaluating emerging business needs against existing solutions will need to be decided.  Service Owners must be named to maintain service descriptions, represent the service throughout the organization, and manage the lifecycle of the service.   A critical success factor in this work is to include the Customer as part of the definition and design of the Service Portfolio.    Who better than the Customer than to help us understand the outcome and value that a service should provide?  By including the Customer, acceptance of the portfolio approach and your chances for success improve dramatically.

One bite at a time…

Click here to subscribe to my newsletter!

Share twitterlinkedinmail

One thought on “Eating an Elephant: Service Catalog vs. Service Portfolio”

Leave a Reply

Your email address will not be published. Required fields are marked *