Cloud and Service Catalog Blog

Lawyering For The Cloud Win. A Primer for Corporate Counsel from EMC

The two biggest objections to cloud computing are security and compliance / regulations. I believe both have some validity but I also believe both can be used as excuses to bury heads into sands and holes.

And I believe shining a light is the best way to assess risk. So it's with great delight I found this article: Cloud Computing Down to Earth: A Primer for Corporate Counsel which starts to list the types of risks that need to be enumarated. 

These include:

1. unauthorized access to confidential client information by a vendor’s employees (or sub-contractors) or by outside parties (e.g., hackers) via the Internet, see id.;
2. the storage of information on servers in countries with fewer legal protections for electronically stored information (“ESI”), see id. at 4, which can be especially problematic in regulated industries that have highly defined requirements with respect to the handling of ESI throughout its life cycle;
3. a vendor’s failure to back up data adequately, see id.;
4. the ability to access corporate data using easily accessible software in the event that the corporation terminates its relationship with the cloud computing provider or the provider goes out of business, see id.;
5. the provider’s procedures for responding to (or when appropriate, resisting) government requests for access to information, see id. What if, for example, a government (domestic or foreign) seizes the actual servers (i.e. hardware) on which Corporation A’s confidential and highly regulated data resides in order to take control of Corporation B’s data, which resides on the same shared, multitenant server?;
6. policies for notifying the corporation of security breaches, see id., so that counsel can immediately fulfill her duties with respect to client notification under Model Rule of Professional Conduct 1.4;
7. insufficient data encryption, see id.;
8. unclear policies regarding the corporation’s ability to “control” its own data, which may result in a quandary if served with a request for production of materials under Rule 34 of the Federal Rules of Civil Procedure;
9. policies for data destruction when the corporation no longer wants the relevant data available or transfers it to a different host, see id.
10. the potential warrantless seizure of corporate electronic mail under the anachronistic Electronic Communications Privacy Act of 1986 (“ECPA”), 18 U.S.C. § 2510, which includes the Stored Communications Act, 18 U.S.C. §§ 2701-12. Signed into law in 1986, the ECPA established a procedural framework for law enforcement authorities to obtain wire and electronic information, including files stored on a computer. Think Miami Vice, not cloud computing. Only two months ago, the Sixth Circuit in United States v. Warshak (6th Cir. Dec 14, 2010), held valid based on the government’s dubious reliance on the Stored Communications Act a warrantless seizure of corporate e-mails notwithstanding a lengthy and informed exposition on the relationship between technology and the Fourth Amendment, see id. slip op. at 14-29.

Actually, as I read these, the ones that I think unique to cloud are 7,8,9, and 10. It's not that 1-6 are not realistic, is that these are existing problems for any outsourcing deal, or internet connected device, which means EVERYTHING. 

The rest of the post provides recommendations on how legal counsel should prepare

 

What's the Cost of Building a Whole IT Front Office Suite?

Buid your own service catalog toolset or acquire one? Hmm... Let's look at the cost, with HUMOR!! All kidding aside, either the menu is a piece of paper or it's an operating model... Which one do you think it is?

What's the Cost of Building a Whole IT Front Office Suite?

Buid your own service catalog toolset or acquire one? Hmm... Let's look at the cost, with HUMOR!! All kidding aside, either the menu is a piece of paper or it's an operating model... Which one do you think it is?

What's the Cost of Building a Whole IT Front Office Suite?

Buid your own service catalog toolset or acquire one? Hmm... Let's look at the cost, with HUMOR!! All kidding aside, either the menu is a piece of paper or it's an operating model... Which one do you think it is?

Tool for Operational Service Catalogs

To manage an operational Service Catalog a tool is required early in the cycle.  But why?  

Some of our customers have shared with us that they started with a static offering, created a brochure and published it on the website. Got some improvement but not much.

They realized later that this manual approach was expensive from a resource and time perspective.

They shared that they should have started with a tool because "our catalog really serves the needs of an IT accounting system tool, a workflow tool, a service level reporting tool, a relationship management tool and a product lifecycle tool." This can only be done with a single tool designed to manage all of this functions.

Nicely said.

Tool for Operational Service Catalogs

To manage an operational Service Catalog a tool is required early in the cycle.  But why?  

Some of our customers have shared with us that they started with a static offering, created a brochure and published it on the website. Got some improvement but not much.

They realized later that this manual approach was expensive from a resource and time perspective.

They shared that they should have started with a tool because "our catalog really serves the needs of an IT accounting system tool, a workflow tool, a service level reporting tool, a relationship management tool and a product lifecycle tool." This can only be done with a single tool designed to manage all of this functions.

Nicely said.

Tool for Operational Service Catalogs

