Service Portfolio Management


Service Portfolio Management is the process responsible for the assembly of an initial Service Design Package (SDP) for each service and its maintenance through the service life cycle. This also involves cooperating with the Continual Service Improvement Process. The SDP may be altered and extended by other Service Management processes. However, Service Portfolio Management is the process retaining ownership and overall responsibility for all Shops, in particular for all service descriptions and documentation. The entirety of all available Saps will form the Service Portfolio. Since customers should be provided with a customer-specific view on this portfolio – the Service Catalog – Service Catalog Administration is an important administrative sub process related to Service Portfolio Management.

Although Continual Service Improvement Process is gaining more and more importance in recent discussions, in our understanding is is part of the Service Portfolio Management. This understanding helps to:

  • reduce the complexity of IT service methods and processes
  • increase the understanding for the correlation of IT service management


The purpose of Service Portfolio Management is to create, manage and improve a service portfolio containing a detailed design package for each IT service.

Service Portfolio Management contributes to an integrated Service Management approach by achieving the following goals:

  • Every service planned and operated by the provider is documented.
  • Every new service runs through a set of standardized activities and procedures to ensure that essential management-relevant information, for service delivery and support, are documented and provided to the relevant management processes.
  • Every service and their design packages are reviewed at regular intervals.
  • Every service is reviewed within the Continual Service Improvement Process
  • Through the service portfolio, an information base for a service catalog is provided.

Roles & Functions

Service Portfolio Management Specific Roles

Static Process Roles

Service Portfolio Process Manager (Service Portfolio Manager)
Manager of the entire process, responsible for its effectiveness and efficiency.
Service Portfolio Process Owner
Initiator of the process, accountable for defining the process strategic goals and allocating all required process resources
Service Portfolio Management Team
Team associated to the Service Portfolio Management Process

Dynamic Process Roles

The following roles are assigned for each new instance of the Service Portfolio Management process and usually outlast for the entire lifetime of one process instance. Changes in the assignments of roles are possible, but apply only to a regarded process instance, and not to the process in general.

Service Agent
This attribute of each service record contains the role/function responsible for the current activity or task within the process of Service Portfolio Management. The Service agent can be changed with the help of a functional escalation, if permitted by the rules.
Service Owner
This attribute of each service record contains the role/function currently accountable for the service (but not for the Service Portfolio Management process). See IT Service Management principles Ticket, Ticket Owner and Ticket Agent for details.
Service Sponsor
This is the person or board responsible for budgets and costs related to a specific service.
Requirements Requester
The person or group of persons expressing new demands/requirements to be fulfilled by the IT service provider.
Service Design Team
Team associated to all tasks in the context of designing a service (creating a Service Design Package)

Information Artifacts

The following chart provides an overview of the main information artifacts in the process of Service Portfolio Management. It illustrates how the service records build the Service Portfolio and how the Service Catalog can be regarded as a restricted view on the service records by covering parts of the information contained in the service records (and thus the Service Portfolio).

Service Record

The service record is the record holding any management-relevant information on a specific service. As depicted above, it is the basic record covering the information that builds the service portfolio, the service catalog and the service design packages. Service record also contains information on documentation requirements and documentation verification needs.

For a list of possible attributes to be considered for the service record, please refer to the exemplary service description.

Service Design Package (SDP)

The Service Design Package is regarded as the entirety of information required to effectively plan, deliver and support an IT service – in other words: to manage an IT service through all stages of its life cycle. The information of a service’s design package is a subset of the information stored in the respective service record. Thus, the SDP is realized as a specific view on the service record, hiding that information which is out of scope for the SDP.

Information that is part of the SDP of a specific service must include the following mandatory information, which at the very least contains:

  • Unique identifier of the service
  • Description of the service
  • Service design plan
  • Service transition plan
  • Service operation and support plan
  • Service improvement information

Service Portfolio

The totality of all service records for all services. Thus, the Service Portfolio may be realized by a database serving as a:

  • container for all service records,
  • container for all service design packages (with restricted views of service records),
  • basis for the service catalog (with a restricted view of the portfolio).

Service Catalog

A customer-specific view on the service portfolio, comprising of that information out of the service design packages which is of interest for the respective customer. Either a single service catalog is deployed, valid for all customers, or different service catalogs are defined for different customers.

