I’ve heard a lot of negative talk about ITIL over the years. Some say they tried it, it doesn’t work and it should die. Some say they tried to implement it, it didn’t work, and it should die. And some just say it should die.I’ve heard every variation of this and can say without hesitation or reservation that it is a load of hooey. Granted, I am a bit biased, being someone who specializes in IT Service Management, but I can make a pretty compelling case as to why the negativity toward ITIL is built on misconceptions and myths; and I know a thing or two about myths.
It's too hard to implement.
Let’s start here, because this is really where the misconceptions begin. Some organizations start with the wrong initiatives. Others fail to put enough effort into the implementation, but the main reason why most implementations fail comes down to organizations getting so excited about ITIL that they try to do everything all at once, which never, ever works. If it did, you wouldn’t have to separate colors when doing your laundry. But if you take time to scope out your ITIL implementation, and what you want to achieve, you set a foundation for success. And since I’ve set a foundation for success by dispelling that myth, let’s tackle another myth, shall we?
It's too academic.
ITIL implementation tends to be jargon heavy, which makes it intimidating for some people. I mean, if a doctor told you that you have a helomadurum, you’d probably worry about that until she clarified it’s a corn on your foot. See what I mean? But there is also a tendency to think an ITIL implementation must be done by the book, which means turning off your critical thinking like you would when watching one of the 47 Fast and Furious movies.
Sure, at times ITIL can seem like taking a college course without the fun shenanigans of actually being in college, but it really doesn’t have to be. For one, you can do an ITIL implementation using the terminology, or language, that your organization understands. For another, your implementation should always come back to what works for your organization, not what the book says. In other words, do what makes sense for you and your team. By keeping it simple, you keep everyone engaged, and no one cries. Because, believe me, you do not want to be known as the person th
It's too bureaucratic.
This is probably the myth I hear most—that there is just too much to do, and you cannot possibly do it all or it will bring IT to a screeching halt. This is partly due to the ITIL books—which are as epic (though not as fun) as The Lord of the Rings—but organizations also have a tendency to try to implement all of the ITIL processes, as if they were trying to break the record for how many hot wings they can stuff down in an eating contest. And we all know how that tends to go.
A better approach is to think about ITIL as a prescription: what is the major pain point in your organization that ITIL can address and what are the shortest jobs that will deliver the biggest wins? Maybe it’s improving your Change Management process. Maybe it’s putting SLAs in place. Whichever you end up choosing, it is a much better approach than trying to do everything all at once and failing.
It's too expensive.
There is a common misconception that you have to train everyone in your organization to the same level of ITIL savvy, or that you need to rush out and invest in all the IT Service Management tools you can find. If you do that, then, yes, an ITIL implementation can be pricey. But you really don’t have to give everyone the exact same training, unless you really want to send management off to a three-day ITIL Foundation class (or they really want to go). As for tools, instead of looking for ones with bells and whistles you can brag about and never, ever use (but end up paying for anyway), look for ones that enhance your processes. There are many lightweight, affordable options for automating processes (here’s one we like and implement often). Some are easier to implement than others, which means you’ll see more value much sooner. You can use the money you save as a result to buy me a thank you gift (hint: you can never go wrong with a good scotch).
It requires too many resources.
Nice try. This is just another way of saying it's too bureaucratic and expensive. Remember, find your pain point and address it with a short project that delivers major value and you won’t have to double your staff or find a way to expand the number of hours in a given day (though if you do manage to expand time, call me).
It doesn't work in an Agile environment.If anything, ITIL is the Mario to Agile’s Luigi. After all, ITSM is about how to better serve customers and Agile is about how to get that work done. So really, they’re made for each other.
There you have it: all the myths and misconceptions of ITIL implementation dispelled. That was easy, wasn’t it? Almost as easy as implementing ITIL. Remember, look for your major pain points and go - but if that seems difficult, maybe try Incident, Change, Problem and/or Knowledge Management for starters. These tend to be the areas where organizations interact with customers the most, and you can build your roadmap for what to tackle next from that.
Want to get started with ITIL at your organization? An Assessment is a great first step.
Here's our guide to getting your organization ready for it.