To manage an operational Service Catalog a tool is required early in the cycle.  But why?  

Some of our customers have shared with us that they started with a static offering, created a brochure and published it on the website. Got some improvement but not much.

They realized later that this manual approach was expensive from a resource and time perspective.

They shared that they should have started with a tool because "our catalog really serves the needs of an IT accounting system tool, a workflow tool, a service level reporting tool, a relationship management tool and a product lifecycle tool." This can only be done with a single tool designed to manage all of this functions.

Nicely said.

Heard around the watercooler

CIO: We need to be customer-oriented and financially transparent.  Our customers are asking that we explain the value of IT to the business, to understand our cost model and provide them with choices that make sense in this down climate.  We need to understand our current portfolio of services and map to where the business is going. 

Director of help desk:  Yes sir.  We need to have a catalog to manage request. But it needs to tie it to the help desk and CMDB.

CIO: We are outsourcing 30% of IT and most of the help desk.  But we will still be providing services

Director: oh.

This is an example of the chasm between senior management and the troops. The troops are paying lip service to the CIO, not out of malice, but because they are not able to connect what they do on a day to day basis with what the business needs.  The focus needs to be in the front-office of IT--that's the part that will survive.

Heard around the watercooler

CIO: We need to be customer-oriented and financially transparent.  Our customers are asking that we explain the value of IT to the business, to understand our cost model and provide them with choices that make sense in this down climate.  We need to understand our current portfolio of services and map to where the business is going. 

Director of help desk:  Yes sir.  We need to have a catalog to manage request. But it needs to tie it to the help desk and CMDB.

CIO: We are outsourcing 30% of IT and most of the help desk.  But we will still be providing services

Director: oh.

This is an example of the chasm between senior management and the troops. The troops are paying lip service to the CIO, not out of malice, but because they are not able to connect what they do on a day to day basis with what the business needs.  The focus needs to be in the front-office of IT--that's the part that will survive.

Heard around the watercooler

CIO: We need to be customer-oriented and financially transparent.  Our customers are asking that we explain the value of IT to the business, to understand our cost model and provide them with choices that make sense in this down climate.  We need to understand our current portfolio of services and map to where the business is going. 

Director of help desk:  Yes sir.  We need to have a catalog to manage request. But it needs to tie it to the help desk and CMDB.

CIO: We are outsourcing 30% of IT and most of the help desk.  But we will still be providing services

Director: oh.

This is an example of the chasm between senior management and the troops. The troops are paying lip service to the CIO, not out of malice, but because they are not able to connect what they do on a day to day basis with what the business needs.  The focus needs to be in the front-office of IT--that's the part that will survive.

IT Service Catalog - Common Pitfalls (Part 2)

First published on 3-22-06. 

The first part of this article 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.

IT Service Catalog - Common Pitfalls (Part 2)

First published on 3-22-06. 

The first part of this article 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.

IT Service Catalog - Common Pitfalls (Part 2)

First published on 3-22-06. 

The first part of this article 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.

What kind of restaurant are you?

In the class we talk a lot about the declarative aspects of the service catalogue.  By declaring into being who you are and what you are about you establish a context for the offers, requests and promises your IT organization will make.

To illustrate the concept I use the notion of what type of restaurant are you opening. Are you a fast food place? A 5 star restaurant?  The catalogue is the menu but it drives the kind of food and ingredients we buy, the kind of kitchen we organize, the expectations for service, how long for service to deliver, etc, etc.  You can't go to Mickey D's and ask for Filet Mignon, you can't go to the French Laundry ($$$$, 3 month wait -- if you can get me in, I'd appreciate it!) and expect food in 1 minute.

Are you this?

Or this?
 

Or this?

This is what business alignment is all about.  Who you are as an IT organization -- whether a cost watching type, or a never-fail-get=it-done-at-any-cost, or another type is it--depends on what business you are. 

So when working on the catalog (your menu, your cuisine, the reason a customer picks you tonight) think... what kind of restaurant am I working for? 

Don't forget sometimes the environment changes: what kind of restaurant is Dell right now? It used to be clear, now .... not so much.

This posting started after reading this article Computerworld > ITIL – filling the IT ‘Subway sandwich’.

It seems that more people are thinking about what kind of restaurant they are.

IT Service Catalog - Common Pitfalls

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.

IT Service Catalog - Common Pitfalls

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.

IT Service Catalog - Common Pitfalls

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.

Explain it to your mom

Mom: What do you do at work?

You:  We are creating an ITIL catalog CMDB initiative to support our enterprise business processes to  align our strategic objectives with our service delivery capability.

Mom: Oh. [silence]  Well. [uncomfortable silence].  That sounds very nice for you.  [bright idea] How many weeks of vacation do you get? 

I've always believed that if you can explain it to your mom, you can probably explain it to your boss. 

