Knowing you need a service catalog and getting your organization to have one are two very different things. Here’s some practical advice for getting started with a basic service catalog (even if you don’t have a full ITSM program!)

Service CatalogIf you’re like many IT organization, having a single list of services for customers to view hasn’t been a priority. After all, you know what your services are and customers must too, because we have a lot of them. So what’s the big deal with a service catalog?

Knowing what you know

Most of you know I used to work for a rather large, global technology company. One of the struggles we faced was knowing what we know. The culture was rich with ‘tribal knowledge’ – knowledge that’s locked up in the minds (and possibly email archives) of a widely distributed network of technical experts.

Which is great, but the problem is it can take a village to fully understand any given topic. Not having a single, consistent understanding of your IT services, and how they’re configured can really slow things down, and cause a lot of confusion. Ever played the game Telephone – where you whisper a short message to someone, who repeats it to the person next to them, and so on around the circle until the last person says out loud what they heard? It’s funny, because the simplest of messages are mangled by the time they reach the end.

Funny as a game, but not so funny in IT, and yet, this is exactly how IT services are documented and communicated with customers in many companies – or perhaps, more correctly – NOT documented and NOT communicated with customers.

What’s an IT service?

To have a Service Catalog, you kinda have to know  your services, but many organizations struggle even to agree what an IT service is, let alone what yours are. I talked about identifying your IT services in a webinar I did on Practical Approach to Getting Started with Service Catalog, and you might find What is a Service in ITIL helpful.

Tribal knowledge to tribal agreement

Ever seen those email conversations where it takes the whole village to sort out the details of an IT service?

Here’s a typical one. (fictional, of course)

Sarah: “I’m setting up a new mailbox. Remind me what the default message store size is again?”

Jonas: “250 MB for the standard user, 500 MB for executives.”

Kanish: “No, it’s 500 MB and 1 GB.”

Jonas: “When did that change? It’s always been 250 MB.”

John: “No, we changed it when we upgraded the storage array in November, except that I thought we decided to just make all mailboxes the same size.”

Sarah: “500 MB or 1 GB?”

John: “2 GB”

Surprisingly enough, this is the best place to start building your service catalog effort.

Why?

Because these conversations create clarity. They’re opportunity for the keepers of knowledge to share what they know with the ‘tribe’. The trick, of course, is to gather bits of information about the service during these conversations. One way I’ve seen it done is what I call ‘reverse engineering’ the service. (Matthew Schwartz described Reverse Engineering over at ComputerWorld.

You’ll want to consult multiple sources to gather as much information as possible:

  • Ask the IT staff who were involved with building and supporting the technologies
  • Talk with users of the service
  • Reviewing existing documentation
  • Look through old emails
  • Leveraging the service desk’s knowledge base and common questions

From the information you gather, draft up a basic service description – a brief document describing the service. (You can download my free Service Description Template.)

The service description should include things like:

  • Details that are in dispute (is it A or B?)
  • How are the parts connected?
  • Are there other parts to the system (security tokens, remote access, cellular devices)?
  • What infrastructure services are required (account administration and authentication, networks, firewalls, storage servers)?
  • What business processes does it support (accounts payable, receivable, general ledger)?
  • Hours of operation (24×7, business hours); are there maintenance windows?
  • How do customers get the service?

Use the service description to facilitate conversation about the service. Let the tribe revise the description until they agree that it most accurately describes the service as they know it.

The tribe has spoken

Getting the tribe to agree is important because with their agreement comes a sense of ownership.   Once you’ve reverse engineered a service description and the tribe has agreed, you now have the basic building blocks you need to start building a basic service catalog.

The service catalog

The single most important thing to remember when building the service catalog is to think like a customer. What would they expect. It’s a well known fact that IT people and customers think differently about IT services. What’s perfectly logical to IT doesn’t necessarily make sense to customers.

Make it easy for customers to find the IT services they’re looking for.

Typically, services are grouped under headings, like:

Email, Calendaring and Collaboration Services

Electronic messaging, calendaring, and personal productivity apps

Client Computing Services

Centrally managed desktops, laptops, and kiosk computers

Phone and Voice Services

Desk and mobile phone and audio-based services

 And, if done with basic HTML-style formatting, clicking on the Email & Calendaring would bring up the list of offered services:

Company email

Provided corporate email address, email, and calendaring

Email distribution lists

Create and manage corporate email distribution lists

Obviously, this is just example, and I’ve intentionally avoided talking about implementing in an ITSM tool. In my experience, gathering and documenting your services is the hard part. Once you have that, implanting in any tool is pretty simple.

Keeping it current

The final challenge is keeping your service catalog current, because we all know that an out-of-date catalog will soon be ignored. (You may even have one or more decrepit catalogs out there!)

You want to make your new service catalog part of everyday life. You want it tied into anything that could change any of the details:

  • Change management
  • Project management office (PMO)
  • System/software upgrades
  • Implementing new features
  • System fixes that change the behavior of the system

And, as before, any time confusion arises, jump into action – never waste a good moment of confusion to help create clarity!

I covered a lot more details in the webinar I mentioned earlier, and please take a moment to download the free whitepaper Practical Guidance on Getting Started with Service Catalog.
Photo Credit: xmacex via Compfight cc