Key Concepts

Continual Service Improvement

An activated and operated service should be continuously reviewed and improved, thus adapting:

  • the service to changing customer requirements
  • the service to rapid changes in business and technological environments
  • the service to changes in own strategy, organization and service portfolio

but most of all, the following question should be permanently asked of the service:

  • Does this service, using agreed SLAs, fulfill our offering to the customer in the most effective and economical way, by providing best value/ service proposition to the customer?

The Service Owner is responsible for the periodical review of relevant Service Reports from the Reporting Management during the Service Operation activity. They can trigger a new Service Design Activity every time it is necessary.


High Level Process Flow Chart

This chart illustrates the Service Portfolio Management process and its activities as well as the status model reflected by the service record evolution.

Critical Success Factors

Performance Indicators (KPI)

For Continual Service Improvement Process:

  • Frequency of service reviews
  • Number of improvements of services

Process Triggers

Event Triggers

  • Every time a customer needs a new or updated service the Service Portfolio Management is triggered

Time Triggers

  • The Service Portfolio Management can be activated periodically to revise the Service Portfolio

Process-specific Rules

  • Every new service requirement that can not be fulfilled by existing services triggers the creation of a new service record.
  • The service design agent is responsible for documenting each activity in service record.
  • The service owner controls the service design agent.

Note: For the different types of rules see Rules.

Process Activities

Service Requirements Definition

The main sources of service requirements are customer demands. Identifying concrete requirements on a service builds the vital foundation for designing and describing the service within the service (design) record.

Requirements definition includes the detailed definition of service documentation and a plan for documentation audits which will verify that the documentation always represents the current status of the service and processes. Moreover that it is distributed, communicated, used and under review.

Activity-specific rules:

  • All customer requirements on a service have to be identified, recorded and weighted due to their relative importance for the respective customer.
  • Requirements requester is set to the customer asking for service (re-)design.
  • Service sponsor is set to the person who triggered the service (re-)design, if no other sponsor is known.
  • Service agent is set to „Service Portfolio Management staff“ by default.
  • Service owner is set to „Service Portfolio Manager“ by default. This assignment can be overridden as soon as another service owner (e.g. a specific IT team) has been committed for this role.
  • Requirements description The RFC must contain a meaningful description of the desired change as well as a comprehensible rationale stating the reasons for that change.
  • Requirements priority reflects the relative importance of the new requirement(s) compared to other requirements on different services. It is set to „1 (Middle)“ by default.
  • Design documentation requirments and verification process
  • The service record is shifted into the status „requirements-defined“.

Service Decision

A decision has to be made on whether the requirements demanding a new service, or the modification of an existing one, shall be realized/fulfilled (possibly in parts). This may, or may not, involve designing a new service or modifying an existing service.

Activity-specific rules:

  • The service (design) record is shifted into the status „decided-accepted“.

Service Design

Based on the customer requirements, the service is designed or improved depending on whether a new service is introduced or an existing service shall be modified. The required information for the SDP is recorded by filling/updating the SDP record.

Activity-specific rules:

  • A service deployment/transition plan is created, addressing the following aspects:
    • (To be completed)
  • A service support plan is created, addressing the following aspects:
    • (To be completed)
  • The SDP record is shifted into the status „designed“.

Once the service design is reflected in the SDP, the following occurs. In case of a new service, actions have to be taken to implement this service in accordance to the SDP. In case of an existing service, adaptations have to be realized in order to align the actual service with its descriptive SDP. In either case, at this stage of the process Service Portfolio Management interfaces with Change Management.

Service Transition

Activating a service means that it is made available to at least one customer with the help of Change and Release Management. A review of the new or changed service is performed after the change, in the context of the Post Implementation Review (PIR) of the Change Management process. The PIR therefore has to approve conformance of the actual change/service with its descriptive SDP, reflected by one or more RFCs. While activity Service Decision paves the way for the Service Design; Service Transition is focused on getting the new or changed service into the live environment.

It is important to understand that Service Transition is a process overspanning and interfacing with Change and Release Management. For each service that has been designed, a Request for Change (RFC) is created to trigger the Change Management Process. However, Service Portfolio Management is just one possible source for RFCs, and an RFC is used as a means to realize the proposed service design reflected by the SDP.