When planning to create a customer-centric Service Catalog, it's a good practice to turn for guidance to real-life catalogs that these customers use every day. And they are not using excel spreadsheets with 100 tabs, and rows. Or patiently reading long PDF's.

IT’s internal customers include the employees, business unit executives, and even other IT managers throughout the company. They are all consumers, and are quite familiar with the online sites of companies like Amazon.com, Dell, and eBay. These familiar Web sites process thousands of transactions every day; more than just a static list of available products, these catalogs are actionable and interactive. 

This is the type of actionable Service Catalog that IT’s customers expect to interact with and use from their IT organisation—providing the means with which to view available services, request services, and track the status for the IT services they require. They help you find, understand, compare, select, configure, customize, order, track status, and remain informed of what otherwise would be an incomprehensible black box.  Isn't IT a black box sometimes?

Here's a simple mnemonic that will help you convey to your mom (and boss, colleagues, and your friends)  what you are trying to achieve with a user service catalog. I have termed the IT Service Catalog user interaction model, YADU. This stands for:

1. Yahoo-like categorization and search
2. Amazon-like merchandising
3. Dell-like configuration and customization
4. UPS-like tracking.

So here's the test...

Mom: What do you do at work?
You:  We are creating a website that allows employees to find, order, customize and track all the service requests they make from us. It's just like when you go to Amazon, or use Yahoo, and then track the Christmas presents on UPS.
Mom: Oh, I see. I hope you don't lose orders like it happened last Christmas with your sister's sweaters. Those people sent the wrong size and then I couldn't find anyone to talk to me.
You: Mom, if you only knew......

Explain it to your mom

Mom: What do you do at work?

You:  We are creating an ITIL catalog CMDB initiative to support our enterprise business processes to  align our strategic objectives with our service delivery capability.

Mom: Oh. [silence]  Well. [uncomfortable silence].  That sounds very nice for you.  [bright idea] How many weeks of vacation do you get? 

I've always believed that if you can explain it to your mom, you can probably explain it to your boss. 

When planning to create a customer-centric Service Catalog, it's a good practice to turn for guidance to real-life catalogs that these customers use every day. And they are not using excel spreadsheets with 100 tabs, and rows. Or patiently reading long PDF's.

IT’s internal customers include the employees, business unit executives, and even other IT managers throughout the company. They are all consumers, and are quite familiar with the online sites of companies like Amazon.com, Dell, and eBay. These familiar Web sites process thousands of transactions every day; more than just a static list of available products, these catalogs are actionable and interactive. 

This is the type of actionable Service Catalog that IT’s customers expect to interact with and use from their IT organisation—providing the means with which to view available services, request services, and track the status for the IT services they require. They help you find, understand, compare, select, configure, customize, order, track status, and remain informed of what otherwise would be an incomprehensible black box.  Isn't IT a black box sometimes?

Here's a simple mnemonic that will help you convey to your mom (and boss, colleagues, and your friends)  what you are trying to achieve with a user service catalog. I have termed the IT Service Catalog user interaction model, YADU. This stands for:

1. Yahoo-like categorization and search
2. Amazon-like merchandising
3. Dell-like configuration and customization
4. UPS-like tracking.

So here's the test...

Mom: What do you do at work?
You:  We are creating a website that allows employees to find, order, customize and track all the service requests they make from us. It's just like when you go to Amazon, or use Yahoo, and then track the Christmas presents on UPS.
Mom: Oh, I see. I hope you don't lose orders like it happened last Christmas with your sister's sweaters. Those people sent the wrong size and then I couldn't find anyone to talk to me.
You: Mom, if you only knew......

Explain it to your mom

Mom: What do you do at work?

You:  We are creating an ITIL catalog CMDB initiative to support our enterprise business processes to  align our strategic objectives with our service delivery capability.

Mom: Oh. [silence]  Well. [uncomfortable silence].  That sounds very nice for you.  [bright idea] How many weeks of vacation do you get? 

I've always believed that if you can explain it to your mom, you can probably explain it to your boss. 

When planning to create a customer-centric Service Catalog, it's a good practice to turn for guidance to real-life catalogs that these customers use every day. And they are not using excel spreadsheets with 100 tabs, and rows. Or patiently reading long PDF's.

IT’s internal customers include the employees, business unit executives, and even other IT managers throughout the company. They are all consumers, and are quite familiar with the online sites of companies like Amazon.com, Dell, and eBay. These familiar Web sites process thousands of transactions every day; more than just a static list of available products, these catalogs are actionable and interactive. 

This is the type of actionable Service Catalog that IT’s customers expect to interact with and use from their IT organisation—providing the means with which to view available services, request services, and track the status for the IT services they require. They help you find, understand, compare, select, configure, customize, order, track status, and remain informed of what otherwise would be an incomprehensible black box.  Isn't IT a black box sometimes?

