How to scope your IT service initiative. Do you need a Portfolio,catalog or requests?

To be able to discuss IT service and potential scope, ambition and effect of IT services we need to establish a few terms. I will use three different terms that is very related to each other.

Service Portfolio: The content of a Service Portfolio describes what capabilities and business processes that a customer have, value and prioritize as of today and the future. This is the basis (customer requirements) that IT need to support and develop with matching IT services. The IT services is completely driven by customer needs. The Service Portfolio can be documented in any already existing or arbitrary format.

Service Catalog: The content of a Service Catalog describes all the IT services that is available for the customer at the moment. Any IT service description clearly states the service content, commitment, limitations etc. The content must reflect the available IT services for a customer and is favorable described as a sales brochure in either electronic- or paper- form.

Request Catalog: The content of a Request Catalog describes all the ways a user can interact with available IT services. It is how a user requests ability to consume an IT service. To add, change, move or delete ability to consume it. The content is completely an effect of IT's ability to bundle requests. The Request Catalog is usually available for users as a web based request portal.  

Now when we have three terms defined on a basic level we can continue with a few examples that is categorized on focus, based on these terms. A desirable effect is related to what part is in focus and the basic conditions to achieve them. This is just a few examples to show how one can categorize desirable effects to enable a strategy and plan that is not to fragmented.

Depending on ambition, and effects you pursue, you can use this way of sorting to scope and focus your initiative to increase probability of a good outcome. Do not try to do more than you can handle. There is a very important relation between the three different terms. A Request Catalog get higher quality if the content is a result of a working Service Catalog where the requests are defined based on how a user is supposed to interact with the available IT services. A Service Catalog in its turn get higher quality if the content is a result of a working Service Portfolio where the Service Catalog content is based on business outcomes prioritized by the customer as important and the IT services necessary to manage the business. The Service Portfolio verifies that the development of the IT services is based completely by the customers needs and future challenges. 

I don't have IT services so what should i do with my Request Catalog?

First a short view back in time.

A few years back Gartner said that until 2013, 80% of IT organizations will have developed a IT Service Catalog prior to their IT Service Portfolio. Now it is 2013 and i don't know whether it is 80% that have actually developed an IT service Catalog. Regardless, I would still assume that out of the ones that have, a majority probably didn't do service catalog at all. What they did was a request catalog for their users to order things from IT. They probably did it without establishing a IT Service Portfolio or service catalog. Considering that the IT Service Portfolio should be the foundation for the IT Service Catalog, which in turn is the basis for a request catalog. what are all these Request Catalogs based on? In this article i use the term Request Catalog for the actual request interface that a consumer (requestor) uses to trigger/do a request.

So how do one develop a Request Catalog without the necessary foundation? My experience, when looking around, is that it has been common to confuse the Request Catalog with a normal Web Shop and therefore the concept of a Web Shop has been the template and guide. A lot of things are actually similar, even close to identical. This is one of the reasons that i think this confusion occurs in the first place. There are fundamental differences, but if you are not looking, they can be hard to identify. If my observations are true, it means that there are a lot of Request Catalogs out there which are designed to work as a Web shop.

Who cares? It is working fine.

Even if the Request Catalog is designed as a Web Shop, the IT organization would probably claim that it has helped them. That it might have improved request handling etc. I can not argue with that. I would even assume that they are right. Its not hard to figure out that everything that used to be ordered manually from a Service Desk in an unstructured way, now is easier to handle from a Request Catalog in a structured way. Win win, or? I'm sorry to say but the whole idea with a Request Catalog is to help the Customer. Did the Customer benefit from the Request Catalog? Well if it is designed as a Web shop, thats exactly what the Customer got. A web page where they can search and order the stuff the IT department think is important to order this way. And the stuff, is probably very similar to what was ordered manually by the Customer from the Service Desk before. All in all, the Customer didn't benefit that much at all. Quicker delivery maybe, better follow-up and some statistics. Nothing to brag about so you should care. This was not it's purpose and the customer benefits and experience should be much better.

Reality check!

