Why is it so hard to define Services?

Services – what your organization offers to your customers – are both the pinnacle and the foundation of an IT organization, yet it seems to me that nearly everyone struggles with defining what they are.  Services are the pinnacle because they sit at the top of your CMDB; built upon and made up the different technological bits and should be first and foremost with your users (via your Service Catalog).  They are the foundation because every action your team takes should point back somehow to providing these services to your customers.  Additionally, they are the foundation for your Service Level Agreements and the metrics you use to gauge your performance.  This is easy stuff, but the majority of IT groups can’t articulate in an elevator, “what do you do for the business?”

In my head, I’m seeing the two Bobs from Office Space sitting across the desk asking a nervous employee, “What would you say you do around here?” because it’s the same metaphor.  What is your value?  What can do you for me?  Why am I paying you?  What makes IT an important player in our business?

I also think of Services as the tip of the CMDB iceberg.  The Services are what sit above the water; they are what your users can see, but they are supported by all the different Configuration Items and technology components that form the complex systems to keep the iceberg afloat.  Your users see only your “Messaging” Service.  In the modern era we know the technical solution behind that is email.  But your user doesn’t see, nor care about (nor should he) about all the Exchange servers and databases and routers and gateways and UPS and SAN devices that make email possible.  Those components sit below the surface.

Your Services should remain generic and technology agnostic – let the technical solution define the specifics.  Fifty years ago, the Messaging Service was provided by the mailroom, a cart and a clerk.  Give your Services enough room to evolve.

Your Services need to be descriptive enough for your non-techie users to intuitively know what they are.  I find the term, “Desktop Support” to be a good example of a bad culprit.  Does this cover help I need on my laptop?  What if I need a physical desk for a new hire; is it these folks or Facilities?  If you give your user the opportunity to be confused, they will be.

Defining Services can be as simple as gathering your team around a table.  Believe me, they know what they spend their time doing each shift.  Ask them to form a consensus on how to group exactly, “what we do around here, Bob”.  This doesn’t have to be anything more than a list.  You’ve now got the first draft of your Services.

Your team might get stuck on the concept of defining business Services vs. technical solutions.  If they can’t see the forest for the trees, try this exercise.  Ask them to define the Services not of your IT organization, but of your city.  The concepts are the same, but an abstraction layer helps folks “zoom out” on the terminology.

Cities might provide Security (Police force), or Fire Services or Snow Removal or Outdoor Space Management (Parks & Recreation).  Perhaps a critical Service such as Trash Removal isn’t provided by the city, but by an independent company.  That’s a good example since we do in fact want the Services that other parts of our business provide to appear in our central Service Catalog.  Such non-IT Services could be HR or facilities-related.

The list will be the hardest part, but offers immediate reward.  Further exercises will have us map our Services to the critical CIs that support them.  We will define our Service Level Agreements saying what acceptable performance is for each Service.  And we will augment the short Service name with a more-detailed description, a managerial contract and technical contact and other metadata we find value in capturing and conveying to our customers.  Finally, we can define the Services’ Lifecycle.  But let’s crawl before we walk.

There’s no excuse for IT organizations to not have at least of list of the Services provided to the business.  It’s the reason we get our paychecks.  Hopefully, IT team leaders won’t see this as a daunting task, but rather a simple afternoon exercise.  By making it obvious the value you that you are providing, you’re strengthen your team and giving IT a bigger say and better seat at the table within your business.

ITIL terms used here:

Service – A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks.  They must add value to the customer, support his or her business objectives and be perceived as a coherent whole.

Technical Solution – Also called an IT System, this includes all the components needed to build the solution.

CMDB – Configuration Management Database.  The single definitive source of information about our assets, their configuration state and their relationships to each other.  Each record in the CMDB is defined as a CI.

Configuration Item – Or CI, an asset, service component or other item that does, or will, require maintenance, integration or customization as part of a system or solution.

Service Catalog – The single menu or list of Services available to customers, along with additional pertinent data further explaining or defining the service.