Service Catalogues - Why you need one

Most organisations that implement ITIL in any way are always quick to get a ticketing system in place. Incidents and Service Requests and even some form of Change Management. A good ticketing system is indeed a foundational tool for an IT department.

Like all great IT people, we all have a sense of how ITIL works, some better than others. However, the absolute bedrock of a ticketing system and the entire IT department is a working Service Catalogue.

Do you have one? Have you read it? Has anyone else read it?

If you answered 3 from 3 then good for you! But I’m guessing that could be less than one percent of you can say that.

Service Catalogues are not the most interesting of documents. They don’t have amusing stories or pretty pictures. However, a Service Catalogue is the most important and powerful document in your world.

A Service Catalogue is a document that defines the services that you as an IT department provide to an organisation. It includes each service and details around support you provide. The What, When, How and Why of supporting each service.

But the kicker. This document is not just for you. Think of it as a contract between you and the business. What’s more, your senior management group, will have signed off on this document.

If you do not have a Service Catalogue, this can sound all very formal and difficult. But remember the upside. This is a contract between IT and the business about what you support. But importantly it also defines what you do not support.

This is why these documents are critical. They address the fundamental problem we have been addressing. People who read this document now understand what you do. Ok, maybe they don’t fully understand, but there’s a marker laid down in a document. It’s a stretch to think that everyone in a business will read this document. But that’s ok.

Think of this as a contract. It’s a contract between the IT department and the business. This might be a process where you need to guide people through a whole lot of it. Drag them kicking and screaming as it were. But the guidance and the negotiation of this document is super important.

Take a basic service like email. A CIO I know negotiated a service catalogue with the IT governance team which was essentially the CEO and CFO. They of course want 100% uptime in their email system.

“Email absolutely can’t be down!”

The CIO responds: “we can definitely do that. However, right now we promise you 99.9% uptime. To do this we have some redundancy, no out of hours helpdesk, just on call. This works pretty well”

“However, to guarantee you that extra 0.1% we need to make a number of changes. More redundant email servers, 24x7 staffing, etc. It’s going to be more expensive. $50-100K for some more servers, a 3 or 4 more IT staff for coverage”

As he starts to tally up the cost, it dawns on the CFO, who does the quickest cost-benefit analysis ever and agrees that they can probably live with 99.9% uptime.

Now it’s important to note that as an IT team they didn’t just get to 99.9% and turn off the email server for the rest of the month (all 43 mins of it). They internally have the best intentions of the company at heart as well, they want 100%. But, to guarantee that starts to change the way you architect those systems, as well as the way you staff your helpdesks and teams.

Having this conversation is critical as it includes the key stakeholders in the decision-making process. They own this, as much as IT. Plus they get an insight into the process. There’s an opportunity for them to understand why that 0.1% is much more expensive. Conversely, there’s the benefit of the wider management team owning this decision and defending it when required.

“How come email is down this morning? Those IT guys are useless!”

“Well, we made the decision not to get the extra hardware and staff to save costs, so you’ll just have to live with it.”

“Oh ok CEO”

In some cases, yeah, you need a higher uptime, or staff ready to take calls and tickets, and the business will pay. These discussions as you sit down with a governance group (it could just be a CFO or owner, doesn’t need to be fancy), and discuss their expectations and yours.

In those moments where you have the opportunity with the key stakeholders, it’s up to you to make sure you are getting this right. Most of the time you need to drive conversation and point out the pros and cons of decisions that are getting made at the time, what the implications are going to be. Because you have this window of opportunity to get this right and set expectations correctly.

It shouldn’t be the only time you discuss your Service Catalogue, you should be doing a review in some regularity, bi-annually or yearly for example. But don’t waste your opportunity to get senior people to understand your world better. Maybe after a time you find that a service needs to be rescoped, and that’s fine. That outage wasn’t acceptable let’s do something to fix it.