Here's a simple mnemonic that will help you convey to your mom (and boss, colleagues, and your friends)  what you are trying to achieve with a user service catalog. I have termed the IT Service Catalog user interaction model, YADU. This stands for:

1. Yahoo-like categorization and search
2. Amazon-like merchandising
3. Dell-like configuration and customization
4. UPS-like tracking.

So here's the test...

Mom: What do you do at work?
You:  We are creating a website that allows employees to find, order, customize and track all the service requests they make from us. It's just like when you go to Amazon, or use Yahoo, and then track the Christmas presents on UPS.
Mom: Oh, I see. I hope you don't lose orders like it happened last Christmas with your sister's sweaters. Those people sent the wrong size and then I couldn't find anyone to talk to me.
You: Mom, if you only knew......

A couple of nice best practices I've heard about

Just walking around our professional services people is an education.  They work with our customers day-in and day-out; they are a veritable fountain of nuggets, ideas and best practices.

I thought I'd share a couple that struck me as really clever and a couple of quotes.

 Simulation.  We simulated the new service definition by bringing in all the stakeholders into a business simulation.  We bring in all the team members -- relationship managers, service delivery managers, service designers and service delivery and we manually simulate a work order, the hand-offs, and the common breakdowns.  Everyone gets a good sense of how the catalog system will work, and their role.  We did this for the five service area before launching our actionable catalog.

Categorization.  We wanted to figure out how people thought of a service, how to name it, how to categorize it.  The customer already had a category structure in the help desk's CTI (category, type, item) for reporting.  But these were not understood by the users.   We printed out a bunch of service titles on cards, and created an initial set of categories in 3x5 cards. Then we brought some users for lunch, and asked them to sort the service titles into categories.  That helped us discover the what services needed to be in multiple categories, missing categories,  and unclear service titles. After a few lunches we had a good category structure.  These are "publishing" categories so a service can belong to multiple of them, or two differently named services lead to the same service. 

Finally, I like this quote from a customer that brings home some of the reality we all live with in IT -- which is that our customers don't know what we do or whether we do it well.

"We are a world-class organization. We've been benchmarked every year.  But we were still at risk of being outsourced.  We got tired of invisible wins and decided we need to earn the brand with our customer to get air cover for other changes.  That's why we are doing an end-user actionable service catalog." 

I love the concept of "earn the brand."  Are there examples of invisible wins in your organization? Stuff that you do really well but doesn't change the perception of users?

A couple of nice best practices I've heard about

Just walking around our professional services people is an education.  They work with our customers day-in and day-out; they are a veritable fountain of nuggets, ideas and best practices.

I thought I'd share a couple that struck me as really clever and a couple of quotes.

 Simulation.  We simulated the new service definition by bringing in all the stakeholders into a business simulation.  We bring in all the team members -- relationship managers, service delivery managers, service designers and service delivery and we manually simulate a work order, the hand-offs, and the common breakdowns.  Everyone gets a good sense of how the catalog system will work, and their role.  We did this for the five service area before launching our actionable catalog.

Categorization.  We wanted to figure out how people thought of a service, how to name it, how to categorize it.  The customer already had a category structure in the help desk's CTI (category, type, item) for reporting.  But these were not understood by the users.   We printed out a bunch of service titles on cards, and created an initial set of categories in 3x5 cards. Then we brought some users for lunch, and asked them to sort the service titles into categories.  That helped us discover the what services needed to be in multiple categories, missing categories,  and unclear service titles. After a few lunches we had a good category structure.  These are "publishing" categories so a service can belong to multiple of them, or two differently named services lead to the same service. 

Finally, I like this quote from a customer that brings home some of the reality we all live with in IT -- which is that our customers don't know what we do or whether we do it well.

"We are a world-class organization. We've been benchmarked every year.  But we were still at risk of being outsourced.  We got tired of invisible wins and decided we need to earn the brand with our customer to get air cover for other changes.  That's why we are doing an end-user actionable service catalog." 

I love the concept of "earn the brand."  Are there examples of invisible wins in your organization? Stuff that you do really well but doesn't change the perception of users?

A couple of nice best practices I've heard about

Just walking around our professional services people is an education.  They work with our customers day-in and day-out; they are a veritable fountain of nuggets, ideas and best practices.

I thought I'd share a couple that struck me as really clever and a couple of quotes.

 Simulation.  We simulated the new service definition by bringing in all the stakeholders into a business simulation.  We bring in all the team members -- relationship managers, service delivery managers, service designers and service delivery and we manually simulate a work order, the hand-offs, and the common breakdowns.  Everyone gets a good sense of how the catalog system will work, and their role.  We did this for the five service area before launching our actionable catalog.

