5 Minute Read
If I could recommend one program (the ongoing activity type, not the software type) to every IT department, irrespective of size or industry, it would be to develop and maintain a Service Catalog. In fact, when I work with my clients’ Helpdesk teams, this baselining exercise is foundational to many of the services I provide.
What is a Service Catalog?
A Service Catalog formalizes what an IT department does and what an IT department does not do.
Service Catalogs that are maintained and adhered to by IT departments and their business peers can be key factors in how high-functioning IT departments perform at the top of their game. If an IT department has not bothered to formally publish this document, the concepts of a Service Catalog may be implied by past interaction or company culture, but this informal approach leaves room for ambiguity. An implicit type of Service Catalog might be appropriate for some organizations, but I would generally recommend the document exist in writing. A department doing this effectively will experience minimal frustration among internal customers, senior management, support agents, and other technical staff while improving tranquility and empathy among the stakeholders. Making the effort to write this document is the right thing for an IT leader to do, full stop. The textbook version of this document is covered comprehensively in the ITIL framework. Since this blog’s purpose is not to provide repackaged/plagiaristic articles farmed from the world wide web (shout out @ChatGPT), the focus will be on my approach — first and foremost drawing from personal experience, second from the management science domain, and last but also least the maligned ITIL textbook.
The Service Catalog represents a contract between IT and the organization it supports.
Collaborating parties, who don’t have a contract that defines their respective roles, face barriers to their collaboration. Conflict about which responsibilities belong to whom risks damaging the relationship over the long term, while parties who have a mutual agreed-upon understanding will have a more sustainable working relationship over the long term. Consider a contract as a metaphor for an IT Service Catalog, and contents of the catalog as provisions of the contract. Hereafter the list of services, representing business administration and technical functions, include in their entirety those which the IT department shall provide. Any request or incident not related to one of these services shall be settled by binding arbitration subject to the foregoing dispute resolution terms in the jurisdiction of the IT department’s choosing. Sounds pretty serious, right? Or is it more like a pathetic attempt at legalese impersonation? A simpler metaphor for an IT department’s catalog might be Yev Kassem’s famous Soup Kitchen menu from the TV show Seinfeld. Kassem’s constantly busy establishment was known to be the best place to get delicious soup (hopefully your IT department is the best place for your business to receive technical assistance), but Kassem enforced a strict manner of behaving when placing an order for soup. Try to order off the menu, and all you’ll get from the “Soup Nazi” is a sharp “NO SOUP FOR YOU!” Don’t get the wrong idea — adhering only to providing service related to the items in the IT Department’s catalog is important but so is diplomatically responding to out-of-scope requests. In fact, defining what is in-scope versus out-of-scope is the first step in starting this document.
Begin with a list
Many who are just starting their own Service Catalog journey begin by staring at a daunting spreadsheet template. These are readily available from a multitude of sources (ITIL is one such source), and the templates feature extensive column headings, formulas, and unfamiliar jargon. If discovering one of these templates initially provides a feeling of accomplishment, know that the feeling is short-lived. Extensive, complex service catalog templates, those that cover every variable imaginable, provide minimal utility and benefit to the teams who rely on them to start their Service Catalog journey. There’s a time and a place for these templates — textbooks and make believe IT scenarios are appropriate. However, I do not recommend taking the approach of starting with complicated templates to my clients. There are two insidious issues with this approach:
- No organization, which wasn’t designed as a cripplingly bureaucracy from the beginning, will be capable of neatly populating the cells, leading to disappointment and feelings of failure from the very beginning.
- It’s a spreadsheet, and it will inevitably be entombed, then buried by the sands of time in a shared folder. You’re more likely to encounter old tax documents on their seventh birthday than you are to look at Service_Catalog_Template_1.xlsx again. My advice is instead to start with a simple list.
The first few items on this list are easy to populate. Many activities in an average IT department occur daily and are always top of mind. Note what these activities are and group related activities into categories where possible. New user setup, granting access to applications, and loaning equipment are routine tasks that are easy to recall. Categorize these as helpdesk services, then move on. To be as complete as possible, it’s worth looking through a sample of <1 year old tickets. This initial list will probably end up looking something like this:
Sample Service Catalog List - R.M’s IT Department
Decorate the list
Next, flesh the list out one attribute at a time. Avoid the tougher to define attributes, like recovery time objective, service level agreement, mission criticality, etc. All of these can be objectively defined for every service in the catalog, but populating these requires deep analysis, input from multiple stakeholders, and meetings. I shudder at the thought. Instead, start with something easy like “if I needed something done related to this service, or if this service is broken, who would I call?” Add these as columns to the list.
Decorated List
Other Attributes
Services will have other attributes that are worth capturing. In addition to some of those already mentioned, consider documenting others:
Service Catalog Attributes
- Service Description that elaborates on its name and can help distinguish what the service is versus what it doesn’t include.
- Tags that can help describe and group catalog items that have things in common. These can describe the status of service catalog items (draft, awaiting approval, active, retirement planned), generalize groups of owners (internal, external vendor, shared), and may describe things about a service that eventually evolve into new attribute columns.
- Costs or rounded figures that imply a quantity of resources required to provide the service. If a dollar amount is inappropriate for the audience, this could also be a percentage of the department’s budget, employee headcount, or person hours spent delivering the service.
- General Ledger Accounts which can help reveal if there is alignment between the catalog and how expenses are tracked.
Additional Attributes
Relations
In future posts, relations between the Service Catalog and other entities, like projects, helpdesk documentation, software applications, or disaster recovery plans will be explored. We also will look at representing these connections between the Service Catalog and other entities using a simple relational database tool, Notion. Consultants who are versed in a variety of IT and management topics can start with a client’s service catalog and strategically identify weak or missing services, a discovery exercise that helps clients get the most value out of the collaboration.
5 Minute Read
| 9 Minute Read
6 Minute Read
| 6 Minute Read
| 7 Minute Read
5 Minute Read
