A mature enterprise will have (at least) many thousands of Transactional Services in their Service Catalog. Designed correctly, it will be easy to find and invoke each one. However, sometimes a Service Requestor needs to access and invoke many different Services to perform certain work under certain contexts. And, while it is a great first step to have all Services in one place, finding and invoking each one that is required to perform a job under a specific context, in a very large pool of Services, can often take a long time. Service Portfolios are a means of solving this problem.
A brief refresher of relevant Service Management topics
In previous publications, we discussed Service Catalogs, Service Categories, and Service Request Types. In short:
- The Service Catalog is the tool that acts as the container.
- Service Categories are logical and intuitive groupings of Service Request Types.
- Service Request Types are entry points to very specific Services that a person can invoke and track through completion.
Defining a Service Portfolio
A Service Portfolio is a logical grouping of Service Categories and/or Service Request Types (SRTs) that are commonly used for a specific and repeatable type of work context, such as a role.
Put another way, a Service Portfolio is simply a context-related or role-related grouping of Service Categories and Service Request Types that act as a set of grouped short-cuts. Grouping them together into a Service Portfolio makes it easier for the people working in such contexts or roles to quickly access and invoke the Services they need, especially when frequently and repeatedly doing so.
Describing the problem that Service Portfolios help solve
In most enterprises, typical contexts are associated with specific Roles so let’s look at a few different roles as examples…
- Imagine a Human Resources specialist who spends his or her day onboarding new employees and consultants, over and over again.
- Imagine a Project Manager, Architect, or Designer who repeatedly needs to request cost estimates, for many different projects over the course of a year, for many different deliverables that will be owned and delivered by different organizations in the enterprise.
- Imagine an Information Technologist or Engineer who needs to install, configure, customize, and run many different types of software, over and over for many different projects, all year long.
Each of the above roles shares a common problem. For every new work iteration, people in these roles need to regularly go back and re-invoke Services that are the same or similar to Services they invoked for the last work iteration.
Service Portfolios represent logical groupings of the Service Categories and Service Request Types (SRTs) that are most commonly used by a specific role. As mentioned, they act like grouped sets of short-cuts that lead to the Services used most by a specific role.
Examples of Service Portfolios
Staying with the roles highlighted in the previous section, we might have the following Service Portfolios to facilitate their work:
- A Human Resources Onboarding Service Portfolio will group and easily make available all or most of the Service Categories that will be used by most Human Resource Onboarding Specialists.
- A Project Management Service Portfolio will group and easily make available all or most of the Service Categories that will be used by most Project Managers.
- An Engineering Service Portfolio will group and easily make available all or most of the Service Categories that will be used by most Engineers.
The benefits of Service Portfolios
As mentioned earlier, a Service Portfolio acts as a grouped set of short-cuts that lead to Service Categories and Service Request Types which are used most by a specific role in the enterprise. Creating these sets of short-cuts has the following benefits…
- People who work in a specific role and who perform the same types of work, over and over again, will waste less time finding, accessing, and invoking the services they need to perform the work related with that role.
- New employees or consultants that come in and work in newly assigned roles can be successful, faster, because they can quickly have access to a toolbox of Service Categories and Service Request Types that are made readily available for them.
- Costs to perform repeatable work a driven down, even further, because the time to find, access, and invoke the same sets of Services, over and over again, is reduced.
- Many people working across a common and specific role will generate higher levels of work consistency and quality because they all have access to and are invoking the same sets of Services.
Service Portfolios should not be confused with the Enterprise Portfolio of Services
A Service Portfolio is simply a role-related grouping of Service Categories and Service Request Types that facilitate Service discovery, access, invocation, and tracking for that specific role. This should not be confused with the Enterprise Portfolio of Services, which consists of all enterprise Services and which is used by Enterprise Service Management professionals to control which Services an enterprise will or will not offer (i.e. Service Management Strategy).
Reuse of Service Portfolio Components
The Service Categories and/or Service Request Types that are aggregated and placed within a Portfolio are not required to be reusable across multiple different Portfolios, although they often are. The primary requirement for being placed into and made available from a Service Portfolio is that the Service Categories and SRTs are repeatedly and frequently accessed enough to justify their existence in the Portfolio. They key is to save the Service Requestor extra steps in finding something they will need, over and over again.
It is, as mentioned, very common for Service Categories and SRTs to be reused across many different portfolios. For example, the category of SRTs called Project Management Services might exist in the Project Manager Service Portfolio, the Developer Portfolio, and the Business Services Portfolio.
Service Portfolio Improvement
It should be noted that Service Portfolios should be fine-tuned and improved, on a regular basis. Over time, the needs of a specific role might change. People working in that role should have a mechanism to request and implement improvements to the Service Portfolios they use the most.
A suggestion for handling this is to have a Service Category for Service Portfolio Management, which leads to specific Service Request Types that allow the invoking of Service Requests that help requestors log issues against existing Service Portfolios and new requirements for either existing or new Service Portfolios. If you go down this path, ensure that you have a clear and accountable owner for Service Portfolio Management whose job it is to handle and address such Service Requests.
Summary and Conclusions
- Service Portfolios are aggregations of various different Service Categories and/or Service Request Types.
- These groupings represent a context-specific or role-specific set of frequently accessed Service Categories and/or Service Request Types that act as short-cuts.
- Composition is based on frequency of access. The more a context or role accesses a specific Service Category and/or Service Request Type, the more it can be justified to put them into the Portfolio for that context or role.
- Service Portfolios are not mandatory for Service Catalogs but should be considered if you believe you can use them to make accessing of services easier for specific roles.