Categorization.  We wanted to figure out how people thought of a service, how to name it, how to categorize it.  The customer already had a category structure in the help desk's CTI (category, type, item) for reporting.  But these were not understood by the users.   We printed out a bunch of service titles on cards, and created an initial set of categories in 3x5 cards. Then we brought some users for lunch, and asked them to sort the service titles into categories.  That helped us discover the what services needed to be in multiple categories, missing categories,  and unclear service titles. After a few lunches we had a good category structure.  These are "publishing" categories so a service can belong to multiple of them, or two differently named services lead to the same service. 

Finally, I like this quote from a customer that brings home some of the reality we all live with in IT -- which is that our customers don't know what we do or whether we do it well.

"We are a world-class organization. We've been benchmarked every year.  But we were still at risk of being outsourced.  We got tired of invisible wins and decided we need to earn the brand with our customer to get air cover for other changes.  That's why we are doing an end-user actionable service catalog." 

I love the concept of "earn the brand."  Are there examples of invisible wins in your organization? Stuff that you do really well but doesn't change the perception of users?

5 suggestions to get your catalog project going

Regardless of whether your IT organization’s most pressing challenge to re-establish trust with business decision-makers or with end users – starting now with the appropriate Service Catalog is the quickest way to get the relationship back on track. Like many IT projects, the factors that separate successful Service Catalog projects from the unsuccessful projects are fairly clear:

1.    Start by using established industry best practices. While every organization has some set of unique characteristics that mean a 100% cookie-cutter Service Catalog is not appropriate, there is enough commonality among IT organizations that a commercially available, best practice Service Catalog can provide an excellent starting point. Rather than building your Service Catalog from scratch, an “out-of-the-box” Service Catalog allows you to leverage the experience and hard-won lessons learned at dozens of other organizations.

    Your internal customers will recognize that the Service Catalog is “in the right ball park”, and they
can use that starting point to quickly provide feedback on the changes required. Designing a Service
Catalog starting with a clean sheet of paper – or worse yet, starting with your current processes – sends the message to your customers that the Service Catalog is just “business as usual”.

2.    Get business unit executive and end user input sponsors early in the project. Don’t let the Service Catalog project become a research project into what IT thinks its customers want. Ask your customers directly. One very successful Service Catalog project started by giving end users 3 x 5 cards of all the services IT thought it offered and asked the users to do two things with the cards. First, users were asked to sort the cards into piles of the services the users wanted, and the services they did not care about. Next, users were asked to write their own 3 x 5 cards with the services they wanted that IT had not included. The results were eye opening for the IT group and formed the basis for their service prioritization.

3.    Make sure your Service Catalog is actionable. There are many Service Catalog templates available in Excel, PowerPoint or Word documents. However, Service Catalogs developed using this method quickly end up on the shelf or on someone's hard drive unused and forgotten. The problem is that they are static documents. Until you give business unit executives or end users an actionable Service Catalog that allows them to request services or plan their IT budgets, the Service Catalog will be viewed as just another unnecessary IT initiative.

4.    Perfect is the enemy of done. A Service Catalog should be a living document that changes as your users’ needs change. Don’t spend months polishing and perfecting the Service Catalog – get it into the hands of your customers with a basic starter set of services and add from there. Services don’t need to be complex to deliver value. A recent study showed that just 20% of the IT services in a  typical Service Catalog drove 80% of the volume, and that some services (often the most complex to implement) were rarely used. If you start with the handful of fundamental services that drive the most volume and expand from there, you’ll achieve both financial benefits and increased customer satisfaction more quickly.

5.    Start today. Every day spent thinking, planning, and evaluating is another day where trust is eroding with your business customers. There are multiple paths to realizing the benefit of a Service Catalog – starting down any of the paths today is better than letting distrust prolong and fester.

5 suggestions to get your catalog project going

Regardless of whether your IT organization’s most pressing challenge to re-establish trust with business decision-makers or with end users – starting now with the appropriate Service Catalog is the quickest way to get the relationship back on track. Like many IT projects, the factors that separate successful Service Catalog projects from the unsuccessful projects are fairly clear:

1.    Start by using established industry best practices. While every organization has some set of unique characteristics that mean a 100% cookie-cutter Service Catalog is not appropriate, there is enough commonality among IT organizations that a commercially available, best practice Service Catalog can provide an excellent starting point. Rather than building your Service Catalog from scratch, an “out-of-the-box” Service Catalog allows you to leverage the experience and hard-won lessons learned at dozens of other organizations.

    Your internal customers will recognize that the Service Catalog is “in the right ball park”, and they
