Pitfalls to Avoid When Implementing ITIL

When implementing ITIL, you will notice that you will discover a number of things that are either not clearly explained in the ITIL books or are omitted altogether.  There can be a number of reasons why this is so. Some of these things may undermine the credibility of ITIL so they are not mentioned. Others are just not appropriate to be discussed in the official ITIL books as they are too specific.  Unfortunately, a lot of these "not discussed" aspects of ITIL are of the negative kind and can be quite damaging to your implementation. Oftentimes people only learn of these pitfalls when it is already too late. Let me share with you some of the pitfalls that I encountered so that you can avoid them when you do your own ITIL implementation.

Before we begin, if you are new to ITIL, you may want to ready my earlier article about The Relevance of ITIL Today to get you up to speed.

If you are already familiar with ITIL, please proceed.

Without further ado, the pitfalls that you should avoid when implementing ITIL include:

Not aligning with senior management

This is the single most important pitfall you should avoid. Note that I do not consider getting approval to start your ITIL implementation an "alignment with senior management". Approval is only the start of the game. You need to constantly update senior management regarding the progress of your ITIL implementation. As you start creating processes, it is critical that you keep management aware of the planned processes at least at a high level. This is to ensure that they are not surprised by what you have created at the end of the project. You do not want to be asked to redo the entire process including tools customization because one senior manager does not agree to what you created. Include milestones throughout your project schedule when you need to keep senior management informed and you have a better chance of getting your ITIL implementation right.

Not creating a team

It is almost impossible to implement ITIL alone. At the minimum, you need to assign Process Owners and Process Managers to each of the modules that you want to implement. Process Owners are senior managers who are champions of their modules and are members of the project's governance committee. Although they may not create the detailed processes, their main role is to give direction and influence other senior managers should there be issues within the process. Process Managers are the people who lead the definition and day to day operations of each process.

Most companies do not have dedicated people who work for each role. Therefore, the ITIL roles are usually mapped to the people in your existing organization. Having a team not only helps you in workload allocation, it also improves the quality of your implementation as your project benefits from the varied backgrounds of the team. Once you have a team in place, your implementation will become much smoother.

Trying to implement all processes at once

People new to ITIL are usually overwhelmed by the number of modules in ITIL.  Some believe that all of these processes need to be implemented. Although it is true that you will reap more benefits if you implement all the processes, in reality, very few companies do this because of the tremendous effort involved. Nevertheless, even if only a handful of modules are implemented, if done properly, huge advantages can already be generated.

Trying to implement all processes at once is a common pitfall early in the planning process. Fortunately, this pitfall is usually nipped in the bud as the project team start to know better and as they chat with people who have implemented ITIL.

Not studying current processes

If you do not know your current processes, how will you know that the process you are creating will work for your organization? For example, you cannot just say that you need to setup a 24x7 Helpdesk if the applications that you support are only being used during office hours.

Your current processes may seem to be inefficient, but there is always a reason why they are that way. If the reason is only because "that is how we did it in the past", then by all means change it if you can find a better way. However, you still need to study current processes in order to gain valuable insight for your future processes.

If you do not know your current processes, how will you know that the process you are creating will work for your organization?

Being too stuck up about the tool

You do not need an expensive IT Service Management tool to implement ITIL.  For very small companies with low volumes, tracking of configurations, incidents, problems and changes can be done through spreadsheets.  Only when the company grows large enough should you look into using a tool to automate certain processes. Don't let the lack of a tool stop you from implementing ITIL. Put the processes in first, then migrate to a tool later.

Of course, for larger organizations who have the volume and the budget for more complex tools, it makes sense to get the tool in from the onset. This will help them avoid data migration (if required) and will help them get the benefits of tool automation immediately.

Thinking that ITIL implementation is expensive

This is a common misconception. As mentioned above, you can implement ITIL without an expensive tool. Aside from the tool however, another expense is ITIL education. Admittedly, this can be expensive if you want to send all your staff for external training. To keep costs under control, you can send key people for external ITIL certification training and then have them share what they learned to the rest of the team.

A copy of the ITIL books is also a good investment. In practice, I notice that these books are only used as reference material so you can cut costs by buying only one set that is shared across the company.

Yes there will be expenses if you implement ITIL but they need not be exorbitant. With proper planning and a practical approach, you can implement ITIL on a manageable budget.

Too much tool customization 

