Skip to content

Taking your IT Service Catalog and IT Portfolio to the next level

September 3, 2008

As internal IT organizations begin to professionalize their interactions with internal customers and become more focused on client experience and service outcomes, they inevitably attempt to develop a service portfolio. This has required IT leaders to internalize the difference between services and the processes, products or platforms that enable those services. IT organizations have gone through a significant learning curve to internalize the fact that services:
• Are intangible
• Are nonpersistent
• Are articulated from the recipient’s perspective
• Implicitly capture the value the recipient derives from the service

Organizations that developed true service portfolios deeply examined and challenged their conceptual understanding of services, negated old technology-centric habits, and acquired new ways of thinking and behaving based on a true service-oriented vocabulary.
With these new insights comes the inevitable desire to continually improve and refine service articulation and positioning, which, unfortunately, often leads to the creation of a hybrid service portfolio/catalog. This hybrid artifact generally obscures IT’s offerings and capabilities rather than illuminating them.

This post describes a typical service portfolio maturation path and provides a sample portfolio for the state that is increasingly considered “mainstream.” It also describes how to avoid “segueing” into the hybrid trap, while providing insight into salvaging such a product if the investment has already been made.

Key Findings
• Thirty-eight percent of businesses have evolved from a pure cost orientation to a service
orientation in their expectations of the internal IT organization.
• Internal IT cannot manage its services if it doesn’t know what they are.
• There is no such thing as a single “best practice” service portfolio.
• Service portfolios evolve over time.

• Define a service portfolio.
• Create the portfolio in your own language, with your own bundling based on a conscious understanding of your internal market and core competencies.
• The portfolio must articulate genuine services. If it’s not a current capability and/or has
a perceived value, source it externally or don’t put it in the portfolio.
• Re-evaluate your portfolio as you sense business expectations changing, and restate it
when appropriate.


The first Step
The first consideration in developing an internal IT service portfolio is the corporate culture and prevailing attitudes about IT’s inherent value to the business. This illustrates how business needs for balancing tensions between agility and efficiency drive expectations (and attitudes) about IT. In general, there are three typical perspectives business leaders have about IT’s potential contribution, and, while all three might exist in a given business, usually one tends to dominate. This should be the target environment.

The first — or supportive — attitude is a traditional one where IT is generally regarded as a back-office utility or cost of doing business. According to a recent ServiceXen survey, in the aggregate, 38% of all IT organizations have this perception, and developing a service portfolio is not
appropriate in this business context.
The second attitude — the enabling attitude — is the emerging mainstream profile, where business dependency on IT for basic operational capabilities “raises the bar” for IT effectiveness as well as efficiency. Here, the role of IT is one of an internal service provider. Another 38% of all IT organizations report this as their current business environment. As a service provider, it is critical that IT can articulate its services in business value terms.
The third attitude — that IT drives the business — is seen mostly in high-tech industries or among sophisticated sector leaders. Here, IT plays a measurable role in revenue generation, and the service portfolio is more tied to business measures of success than to IT measures.

Approximately 11% of all IT organizations report this as their prevailing business climate. (The remaining survey respondents reported either “don’t know” or “other” in response to questions
regarding business attitudes about IT). These attitudes, which we refer to as “supporting,” “enabling” and “driving,” represent a maturity path, with each dictating a slightly different approach to the articulation of a service portfolio. It is important to consciously identify prevailing attitudes and their pace of change to develop a portfolio that will resonate with the business. Table 1 illustrates how these aggregated attitudes break down by industry sector.

Table 1. Business Expectations of IT by Sector (Percent)

Financial Government Insurance Manf. Services Utilities

Support 45.5 35.7 33.3 39.6 37.2 40.7
Enable 24.2 38.8 33.3 46.5 36.2 33.3
Drive 21.2 8.2 22.2 7.9 10.6 18.5

Building the Portfolio
Table 2 illustrates how a service(s) might be represented in each of the three environments and,
therefore, how its articulation and leverage might mature with changing business attitudes.

Table 2. Typical Portfolio Evolution

Supporting Enabling Driving
Not a Portfolio Portfolio in Market Terms Portfolio in Value Terms
E-Mail Application Hosting Services Virtual Workplace Services
Network Monitoring Telecommunication Services Collaboration Services
Security Desktop Management Services
Videoconferencing Facilities Services
Remote Access Secured Access Services
Cell Phones/PDAs Mobile Computing
Wireless Computing