can use that starting point to quickly provide feedback on the changes required. Designing a Service
Catalog starting with a clean sheet of paper – or worse yet, starting with your current processes – sends the message to your customers that the Service Catalog is just “business as usual”.

2.    Get business unit executive and end user input sponsors early in the project. Don’t let the Service Catalog project become a research project into what IT thinks its customers want. Ask your customers directly. One very successful Service Catalog project started by giving end users 3 x 5 cards of all the services IT thought it offered and asked the users to do two things with the cards. First, users were asked to sort the cards into piles of the services the users wanted, and the services they did not care about. Next, users were asked to write their own 3 x 5 cards with the services they wanted that IT had not included. The results were eye opening for the IT group and formed the basis for their service prioritization.

3.    Make sure your Service Catalog is actionable. There are many Service Catalog templates available in Excel, PowerPoint or Word documents. However, Service Catalogs developed using this method quickly end up on the shelf or on someone's hard drive unused and forgotten. The problem is that they are static documents. Until you give business unit executives or end users an actionable Service Catalog that allows them to request services or plan their IT budgets, the Service Catalog will be viewed as just another unnecessary IT initiative.

4.    Perfect is the enemy of done. A Service Catalog should be a living document that changes as your users’ needs change. Don’t spend months polishing and perfecting the Service Catalog – get it into the hands of your customers with a basic starter set of services and add from there. Services don’t need to be complex to deliver value. A recent study showed that just 20% of the IT services in a  typical Service Catalog drove 80% of the volume, and that some services (often the most complex to implement) were rarely used. If you start with the handful of fundamental services that drive the most volume and expand from there, you’ll achieve both financial benefits and increased customer satisfaction more quickly.

5.    Start today. Every day spent thinking, planning, and evaluating is another day where trust is eroding with your business customers. There are multiple paths to realizing the benefit of a Service Catalog – starting down any of the paths today is better than letting distrust prolong and fester.

5 suggestions to get your catalog project going

Regardless of whether your IT organization’s most pressing challenge to re-establish trust with business decision-makers or with end users – starting now with the appropriate Service Catalog is the quickest way to get the relationship back on track. Like many IT projects, the factors that separate successful Service Catalog projects from the unsuccessful projects are fairly clear:

1.    Start by using established industry best practices. While every organization has some set of unique characteristics that mean a 100% cookie-cutter Service Catalog is not appropriate, there is enough commonality among IT organizations that a commercially available, best practice Service Catalog can provide an excellent starting point. Rather than building your Service Catalog from scratch, an “out-of-the-box” Service Catalog allows you to leverage the experience and hard-won lessons learned at dozens of other organizations.

    Your internal customers will recognize that the Service Catalog is “in the right ball park”, and they
can use that starting point to quickly provide feedback on the changes required. Designing a Service
Catalog starting with a clean sheet of paper – or worse yet, starting with your current processes – sends the message to your customers that the Service Catalog is just “business as usual”.

2.    Get business unit executive and end user input sponsors early in the project. Don’t let the Service Catalog project become a research project into what IT thinks its customers want. Ask your customers directly. One very successful Service Catalog project started by giving end users 3 x 5 cards of all the services IT thought it offered and asked the users to do two things with the cards. First, users were asked to sort the cards into piles of the services the users wanted, and the services they did not care about. Next, users were asked to write their own 3 x 5 cards with the services they wanted that IT had not included. The results were eye opening for the IT group and formed the basis for their service prioritization.

3.    Make sure your Service Catalog is actionable. There are many Service Catalog templates available in Excel, PowerPoint or Word documents. However, Service Catalogs developed using this method quickly end up on the shelf or on someone's hard drive unused and forgotten. The problem is that they are static documents. Until you give business unit executives or end users an actionable Service Catalog that allows them to request services or plan their IT budgets, the Service Catalog will be viewed as just another unnecessary IT initiative.

4.    Perfect is the enemy of done. A Service Catalog should be a living document that changes as your users’ needs change. Don’t spend months polishing and perfecting the Service Catalog – get it into the hands of your customers with a basic starter set of services and add from there. Services don’t need to be complex to deliver value. A recent study showed that just 20% of the IT services in a  typical Service Catalog drove 80% of the volume, and that some services (often the most complex to implement) were rarely used. If you start with the handful of fundamental services that drive the most volume and expand from there, you’ll achieve both financial benefits and increased customer satisfaction more quickly.

5.    Start today. Every day spent thinking, planning, and evaluating is another day where trust is eroding with your business customers. There are multiple paths to realizing the benefit of a Service Catalog – starting down any of the paths today is better than letting distrust prolong and fester.

erp4it: Food for thought: Service catalog confusion

Not atypical of the conversations we have in class.
Food for thought: Service catalog confusion.