This pitfall is especially true for large implementations spanning multiple countries across the globe. As each territory gives their own requirements based on local laws and practices, your go-live date gets pushed backward as the tool increases in complexity. At worst, this problem can totally derail your ITIL implementation as expenses escalate with no visible end in sight. Too avoid this, you need to make sure that you have a tight control on modifications from the start. Most ITIL tools like Remedy and ServiceNow already have pre-configured processes out of the box though I've never heard of anyone using these tools without modification. Nevertheless, if you do customization, make sure of the following:

1. Changes needed by all parties are prioritized and
2. Keep a close eye on your resources (e.g. time, budget and people)

A useful technique to use is the Agile programming methodology. Through this methodology, instead of aiming for one big go-live at the end of 2 years, you instead release working software at the end of each sprint -- which can be from 2 weeks to 1 month. The company is immediately able to use the tool and critical changes can be included in the next release instead of at the end of the project. Agile development is truly an awesome methodology. If anyone is interested, I can write more about this in a future article.

Not understanding local requirements

This pitfall is the opposite of the above pitfall. Whereas it is important to prioritize requirements that are beneficial to all parties, this does not mean that you should not listen to requirements that are sent by a single party. This is because this requirement may actually be beneficial to all but were not articulated by the other parties. Another reason why it is important to understand local requirements is when these requirements are mandated by local laws. An example is the requirement for providing Sarbanes-Oxley evidence for changes affecting significant financial applications. If a new tool will remove this capability, you need to make sure there are alternate ways to provide this requirement or your company may get in trouble with the law. If there are no alternate ways, you may need to add the requirement to your tool in order to comply with local laws.

Not creating documentation

The ITIL books are good reference materials. Unfortunately, the ITIL books cannot be used by themselves to support an ITIL implementation. There are a number of documents that you need to create for your own company. At the bare minimum, you should have the following:

1. Policy Documents - these contain definitions and guidelines that should be followed by your company. An example of a policy for the Change process is the definition of when a change is considered a Significant change.
2. Process Documents - these include process flows, high level steps and roles and responsibilities. An example process document is the process for handling emergency changes.
3. Work Instructions - these include detailed instructions for the people on the ground who are doing the actual work. These documents may include screenshots of the tool, field names and detailed entry instructions. As these documents are very specific, they are more frequently updated compared to policy and process documents.

Thinking tools can fix bad processes

The processes that you create for your organization must be robust, practical, efficient and secure. This will ensure a higher degree of success when you start mapping your process to the tool that you plan to use.

On the other hand, if your process is full of loop holes, extremely slow, inefficient and unsecure, implementing a tool will only waste your time and effort. This is because implementing an automated tool will not fix the problems that you encounter due to bad processes. It will only help you to encounter these problems much quicker.

... implementing an automated tool will not fix the problems that you encounter due to bad processes. It will only help you to encounter these problems much quicker.

Not keeping up with the ITIL versions

ITIL updates its versions at a relatively slow pace.  Thus after implementing the latest version, you don't really expect to update it the following year.  Nevertheless, it is important to keep up with any changes when they are published.  This is because the scope, roles and responsibilities, processes and other concepts are continually enhanced and changed.  If you do not update your team, you may eventually have mis-communication when you interface with companies who are using the latest version.

Note that you do not need to get your team to attend ITIL re-certification every time there is an update (though this is not a bad idea if you have the budget). However, you definitely need to make sure that they know what are the changes.

Mistaking ITIL as a complete IT framework

ITIL is a very good framework for Service Management. Having said that, it is important to understand that ITIL does not cover everything. Instead, you should see it as a companion framework to other IT frameworks. There are a lot of frameworks that ITIL can work well with including:

• Governance - COBIT
• Enterprise Architecture - TOGAF, Zachmann
• Software Development - Waterfall, Agile Development
• Quality Assurance - Six Sigma
• Problem Solving - Kepner Tregoe
• And much more...

Although ITIL is not the only framework you need to learn, it is a good place to start as you setup your IT service organization.

Summary

Indeed there are a number of pitfalls that you can face as you implement ITIL. The list above is definitely not comprehensive. Nevertheless, don't let these pitfalls discourage you from implementing ITIL. As with all process changes, you just need to ensure that you learn from other's experiences in order to have a smoother time when you do your own implementation. I hope by reading this article you will be able to avoid these pitfalls as you go through your own ITIL implementation journey.

How about you? Have you encountered these pitfalls in your own ITIL implementation? Are there any other pitfalls you think we should take note of? Please share your ideas in the comments below.