IT Service Catalog The Common Pitfalls (Part Two)

By Rodrigo Fernando Flores

The first part of this article can be found at ITSMWatch.com . It covers the key reasons why you need a Service Catalog, Pitfall #1: Assume your customer understands what you're talking about, and Pitfall #2: If you document the Service Catalog, they will com.

Pitfall #3: Solving World Hunger
Many Service Catalog projects attempt to exhaustively document every service, every service option or permutation, with each associated activity, task, configuration item, and workflow, and end up, Well, exhausted.

It is hard to keep track of the number of Service Catalog projects that start out as quick laboratory experiments and end up as multi-year research projects. Here are some symptoms you may be on the wrong track.

• Your catalog is in a Word or Excel document running hundreds of pages, it won't be read.
• The services you thought were fully documented changed before you were able to publish them, you're making it too complex.
• You spent months coming up with the right category-type-item (CTI) structure, you were talking to the wrong people.
• You started by documenting the back-end technologies, assets, and infrastructure, you're not customer-focused in your approach.
• You find yourself with flow diagrams that extend hundred of pages, it will not be used.

Don't let this happen to your project. Remember, "Perfect is the enemy of done."

Creating an actionable and successful Service Catalog may seem like a daunting task, but it doesn't need to be. Successful Service Catalog projects are pragmatic and focus on making high-return, customer-facing services accessible to your business users in order to build credibility and make an impact.

As the surf band, the Ventures, said: "Walk, Don't Run." Follow the adoption wave in rolling out your Service Catalog:

• Start by cutting your teeth on end user services for the quick win;
• Extend the catalog to application-related services and more technical infrastructure services.

Pitfall # 4: A Service Catalog is just a front-end to the Service Desk
Many failed Service Catalog projects start at the help desk. At first glance, the help desk may seem like a good place to start. Following ITIL guidelines, the Service Desk is the point of contact with your end users for addressing any problems, complaints, or questions. But based on experience, it is clearly not the right place to start with your Service Catalog.

First of all, the Service Desk is designed around Incident Management to address service disruptions, whereas a Service Catalog should be focused on ongoing service operations and service agreements to support the business. Moreover, the Service Catalog encompasses more than just services associated with the traditional help desk. The purpose and scope are different, and the approach should be different as well.

Another challenge with the help desk approach is the interaction model. In an effort to make the Service Catalog actionable and transactional for end users, I often see service descriptions linked to a self-service help desk form. Unfortunately, these forms are typically designed based on a CTI (category-type-item) and trouble ticket structure.

The CTI structure works well for trained staff to quickly record and resolve incidents. But for business users, it is extremely cumbersome to choose from a pick list in a CTI structure; in many cases, they are faced with a series of cascading menus that fill the screen.

End users simply refuse to adopt this self-service model; instead, they pick up the phone to call the help desk. If you had hoped to use the Service Catalog to drive standards and reduce costs by eliminating manual steps, yet you approach it as simply a front-end to your existing help desk system, you clearly won't accomplish your objectives.

To succeed in making your Service Catalog actionable and user-friendly, you need to provide business users with an interface that they are familiar and comfortable with. Look to the leaders in e-commerce for ideas. Provide the same look and feel (e.g., search and browse, create a shopping cart) that users encounter when ordering products or services online.

It's a concept such as; Yahoo-like search and categorization, Amazon-like merchandising, Dell-like configuration and UPS-like tracking for services. The payback is faster adoption and more immediate benefits for your Service Catalog project.

Conclusion
We've seen many IT organizations that try to create Service Catalogs themselves make many of the same mistakes. Now that you know some of the common pitfalls, you can focus on how to ensure success with your Service Catalog initiative:

1. Define services from the perspective of the internal customer;
2. Segment internal customers and deliver differentiated, role-based content;
3. Make it transactional and actionable in nature; and
4. Provide users with a "look and feel" and experience that they are familiar with.

Implemented correctly, the Service Catalog can drive a fundamental change in the relationship between IT and the business. The Service Catalog can communicate how IT helps internal business customers and end users do their jobs. The Service Catalog sets realistic expectations with regards to deliverables, price, and performance metrics. Finally, a well-executed Service Catalog can help your IT organization to manage service demand, standardize service delivery, and improve service quality.

Future articles will delve further into the tips and tricks to success. Stay tuned for more on the IT Service Catalog.

Rodrigo Fernando Flores is the founder and chief technology officer of newScale, with more than 20 years experience in software development and IT management. He is a member of the IT Service Management Forum USA, and has advised several leading Fortune 500 companies in their ITIL and Service Catalog initiatives.