One of the most important aspects of a Service Catalogue is what is “in scope”. Think about all the things you look after in your team. It’s easy to get a base list and core IT items like email and file servers should be easy to knock up a scope for. Trust me, those aren’t your problem. Think about the edge cases, the software used in departments, the hardware that’s not really owned by any one single team. How do you include these things? It’s important you refer to them because it’s these little items that you inevitably spend your time on. The old 80/20 rule. Right. Email is super easy, you either host it or put it in the cloud. If it’s in the cloud, then there’s nothing to do except basic management. If it’s Exchange on-premise, then same basic management, but you google search that weird event log when you’re not sure what to do. Plus, patch it monthly. Sysadmin 101.

Now consider some of the software the different departments use. Does it have a weird server, with an application that has to be running on the desktop? No silent installer for the client? A weird version of Java? Does it use Flash or Internet Explorer 9? Is it written for a 16bit Windows XP subsystem environment? Does it only use one specific fork of awk? We’ve all had these weird pieces of software. Inevitably we get dumped with this crazy software and left to deal with it.

Service Catalogues are the time to fight back. Sure, you’ll work with your crap software, but understand that it’s a two-way street.

Is it in the hot DR strategy?

Not with an architecture like that. Sorry, in an emergency you’re waiting for backups.

Can you include it with your auto-patching setup?

Nope, it’s manually getting patched. Yes, our manual patching is done on Tuesday at 2:30 pm. If that’s not acceptable, then let’s negotiate for some kind of after-hours support.

The reality of life is that sometimes people with no software experience, puke out code that somehow compiles into a system that you are asked to support. Until we can legally imprison these people and maybe cut off their hands to stop it happening again, it’s a fact of life. However, what we can do as a mature IT team, is to document this atrocity and ensure that everyone understands the implications of using it.

On the day the “designers” of the system vomit out another release, which requires everyone to be a local admin and won’t be integrated into your perfectly sculptured SCCM or Puppet system because it has no /S on its .bat file of an “installer”. When your users demand you install it immediately onto 10,000 of your most finely tuned desktops, you can refer back to your Service Catalogue and point to the place that refers to this abomination of spaghetti code and prophesies this day and proclaims “No! It cannot be done, and you must wait!”.

So sayeth the Service Catalogue.

Of course, this will probably infuriate whoever came to you with the request. Especially if you say it like that. However, stand your ground. You warned them. People agreed. Very senior people whose last name is on the building was there or at least cc’ed on the emails. You don’t make your team stay late. You’ve already agreed a course of action, and it doesn’t include the IT team filling in for other people’s bad choices.

It does include some proactive planning and hopefully this is part of a list of legacy systems you are all working together to move away from to another vendor.

Then you can choose the following retirement options for this software:

a) Move it to a farm “upstate”

b) Put it out to stud like a racehorse

c) Flush it down the toilet like a dead goldfish

d) Take it out the back and shoot it as Travis does with his dog “old yeller” when he gets rabies

PS – I really hate badly written software.

While we can all hate bad software, hopefully, you can see that we change the interaction at play. Rather than having bad software forced upon us, we support it on our own terms, with more realistic outcomes. But further than that, we identify it as “bad software” and start to have the conversation about how we get “good software”. Now, hopefully, instead of having this software thrust upon us and being expected to “do your job”, when said job is nigh on impossible to support, there is some group ownership of this software with a longer-term view for improvement.

This starts to sound like a way more equitable way of dealing with the problem. It’s not always a case of being able to just say a blanket “No” to any and all requests. There’s going to be things we have to do in the name of getting business done. Many times, software doesn’t have a replacement we can just wait for the next financial year to purchase. We may have to live with it forever. But, sometimes even just identifying the issues, noting down some way of dealing with it, and setting reasonable expectations for upgrades etc is enough to stop those 4:30 pm on a Friday impossible requests from ending up being “IT’s problem”. It makes it everyone’s problem.

