Portfolio of Services

So having established what the building blocks for a service are we will now seek to demystify the subject of the Service Portfolio.

The Service Portfolio has three components – the Pipeline of chartered services, the operational Catalogue and the Retired services (withdrawn / mothballed / decommissioned).  

Page 24 of the Service Strategy book describes the need to define customer facing services and supporting services.  Customer facing is the only part of the Service Portfolio published to customers. The Service Catalogue sets out the discrete service assets and respective link to business activities and outcomes.  Therefore it is important to establish a catalogue of services that contribute to strategic business objectives. 

The Business Relationship Manager will work with the business customers to define the description of the new or changed service that is captured in the Service Catalogue.  In my experience there is no need for a customer agreement portfolio because it sounds transactional to me and not particularly partnerial.  The BRM should map business demand patterns (that require an increase in compute)  to appropriate services and provide advance notice of these changing requirements to the Service Owner in the Service Provider organisation.  Additionally the BRM should periodically check with the Business stakeholders whether the desired outcomes are still valid.

The Service Portfolio is viewed as the steward of the Service Assets that are key to delivering business objectives.  Service Portfolio Management is about making sure that the Service Portfolio has a comprehensive view of all the discrete services that are provided. The “good book” [Service Strategy] fails to distinguish between Internal and External Service Providers.  So in the diagram above the Service Portfolio should be owned by the Retained Organisation but the CMS and downstream information stores may be owned externally and will appear as a black box especially if they are Cloud Based Services.

The difference between the Service Pipeline and the Project Portfolio is not clear to me.  Most clients have a single integrated Investment Portfolio tool [e.g Clarity] from which they make informed decisions about how they will approve budget expenditure.  When a development project moves through the V Model [waterfall] or Agile development lifecycle the Service Provider should be engaged to conduct Operational Acceptance and Service Readiness. Given this, why do we need a Project Portfolio in the Service Management Knowledge System?

The Service Catalogue is the single source of consistent information on all the operational (live and testing?) services and those being prepared to be run operationally [Service Transition]. It identifies business units and customer groups. There is limited value in defining the supporting services {Technical View] because these are likely to be outsourced to a lower cost provider.  In this example the CMS has a core set of Configuration Items that relate to Information and Applications rather than physical technical components.  Where open source code is in use then distributed version control systems which are available in the cloud [gitHUB] should be considered.

There is no single correct way to structure and deploy the Service Catalogue.  Each Service Provider organisation should consider their current and evolving needs. Service Design Page 58 states that the Service Architecture provides the independent business integrated approach to delivering services and the management of those services.  

If you are keen to understand how best to structure your Service Catalogue you could identify your Service Assets in the form of Capabilities and Resources which could be very helpful because the guidance provided in the Service Design core volume is not consistent. 

On page 55 there is a list of typical items that should be included in the Service Catalogue:  Service Name,  Service Version,  Service Description,  Service Status,  Service Classification and Criticality, Applications Used, Data and/or data schema used, Business process supported, Business Owners, Business Users, IT Owners, Warranty level, SLA and  SLR references, Supporting services, Supporting resources, Dependent services, Supporting OLAs, contracts and agreements, Service costs, Service charges, Service revenue, Service metrics. 

The same core volume in Appendix G page 335 Table G.1 provides the following Service catalogue example:  Service description, Service type, Supporting services, Business owners, Business units, Service owners, Business impact, Business priority, SLA, Service hours, Business contacts, Escalation contacts, Service reports, Service reviews, Security rating.

A good place to start is to request to view the Business Continuity Plan [Red Book or online version] which describes the critical Business Processes and their key outputs.  This document also sets out the regulatory, reputational and financial risk to the business in the event of loss of business capability.  In addition the impact on the customer experience is also listed [e.g number of customers impacted if the ATM service is down for an hour on the last Friday in the month].  When these requirements are captured it is then possible to create a meaningful and relevant service catalogue incorporating some of the parameters listed above.

With respect to Retired services this should be classified as a status flag in the Service Catalogue. 

Providing Information Services to the Business