So even if we admit that the Request Catalog should have been preceded by a IT service catalog and an IT Service Portfolio we can not change the fact that this, most likely, is not the case. So what do we do? If i would give the suggestion now to start a IT Service Portfolio initiative you would probably quit reading about here :) so i will not, but if you can, I suggest you do. But without it, how do we continue? Lets face it, no IT Service Portfolio is a weak start for a IT Service Catalog or a request catalog.

Can we turn this thing around?

Sure, of course, easy? maybe not. There are a couple of small things that can be done to gain short term benefits. And this time I'm talking about the benefits the Customer would experience. This will rub off on IT as well but that is a side affect, not the purpose. What we get from changing the focus a bit is a Request Catalog that is easier to manage and easier for the Customer to use.

What should we do then?

I will go deeper into each bullet but here are som principles.

1. Stop treating The Request Catalog as a Web Shop

2. Think Customer Scenario

3. Standardize and reuse everything

1. Stop treating The Request Catalog as a Web Shop.

So what are the fundamental differences between a Request Catalog and a Web Shop? As i mentioned earlier they can be hard to identify but that is not due to complexity, it is more due to that they are small and seems so obvious that we don't manage them properly. 

In a Web Shop you enter everything you got. If what you sell is not available in the Web Shop, you can not sell it. You try to create interesting and dynamic content that is frequently renewed/replaced and to top it off you offer a shopping cart and promise a good shopping experience. Everything a Web Shop should be. Throw in a couple of weekly offers and "right now" bargains you are on the right track for a good Web Shop. 

Is this applicable for a Request Catalog? Let break it down.

- Everything you got 

- Dynamic that is frequently renewed/replaced

- shopping cart

From the list above there is only one thing that I think is applicable for a Request Catalog. That is good shopping experience. Why? Well briefly explore each one. 

"Every thing you got" is a very poor strategy. The content in the Request Catalog should not be what IT "got"or want to offer, it should be what the Customer needs. That means that even if we have 5 different laptops models available, we should NOT put 5 different laptops models to choose from in the Request Catalog. 

"Dynamic that is frequently renewed/replaced" is lack of standardization. In a Request Catalog we want the opposite. The On-bonding service that the Customer finally learned to find and order should be consistent over time. It should be called the same thing, found the same way and in the same place. Actually, the more boring it is, the better experience for the Customer from recognition and repeatability perspective. 

The "Shopping Cart" is an old dinosaur. It is basically always there but the more it is used, the more it confirms that we do not help the Customer in the right way. We should offer more "single click" and "bundled service" that is fit for purpose. The cart is basic functionality in a Request Catalog and your design should consider it as a last resort option for the Customer, not the normal way.

2. Think Customer Scenario

To design content for an Request Catalog requires some thought. We had the example earlier of the 5 different laptop models. I know a laptop may not represent the best of "Services" but the example works anyway and the principles are the same in other context as well. The scenario is that a customer wants "a laptop", not "that laptop". So why would we offer 5 different laptops models and force the customer to chose one? We cannot assume that the Customer can chose the most appropriate one based on models. What we should offer is "a laptop" with relevant descriptions, maybe a few flavors like "light sales laptop" or "big screed laptop" or "powerful designer laptop" etc. Now you might say that -"Hey, then we will end up with 5 different laptops anyway! we did not earn anything with this design". And part of it is true. The number of options for the Customer might not decrease. But there is important differences. 

One difference is that the items reflect the Customer needs (scenario). If I'm ordering a laptop for a sales person it is much easier to understand and chose the correct one if it is called "light sales laptop" compared to a Supplier named Hardware model. 

Another reason is that the "light sales laptop" will be in the Request Catalog all the time even when the IT department changes the laptop model for another/newer one. The Customer will order the same thing year after year but the model and equipment that is delivered changes according IT cycles. Of course we can link information about the actual model that will be delivered when ordered, there is nothing wrong with that.

3. Standardize and reuse everything

