10 Tips for Getting Started with ITIL – Part 1

Some people panic when they hear the word ITIL – either because of memories of previous painful, or failed, ITIL adoption projects, or because of the fear of the unknown. People might also view ITIL as an all-or-nothing opportunity, but the reality is that it doesn’t have to be that way. Case in point: very few companies can say that they have adopted elements of all 26 ITIL processes and its four functions. And if someone says they did, you might want to check that their nose isn’t growing longer.

In fact, one of the best tips I can offer re getting started with ITIL is to realize what it is and what it is not. While it includes many best practice processes, it’s about so much more than those processes. It’s really about delivering IT as a service; and it’s not something that you can be compliant with, as it’s not a standard.

The key word with ITIL is “adopt” – as ITIL is very much about adopting, and adapting, the parts of ITIL that your organization needs. So, if you are planning on adopting ITIL – whether via a greenfield initiative or the formalization of existing ITSM capabilities – then ITIL only needs to be what you need it to be.

This two-part blog offers a total of ten tips for getting started with ITIL that will hopefully place you and your organization in good stead to reap the benefits of the ITSM best practice framework.

Tip 1: Establish a Formalized Service Desk

A key thing with ITIL is to start, where possible, with quick wins, and very often that happens when you simply improve on things that you already do. The chances are that you already have a help desk, a service desk, or at least a dedicated place where people can go to flag their technology issues to IT. Even if it isn’t available all the time, having a dedicated single point of contact will help your end users to get used to logging things in a central location rather than just wandering up to the IT area seeking their favorite technician.

Having a formal service desk in place is a solid base for managing your incidents and service requests as efficiently and effectively as possible. It offers not only swifter resolutions but the better management of expectations, the ability to prioritize and exploit knowledge management, and better insight into both operational and service performance. Plus, it’s the professional, customer face of IT.

Tip 2: Identify Root Causes

The day-to-day routine of an IT support team might feel like “saving the world, one incident at a time.” However, a number of incidents will be recurring and rather than wasting resource on fixing each and every incident again, and again, and again, ITIL suggests that problem management is used to eliminate the root cause of the incidents (and thus the recurring incidents).

So problem management is the process that investigates the root cause of incidents and identifies solutions to resolve the issues either as a workaround or as a permanent fix. When starting with problem management, look to your biggest pain points, for example major incidents and understand what caused them, find a fix (interim workarounds and/or permanent resolution), and ensure that any lessons learned are documented and acted on.

Once you’ve got a solid process in place, you can progress to more proactive problem management activities, for example trending (has this issue popped up before?) or talking to service delivery managers or support team leads about what keeps them up at night.

Tip 3: Manage Your Changes

All changes to your production environment should be under formal change management (yes, tell me about it). In the absence of having any controls in place – change is often driven by technical rather than business objectives and without taking a bigger picture view. This can lead to clashes, outages, and rework.

Poorly managed change can cause extensive downtime not to mention generate reputation, financial, and even legal repercussions. Introducing formal change management is the first step in better controlling, and protecting, your production environment – so start by making it easy for people to do the right thing. Introduce standard changes for so-called BAU (“business as usual”) tasks; if it takes seconds to raise a change then there is absolutely no excuse for not following the process. Consider bringing in a change advisory board (CAB) to discuss the high risk and/or high impact changes – they need to be sanity checked and talked through so that planned work, and its impact, can be assessed from an end-to-end service perspective rather than a specific technology view.

Tip 4: Track Software Licenses

Software asset management (SAM) isn’t considered a core ITIL process but it should be (it is in the ITIL books if you look hard enough, honest – I’ve read the chapter listing). SAM is a key capability for any organization, required to meet its legal, financial, and reputational responsibilities, that enables the business to understand what software is installed, how it’s used, and ensure that the appropriate licenses are in place for compliance.

If you’re not sure where to start, make your initial focus your biggest areas of risk – typically the Microsofts, Oracles, or Adobes of the world, and then expand the scope of your process over time. Also look to build on what you already have in place, for example:

• Do all software requests go through a single point of contact such as the IT service desk?
• Is there a request fulfilment process you can link into?
• Is the procurement process centralized?
• Does IT security have a software acceptable usage policy that you can reference?

Tip 5: Start Using a CMDB

Used wisely, the configuration management database (CMDB) is a key enabler for resolving incidents, identifying the root cause of problems, assessing the impact changes, and building the technical layer of a service catalog. 

Even if your CMDB isn’t complete, or is limited only to certain areas within your organization, you should start linking incidents to related services. And when you create a change or a problem, make sure that you link it to a service. Where your CMDB isn’t complete, add service information as you encounter incidents, problems, or changes. This will ensure that you get an accurate picture of the state of your IT estate and will allow you to better build and maintain the relationships between your IT elements and your business services and processes.

So, that’s my first five tips. Come back for part two of this blog where I’ll look at everything from knowledge management to continual service improvement (CSI) in getting started with your ITIL journey.

What are your top tips for getting started with ITIL? Please share in the comments section!