A Practical Approach to Getting Started with Service Catalog

Recently I presented a webinar on getting started with service catalog. It’s a topic that comes up often because getting started can be harder than it looks – especially without the support of a full IT service management (ITSM) program. If you know you need a service catalog but aren’t sure where to get started, the webinar offers a practical approach to get you up and going with a basic service catalog.

Some of the common challenges that organizations face when trying to build the service catalog are:

---

• Staff may think: ”Our users know what we do”
• IT services evolve too rapidly
• Changes are made with little formal change management
• Siloed organization: poor/informal communication between teams – app dev, infrastructure, and support
• “We are technology (not service) providers”
• Lack of service owners
• Cultural resistance
• Lack of organizational support
• Lack of time and attention to build it
• Thinking that ‘service catalog’ is a document – “We already have one…somewhere…”

If any of these sound familiar, I encourage you to watch the webinar and download the whitepaper.

Your Questions and My Answers

Below are my answers to some questions asked during the webinar.

Q1: “If you need to create a request catalog within a very short timeframe, what is the least amount of information you would recommend to publish in a live catalog, before being able to circle back and add/fill in more information?”

A1: Kind of a ‘minimum viable product’ approach. I like the question, partly because it’s realistic. Of course, the balance you’re getting at is that it will take some time to gather the information I described in the webinar, delaying publishing a catalog. This is why I strongly recommend starting with a very basic service description. I like the saying “if you can’t explain it to a six year old, you don’t understand it well enough” (or something like that). The bottom line is that it should be relatively simple to write a paragraph or two describing the service. Getting bits and pieces of that description from as many people who know parts is the strategy I highly recommend. In so doing, you both get a complete picture, but you also get the buy-in of those who contributed to the effort.

So, to answer the question directly: a one or two paragraph description is the minimum amount of information on which to base your first service catalog.

Q2: “Can we have an example of a good service catalog?”

A2: I wrote a whitepaper to go along with the webinar that has a pretty decent sample in it. You can download it here. Hopefully it will get you going in the right direction.

Q3: “Can I use <several tool vendors mentioned> for ITSM just like other vendors available on the market?”

A3: There are lots of effective tools for service catalog. Honestly, though, the greater challenge, by far, will be the cultural aspects addressed in the webinar. There’s no magic solution to make that part easy, which is why I encourage you to focus on the people and the process long before looking at tools. This is my recommendation even if you already have a tool. Keep it simple and focus your efforts on the people and the process. Once you’ve done the hard part – as I addressed in the webinar – implementing it in a tool is a snap.

Q4: “Typically, what does each item in a service catalog link to? Help Desk requests? General documentation? Just curious to see or hear about examples.”

A4: This gets to a point that I only lightly touched on during the webinar – the difference between a service catalog and a service request catalog. In short, a service catalog is a listing of available services. Clicking on a service generally brings up additional details about the service, and likely includes a “how to request service” section.

A service request catalog is automated, so clicking on the service takes you directly to a request form of some type – making it very simple to find, select, and request a service. The obvious analogy is the online shopping cart. Online retailers have mastered the art of making it easy to find what you’re looking for (and often stumble upon some things you didn’t even know you needed!), and making it super easy to get in your cart.

Q5: “How do you handle third-party and hosted systems?”

A5: I think the question has to do with implementing a service catalog on a hosted ITSM tool, which can vary quite a bit between the various vendors. I’m far from an expert in the various tools out there, but there are two key things you want to keep in mind:

1. Make sure it’s easy for users to find the services they need
2. Easy integration with the rest of your ITSM solution

These are key regardless of the tool or hosting arrangement.

Q6: “What is the best way to determine the frequency of the service catalog update for a particular company?”

A6: The challenge is doing it often enough to keep it current, but not too frequently that people start feeling like it’s taking up a lot of their time. It’s something you kind of have to size up according to the culture of your organization.

Yearly is the least frequent I’d recommend. Ideally, I like having a quarterly review – maybe even tied in with a quarterly service review, or customer meetings.

Q7: “Would you use a service catalog as a starting point to agree on SLA’s? Should they be included in the catalog?”