To design the content this way means that we need to keep the focus on the customer and try to standardize based on customer scenario. It should be standardized with Customer focus. What does the Customer need included when requesting lets say staff On-boarding. We decide to include a laptop in the On-boarding service. Whenever someone orders the On-boarding service we will include the delivery of a laptop. Seems reasonable. When doing this we want to minimize the administration of this request. The laptop models we already have ("light sales laptop" or "big screed laptop" or "powerful designer laptop|) we want to reuse fully. If we standardize them correctly and want to "bundle" them into the On-boarding service we can reuse them exactly like they are. Once the On-boarding is triggered and the appropriate laptop is chosen by the Customer (could even be automatically selected if on-boarding is triggered on role) Every thing should be inherited and reused. Due to that the laptop does not change over time, there is no affect on the other services and recognition and repeatability from a Customer perspective is very high. The IT organization get a common way to deliver a laptop and can constantly improve the way this is actually performed even if it is requested separately or included in a bundle. 

What is the gain of all this.

If you apply the above, you will still not have a request catalog content based on a IT Service Catalog. But what you will get is a Request Catalog with a customer focus. The more you are able to standardize and reuse, the more "rub of" the IT organization will get. The more recognition and repeatability the Customer get, the better the shopping experience will be. If the Customer have requested a service before, they want it to be easy enough so they can do it again, with a blindfold. If the content is called something today it should be called the same tomorrow. We do not want changes made to content that forces the customer to search or read through the content again. Keep the changes of the "front" to an absolute minimum in a request catalog. Content that is added, phased out and replaced will of course occur. A few years ago there where no tablets, now there are. Now they are called iPad, Xoom, Tab, Nook, Nexus etc. Who knows what they will be called in the future? If we would design the content based on supplier models we would have a continuous need to change it as soon as we provide a newer or different brand or model. If we would design standardized content with customer focus we would probably have tablet names corresponding to the use it was targeted for. The need to change them would be very limited, even with linked information about the current model that is delivered.

Am i in the green zone now?

This does not in any way change the need for a IT Service Portfolio and a service catalog. What it does is that it gives you a working Request Catalog instead of a miss aimed Web Shop.

Create an IT-service in 90 minutes

The task of creating IT-services could be daunting and it seems as many companies and IT departments are struggling with it. I like to simplify things to the point it gets ridiculous and start from there. If this mindset is applied to service and service modeling a couple of questions come in my mind. I think they are fundamental when defineing a Service in its simplest form. One important thing with these questions is that the answers can not be IT guessing. The answers must come from the IT consumer. No interpretation is allowed and I will get back to why I think so.

- WHAT is the consumer doing (in its context and with what applications)?

- WHY is the consumer doing it (what is the end result of the task)?

- What would happen if the consumer COULDN'T do the task at that moment (is it critical or could it be done later or in batch)?

So the header said "in 90 minutes" and that would imply that there is a recipe for achieving an IT-service in 90 minutes. Could it be done? well as I said, I like to simplify things so if you only allow 90 minutes to achieve this that is what you will get. On the other hand if you allow 4 weeks for it I am not so convinced that your result will be a hundred times better so keep it ridiculously short. 

What you will get is a clear understanding of what Infrastructure components are in direct relation to what the business actually do and what the effect is when they are not available. As I see it, an IT-service in its simplest form enabling IT to communicate with the business about services they can identify with and the ability to understand how it is delivered and what IT is contributing to.

Plan the 90 minutes in 2 steps. The first step is to schedule a meeting with a IT consumer that works in the area where you want to start your service modeling. The second step is to schedule a meeting with the technical responsible, probably more than one, of the applications that the consumer is mentioning during the first meeting.

Step one, meeting 30 minutes with the business. The person or persons that are invited should be very familiar with the business process and it is important that they are executing a part of their process. Try to identify a critical step in their process and ask them the three questions. you could end it right here with the answers or continue to ask them the three questions for each step of the business process that they can cover. Keep it simple and scoped instead of trying to cover too much.

Answers from first question: The answers of the first question is what I like to call service functions. Each consumer step is a potential service function. Sometimes multiple answers might be good to add to the same service function depending on the answer related to the depth in the business process. The key here is that the consumer can fully identify herself with the name and description of all the service functions. This still has nothing to do with IT so do not change it in any way to correspond more or less to IT terms, even if the consumer uses a "system" name in it, do not change it. Additionally, every time the consumer mentions a system or application, take a note of it. This will be the base for your second meeting. From a IT perspective the naming of the service functions are completely irrelevant. It could be called anything as long as the business and consumer understands what It is when using it during a follow-up or saying that it is not available for any reason.

Answers from second question: The answer of the second question is used to name the service. The logic here is that all answers from question one that is related to the same answer from question two is same as multiple service functions related to a service. If you merge two services to one then you have to relate all service functions to the new service as well. Important here to keep the business language and the correlation to the business result.

Answers from third question: The answer from the third question is the criticality of each service function. Yes that is correct, the criticality in this case is specified on service function and not the Service. This way they can easily be aggregated to the service when needed. Make it easy and classify the service requests as critical or not. The point here is that critical is a process stop for the business. A service function or business step that can be performed at another point in time is not critical.

Summary of step one, first meeting. Visually now we should have something like this.

We have one (or multiple if you had the time for it) service and at least one service function, hopefully more, related to each service. The service should have a name that completely corresponds to a result that the business is dependent on and should be identifiable by anybody relevant in the businnes. The description of the service must cover all the service functions that are related to the service but no more. The service functions are the content of the service so the service does not enable more than specified through the service requests.

Step two, meeting 60 minutes with the technical responsible (systems and applications mentioned during meeting one). The persons that are invited should be technically responsible or technically involved to the degree that they are able to answer on the technical impact of a service function in their respectively systems. The questions for each service function to the system representatives are:

- Specify any infrastructural equipment related to perform a specific service function. If you need to keep this easy, concentrate on applications installed on servers and the server itself.
- Is the infrastructure equipment critical to perform the service function or not. Can the consumer carry out the service function when the infrastructural component is not available (it might have redundancy or a queuing functionality that does not require full availability) or not.

Summary of step two, second meeting. Now we should have something like this.

Each service function has critical or non critical infrastructure components related. The infrastructure criticality only shows if the equipment is critical for the service function to work. It does not say if the service function is critical to the business. The relationship from the service function to the service tells if the service function is critical to the business. 

If you would use this visual structure when ever planing a change or managing an incident it is really powerful in impact analysis. It tells us clearly what service function a infrastructure component will affect and the meaning of it for the business/consumer. The same goes when a new demand of functionality is requested. It is easy to define if it is an add to an existing service function or a additional service function that needs to be defined and if the existing infrastructures is reusable or need additions as well.

After this first simplified step it is just the rest left :)