Providing the right support

The portfolio represented in the “supporting” environment is not a portfolio at all. It is a random list of services, processes, products and platforms, generally representative of what the IT organization spends the most time or money on. It is focused on how IT delivers services, not the value of those services. It is highly commoditized and is articulated from an IT rather than a business perspective — which make it almost impossible to discuss in terms of business value.
This list illustrates where most IT organizations begin in attempting to develop a portfolio. It usually contains anywhere from 50 to 150 items. IT organizations at this stage will go through several more iterations as they gradually understand the criteria for a service and learn to articulate their services from a business perspective. In the end, they should have no more than 15 to 20 services on the portfolio (if they are responsible for infrastructure and application services).

IT organizations among the 38% whose businesses are still fundamentally cost-centric should not attempt a service portfolio — to do so will cause further misalignment as IT attempts to position itself for a role the business does not value. This stage of portfolio development is important only to understand where the IT organization is in its ability to position itself as a service provider and how much effort remains before it can create a portfolio worthy of presentation to the business.

The Enabling Stage
The “enabling” portfolio represents the minimum level of portfolio maturity that must be achieved if the portfolio will be communicated to the business or used as any kind of decision framework. The portfolio is still somewhat technology-centric, but uses a vocabulary the business is generally familiar with, and it is described in market terms, which facilitates necessary competitive benchmarking. It also creates the potential for manageable chargeback buckets that provide the business with a much better understanding of what it is paying for and what value it is receiving.

The Driving Stage
The “driving” portfolio is the penultimate articulation of the service’s true business value. Unfortunately, it is not typically articulated in market terms, and so does not allow for ready benchmarking. Its benefits may also be less tangible and more difficult to articulate in financial terms. For these reasons, this type of portfolio is only appropriate for IT organizations that do not face credibility issues and in organizations where IT considerations are fully integrated into the business’s strategic decision-making processes.

Considerations for Creating an Enabling Portfolio
Considerations in finalizing your portfolio include:

• Your current accountabilities:
• Some organizations do very little in the way of solution design, consulting, procurement and so on. Do not list services you do not currently perform or where the accountability resides elsewhere.
• Your bundling strategy:
• How many services should you articulate — fewer, broader services; or more, narrower services? In general, it’s easier to start with fewer, broader services.
• What is your measurement and/or chargeback maturity? Organizations with limited ability in these areas should start with fewer, more-aggregated services.
• How the portfolio will be used:
• Is it strictly a communication tool, or will it be used as a classification scheme for a catalog or benchmarking? Will it be translated into chargeback line items? Will it be used to target process improvements? Will service-level agreements be attached?
• The language employed:
• Services need to be labeled, defined and described in terms that will resonate with your specific industry and culture. IT organizations the world over may offer essentially the same services, but their positioning should be specific to their individual business context.
• Sourcing strategy:
• If you are outsourcing some of your services (or parts of your services), who “owns” the client relationship and the portfolio? That is, is the external service provider (ESP) positioned as a subcontractor or as a co-provider? If the former, your sourcing strategy may have little or no impact on how you choose to articulate your portfolio. If the ESP is a co-provider, its portfolio management practices may affect the portfolio content and positioning.

All these questions will provide insight into how many or how few services you should articulate
when you start out and how the portfolio might be extended over time.

A Sample Enabling Service Portfolio
I have chosen the enabling stage to illustrate a full-blown portfolio for several reasons. First, it is the emerging mainstream context for most IT organizations and, second — as previously stated — it represents the minimum level of portfolio maturity necessary to succeed as a positioning tool with the business.
The following is a sample only, stated in terms that should be readily recognizable to the IT organization and the business. It is illustrative only and is not intended to be all-inclusive. These services can also be bundled and/or described with infinite variety. Any attempt to leverage this sample should take the above considerations into account, with the ultimate portfolio representing a bundling strategy and language appropriate to your particular environment. The bold items generally represent the service itself; the bulleted items can either be clarifying descriptors or —in exception situations — subservices you might want to highlight by culling them out as separate services. This often occurs with consulting services.

Infrastructure Architecture Services

• Solution design and engineering
• Research and development Strategic Sourcing and Relationship Management
• Resource brokering
• Strategic sourcing
• Vendor management (for example, performance management, contract management and relationship management)
• Outsourced business process management Asset Portfolio Management
• Workplace services — for example, employee support services (help desk), desktop management, employee A/M/C and field services
• Facilities management
• Disaster recovery
• Material logistics and procurement
• Managed print services

