You Must Have a Service Catalog

Before the arrival of ITIL v3 in mid-2007, many large IT organizations were struggling to overcome CMDBPD: configuration management database project despair. Then ITIL v3 gave IT organizations a shiny new tool: the service catalog. Now, you’d have thought that their CMDB failures—stemming from the lack of a real understanding of purpose and need, planning, commitment, etc., and too heavy a focus on the technology and data—would have left IT organizations in the ideal position to attack service catalogs with a new and winning approach. But we didn’t learn (well, many of us didn’t learn). For many, the service catalog became CMDB 2.0.

Thankfully, the title of this article isn’t my advice to you. It’s just another bold statement about ITSM that I wish I weren’t hearing or reading almost weekly. Our obsession with the service catalog—just one among many ITSM tools, modules, or capabilities—is over five years old, and it seems every IT organization has either decided or been told that the service catalog is an absolute must-have.

However, in my opinion, it’s best to look back before we move forward.

The Wonder Years

While the concept of the service catalog has been around for well over a decade (in 1999, I demoed an online employee portal mockup for the UK Post Office’s Innovation Lab), ITIL v3 gave it a big push. There are many methods for collecting statistics on the demand for, adoption of, and success of service catalog initiatives, but my favorite isn’t exactly scientific: Based on audience feedback during presentations at various global ITSM events, it would seem that 30-50 percent of organizations had a service catalog in 2012-2013 (varies widely based on geographic location). Of that, less than two percent felt they were receiving the promised or expected benefits from their service catalog initiative.

For a somewhat more scientific take on the issue, when Forrester, the global research and analysis firm, asked forty billion-dollar corporations about the maturity of their ITSM initiatives, service catalog management scored the lowest, behind problem, availability, and configuration management. (You might have noticed a sneaky shift from service catalog to service catalog management in this. It was deliberate.)

Where Is the “Management” in Service Catalog Management?

As it was with the CMDB, organizations focused on the service catalog tool at the expense of service catalog management. Our unhealthy focus on technology and data, our belief in limited best practices, and our use of somewhat inappropriate terminology constrained and misguided our thinking. The result? Many IT organizations, all of which had the best of intentions, succumbed to the common stereotype of being overly focused on IT inputs at the expense of business outcomes.

There’s no doubt that an effective service catalog can help both the IT organization and its customers. Service catalogs can:

• Provide better support for existing ITSM processes, such as incident and problem management, change management, service level management, and service reporting, and they can improve service delivery and customer satisfaction, which can potentially reduce costs. 
• Improve IT/business alignment (I know, it’s a bad term, but it’s part of our common language, for better or worse). A service catalog—or, I would argue, service catalog management—can help improve communications, the understanding of needs (and capabilities), expectations management, customer experience/satisfaction, and maybe even the current need to demonstrate the business value of IT.
• Improve financial control, including cost and pricing transparency, chargebacks, and demand management (through differential pricing models). 
• Increase operational efficiency, especially through the automation of ordering and provisioning. The latter can potentially deliver considerable time and cost savings.

Can all this be achieved by simply buying and populating a service catalog? Probably not, but people still try.

Common Service Catalog Mistakes

Before we look forward, let’s briefly consider some of the most common perils and pitfalls of service catalog (management).

1. The “Let’s buy a service catalog tool!” approach (which is not dissimilar to the “Let’s buy an ITSM tool!” approach). This is where the service catalog is seen as a technology project rather than a business-driven change. 
2. Limited or misjudged service catalog (management) initiative objectives. The service catalog must be more than just a list of IT services (although for some organizations it could be all they want and need, and maybe Microsoft Excel would suffice). 
3. Limited understanding of the IT services that should populate the service catalog. Service definition is difficult, but that’s no excuse. Any provider of services should know what they provide, from a customer perspective, and the associated attributes. 
4. Critical acclaim, minimal adoption. The service catalog is pushed out to the business with great fanfare…followed by little to no business adoption.

In light of the above, is your service catalog initiative a train wreck waiting to happen? Even if it’s not, please also consider the following.

The Building Blocks for Success