Service request vs Service offering

I realize that its not always clear what we mean when talking about service in the context of a service catalog. Usually we talk about a service and the service catalog in the same sentence but we need to be specific about what it means.

A service in this context consists of two things. The service offering and the service request. The service Offering describes what is included in the service. What parts of the service is optional vs mandatory and the cost associated with the consumption of the service or any parts of it. All available services should be found in the IT Service Catalog. This service is often what is used for follow-up with the customer.
The service request is how you trigger a Move, add, change or delete (MACD) request and there are usually multiple different requests depending on what you want to do and they all are connected to the same service. The service request can be requested by the customer on behalf of a consumer or the consumer can initiate it to be approved by the customer if applicable. the consumer is the one that will use the service or parts of it. The service requests should be found in the IT Service Request Catalog.

A customer understands the warranty (when available) and usability (what functionality) of a service that could be available for a consumer by reading the service offering in the Service Catalog. the consumer initiates a service request which states what and how the service is to be consumed, and if required, the customer approves or denies this service request in the Request Catalog.  

In the service catalog you should find the service offering and the service requests you should find in the Request Catalog. Optimal is if there is a relation inbetween them to clearly show what requests are related to what services. The service offering is the description of the service and the service requests are the way you can interact with the service by MACD consumers, capability, functionality etc.