Next up in our series is the Security Service Catalog. Like most of the Magnificent tools the service catalog has roots from ITIL and drives operational excellence or six sigma type outputs. I prefer a much more modest scope because this is an area where it's easy to do too much. Keep it simple and save the energy to include costs, SLA's, and other management features for later.
While it might be a simple document, the service catalog kind of sneaks up on you. No one likes taking the time to put it together and sometimes dismiss it as management overhead. As soon as it's done it's posted on the intranet and nothing happens.
Then one day someone asks a question:
Then simple service catalog comes to the rescue. Voila!
The above all start with defining what 100% of your services means to you. It's kind of the offensive line of the magnificent 7: not much attention but so much relies on it.
Our position statement: a service catalog is a document listing 100% of what your service covers. It provides the foundation for multiple deliverables and helps all stakeholders understand what you do. It's better than nothing for the efficiency gained from reuse when addressing any need requiring a scope definition of your service. It's focused on simple service and sub-process definitions, keeping attributes and measurements about the services for other deliverables.
Stay on Target
The first trick to produce a useful catalog is finding the right level of detail. This is not an exercise to justify everything you do. It's an exercise to define the services your team provides the company. If your company is already an ITIL shop, align with the buckets e.g. problem, service management. If you're not an ITIL shop, I don't recommend you start a grass roots ITIL movement. Keep it simple. In my experience you shouldn't have more than 8-10 key services. A handy guide is ISO 27k. The control domains might not be defined as processes but they're a good guide. They don't map perfectly however and that's why it's a reference point only. Couple other notes:
If employees are new to defining what they do, they might get a little nervous because the next thing you might do is start to measure them on it! Thus, people will tend to document way too much. If you must, let them do it and set the expectation you'll be asking them to consolidate into functional buckets. Here's an example service catalog I scrubbed and combined from a few others. Each Service and sub-process should have one owner and two-three sentence description (no more). Be suspicious if you have more than 40ish sub-processes or greater than 10 key services. Here's some criteria I've found useful when defining:
And for the process geeks, it's a process if it has a true SIPOC (source, input, process, output, customer) and one Accountable person.
On Organization Charts and Politics
Please don't take the easy path and map your processes using your org chart. It's okay to have a sub-process in one group under a key service in another. If it's not right for your business, be candid about it. You don't have to re-org right now but when you do people will understand why. This is a great intra-group FUD killer. Employees inherently know when something isn't aligned. It's best to acknowledge and have some candid conversation about why. Whenever I've seen an "as-is" catalog there's usually a "to-be" not far behind.
Don't Delegate the Task
When you create or update your service catalog, please don't delegate to a project manager, chief of staff, or anyone other than your direct reports. It will be incorrect and easily dismissed unless the accountable middle managers take ownership of their services.
The related areas of the service catalog start to merge into ownership, role definition (RACI), capacity management, and effectiveness. Those are magnificent tools themselves and will have their post. If you don't have a current service catalog. Please give it a visit. I'm not sure why exactly but writing down what everyone does earns major leadership points within and beyond your team.
One more note, whenever we (as software developers) see data that looks like a table with multiple dependencies and measures associated to it, we get excited because there's opportunity for analysis, reporting, and visualization that takes a prohibitive amount of time in excel. More to come on this topic...