I published this two-part article a litle while ago.
Do you see any other common pitfalls? Could we all together put together the ultimate DO NOT DO THIS list? Please reply and let me know and we'll compile the next 10 most common pitfalls of creating service catalogs.
IT Service Catalog - Common Pitfalls
Over time, there has been a wide range of Service Catalog initiatives - from the very successful to the flat-out failures. From this broad spectrum of experiences, clear patterns have emerged. The same mistakes have been made in many of the failures, and many common attributes associated with the successes. Whether you call them best practices or hard-won wisdom, there are clearly lessons to be learned from these experiences.
This is the first of a two-part article sharing some of those lessons learned and suggesting ways you can achieve success by avoiding the most common pitfalls. But before we talk about the typical mistakes in creating a Service Catalog, let's briefly review its purpose.
Why Do You Need A Service Catalog?
The primary purpose of a Service Catalog is to communicate how IT can help internal business customers and end users do their jobs. A successful Service Catalog helps the business understand the value that IT delivers, answering the questions, "What does IT do?" and "How well does it do it?" By mapping IT services more explicitly to business needs, the IT organization can better understand how to add even more value. This aspect of the Service Catalog helps address three of the most emotional words in the IT vocabulary; "IT-Business Alignment."The Service Catalog can also provide a vehicle to realistically set - and meet - business expectations. One of the common complaints we hear is that IT never meets it deadlines. You may think you're delivering what the business wants, when they want it. But without a Service Catalog to clearly articulate what will be delivered and when, at what price and what service level, your internal customer's expectations are likely to be very different than you think they are.
In addition, a Service Catalog can help standardize service delivery and improve service quality. Without a standard catalog of services, each request from the business is treated like a unique deliverable - achieving consistent service levels and continuous process improvement becomes virtually impossible. By guiding business users to order from a standard menu of services offered, the IT organization can drive repeatability and predictability, which is the only way to improve quality and reduce costs.
Finally, the Service Catalog can influence and inform business user' consumption choices. Even if you don't actually charge services back to the business, the catalog can help them select the appropriate service by providing visibility into scope, cost, and service-level options. By publishing tiers of service and cost-performance trade-offs, IT can effectively "right-size" consumption, reduce overbuying, and control demand.
The end result of a successful catalog of standardized IT services is measurable and dramatic. Some noted benefits we have seen:
- A 30 percent reduction in the operational cost of delivering IT services;
- 50 percent faster cycle time for the fulfillment of services;
- Better allocation of resources to effectively meet business demand; and
- Most importantly, significant improvements in internal customer satisfaction.
Clearly, if you are implementing ITIL, or any service-based framework, the Service Catalog should be at the top of your to-do list. Now let's take a look at the top four pitfalls to avoid in your Service Catalog project.
Four Common Service Catalog Mistakes
Pitfall #1: Assume your customer understands what you're talking about.
A common mistake with many Service Catalog initiatives is defining services in technology terms, with service levels based on the metrics that are easiest for IT to track. This is called the inside-out approach and it almost always fails.
Successful Service Catalog projects start by asking users and business stakeholders what they want and what's important to them, and building the catalog around those success factors. This is the outside-in approach.
The problem is that while IT tends to be organized around technical, skill-based or asset-based silos, business users think in business outcomes. So while IT's customers may be thinking about on-boarding new employees or their order-to-cash process, IT is talking about their change management process or distributing computing.
If you package and communicate your services and metrics with a focus on business-relevant deliverables, rather than the underlying technologies and technical service levels, you've overcome one of the greatest barriers to success.
Pitfall # 2: If you document the Service Catalog, they will come.
Recently, we spent time with the IT infrastructure group of a large organization that took two years implementing ITIL. They sent their entire team to ITIL training; they dutifully documented their processes and catalogued their services. But nothing changed in their interactions with business users. Despite having a list of IT services readily accessible on the corporate intranet, business users didn't seem to want to refer to it.
The problem was that their Service Catalog was merely a static reference document. End users could go to it to read about IT services, but they needed to link to another form or call the help desk to submit a request. Business unit executives could skim the document to see service level commitments and budget allocations, but they had to contact a relationship manager for up-to-date information on service performance, cost, and quality. The Service Catalog became just an extraneous step in the process.
Too many Service Catalog projects stop with publishing a document or posting it on the Web. These catalogs aren't used and they don't make an impact. A successful IT Service Catalog is accessible in the moment your customers want to or need to think about IT. Here are a few tips:
- Make it interactive. Rather than presenting a super-set of all possible services and options, personalize the users' view of the Service Catalog based on their job function, location, and role.
- Make it actionable. End users should be able to place an order within the Service Catalog, and business executives should be able reference the Service Catalog when they want to review their IT bill or make sourcing and budgeting decisions.
- Keep them coming back. Use the catalog to keep the business updated on IT consumption and service levels, and provide end users with the ability to check the online status of their requests.
Keep these principles in mind and you can overcome this pitfall and promote adoption. Otherwise, your Service Catalog is likely to gather dust on the virtual shelf.
In the next installment we will cover Pitfall #3: Solving World Hunger and Pitfall #4: A Service Catalog is just a front-end to the Service Desk.
Until then.
Comments