Saturday, August 05, 2017

Do we need Service Portfolio Management?

Do we need Service Portfolio Management?
I am not a big fan of ITIL. DevOps and ITIL are basically both IT Service Management (ITSM). The patterns are the same though the execution is different. Service management is not one theory among many. Service management models reality and ITSM is the description of IT reality: of all the activities that happen in the real world.

Everybody manages change; everybody releases into the world; everybody manages capacity and availability and continuity; everybody manages incidents and requests; everybody defines strategy, plans, designs, and builds services; everybody does improvement. The levels of maturity might very but these practices are present in every organization.

 DevOps is one codification of that reality and ITIL is another. I am a DevOps guy.

Nevertheless there is a concept in ITIL that I like very much. It is called service portfolio management. A company’s service portfolio can be defined as a group of services that are listed in terms of their value for business. This portfolio can include everything from in-house services to outsourced ones. If we compare project and service portfolio management, they have obviously many things in common. First of all they both share the same technique and same goal of general portfolio management: Making right decisions about investments, which is not that different from classical financial portfolio management. The main goal of service portfolio management is to maximize the realization of value to the business and meanwhile balance the risks with the costs.

Too many organizations take a portfolio view of only programs and projects, whilst neglecting the operational systems. This is one order removed from a truly holistic view. Project portfolio management only looks at change, not the current state. Service portfolio management looks at the services in production as well as the proposed changes to service. It looks at the distribution of resources across both Build and Run, not just Build. It considers the impact on the existing services when we try to introduce new ones. Failure to do this is why so many IT departments are drowning in projects and have ever increasing operational costs.

Failure to manage across the whole portfolio of current and planned services - focusing instead on only the portfolio of change - means that there will be a continuous deluge of CapEx expenditure on new services with zero consideration of Run's ability to absorb them (and often zero budget to do so too). Notice that the differentiation between Build and Run is also valid for DevOps teams. When they need most of their time to Run things, there is no time to Build things. On the other hand, when they are expected to Build continuously, there is no time to Run things. We hollow out our capacity to deliver the services because we are so busy building and changing them.

Balancing priorities and resources across the portfolio of change, of projects, of programs, is not enough. We must balance across all activity, across Build and Run together. ITIL Service Strategy tells us exactly that by defining the concept of service portfolio management. IT management is a constant balancing act of Build and Run.

If you look at project portfolio management historically, it is clearly not about services, it’s about products. At the end of a project there is a result, after that is delivered, the project ends. There is a fundamental difference in the philosophies of project and service portfolio management. With our customers, we should talk about services. A service is a means of delivering value to customers by facilitating the outcome customers want to achieve, without the ownership of specific costs and risks. This is what your customers want.

When it comes to successful service portfolio management, Product Managers and Product Owners play an important role as they are expected to manage the services and products throughout their lifecycle. Project Managers manage only the project.

A typical service portfolio contains three subsets.

1. The service pipeline includes the list of services that are currently under development or consideration for a specific market or demographic. This is your project portfolio. The service pipeline can also include goals, priorities as well as short term and long term goals of your business. 


2. The service catalog is the section of the portfolio that is visible to your customers and provides an insight into the services and products your business delivers. 


3. The last subset of the portfolio is the retired services that include products and services that are soon to be withdrawn or have already phased out. 


Alex Lichtenberger created a nice overview of these subsets and the relation with project portfolio management with the diagram below.



You can buy my books The Art of Technology Project Portfolio Management and The Science of Technology Project Portfolio Management separate or as a bundle in my store. Just click here or on the image.
Posted on Saturday, August 05, 2017 by Henrico Dolfing