The broadened processes contained in the ITIL® v3 service lifecycle have provided greater interest and associated challenges related to developing a service portfolio and service catalog. One of the most challenging is deciphering the components of a service catalog: what its end-state looks like to IT and the business, as well as how it can be leveraged to deliver business value.
Before we decipher the attributes of a service catalog, let’s first address a common mis-perception. Many organizations can churn a lot of cycles when defining a service. Referring to the service strategy publication in ITIL®, the definition is simple: “A service is a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks.” This definition is clear, but it is not so easy to deconstruct into a consumable and actionable form.
The mis-perception occurs when organizations define services that are merely requests. As an example, many organizations view the service catalog as a menu where businesses can order services a-la-cart. Is it truly a service, or is it a standard request that is part of a more encompassing service? It is the latter. Therefore, it is important to understand the difference between a service and a service request.
For example, when we consider ordering a laptop as a service, is the value achieved when the laptop is delivered? Probably not. The real value is realized when the user logs in and performs work that produces the business outcome that the laptop is intended to enable. The request for the laptop needs to occur and there must also be a workflow to deliver the laptop in a manner that meets the customer’s expectations. However, delivery of the system is not the end of the service value chain. The request for the laptop is the catalyst that will lead the customer to the real service value.
Imagine for a moment that a new project manager (PM) is starting with the company next week. The manager of the new PM reviews services, such as laptop delivery, phone and email setup, and facilities requests. The manager then proceeds to fill in the required fields of the online forms and submits as instructed, kicking off the back-end workflow to fulfill the services. However, what did the manager truly provision and are these services that the PM will need to be productive on the first day of work? Maybe. But in taking a closer look, the only guarantee is that the PM will have a laptop, phone, email address and a place to work.
This begs the question: What has the PM actually been enabled to do? The real value has not yet been delivered. It is still up to the manager to determine what components of those services, such messaging and telecommunications, the PM will need to be productive. Service value can be achieved only if the components of the services are understood.
Figuring it Out
To clarify the components of a service catalog, take small steps to help gain support of the effort. One way to do this is to start with a baseline of no more than 10 services with six attributes. Keep in mind that services must enable a business outcome in order to be perceived as valuable.
To get started, define up to 10 services with the six baseline attributes that lead to quicker wins versus attempting to develop all services end-to-end in one big bite. It is a good practice to appoint a reasonably-sized guiding team to develop the catalog. Remember one key phrase: “consensus can inhibit development.” Making an attempt to get every department within the organization to agree to the definition of a service, its attributes and scope will lead to gridlock. To make steady progress, keep the size of the guiding team manageable to no more than four to six members. Try to keep the amount of communication channels to a minimum, otherwise over-communication will occur and impeded progress.
When deciding on the initial list of services to place in the catalog, choose services that are smaller in scope versus choosing services that are provided to everyone. Choosing a single-line of business with multiple departments is appropriate to keep the scope manageable. Keeping it simple in the beginning will allow the team to facilitate buy-in and achieve a quicker win. Focus on the following attributes:
Service Name – It is surprising at how long it may take to get a team of professionals to agree to a service name. Discuss it thoroughly, but try not to take more than one week to decide. Let majority rule.
Service Description – Be careful not to write a book that describes the service, refrain from technical wording and keep acronyms to a minimum. The goal is to write a clear, concise and quotable description that everyone can understand, support and recite.
Service Owner – This attribute is often overlooked, but its importance is critical. Give a face to the business to ensure service expectations are met. Select a leader that is respected by the entire organization.
Business Users – Once the service is named and described, identify the users of the service. Forsythe recommends identifying by department.
Support Teams – These are the teams that will be held accountable for supporting the management and operations of the service. It is unlikely that only one team will support a service. Typically, multiple teams support a service, but choosing an overall owner is a good practice. Services are normally made up of various components and each member’s responsibilities should be listed, ensuring quality service is met.
Criticality of the Service – Defining criticality sets the tone for how the service should be prioritized, managed, operated and supported.
By following these six attributes, any organization can get started on developing a service catalog. From this point, a prioritized list can be defined as to which services will be deconstructed into its associated components. The end result will be a more direct path to achieving the delivery of quality service, customer satisfaction and business value.