Consulting Services
• Project services (for example, project management, auditing and portfolio management)
• Business process re-engineering
• Organizational change management
• Special-event management
• Logistics management
• Facilitated risk management
• Business continuity planning
• Safety and risk programs
• Training and education

Application Services
• Application development
• Application maintenance
• Application hosting
• Systems integration
• Electronic intrusion detection and prevention (for example, security)
• Document management
• Decision support services

Note that there are no software applications, no devices, no processes and no computing platforms represented in this list. Because a service is intangible and focuses on what is delivered, not how it is delivered, such elements do not belong here. Software applications and personal computing devices belong in a catalog — not a portfolio. Once the portfolio of services is decided on, the next step is to craft a short description of each service and a clear business value proposition associated with it. Ultimately, the service portfolio should more or less fit on a typical two-sided, trifold, glossy brochure.

Service Portfolios vs. Service Catalogs
There is a growing tendency among IT organizations attempting to improve their positioning to include elements of both a service portfolio and a catalog in the same artifact. In general, when this occurs, they first create an appropriate service portfolio, so they have passed the first hurdle of conceptual understanding around what a service actually is. Naturally, they then want to perationalize this, and they consider a catalog implementation the next logical step. First and foremost, a catalog is a service order processing mechanism. It is primarily a request management tool. It may also contain a chargeback engine and service-level administration capabilities, but it is not a marketing tool. It organizes all the things a customer can buy so that they’re easy to find and so that their pricing, service levels, escalation procedures and request mechanisms are clear. It should use the service portfolio as its organizing framework. A “desktop management” or “workplace” service, for example, might have catalog entries for PCs, user ID maintenance, employee moves, printers, cell phones and so on. Those entries present options, explain pricing and clarify what the customer can expect in terms of provisioning and follow-up. They then typically enable the customer to order items of choice, integrating the request into IT’s back-office fulfillment mechanisms.

The hybrid approach of combining a portfolio and a catalog tends to occur in organizations that have no budget for an off-the-shelf tool and/or have a “not invented here”/”do it yourself” culture. inevitably, they take the portfolio — usually a static document — and add elements of pricing and service levels to it. They may also provide extensive descriptions, user accountability charters, disclaimers, policy statements, escalation procedures, central point-of-contact information, and many other useful tidbits pertaining to service delivery or consumption. They then passively post the information on their intranets, where it languishes unread and unused.

Essentially, when IT takes this approach, it does a tremendous amount of valuable business planning work, but it articulates the results in the wrong way and in the wrong place. The portfolio transforms from a valuable positioning tool and decision framework into a policy manual that is so large no one will ever read it, and so passively deployed that no one will ever use it. It is also no longer a catalog, because it typically contains no orderable devices or services and, if it does, provides no way to request them.

Salvaging the Effort of a Hybrid Portfolio/Catalog
The information contained in a hybridized portfolio/catalog is extremely valuable — too valuable to sit on a shelf. There are two basic paths to redeem the effort and achieve something viable from it. They are not mutually exclusive and, in the long run, both should be addressed — but, for those with an immediate need to leverage the planning information in a hybrid portfolio/catalog, one option or the other must be pursued.

• Deploy a true catalog tool — Use the information already developed to populate the tool’s business and service administration capabilities and provide the necessary business rules to manage request processes.
• Employ relationship managers — Rather than creating a static policy document that the intended audience must seek out or “pull” (which will rarely happen and, when it does, will result in the effort being set aside when the reader sees how big the file is), “push” it. That is, use relationship managers to personally orient business customers to the document, its content and its benefits. Revisit it regularly. If you do so, when a catalog is eventually deployed, the learning curve for customers will be much less.

A service portfolio is a must for IT organizations in all but the most commoditized, margin-focused industries. IT has largely internalized the true nature of services, but it struggles to translate that understanding into a workable portfolio. The desire to use a “standard” portfolio is understandable, but dangerous, because every business culture is different. Because a portfolio’s purpose is to help your business customers understand the value of your services, it must be couched in terms appropriate to your environment. Bundling decisions must also be made, based on where the portfolio will be used as a decision framework and how quickly IT can mature in related service management areas, such as activity-based costing/chargeback, process improvements and service-level management. Getting the portfolio right when you’re first starting is important, but it is equally important to revisit it periodically, because capabilities, internal markets and external realities change.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: