Yesterday, I had the great honor and pleasure of presenting “Creating a Unified Service Catalog” alongside Jeff Wetherbee from the University of North Carolina, Charlotte. Upon reflecting on the session, a few things stuck out to me, so I thought I’d share them with you.
Before getting into that, though, I’d like to thank Jeff for being up for the presentation and putting so much time and effort into making it happen. UNCC has put together a truly impressive unified service catalog thanks in large part to his efforts. So thanks, Jeff. It was a fun and rewarding project.
Okay, down to it:
On Hating Your Current Service Catalog
The first thing that struck me during the presentation came right at the beginning. Jeff and I spent a good amount of time working on the content of the presentation and really hoped to deliver something insightful around both our process and the technical implementation within Cherwell (please no comments on referring to myself and insightfulness in the same sentence). Anyway, right as we started the presentation I realized we didn’t really plan any way to kick it off (whoops!), no intro questions or anything like that. So I adlibbed a couple.
How many of you are working on or have a service catalog? was the first. I’d say around ¾ of the room raised their hands - not particularly earth shattering considering everyone there had chosen to attend a service catalog presentation. What was interesting was the response to the follow-up question: How many of you are happy with your current catalog? After this one, only 4 hands remained. Even I was caught off guard by it. I’ve done a lot of work around service catalog and know that it’s a challenging aspect of ITSM, but to learn that 4 people of 150 like their catalog was surprising to me.
Now I don’t want to go down the path of fuzzy math or “alternative facts” – again, this was a presentation on catalog so naturally I expected some to be unhappy with their current situation. But this session was on creating a unified catalog, not improving or revamping one (topics on which I would have expected those types of numbers). To see 4 out of 150 in yesterday’s crowd was amazing, even when you factor in that one person who keeps their hand up strictly because they're convinced there's a Twix bar waiting for anyone who answers the question.
We see you.
So in truth, it’s 4 out of 150, plus or minus one swag hoarder.
Ready to take this a step further?
Here's our free Service Catalog Template! Start Organizing Your IT Organization Today!
Anyway, back to the point. While I was surprised by the response at the time, I simply made a joke and moved along with the presentation. It wasn’t until reflecting on it later that it really stuck out to me just how big of deal that actually is. The service catalog is the foundation of your IT Service Management initiative, your whole ITSM tool is built upon it. How happy can we be with our house if we don’t like the foundation?
We had a house once that I really didn’t like. We bought it because it was the best we’d seen at the time, rather than it being one we actually loved. We made a lot of great memories in that house, but I never liked it. I didn’t like working on it, I didn’t want to invest in expanding it, everything I did with it was a challenge. I wonder how many people feel this way about their service catalog - and about their ITSM tool.
The good news is that, while rehabbing your catalog is a big deal, it doesn’t require buying a new house. It can be fixed. The main thing is to understand what you don’t like and to do something about it rather than living with it.
On Handling Applications in the Service Catalog
Another question I’ve been pondering since the session came toward the end. Jeff and I were asked an excellent question around how to handle applications in the service catalog. This is a pain point for every single catalog I have had the privilege of working on. Namely, IT knows applications, our users know applications, how do I get them in the catalog without turning it into an application support catalog?
The reason this comes up all the time is because there is no easy or singular answer to it. In this article, if I haven’t already set off your TLDR (too long, didn’t read) alarm, I’ll hopefully provide you some ideas and tips for managing applications, but there is no universal silver bullet.
So, let’s talk through the issue. The main challenge is that we want our catalog to focus on the business outcomes IT supports. Recognizing that IT exists to support the business, how do we present them a catalog that directly shows the outcomes we are supporting in a manner that is meaningful for them. Yes, you will have enabling/internal services that aren’t visible to customers, but fundamentally it should articulate to the business exactly what IT is providing them.
In a perfect situation, this is the route you’d take to create your catalog: You would create a service for Email and Calendaring, for example, regardless of whether you were doing on-prem Exchange, Office365, or Gmail, because Email and Calendaring is ultimately what you support for the business. You are supporting that business outcome. I’ll elaborate.
Services live a layer above applications in the service catalog hierarchy because, while applications may come and go, they’re still supporting that same business outcome – at least until the business says they don’t need that business outcome anymore. This model works well with this example, but gets more challenging when we start trying to map enterprise applications such as SAP, PeopleSoft, Banner, etc.
Enterprise applications get tough because they support multiple services, Human Resource System Support, Finance System Support, SIS Support, etc. This is further compounded by the fact that our users also know them and refer to them by the application.
There are a couple ways to handle this. One is to list the applications in the service description, even in the categories and subcategories of the service catalog. This way it shows up in searches and is visibly mapped between the service and the application.
Another route is to create a service for Enterprise Application Support and one for Departmental Application Support, then nest the appropriate applications under them. While this approach makes me cry a little on the inside, it’s valid and works for many organizations. I cry because I know this approach will become detrimental to your organization after you’ve reached a certain level of maturity within ITSM. Why? Because what you’re really doing with this is working at the service level while you’re actually still at the application level. This will eventually give you headaches, but if it works for now it may be worth it for your organization.
I’ll write a separate article doing a deeper dive into the application and service catalog issue, for now I’m going to get back to the conference. Those donuts aren’t going to eat themselves.