As with most business activities, it’s important to understand the difference between processes and enabling technologies. “People and process before technology” is a common ITSM mantra. As alluded to above, without the support of a strong service catalog management process and the efforts of capable people, your service catalog (tool) will struggle to deliver the anticipated benefits. Simply implementing the technology and populating it with an initial “data grab” will deliver a suboptimal solution that decays over time: a service data graveyard.

Things are getting better, though. We’ve seen a shift recently toward trying to see beyond service catalog (management), to looking beyond the tool and the process to view the activities and enabling technologies from the customer’s perspective: what customers want and need, instead of what the IT organization thinks it should be doing, which is always a combination of herd mentality and best practices. James Finister and Rob England are two vocal proponents of this shift. Rob, for example, has differentiated between the service catalog (a list of services, perhaps the output of service portfolio management) and the service request catalog. This makes sense, given that one possible cause of service catalog failure is that we really don’t know what we are trying to achieve/deliver.

The figure above is a simplification of our great expectations for the service catalog: we expect it to do it all, but our focus is too narrow. Is it any wonder that so many service catalog initiatives are considered suboptimal if we charge at the middle circle and fail to fully consider the other two?

Part of the problem is that the term service catalog is a poor container for our wants, needs, and desires. Using this term only limits our thinking and our chances of success. Instead, we should start thinking in terms of service portfolio management—albeit with a broader definition: the “portfolio management of services” rather than the “management of the service portfolio”—and self-service and automation.

Improving the Odds of “Service Catalog” Success

So what can you do to help ensure that your service catalog initiative doesn’t die a slow death in the hands of misguided project managers and unreceptive customers? Here are a few suggestions.

1. Think service catalog management, not just service catalog. What are your processes for reviewing and changing service catalog content, or changing the service catalog and its related processes? 
2. Service portfolio management should be the precursor to service catalog management. You’ll need to understand your end-to-end services (e.g., what they are, who uses them, what they do, how they are composed, what they cost), and in business terms rather than IT terms.
3. Get the right people involved. This is the business’s service catalog, not IT’s. IT should not drive the look, feel, or content of the service catalog, the business should. 
4. Be clear about the objectives for service catalog management and not just the tool. You’ll need to identify the issues and opportunities you’re trying to address. The objective should definitely not be “creating a service catalog,” but it should definitely be more than a list of IT services. What are you looking to achieve? 
5. This isn’t just a data-collection exercise. Interestingly, for some organizations, service catalog has reignited the need for a CMDB and associated service asset data. 
6. Ensure that your ITIL processes are fit for purpose. To get the best out of your service catalog, you’ll need the support of certain ITIL processes, such as financial management (service costing through to accounting), service level management, and configuration management. 
7. Don’t emphasize the front end (shopping cart) at the expense of back-end data and activities (e.g., consumption monitoring, automated provisioning). Your service catalog should be more than an Amazon-like storefront and shopping basket (unless this is all your business actually needs). 
8. Align your service catalog initiative with your corporate automation initiative. This will help ensure that you’re leveraging relevant experience, supporting the integrations, and avoiding the duplication of effort (and possibly cost). 
9. Continue to involve your customers. Actively seek feedback and be open to criticism. Monitor usage. Offer coaching and training. Try different strategies for increasing service catalog use and improving ease of use. Nurture and feed your service catalog like you would any other living thing. 
10. Think ahead. Look at the potential for exploiting shared services in the future (a single employee portal, perhaps).

So, is the service catalog really a “must-have”? By itself, definitely not. But as something that uses service portfolio management and people, process, and technology to deliver the potential business benefits of self-service, workflow, and automation? Absolutely. But only if you do it right.

Stephen Mann is a keen blogger and ITSM industry commentator. His career has included stints in IT research and analysis (at the UK Post Office, Ovum, and Forrester), consultancy, ITSM, asset management, innovation/creativity facilitation, project management, finance, and internal audit. Stephen is currently a senior manager in product marketing for ServiceNow, where he hopes he’s writing stuff that makes a difference. Follow him on Twitter ( @stephenmann )!