what's missing inthe discussion?  A customer, commitments, service level options, costs or pricing.  Without those the conversation remains abstract and theological --  too much: how many angels can dance on the head of pin, and not enough: this is what we are in business to do.

Thanks Charlie

erp4it: Food for thought: Service catalog confusion

Not atypical of the conversations we have in class.
Food for thought: Service catalog confusion.

what's missing inthe discussion?  A customer, commitments, service level options, costs or pricing.  Without those the conversation remains abstract and theological --  too much: how many angels can dance on the head of pin, and not enough: this is what we are in business to do.

Thanks Charlie

erp4it: Food for thought: Service catalog confusion

Not atypical of the conversations we have in class.
Food for thought: Service catalog confusion.

what's missing inthe discussion?  A customer, commitments, service level options, costs or pricing.  Without those the conversation remains abstract and theological --  too much: how many angels can dance on the head of pin, and not enough: this is what we are in business to do.

Thanks Charlie

Service catalogs meet SOX compliance

Last month, I learned of a significant win by one of our customer's service catalog teams.  At this large company, IT service catalogs are being used to pass the SOX audit for application access.

The company uses over 50 applications to feed the ERP General Ledger.  It is not uncommon for the ERP to be fed data from many systems.  But this causes a potential compliance problem: how to prove to auditors that you are meeting segregation of duties rules?  How can prove that an employee with access to one of those systems using a particular role does not conflict with segregation of duties rules when they access another application in a different role?  This is applicable to every company that must pass SOX compliance.

Typically segregation of duties can be roughly translated to "don't let the person who inputs vendors  also cut checks because we don't want Jimmy in AP to cut checks for his brother-in-law." Or "don't let the people who work in development have access to the production database because we need to ensure the integrity of the data."   In this particular client's situation, the issue is: If I have admin rights to application #20, I should not have XYZ role in application #64 because I could then create a bogus account?

This compliance gap had to be resolved within 90 days.

The team in charge of the IT Service catalog at this retailer saw a great opportunity to extend the deployment of their catalog and create credibility for their project.   

The team created a service catalog for application access.  Every application and role is a "service" in the catalog.  Users who need access to an application can quickly find the system, the description and the applicable access policies.  The user selects the service they need, which bring a service specific form to initiate the access request.  The system automatically manages authorizations, keeps auditable records and helps the approvers look up what systems the user already has.  And for the auditors it answers the question of "who has what and are controls being followed".

Along the way, the catalog team learned users think of application access and software package to mean the same thing, which was used to improve the navigation of their catalog.

But it doesn't end there.

At another client, they took the access service catalog further. Their problem was both a how to achieve compliance and improve operational effectiveness.

Their manual administration could not keep pace with ever-increasing demand for ID provisioning.  Their user population and number of systems continue growing year over year ID. In fact, their activity records showed a continuing trend of double-digit growth each year (over 500,000 activities expected in 2005 and a doubling in 2006).  Doing it manually was cost prohibitive (They already had 20 people full time typing in access requests.  And accuracy of data could not be guaranteed to meet security and privacy policies).  The growing user dependence on systems created a need for faster turnaround to deliver these IDs.

Again, the team created a service catalog for application access.  Every application and role is a "service" in the catalog. By integrating the request process with their identity management system requests now take 3-5 seconds after approval.  Plus they cut manual entry costs for tens of thousands requests/month and passed their audit.

There are two lessons from these stories.  First, the service catalog can enable compliance in a user friendly way. Instead of pure policy enforcement, the team used the catalog approach to make getting access to the applications employees needed  faster and more convenient while increasing security and compliance.  Second, the team was pretty smart in aligning their initiative with a MUST FIX RIGHT NOW pain; it made them heroes and led people to assess the project a success.

At my next class in Las Vegas, we'll be covering a bunch of these case studies so stay tuned.

 

Service catalogs meet SOX compliance

Last month, I learned of a significant win by one of our customer's service catalog teams.  At this large company, IT service catalogs are being used to pass the SOX audit for application access.

The company uses over 50 applications to feed the ERP General Ledger.  It is not uncommon for the ERP to be fed data from many systems.  But this causes a potential compliance problem: how to prove to auditors that you are meeting segregation of duties rules?  How can prove that an employee with access to one of those systems using a particular role does not conflict with segregation of duties rules when they access another application in a different role?  This is applicable to every company that must pass SOX compliance.

Typically segregation of duties can be roughly translated to "don't let the person who inputs vendors  also cut checks because we don't want Jimmy in AP to cut checks for his brother-in-law." Or "don't let the people who work in development have access to the production database because we need to ensure the integrity of the data."   In this particular client's situation, the issue is: If I have admin rights to application #20, I should not have XYZ role in application #64 because I could then create a bogus account?

This compliance gap had to be resolved within 90 days.