Activity-specific rules:

  • Service agent is set to „Service Portfolio Management Team“, if no other specific person is available for this role.
  • If the RFC is not accepted then something was (formally) wrong with the content of the RFC. Perhaps, information provided to the Change Management process via the RFC is not complete, or another formal error has occurred. Rejection of the RFC does not imply rejection (in terms of failed authorization) of the change.
  • If the change is not authorized, or if the rollout of an authorized change is not successful, the transition of the service has failed and the service record is shifted into the status „transferred-failed“.
  • The service record is shifted into the status „transferred-successful“ if the Transition activity is passed through without any problems.

Service Operation

Designed, tested and activated service is operated in this sub-process. This means the service is up and running within agreed service levels and providing agreed results. Operational processes:

  • are running the defined service (through planning, operating and monitoring of IT service, infrastructure and related resources)
  • are monitoring the service performance (e.g. Event & Alter Management Process)
  • keeping the service within the defined service levels (e.g. Incident Management Process, Problem Management Process, Change Management Process)
  • provide counter actions in case of acute or possible malfunctions of the service (e.g. Incident Management Process, Problem Management Process, Change Management Process, Availability Management Process, Continuity Management Process)
  • improving the service continuously, which means improved costs/ result for both company and customer (Continual Service Improvement Sub-Process)
  • collecting inputs on service changes and forwarding these to the Service Design within the Service Portfolio Management Process
  • up-dating the service documentation and verifying that the documentation is accurate

Service Operation is performed in a well balanced environment, bringing different components into a harmonic total composition:

internal vs. external orientation of the IT
both need to be brought in a balance – IT driven only by the internal view of the department is not business aligned, an IT only business focus can not deliver the agreed results
stability vs responsiveness OR reactive vs. proactive behaviour patterns
Responsive and fast IT reaction is always one of the main customer requirements but only a balance with stability allows it to perform IT operations on an agreed level of SLAs
Service quality vs. cost of service focus
„IT always costs too much“ is a standard quotation in business operations – but the delivery of service quality needs resources, thus the main focus of IT service operations should be a balance of service quality and costs (with active discussion with the business partners).

Main success factors for service operations:

  • pro-active communication with business and external partners
  • information receiver oriented communication – on right level of detail, cost and frequency
  • a desire for communication and understanding on both sides (IT and business) through understanding of a „one team“ approach – internal and external with the business partners
  • documentation of deliverables, procedures and operations
  • definition and permanent optimization of rules and daily running according to theses rules without exceptions

It is important to understand that Service Operation is a sub-process over spanning and interfacing with Incident, Change and Release Management. For each service that is designed and transferred into production; the right number, right capacity and right planning of resources needs to be operated to provide the service on an agreed quality level.

Activity-specific rules:

  • Service owner is the control function
  • Service owner is:
    • responsible for recording and monitoring the Service KPIs
    • monitoring the service docuemntation
    • in case of necessary service improvements requesting those by:
      • requesting a new service design phase (in case of major changes to the service) OR
      • initiating a RFC at Change Management Process (in case of minor changes to the service)
        • If the RFC is not accepted then something was wrong with the content of the RFC. Perhaps, information provided to the Change Management process via the RFC was not complete, or another formal error has occurred. Rejection of the RFC does not imply rejection of the change (in terms of failed authorization).
        • If the change is not authorized, or if the roll out of an authorized change is not successful, the transition of the service has failed and the service record is shifted into the status „transferred-failed“.
    • in case of interaction with Incident Management Process and Major Incidents the coordinating role
    • in case of interaction with Change Management Process and Category 01 Changes
      • the authorization role AND
      • is part of Change Advisory Board
  • Service agent is set to Service Operation Team
  • The service record is shifted into the status „in operation“ if the Operations activity is in progress.

Service Deactivation

If a service is no longer required, which may be due to various different reasons like changed customer requirements or substitution of the service, then it is deactivated. This particularly implies the removal of a service out of the service catalog in order to make it not available/subscribable anymore by any customer. A backup of the service record and service design package may be stored in the service portfolio.

Activity-specific rules:

  • The SDP record is shifted into the status „retired“.
+49 89 - 44 44 31 88 0