In a lot of organisations, IT people are realistically the only people that can fix the coffee machine, or the TV in the break room or the jukebox. But let’s be honest, are those things critical to the function of the business. With the exception of the coffee machine … no, they most likely aren’t.

Do people expect you to fix them like they are? These are things that need to be included in your Service Catalogue. Sound basic and they are, but if your team looks after them in any way then it’s part of your job. Most likely you find a few things that are more critical than a TV. More likely to be things like the TV in the reception area which customers see, or air conditioning system for the building, or alarm security system, or video surveillance systems.

A lot of these systems have electrons and even networking components. But they can be borderline as far as stock standard IT type items.

Maybe, it’s more like the video surveillance system that neither IT nor the maintenance department owns. Both have some level of skills to maintain it, but neither have official responsibility for it.

It might be time to step up and take on that system to ensure it’s getting looked after. We can be super reluctant to do that because it’s another task on the giant pile of tasks we need to do. What if instead of just piling more work onto your teams list, you actually define this in your Service Catalogue. Then as you go through your entire list of responsibilities you can define what air conditioning maintenance looks like (simple call to a guy). Or what it looks like to take on video surveillance systems. That latter could be quite involved and take on further budget costs, capital costs and time for installation, configuration and maintenance.

By doing this, however, you roll things into your planning, so that ancient old phone system gets replaced with a more modern solution. In doing so you might save the company a large chunk of maintenance costs. This type of complaint is common with IT guys. Why do we have that legacy PABX or old security system which stores recordings onto DVDs? It must be expensive to maintain and there are better ways to do it.

Yes, it is expensive, yes there are better methods. Time to put your big boy pants on. Put a business proposal together and help save the company time, money and effort. I can’t imagine an executive who would say no to someone stepping up to take on the responsibility and do it better. Remember that the finance guy who rings the PABX guy to change phone numbers around probably hates it as much as you do. He probably understands there’s a better way to do things but he wouldn’t know how to get there.

Be sane and help the guy out.

What do you Catalogue for your Service

So you know that you need to look after a service, say email, but what do you put in your Service Catalogue under the entry “Email”?

First of all, determine what the scope of the service “Email” includes. You’d probably write things about sending and receiving, filtering, archiving, litigation hold, permissions, forwarding. Standard stuff. What about email clients like Outlook? Does that count? Well possibly, but that may be included in “Software, Desktop Apps” and feature there.

It’s up to you but, after defining your service, you need to scope out how you support it. In this case, you may want to include details of a support team structure that includes Exchange architects, not first-level support. It’s up to you though and each case is different.

You provide email. How do you intend to provide this service? On-prem, cloud, some sort of redundancy? You don’t need to include IP addresses and server names, but you should have some details as to the basic architecture you are using or intend to use for this service.

This should lead on to DR, backups, and your SLA for your service. SLA for uptime, SLA for response to an issue with the service, a critical issue with service, and Recovery Time Objectives and Recovery Point Objectives.

This is the document you want to give you these types of details. The factors here will help determine a lot about your IT team.

They determine the things you drop everything for to go fix. If email is critical to the business (HINT: it’s usually not), then when it’s broken, you stop and fix it. That could be 24x7. Maybe that’s only when business is conducted which is more like 8x5.

This is a critical distinction. If you agree to 8x5 as critical hours, then by definition after hours are a whole different ball game. Now, that might not mean you can just switch off and let everything die until 8 am the next day, but it could possibly mean that for non-critical systems. A system providing software updates could be down for a day and the business keeps on making widgets.

Which by definition means if it breaks at 9pm and you fix it at 10 am the next day, you could be well within your SLA period. Nothing is critically affected, widgets are still made, life goes on.

This may not be as important for Joe Bloggs the standard user, but for burnt-out IT guy, it would be awesome to know that you don’t HAVE to fix that system out of hours. Because in all likelihood, you won’t get paid for it. You can get an SMS or email informing you that a non-critical system is down, and you can enjoy your downtime knowing that you are within your right to wait until tomorrow to fix it.