The team in charge of the IT Service catalog at this retailer saw a great opportunity to extend the deployment of their catalog and create credibility for their project.   

The team created a service catalog for application access.  Every application and role is a "service" in the catalog.  Users who need access to an application can quickly find the system, the description and the applicable access policies.  The user selects the service they need, which bring a service specific form to initiate the access request.  The system automatically manages authorizations, keeps auditable records and helps the approvers look up what systems the user already has.  And for the auditors it answers the question of "who has what and are controls being followed".

Along the way, the catalog team learned users think of application access and software package to mean the same thing, which was used to improve the navigation of their catalog.

But it doesn't end there.

At another client, they took the access service catalog further. Their problem was both a how to achieve compliance and improve operational effectiveness.

Their manual administration could not keep pace with ever-increasing demand for ID provisioning.  Their user population and number of systems continue growing year over year ID. In fact, their activity records showed a continuing trend of double-digit growth each year (over 500,000 activities expected in 2005 and a doubling in 2006).  Doing it manually was cost prohibitive (They already had 20 people full time typing in access requests.  And accuracy of data could not be guaranteed to meet security and privacy policies).  The growing user dependence on systems created a need for faster turnaround to deliver these IDs.

Again, the team created a service catalog for application access.  Every application and role is a "service" in the catalog. By integrating the request process with their identity management system requests now take 3-5 seconds after approval.  Plus they cut manual entry costs for tens of thousands requests/month and passed their audit.

There are two lessons from these stories.  First, the service catalog can enable compliance in a user friendly way. Instead of pure policy enforcement, the team used the catalog approach to make getting access to the applications employees needed  faster and more convenient while increasing security and compliance.  Second, the team was pretty smart in aligning their initiative with a MUST FIX RIGHT NOW pain; it made them heroes and led people to assess the project a success.

At my next class in Las Vegas, we'll be covering a bunch of these case studies so stay tuned.

 

Service catalogs meet SOX compliance

Last month, I learned of a significant win by one of our customer's service catalog teams.  At this large company, IT service catalogs are being used to pass the SOX audit for application access.

The company uses over 50 applications to feed the ERP General Ledger.  It is not uncommon for the ERP to be fed data from many systems.  But this causes a potential compliance problem: how to prove to auditors that you are meeting segregation of duties rules?  How can prove that an employee with access to one of those systems using a particular role does not conflict with segregation of duties rules when they access another application in a different role?  This is applicable to every company that must pass SOX compliance.

Typically segregation of duties can be roughly translated to "don't let the person who inputs vendors  also cut checks because we don't want Jimmy in AP to cut checks for his brother-in-law." Or "don't let the people who work in development have access to the production database because we need to ensure the integrity of the data."   In this particular client's situation, the issue is: If I have admin rights to application #20, I should not have XYZ role in application #64 because I could then create a bogus account?

This compliance gap had to be resolved within 90 days.

The team in charge of the IT Service catalog at this retailer saw a great opportunity to extend the deployment of their catalog and create credibility for their project.   

The team created a service catalog for application access.  Every application and role is a "service" in the catalog.  Users who need access to an application can quickly find the system, the description and the applicable access policies.  The user selects the service they need, which bring a service specific form to initiate the access request.  The system automatically manages authorizations, keeps auditable records and helps the approvers look up what systems the user already has.  And for the auditors it answers the question of "who has what and are controls being followed".

Along the way, the catalog team learned users think of application access and software package to mean the same thing, which was used to improve the navigation of their catalog.

But it doesn't end there.

At another client, they took the access service catalog further. Their problem was both a how to achieve compliance and improve operational effectiveness.

Their manual administration could not keep pace with ever-increasing demand for ID provisioning.  Their user population and number of systems continue growing year over year ID. In fact, their activity records showed a continuing trend of double-digit growth each year (over 500,000 activities expected in 2005 and a doubling in 2006).  Doing it manually was cost prohibitive (They already had 20 people full time typing in access requests.  And accuracy of data could not be guaranteed to meet security and privacy policies).  The growing user dependence on systems created a need for faster turnaround to deliver these IDs.

Again, the team created a service catalog for application access.  Every application and role is a "service" in the catalog. By integrating the request process with their identity management system requests now take 3-5 seconds after approval.  Plus they cut manual entry costs for tens of thousands requests/month and passed their audit.

There are two lessons from these stories.  First, the service catalog can enable compliance in a user friendly way. Instead of pure policy enforcement, the team used the catalog approach to make getting access to the applications employees needed  faster and more convenient while increasing security and compliance.  Second, the team was pretty smart in aligning their initiative with a MUST FIX RIGHT NOW pain; it made them heroes and led people to assess the project a success.

At my next class in Las Vegas, we'll be covering a bunch of these case studies so stay tuned.