“Slow.” “Bureaucratic.” “Out-of-date.”
Just a few of the words I’ve recently heard or read used to describe ITIL®.
Could it be because no one has really implemented ITIL?
So before the world reminds me that we don’t “implement ITIL”, we implement “IT Service Management based on ITIL”, hear me out. Is ITIL really too bureaucratic and out-of-date, or is it that few have really implemented ITIL? Allow me to elaborate.
In my experience, the typical ITSM implementation based on ITIL looks something like this:
- Incident Management
- Service Desk
- Change Management (well, sort of)
Some organizations may have rolled out some kind of Problem Management process or Request Fulfillment process.
Some organizations may have implemented what they are calling a Service Catalog, although that “Service Catalog” is actually a Service Request Catalog.
Some organizations have implemented a CMDB, which is often created as an output of a discovery tool. The discovery tool does a fantastic job of discovering anything that is attached to the network and collecting all sorts of information, most of which we really don’t need (or want!) to manage within a CMDB. Perhaps rudimentary, serially-defined relationships are discovered (which is to say that whatever the discovery found next must have a relationship to what was found immediately before). The assumption is that anything that is discovered is a Configuration Item (not necessarily true).
In my experience, the focus of most ITSM implementations are on the day-to-day operational aspects of an IT organization-and not much else. Of the 26 processes defined by ITIL, most organizations attempt to implement only three to six of those processes. The processes that are implemented are primarily focused around IT operations.
If you think about it, it’s like the old “cart and horse” story, but with a twist. Many ITSM implementations worry about making sure that the cart is ready for use, but ignore the fact that a horse is also needed.
I’m not suggesting that an organization arbitrarily implement all 26 processes. However, if you’re basing your ITSM implementation on ITIL and if some thought isn’t given to the other aspects of the service lifecycle, then the implementation will eventually begin to struggle, will not evolve, and will ultimately fail to deliver on the should-have-been value of an ITSM implementation.
What I am suggesting is to follow a “adopt and adapt” approach. Adopt the concept, and adapt it to meet the unique needs of your organization. So, if we are to adopt the approach that ITIL suggests, then that means we must consider each area of the service lifecycle.
Service Strategy – What does our business need from IT in order to be successful? What services does the business need, and what is IT’s capability for delivering those services? Is anyone at the executive management level aware of and supporting our ITSM efforts? Has a plan been developed, documented, and agreed that defines the why, who, what, how, and when of the ITSM implementation? Is this plan regularly and periodically reviewed and adjusted as necessary?
Service Design—One of the most frequently encountered mistakes I see is a rush to draft Service Level Agreements (see my blog, “Do you really need a SLA?”). What I usually find are three flaws:
- Services have not been defined and agreed
- No consideration has been given to the fact that the organization has critical dependencies on external suppliers in order to deliver Services
- Metrics have not been defined that reflect business-relevant (not just IT ) measurements
Service Transition – Change Management has three purposes – ensure that the appropriate model for managing a change has been utilized, communicating changes, and scheduling changes so that they don’t collide with one another. Change Management was never intended to be a bureaucratic exercise, but because other aspects of Service Transition do not get addressed, Change Management often is burdened with additional responsibility. For example, in the absence of a formal Release Management process, Change Management often gets tagged with understanding and tracking all of the elements of a build. In the absence of formal Service Validation and Testing, Change Management gets stuck with ensuring that testing and quality assurance has been done.
Continual Service Improvement – Too often, ITSM implementations are treated as “one-and-done” endeavors. I have long said that one of the reasons why to implement ITSM is to establish an approach for continual improvement. The business that you work for today is not the same business it was five years ago, or even one year ago. We need a way to evolve alongside our business. We need a way to identify and implement the right improvements.
I will be among the first to agree ITIL is far from perfect (what is perfect?), but ITIL must be thought of as an ecosystem. Understanding how implementation decisions impact the overall viability of the ecosystem is crucial. Do you need to formally define and implement processes from each phase of the service lifecycle? Perhaps. Or perhaps not. Regardless, you should define – and document – the approach you intend to follow to adopt and adapt and how you intend to address each phase of the service lifecycle. If you do this, coupled with an approach of continual improvement, your ITSM implementation based on ITIL (or whatever methodology (or methodologies) you choose) has a greater chance for success.
Click here to subscribe to my newsletter!
 ITIL® is a Registered Trade Mark of AXELOS LimitedShare