PM Articles > Alan S. Koch > ITIL in an IT Services Company

ITIL in an IT Services Company

by Alan S. Koch, PMP

A while ago, Cinda Voegtli, CEO of Project Connections engaged me in a conversation about why she as a business owner should care about ITIL. That back-and-forth turned into an article that ended with an open invitation to answer your questions about ITIL. Reader "RRP" took us up on that offer, and my e-mail back-and-forth with him proved to be interesting in addition to being a lot of fun! What follows is an edited transcript of our exchange. Our conversation may help you figure out how to start a productive dialog with your customers in environments where IT is perceived as a utility, and IT service conversations as background noise.

What's the Point of Having a Framework?

RRP: The other day I was having a discussion with my elder brother, who is not in IT but is somewhat informed about the industry. I was telling him about my work training and promoting ITIL, which guides IT organizations/service providers in delivering quality services, aligning with the business needs, and enhancing their Service Management capabilities. My brother questioned if that applies to only IT service or to any service.

I was not sure how to answer, but I said: Because IT is not especially mature or standardized, the industry has been struggling to manage the services being delivered and supported. ITSM [Ed. Note: IT Service Management] best practices were learned from other service industries such as hotels and airlines, and applied to IT. Maybe these best practices can be used by other industries, but there is another name for that: BSM (Business Service Management).

Alan S Koch (ASK): Your answer was right on the money. ITIL is based on timeless principles of Customer Service that have been the basis of much good work over the decades (centuries?) ITIL takes those timeless principles and wraps them in practices that are very IT-specific.

One of my clients is the IT director of a hospital services company. She correctly saw that much of ITIL could be used to improve the hospital services their company provides. But that would require distilling the customer service principles out of ITIL and wrapping them in hospital-specific practices. (That turned out to be more work than the CEO was willing to expend.)

RRP: I was trying to explain to my brother that the ITIL framework fulfills several needs: It helps the service provider understand what services he is providing from both the perspectives of customer and Service Provider; it supports customer outcomes; it helps the provider understand that their services do facilitate the business value which is as defined/measured, and also bears on the specific risks and costs involved.

My brother said, it looks like more "management crap" like Six Sigma, which needs management support, lots of money, people's acceptance (which can drive attrition), and in the end it still does not succeed.

ASK: Your brother is not alone in his jaded view, and this view is based on the reality that many companies have indeed wasted too much money on these sorts of frameworks. Six Sigma, ISO 9000, PMBOK, CMMI ... and now ITIL.

The key difference between companies who have gotten real benefit out of these frameworks and those that simply wasted money boils down to their approach. The money-wasters try to "implement" the framework. They read the book, take the training, and then simply do what it says. The companies that benefit use the framework as a reference, and ask themselves how they can make their companies run better by exploiting the practices in the framework.

My favorite approach to keep clients from the money-waster mindset is to use more than one framework at the same time. With my current client, I am referencing ITIL, CMMI-SVC, and the PMBOK® Guide. So when someone wants to do something "the ITIL way," I can say, "But CMMI says this ... Let's look at which fits us better."

Defining Services and Building Relationships

RRP: I told my brother there are more than 10,000 organizations ranging from IT and non-IT organizations such as Disney, who have implemented these practices and reaped benefits. He asked how my training is going to help the individual employees who are not even aware what the contract/project agreement says; they don't have access to SLA document/Catalogue etc.

This is where I was dumbstruck.

ASK: Tell me about the project you're currently doing.

RRP: It's a Production support project, and it's divided in to IT (Application Development and Testing), and IS (Apps support, Change, Release, Service Desk, Incident Management, Enterprise Windows/Unix/DBA). No one understands the services we are supporting, as we are speaking in technology lingo: DNS service, Windows service/Unix servers, applications, etc. That's the structure of the teams.

ASK: What products and services does your company provide to your company's customers?

RRP: Our company provides a wide range of information technology-related products and services including application development; business process outsourcing; capacity planning; consulting; enterprise software; hardware sizing; payment processing; software management; and technology education services.

ASK: Who (generally) are your company's customers, and how do they use the products and services that your company provides to them?

RRP: Our company's customers include industry types ranging from healthcare to banking to telecom. The customer I'm supporting is in a NA Telecom company.

ASK: How does the work you are doing on your projects relate to the products and services that your company provides to your company's customers?

RRP: I work in the release and deployment process for a production support project, managing day-to-day release activities and change requests. It's a Time & Materials project, so I'm not really sure what is in the Master Service Agreement, but this project is not based on an SLA so there's no way to see the services our day-to-day tasks are helping. Our project is structured with all the technical management, application operations, service desk, Incident Management functions and processes.

So how can I talk about ITIL here? Service Agreements/contracts, Service Catalogue, SLA documents, etc. are not visible to us as the support/development/process managers. I doubt even our Service Delivery Manager has access to it. I'm not able to connect to what we are doing in day-to-day operations, and how ITIL will help.

ASK: ITIL makes a big point out of saying that most of our Customers use the IT Services that we provide to them as a means to provide their services to others. (e.g. The finance department uses IT Services to provide financial services to someone else.)

Your company is an IT Service provider. What can be confusing is that your customers are also IT Service providers (the IT departments of banks, Telecoms, etc.). The SLAs, Catalogs, etc., that you do not see are between your customers and their customers. What I hope you do have are SLAs, Catalogs, etc. between your company and your customers (the IT departments).

Your lack of visibility into your customers' commitments to their customers is a common problem for IT Service providers. Your services are being treated as utilities by your customers: "Just give me what I ask for and leave what I do with it to me." To act as ITIL expects us to, we must have a closer relationship with our customers and better visibility into how our services enable their services.

ITIL's Customer Relationship Management process (newly formalized with the 2011 update) is designed to build just that kind of relationship. As with any relationship, you will not be able to build it overnight. But the more effort we put into it, and as our customers (the IT departments) see that they benefit when we get insight into what they do with our services, the more open that relationship will become. At least, that is what we hope! (By the way, the Service Delivery Manager you mentioned in your initial message may be what ITIL calls the Business Relationship Manager.)

Just Give Me SMTP and Nobody Gets Hurt

RRP: In an ITIL training session one of the participants asked, Our company has only incident and problem management to deliver, so will these be services in real sense? If so, how will we catalogue only these services? (IT service Catalogue process)

ASK: Incident and Problem management are not really services; they are processes you use to support the services you provide. An Incident is defined as an interruption or degradation of a service. Give me an example of what has been interrupted or degraded when you are doing Incident Management.

RRP: Email is one of the services we provide incident management support for. The other day there was an outage of several hours, almost a day, and Microsoft's SMEs were on the call to resolve the issue.

ASK: When you look at it as I described above, you see that e-mail is one of the many services that you provide to your customers (the IT departments). You listed several other services in response to my first question (above): "application development; business process outsourcing; capacity planning; consulting; …". When you are doing Incident Management, you are supporting those services.

RRP: One last question: How do organizations manage their service delivery without using or being aware of ITIL?

ASK: ITIL is a collection of "best practices" in IT Service Management. Where did these "best practices" come from? The library that was ITIL v1 (though it wasn't called that) was compiled in the 1980s. But the IT industry (it was called "Data Processing" then) started 30 years earlier. Organizations just figured out how to do things, and some organizations figured out how to do some things really well.

The same is true today. Innovative people can figure this stuff out for themselves. But why waste the time and effort re-inventing the great practices that have already been collected into ITIL?

Got an ITIL Question? Let's talk about it! E-mail me at

Not all comments are posted. Posted comments are subject to editing for clarity and length.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.