A7: It depends how well established SLAs are in the organization. For organizations who are just establishing what their services are – SLAs probably either don’t exist, or are just being introduced. My concern is introducing two concepts at once – the service catalog and SLAs.

On the other hand, if your organization has had SLAs in place for some time, and both IT and the business understand them, then they should be included (to help users understand what they can expect of the service).

Q8: “What if our customers are both non-IT and IT users who would be using the Service Catalog? How do we gear the Catalog for both?”

A8: I like the concept of a multi-viewed catalog – a customer view and an IT view. It’s a concept buried in the ITIL books, and it can be really helpful. The customer view should be focused on the details important to end users, and the IT view should highlight the technology components and how they’re integrated to deliver the service.

Q9: “Do you recommend a category and a sub-category of service catalog?”

A9: During the webinar, I talked quite a bit about making it easy for users to find what they’re looking for. I’m a fan of broad categories – like “computing services” and “phone and voice services” with no further sub-categories. One of the elements of good user interface design is limiting the number of clicks required to find what the user is looking for. Drilling down to multiple sub-categories, which may seem logical (especially to us techies), can make it harder for users to find what they’re looking for.

Also – keep in mind that we IT people think differently than our customers. What makes perfect sense to us may completely confuse our users.

It’s also worth mentioning that it’s a good idea for users to be able to find services in various ways, like alphabetical listing and keyword searching.

Q10: “For your internal view of your service catalog, should you link your more detailed service catalog items to standard operating procedures or should SOP’s be separate?”

A10: In concept, I like having everything nicely linked and easy to find. But in practice, this is where a service catalog effort can really struggle – trying to do too much too soon, and losing support. I’d much rather see success with a very basic service catalog with strong cultural support for it, and then continually improving it – with the input and involvement of stakeholders.

Q11: “How can we determine the best level of granularity/detail to include in the service catalog?”

A11: A good question that actually gets to the heart of my webinar. To answer the question, you have to get the experts in your organization involved. I talked quite a bit about ‘tribal knowledge’ – the idea that the details of your services are known in part by many different subject matter experts in the organization. The goal is to leverage that knowledge and create descriptions that the ‘tribe’ agrees to in the end.

Keep in mind that it’s far, far better to be successful with a very basic service catalog and improve it over time than to start too big and fall short.

Q12: “How can we involve the end users in performing the service catalog?”

A12: Here’s a question that I love – how to get your customers involved. I really like it because that’s where it has to start – with the customer perspective, and what better way than to get them involved.  But how?

Most organizations have what I call “IT-friendly” users out in the business. Those people who other users go to for help and questions before they call IT. If you don’t know who they are, ask your service desk team. They do. Form a users advisory group and ask for their help in shaping the service catalog. (Many major software vendors have been dong this successfully with beta programs, power users forums, and advanced releases.)

If you do a customer survey, ask if they would be willing to serve on a focus panel, and form a group to review the service catalog.

If you have relationship management, do service reviews, or hold other customer meetings; put the service catalog on the agenda and ask for feedback.

Q13: “If I was starting from nothing should we start small and grow out services; was thinking of building internal IT services first and then learn and build out. Does this seem a reasonable approach?”

A13: Couldn’t have said it better myself. Yes; that’s exactly what I’d recommend. Remember that a big part of the challenge is getting the culture of your organization to adopt the service catalog into daily operation. By starting small and gaining momentum, you’re greatly increasing the odds of successful adoption.

I also like that you highlight learning as you go. This is really important even if you’re very familiar with service catalog – you want the people in your organization to learn about service catalog, and get engaged in improving it as you go along.

Q14: “Some services have nothing to do with technology (e.g. consulting)…. ”

A14: That’s absolutely right. And if there are non-technology services you offer – include them in the service catalog.

You’ll want to be sure they’re defined as services (not activities).

Services should:

• Be recognized by users as a solution
• Support a business process
• Include all the technology components

Thanks everyone who attended the webinar, and thanks for all the great questions.  If you haven’t had a chance, you can still watch the recording.

Good luck with your service catalog!