Most likely you get an angry phone call from a user at an unrealistically late hour informing you that a system is done, and by the Service Catalogue you are within your rights to say “No” or have no one on your 24-hour helpdesk who can fix the issue, only do limited troubleshooting.

The point is this is the place to define these criteria.

• What is this service?
• How does it work?
• Who supports it?
• What happens when it breaks?
• How long is the business able to function without it?
• Document it, discuss it, negotiate it and agree on it.

Sword and Shield at the same time

This is probably at the heart of a lot of the big complaints I see from IT professionals. We are torn from one critical issue to the next. We are a people in demand.

A big one I see is the Executive who wants item X. Say you have all Windows desktops. Executive comes in with new MacBook. Demands to be able to use said MacBook instead of Windows machine. This is a perfect place to refer to your Service Catalogue. Under desktops you clearly specific Windows 10 supplied by vendor X. As this is not in the Service Catalogue, you can do either one of two things.

Firstly, take the opportunity to include MacBooks as part of the Service Catalogue. This could be a good thing. But first, look through your Catalogue, see what services may need to be changed to accommodate MacOS. There may be software that isn’t native on the Mac. Ok well, you can run Parallels and put Windows on it. Technically, this solution may fix your issue. But there’s a cost. And most likely a user education cost as well. Your users may struggle to understand Virtual Machines. Maybe, there’s a cost to upgrade a system for MacOS support. You may need to train more of your helpdesk on how to support MacOS. Maybe you stand firm that only Executive A can have a MacBook and he supports himself and deals with the consequences. Maybe you are in a situation where you need to expand your support to include multiple OSes anyway and this was inevitable.

Either way, this is the chance to revise your Service Catalogue and include all the ramifications, costs, SLAs etc to the document.

You may find that the Executive just likes the look of the Mac and he doesn’t want to have to pay extra costs. You definitely want to have all this agreed on before the Executive brings his shiny MacBook to the next big meeting and EVERY Executive now wants a Mac.

Before you had a Service Catalogue, these kinds of requests are potentially difficult to shut down. You’re just being petty or no fun when you just say no all the time. Instead, now you are demonstrating how changing the end-user environment fundamentally shifts how you provide services to the company all with one MacBook. At the very least you have a concrete document you can review and say these systems do or do not work with this new machine. You may find it quite compatible. You may find that systems you have in place to provide compliance reporting, antivirus and other services which protect the company aren’t compatible and you have a demonstratable case of “this breaks our compliance”.

That may not be too much of a threat if the widgets you make are toys for kids. But if you make highly classified widgets for redacted then that may prompt more of a response.

If you are overruled and Executive MUST have the MacBook, your Service Catalogue exception may be “supported on best efforts only”

Maybe the request isn’t a petty one of MacBooks vs Windows. The process is the same though. Suggesting a change to the services IT provides needs to be vetted against the catalogue to understand the impact. Then if everyone is happy changes and inclusions are made.

You have a tool now. It’s your sword and a shield in one. It protects you. It can help fight your battles for you.

Putting it all together

Now after some hard work you have a Service Catalogue. It is for now complete. All services you provide to the business are included. Standard IT stuff. Crap software. Slightly not IT stuff. MacBook’s and next year Linux.

You now have in your hands or on your screen a document that defines IT for your business.

This is fantastic! Now, the real work can begin. Because this document can determine how you put together your IT team. IT documents for how you put together your IT systems.

Before you were just guessing, based on gut feeling. Now you have a mandate.

Sounds amazing and it could be. In most cases, you may not feel you have much to change in your team, in your environment. But over time you have a tool you can use. You use this for planning, for budgeting for understanding where and how your team will grow over time.

This is an excerpt from Becoming King of the Nerds: How to Run IT Teams and Influence People

Grab the eBook or paperback for more great tips and wisdom. All the really good stuff you have to pay for.

Available from Amazon at: https://amzn.to/3wsjFgi