The understated elegance of IT service scope

It is very unfair to compare IT with other industries out there. IT deals with IT things, as opposed to every one else. But I can’t help in looking at other industries, like the food industry, and feeling a little bit of envy as to the way they execute and deliver on their services, if you’d call them that. Stranger, still, is that when you think about it there isn’t the equivalent to an ITIL, a CoBIT, an IT4IT or anything over there (AFAIK. If there is, I will be glad to be corrected).

Let’s pick burgers. Easy, right? Think about your favorite burger place out there. The service they provide is quite simple: a hamburger patty on a bun, plus anything else that you want on it. The process of making a burger, really, is the same wherever you look:

1.  Procure hamburger patty

2.  Cook hamburger patty

3.  Serve hamburger patty with extras

4.  Enjoy!

That’s it, really. Heck, you can do this at home with your own grill. What makes you go to restaurant A over restaurant B? If you think about it, many things come into play:

• Quality of the ingredients (questionable, but OK)
• Speed
• Experience
• Price

And so on. Where do these things come from? If we were to translate this to ITSM terms, those would be Service Strategy and Service Design. They know who you are, they know what you want and they’ve designed their products to fit into your lifestyle. Want it fast? Mickey D’s. Want it great? Five Guys. Want it gourmet? Many other places. But this post is not about strategy and design. It is about scope.

The elegance of many of these places is that, based on their strategy (how they want to sell a burger to you) and their design (Mickey D’s approach (burgers, breakfast and tacos) vs. Five Guys (Burgers. Really good burgers) there is a simple thing called scope. For whatever it is they thought of offering you, the scope is limited to that. And that is something that IT sometimes misses.

You see, understanding the scope of your services is essential when you’re going through strategy and design. You want to offer burgers plus tacos, pancakes, fish and chicken sandwiches? That’s great. That’s your design and your scope. Want to focus on just great burgers and maybe a couple of extras? Also great. That’s your scope.

Scope means that at every restaurant that you have you will only offer those things that you strategized and designed for. If someone were to walk up to your place and ask, say, for a pizza you would have to tell him at that time that you don’t do pizza. If they were to go up and ask for a Bison burger, or a Kobe beef burger, and it is not on your current offerings, you could tell them no at that time, but maybe in the near future if the demand of said request is OK.

Let’s take this a level down. Once you’ve defined scope, you can tell each and every one of your restaurant what to have and how everything relates to everything else. You’re not going to go buy pizza dough for your restaurants, and if one actually goes out and buys dough without your authorization you can actually make the case to ask “why” many, many times since you’re not on the business of making pizza…unless you specifically change your services to accommodate pizza as a service.

Where am I going with this? Something really simple: these types of restaurants know, and understand, what their Vital Business Function (VBF) is. They sell burgers. Some sell burgers plus a little bit extra on the side (e.g., chicken sandwiches). But at the end of the day, their core business is selling burgers.  

In IT, we support tasty outcomes…

Here’s the connection with IT. It is very, very easy to go offer things in IT without defining what our true scope is. And this is because many organizations out there do not understand their VBFs relative to the business function they are supporting. It is also very easy to procure technology solutions that may appear to solve an issue from the outside,  but since it is being pursued in isolation it adds no value to the organization.

So where do I got the idea that clearly defining a service scope is great? Couple of years ago I was part of a program where I was the ITIL subject matter expert in support of the maintenance of an ISO/IEC 20000 certification. I was familiar with ISO/IEC 20000 before getting there, and have held Foundations level certification for quite some time before, but actually seeing it in action was an eye-opening experience.

Now, let’s be clear. The actual pursuit of ISO/IEC 20000 certification is not for every organization. It requires resources, commitment, time and money, and it is definitely worth pursuing if your organization is looking to stand a head above competitors in your environment. 

Setting the stage on scope…

Here’s where things get interesting: setting the scope for and organization’s ISO/IEC 20000 service management system (SMS) and certification is, by itself, an exercise in deeply understanding your customer and which VBFs you support by providing services to them.  For clarification purposes, here’s how ISO defines the standard:

“ISO/IEC 20000-1:2011 is a service management system (SMS) standard. It specifies requirements for the service provider to plan, establish, implement, operate, monitor, review, maintain and improve an SMS. The requirements include the design, transition, delivery and improvement of services to fulfil agreed service requirements.”

The establishment of a SMS based on ISO/IEC 20000 requires you to follow all of the requirements set out in the standard document. There is no ambiguity there; if it says that you have to have that!

I won’t bore you with the details as to how to actually get an organization certified; that’s a very lengthy conversation! But the point I want to make regarding the elegance of scope is this: having a well defined scope actually can help your organization. Here’s how:

Choosin’ what you cook…

Want to see how some service providers out there are setting their scope to meet the requirements of the ISO/IEC 20000 standard? Spend some time browsing some of the scope statements (bonus points if you notice how many organizations in the U.S. are certified in ISO/IEC 20000. You’ll be surprised!)

If you go through some of them, you will note that some are very narrow, while others are a bit more broad. However, all of them are very specific. And here’s where doing this sets these organization appart: everything they’re doing relative to Service Management is applicable to the scope. If it’s not in scope, it’s not applicable! Look at this example (modified, of course).

The IT Service Management System of that supports provision of IT services in accordance with the Service Catalog to internal customers from .

That’s it. They’re serving the VBFs of their customers with the services listed in the catalog to that location only. That means that the activities and processes they’re executing are just applicable to that scope. Can you imagine how big, for example, their CMDB is? I will bet you that not that big! I can also bet you that the Service Catalog is very narrow. They’ve chosen to be narrow and deliver their services according to the defined scope. Just the same way someone chooses to sell hamburgers over pizza.

…and stickin’ to it!

So you’re thinking about the scope of services for your IT organization. Maybe you do not know what it is, your customers are confused as to what they can expect from you and/or you’re managing so many servers, applications and devices that you don’t really know what you’re managing. Here’s a few tips to get you started on setting a good, crisp service scope:

• Understand your customer’s VBFs: this sounds hard, but it’s not quite. You have to engage them, talk to them and understand what is it they do. Another way of thinking about it would be thinking what activity your customers, and your company, does that, if it were to fail, would cause the company to lose business or reputation? There may be multiple activities, but I’m sure you can single between ten or fifteen discreet activities (may be less) that you support. By the way, don’t think that since you have a Service Catalog you can determine that from there. You have to go ask!
• Once you’ve identified VBFs, start understanding how your organization Service Management Systems support it. Those processes, objects and tools should be good at supporting whatever it is that falls under the scope. Everything else has to be recognized as a manageable risk, a contract, an OLA and so on
• You may note that the output of some activities you were performing earlier seem wasteful in hindsight. This is a good thing! Wouldn’t you like to have a CMDB that is actually manageable? Availability and Capacity plans that are laser focused on activities that matter?
• Lastly, realize that at the end this way of thinking is different. People may resist thinking this way. Some will try to protect their silos, others will think that everything matters. Nothing can be further from the truth. Having a well defined scope of services provides focus to your organization. It allows the organization also will be more open and more able to identify improvement opportunities, since it is managing a narrow set of things as opposed to everything

So there you have it. We went from hamburgers to IT service scope, but I wanted to illustrate a good point here: your IT organization does not need to over extend itself managing everything under the sun, just like some food establishments do not sell everything under the sun. They could, and so could you, but your organization can be more effective when identifying and narrowing your scope of services to make it more flexible and manageable. Think about it the next time you get remember how hard it is to manage your CMDB, or when you go get a burger! ¡Buen provecho!