The concept of IT Service Management is rooted in the idea of managing and delivering services versus operating and maintaining systems and technology. This can be a major paradigm shift with IT teams as most “techies” are extremely well versed in current and trending technology, but struggle with the concept of providing a “service”. This can significantly compound the difficulties of establishing a Service Catalog. It has been my experience that organizations that get “stuck” in an infinite Service Catalog Project loop, have overlooked a few critical steps that would have facilitated the intended outcome.
Phase 1: Define. The first activity of any endeavor should always be to establish and socialize a common vision for team members and relevant stakeholders. In the case of a Service Catalog Project, the vision may appear to be apparent…the establishment of a Service Catalog…however, most projects of this nature fail to go through the necessary evil of actually defining and agreeing to the definition of a service. As a recommendation, IT Infrastructure Library (ITIL) defines a service as “A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks.”
Regardless of how your team settles on the definition of a service, this should absolutely be your starting point. It will quickly get the Service Catalog Project Team on the same page and help eliminate inference and misconceptions about services. With service defined, the team should then identify all customer related activities (internal and external) and agree on which of those offerings satisfy this definition. That said, the process of defining and understanding this outcome-based definition of a service will have greater success if ALL relevant stakeholders are included. So this begs the question: who are the ‘relevant’ stakeholders?
Organizations of all types seem to understand that establishing a service catalog is a major undertaking, and as such, the most common approach is to launch a project. While I will agree with this approach as a great starting point, team composition is often the result of ‘best guess’ selection. Relevant stakeholders should include adequate representation from all parties with vested interest in the service catalog. Typically, organizations will include some or all of the following roles on the team: The Project Manager, a Team Lead, the Service Catalog Manager, representation from a few key processes (Incident Management, Request Fulfillment, Change Management), as well as a few key members from the Tier 2 Technical Support Teams. With that done, the team is set, and the project begins. However, the stakeholder most often overlooked in a Service Catalog initiative is; unfortunately, the customer!
For all the hard work that goes into providing appropriate services at varying levels to different customers with specific needs, I continue to be surprised by how “late in the game” we involve our customers. The point here is this, if services, projects, and changes are planned and implemented without customer involvement, we fail to attain customer buy-in early on. As a result, the only communication option remaining for the customer after ‘go live’…is feedback. If you’ve ever been on the receiving end of this feedback, you know that some will be good, and some…well…not so much. With respect to the – constructive – feedback received, the facts are simple; customer involvement early in the process would have ultimately led to a solution set better aligned with customer expectations.
I know.
I hear you.
That said, the consequence of not involving the customer is that ever-persistent state of reactive activities, fire fighting, and potential re-work that could have been prevented. As to how to involve your customer(s) in the project, my advice is to categorize your customers into groups, and then seek to establish individual representation for each customer group.
Customers are essential to identifying services, as they often have a better sense of the services they receive from service providers (and how well or poorly their needs are being served). As IT Service providers, it can be an exhausting effort to identify all services offerings in a vacuum. I’ve seen situations where technical folks gather around the table adamantly debating whether or not applications are a service, or whether or not the network is a service. The value of having customer representation in the room is that it affords you the opportunity to ask them the direct question: “Which of our services do use?” Try as we might, there is NO substitute for the customer’s perspective.
With the addition of customer representation, the team is now better suited to adequately identify services for the catalog. But hold on…not so fast! Barreling down the path of simply identifying and listing services can quickly become an arduous and seemingly never-ending task. In fact, a colleague of mine told me that a former client once came up with a list of over 700 services. Wow! But…now what? If that is your number of services, how do you present that to customers in a user-friendly format? Which customers should see which services? These questions, and many others will arise in the form of new challenges if we simply start out by focusing our energy on identifying individual services. A means of preventing this exercise from resulting in an unmanageable number of random services is to first provide structure. This structure comes in the form of identifying overarching headings under which specific services will be later populated. These headings are commonly referred to as “Service Lines”.
A service line is essentially a grouping of related services. Without which, you may end up in a similar situation as the team who generated that random list of 700 services you will find difficult to control, manage, and or communicate. When discussing or explaining service lines, I like to use the analogy of a restaurant menu as a service catalog. Since we are all familiar with how menus work, think of the headings on the menu like, Appetizers, Salads, Chicken, Beef, Pasta, and Deserts as service lines. Under each of these headings (service lines) are listings of the specific dishes (services) available to customers. This widely understood method of grouping like dishes can easily be transferred to your service catalog by using service lines. However, since most service line headings are not as universally recognizable as menu headings, you should consider using brief description to facilitate ease of use.
One example of a service line and description that I advise clients to use is “Resource Management”. The accompanying description included in the catalog would be as follows: “This service line includes services that implement, operate, and maintain physical IT service assets that underpin IT and business services.” With this service line example, you can easily see how services such as Server Management, Network Management, Storage Management, and Print Management could logically fit into this service line description.
To the point, the task of identifying service lines is a manageable way to provide structure to the more daunting task of identifying individual services. Then, each service you subsequently identify as a current offering will have it’s logical place on the menu.
By this point, you have identified stakeholders (including your customers), defined the concept of a service, and established your service lines. This is the promising start needed to generate the positive momentum required for “Phase II: Design,” which will be the topic of my next blog of this three part Service Catalog series.
