It’s unfortunate, but projects sometimes fail. In fact, IT projects in general fail anywhere from 20 percent to 50 percent of the time. While many factors may contribute to a project’s failure, identifying the specific ones that caused a particular project to fail can sometimes be challenging. At other times, however, the things that caused a project to fail are glaringly obvious.
According to one report, 30 percent of IT service management projects are left unfinished because their service definition is inherently flawed or unclear. A study involving about 100 companies that attempted to implement a Service Catalog showed that only 57 percent of the businesses viewed their project as a success, and 12 percent of the companies considered their project a complete failure. Approximately 34 percent of the businesses that participated in the study viewed service definition as one of the biggest threats to a Service Catalog implementation being successful.
With more than 17 years of experience, Evergreen Systems estimates that 80 percent of Service Catalog projects are a failure in the eyes of the customer. Service Catalog projects have such a high failure rate because they often do not deliver an experience that clients will like and use.
Although a poor service definition may be responsible for nearly one-third of abandoned ITSM projects, it is far from being the only culprit when it comes to failed Service Catalog projects. One of the biggest threats to the success of Service Catalog projects might simply be the language that’s used during their implementation.
What Is an IT Service Catalog?
In broad, generally accepted terms, an IT Service Catalog is simply a list of the technological resources and services that an organization makes available to its employees. ITIL v3 identified Service Catalogs as a best practice for service management and defined them as either a database or a structured document.
ITIL makes a clear distinction between customers and the users of services. ITIL considers a customer to be someone who establishes and agrees to service targets and who provides funds for the agreed-upon services. A user is an individual who uses the services acquired by a customer. Customers need to know what kinds of services an IT service provider offers so they can decide which ones to get for their users and budget accordingly. Users, on the other hand, need to know the specific IT services that are available for their use on a daily basis.
While many IT professionals refer to the service information that users have as a Service Catalog, doing so blurs the line between the information users have access to and the information customers require to choose the services they want to offer to their users. The information presented to users is actually less like a Service Catalog and much more like a service request catalog.
A service request catalog is a list of the different services users can request from their IT service provider. A service request catalog may include things such as a request for software, hardware or access to certain protected information. User-facing service request catalogs are typically supported by automation, which is able to satisfy requests quickly.
The information IT service providers give to customers so they can choose the IT services they want their employees to have access to is what comprises an actual Service Catalog. While service request catalogs normally list the individual services users can request, a customer-facing Service Catalog lists services that may have a variety of individual service requests affiliated with them. This means one of the options listed in a Service Catalog may trigger several of the services listed in a service request catalog.
Clearly, there are at least three very distinct sets of information that are often called Service Catalogs. For this reason, it’s easy to understand how a Service Catalog project might fail if a consensus about what “Service Catalog” actually means within an organization isn’t reached before a Service Catalog project plan is even developed.
This can be very confusing. In order to make this actionable, Evergreen’s approach combines the needs of all of the constituents in one solution – supporting both service requests “catalogs” and Service Catalogs, and linking them logically and naturally as would be expected by all of the constituent types.
Barriers to Service Catalog Project Success
For the purposes of this discussion, Service Catalog will be used to refer to more than the information that customers use to select the IT services they want their users to be able to request. In ITIL v2, Service Catalogs were briefly mentioned as being a result of the Service Level Management process. In the ensuing version of ITIL, the Service Catalog is described as more than a process in and of itself. It’s also described as the foundation of the service level management lifecycle.
Even though it’s a critical part of the service level management lifestyle, there are many barriers that prevent a Service Catalog implementation project from being successful that extend well beyond semantics. As more and more companies manage to overcome these challenges, Service Catalog best practices are being honed further to provide others with a practical roadmap to a successful Service Catalog implementation.
Some of the things that may prevent a Service Catalog project from being successful include the following:Misplaced motive
Depending on the project, your motive for doing it can play a big role in whether your project will ultimately succeed or fail. This certainly seems to be the case when it comes to Service Catalog projects.
The reason for this is quite simple. If the point of a project is to offload IT work, the project will probably be done quickly and rather carelessly, which will produce a result that falls far short of the expectations that your end users or customers have. Failing to deliver what you said you would does more harm than doing nothing because it angers, frustrates and disappoints your customers — possibly irreversibly.
The motive for any project, including your IT projects, should be to produce a product your customers want, need and will use — not what you think they want and not to offload work. You’ll only know what your business users need if you fully commit to customer-centric design principles. These principles challenge you to keep the needs and wants of your end users at the forefront of your designs from the start through the end of a project. The benefits of employing customer centric design principles include empowering you to lead your customer’s decisions in the direction you want them to go. They also include a positive change in the way your end users interact with your IT.
Service Catalog is considered an IT project
Too often, a Service Catalog implementation is considered an IT project instead of a business project. While IT will most certainly be involved with the design, support and management of your Service Catalog, the tool itself is made for business purposes. The point of having a Service Catalog for your business users is to increase their productivity by giving them easier and faster access to the technology they need to do their jobs better and more efficiently.
As a general rule, every IT project should start with a careful consideration of what your customers’ business needs are, and this is particularly true when it comes to a plan for a Service Catalog project. For your Service Catalog project to have a chance to be successful, it’s vital to involve your end users in the development process from the very beginning. While doing so might extend the length of time it takes for you to actually install a Service Catalog, involving your end users throughout the process increases the likelihood they’ll actually use the tool IT is creating for them once it’s completed.
The first step to getting your business users involved is to explain exactly what a Service Catalog is and how it can help them in language that is meaningful to them. If you can explain the benefits a Service Catalog will provide (e.g. increased productivity, faster IT service request fulfillment times, etc.), you increase the chances your end users will get behind your implementation project and provide feedback that will help to guide the project in the right direction from the start.
Approaching your Service Catalog implementation as a business project instead of an IT project provides additional benefits as well. With this approach, your IT team will stay focused on building the right Service Catalog as much as they’ll concentrate on building it right. This is key because it doesn’t matter how well something is designed if it’s not a product or tool that addresses a need your customers have. In other words, it is as important for your Service Catalog to be the right tool for your end users as it is for it to be well designed. By looking at your Service Catalog project as a business project, the ultimate business purpose of the Service Catalog is paramount instead of being a secondary consideration.
Another benefit of this approach is that if you build your Service Catalog with the firm intent to combine beautiful self-service AND automation, your IT costs will go down, possibly very significantly. This is because your business users will no longer have to call a service desk or rely on email to get the technical support they need. Instead, they can simply use the handy tool that was designed with their exact needs in mind, and by knowing that need – you can automate the work of IT to fulfill that request.
Culture is resistant to change
Sometimes, a company’s culture can make it difficult to introduce a change such as a different way to request IT service. Even if the entire culture isn’t resistant to accepting new things, there may still be some passive resistors who are able to influence the opinions and actions of others, which can impair the success of your implementation project. While you may not be able to change a company’s entire culture, you can involve both the early adopter types as well as the people who are reluctant to accept your Service Catalog early in the planning process; on the one hand to get them promoting your approach, and on the other hand to get them used to your initiative and increase the likelihood they’ll embrace it once it’s completed and installed.
You only have one chance to launch your Service Catalog for the first time. It’s important for you to remember that your Service Catalog already has competition even as you launch it because end users can simply pick up the phone or send an email to get technical support — things they’re already used to doing. With this in mind, you need to make sure your Service Catalog is going to be the most reliable and efficient choice to place a service request from the moment you roll it out. If you’re not successful at this, it will be very difficult for you to convince your end users to depend on your Service Catalog after it’s relaunched in the future.
Installing a Service Catalog involves much more than simply implementing a useful tool your end users can use to request technical assistance. It also involves providing a service business users will utilize on an ongoing basis. This means implementing a Service Catalog isn’t just a one-time project. Instead, it’s a process that needs to be managed and continually evolved after phase 1 of your Service Catalog is put into service. If your Service Catalog project management team fails to realize and accept this during the development phase, it can lead to unrealistic expectations and have a negative impact on the initial and continued success of your Service Catalog.
By building in ITIL Service Catalog management processes early in the development phase, your Service Catalog will have the flexibility and capabilities necessary for it to be successful over the long haul. With these processes in place, you’ll be able to manage delivery and demand by adding, changing and retiring available services as necessary, for example. You’ll also be able to improve the relationship IT has with your business users and the perceptions your end users have of IT in general. You’ll have performance measures you can use to evaluate your Service Catalog and the fiscal controls needed to identify services that have little value as well.
Put simply, building ITIL Service Catalog management processes into your project early on will enable you to manage your Service Catalog as a business much more easily, after it’s implemented. This is particularly beneficial if you offer IT services to businesses other than your own because you’ll have the processes and transparency in place that will enable you to remain commercially competitive.
Too much, too soon
One of the biggest impediments to the success of a Service Catalog project is trying to do too much, too soon by initially implementing your Service Catalog on a wide-scale basis. Instead of “boiling the ocean” with a large-scale roll out, it’s wiser to start small by beta testing or piloting the concept in just one office or division. This will give you the chance to fix any bugs your Service Catalog has while they’re still small, manageable problems. It will also give you the opportunity to garner support for your Service Catalog project.
As the people in the division you initially introduce your Service Catalog to start enjoying the benefits it provides, they will tell their coworkers in other departments and divisions about the new tool you’ve provided. This will make the people who are still waiting to have access to your Service Catalog look forward to using it instead of dreading the upcoming change.
Some catalog service projects fail because they are over-engineered. To prevent your project from being too complex for your customers, you must become familiar with their knowledge of technology and web portals so you can create a tool they’ll be comfortable using.
You also have to have the ability to recognize when your project is actually done. Before you started your Service Catalog project, you should have created a strategy and roadmap for a clear project with measurable benchmarks. In general, when you’ve achieved all of your benchmarks, you’ve finished the initial prototype of your project. You can ruin a project if you add too many last-minute bells and whistles as you near its completion, especially if your add-ons make your Service Catalog unnecessarily difficult to use, and they fail to add to the value your customers see in it.
As a general rule, it’s wise to adhere to the 80/20 rule, which dictates that your project should be 20 percent effort and 80 percent results. Your initial goal should be to produce a Service Catalog that has the basic capabilities your end users need. You should then solicit feedback on your Service Catalog from the people who will actually use it and incorporate their meaningful suggestions into future evolutions of your product. Doing this will prevent you from designing something that isn’t suitable or practical for your customers. It will also keep you in regular contact with your end users and positioned to satisfy their exacting wants and needs.
Note that while this is easy to agree to in principle at the design discussion level – it is very hard for IT to do, because IT’s nature is to go for 100%. During the project this will become a challenge, which can cause the scope to be never ending. To guard against this – 1) Get a clear understanding that phase 1 just has to be 30% better than what our users have today. 2) Communicate to the team and the customers that this is just phase 1, it will continue evolving on a regular basis on a cycle that you set, say 6 months – based on the interaction of IT and customer together. And 3) Set the schedule and then don’t change the go live date – this will force IT to make the tradeoffs necessary to get phase 1 into production as it should be.
The only way you can fix a problem is if you’re aware of it. You can’t learn what problems your customers have with your Service Catalog if you’re avoiding their invaluable feedback. Even if you’re not looking forward to what they have to say, you have to make it a regular practice to listen to what your end users think about your product. Doing so is the only way you can address their concerns and improve your Service Catalog so it works the way your business users need it to.
Simply waiting for customers to share their thoughts really isn’t enough. You can save a lot of time and spare yourself and your team a lot of wasted effort if you actively solicit feedback from your customers. Feedback can do more than identify problems. It can also be a source of useful ideas you can incorporate into your final design. Listening to feedback and responding to it openly and honestly is a good way for IT personnel to build and reinforce trust with their business users as well.
Why Evergreen Systems
If you’re looking for a Service Catalog solution for your business, contact Evergreen Systems. For nearly two decades, IT service management has been our primary focus, and we continue to help mid-market, Fortune 1000 companies and public sector organizations improve their IT service management today.
Our 80-person, U.S.-based IT consulting firm is one of the top two U.S. ServiceNow, non “Big Five” partners. We have more than 10 years of domain expertise in each part of ServiceNow’s Service Catalog. Three years ago we asked why our customers can’t have an “Amazon like” experience of IT, and the answer was, “they can.” So we began looking at everything in IT Service Management from the customer in, rather than IT out, and it changed everything we do.
Our IT Service Catalog solutions for ServiceNow are complete, end to end, pre-built solutions on the ServiceNow platform, making it easier and even better to use. As a ServiceNow Gold Services Partner, Reseller and Authorized Training Partner in the U.S. commercial and public sectors, we deliver an unparalleled experience by providing complete “IT as a Service” solutions. We offer state-of-the-art, pre-built software solutions for ServiceNow users that you can use as early as today. Our innovative software packages include an Employee Self-Service Catalog and Portal and an Enterprise Service Catalog Taxonomy Designer.
All of our Service Catalog solutions are based on five primary design principles so you can be sure you’re getting the modern, intuitive Service Catalog you need to provide the IT services your customers want. These design principles are:
With Service Catalogs being so critical to managing your IT resources effectively, why wouldn’t you choose to work with an industry leader to create a solution for your business? We don’t just offer the Service Catalog you need. We also offer training to help you and your employees master the use of your easy-to-use Service Catalog quickly, meaning we offer you a complete Service Catalog solution. Contact us to learn more today.