Welcome to TechnologyProfessional.Org

Advance the profession. Advance your career.

Login now!

Member Login

Lost your password?

Implementing ITIL

April 9, 2009
By

Implementing ITIL in One Easy Step

As a consultant one of the things I do is recommend that organizations look to ITIL for guidance as they develop their internal IT governance solutions and operations processes.  While this is not a particularly stunning revelation to most organizations, what is stunning is that I classify it as a quick win. A fully-implemented ITIL solution in a large organization can take years of focused process updates, retraining, and documentation. Even then, the results may not touch every area of technology operations.

So how can I call ITIL a quick win?  Because organizations that try to implement ITIL as part of a sweeping, all-inclusive change will fail. The only way to successfully implement ITIL is to start small and grow it over time. How small is small?  Based on my experiences, it only takes two words to change an organization.

Take the Step

My first ITIL implementation was for a very large retail organization. We were looking for ways to better organize an extensive IT operations business unit and through research and consultation decided ITIL presented the best overall solution.

We spent months looking at how ITIL worked. We built virtual teams, brought in consultants and wrote volumes of detailed implementation documents. We had meetings, discussions, negotiations and endless reviews of process and procedure both existing and “to be.” As part of this effort I learned that, in the end, the single most important thing we did was to focus on two words:  incident and problem.

Most organizations use the words incident and problem interchangeably to describe what can ultimately be described as involuntary change. That is to say, something broke.  However, when we began to identify an incident as the act of involuntary change (the server crashed) and the problem as the reason for the incident (a bad software package) we found we could much more simply communicate status.

Communication is key. It is the mantra on the brains of anyone who has ever joined the ranks of management. When we distinguished the difference between incidents and problems a world of change opened up for us simply because we were not just communicating, but we were communicating effectively.

With the support of our executive management we, eventually, retrained the entire organization to use the word “incident” to define something that was currently impacting the environment and “problem” as something that caused the incident or in many cases, multiple incidents. We drilled this into the fabric of the organization for a year before we even seriously floated the idea of really implementing ITIL, but when we did the changes were not jarring. The changes were almost common sense.

With those words in place executive management relaxed when we told them the incident was addressed and would immediately ask what the problem was. When that happened, when teams not directly involved in our ITIL efforts started not only using our language but understanding it, we knew we were on the right path. We were able to implement meaningful root cause analysis (RCA) as part of our problem management process and classify  incidents under existing problems or problem categories. However, it was not until we implemented our operations dashboard in these terms that things really began to click.

On the back end we could prioritize problems based on the number of associated incidents and business impact then address the problems accordingly and with the right resources. When we stopped fixing the same symptoms repeatedly, but instead implemented real solutions to the underlying problems, our stability markedly improved along with many other areas of our environment.

Conclusion

It can be argued that we adopted ITIL, at least the ITIL mindset, before we ever deployed it.  took the smallest piece, the simplest concept, and before anyone really realized what happened we had grown it into a real force for change in our environment.

In the end, though, what was it that really made us successful? The following three things:

1.      We were ready for change

  • Spencer Johnson in Who Moved My Cheese? shows us that change is omnipresent and that we can either proactively meet it and choose our future or we can be impacted by it.
  • ITIL was our response to required organizational change in order to improve ourselves. We knew things weren’t going as well as they could so we moved to make them better.

2.      We made the right change

  • Malcolm Gladwell in The Tipping Point teaches us that it only takes a small change to have a big impact as long at it is the right change.
  • By choosing to start very small, but very focused we found the right balance we needed. This was as much luck as anything, but identifying success is sometimes as important as purposefully instantiating it.

3.      We kept on making changes

  • Jim Collins in Good to Great talks about the flywheel effect as it relates to organizational change. While it is difficult to get the flywheel turning, once it has momentum, it only takes a little effort to keep it spinning.
  • Once we noticed that change was taking place, that things were working, we kept the pressure on, and the flywheel kept spinning.

I led several ITIL implementations since then and have written enough process and procedure to fill several books, but none of those initiatives have shown the potential for success that my first experience did. The problem is that many organizations feel they can “buy ITIL.” If they hire the right consultants, write the right process, and train the right people they will be successful;  but in the end, they never do the simplest thing. They deploy the heck out of it, but they never truly adopt it.

Tags: ,

2 Responses to “ Implementing ITIL ”

  1. Jan on May 13, 2009 at 1:50 pm

    Implementing ITIL is easy, but does one know the key on how to run it successfully is always the question. You have provided outstanding inputs about the matter and I firmly believe about keeping on making changes because it creates a more updated output. We don’t have to adopt something that we don’t know so if one thinks of implementing ITIL in his business, he should know the twists and turns first. Good article, you give a very good insight.

  2. Dave Barrett on May 30, 2012 at 9:44 am

    The key to your success would appear to be indoctrination, and adoption of common sense rather than ITIL, such as switching focus from the sypmtoms to the causes. Tell enough people often enough your definition of incident and problem and they will end up going along with you. That does not mean, however, that your definitions are the best ones. I work in a support environment which has adopted the standard ITIL model of incidents and problems and I am constantly battling against it, and ending up wasting time duplicating information and looking for workarounds arising from a model that does not match the real world. It may be close for front-line Help Desks, but not for second or third-line support. I am sure that there is a model that would fit more widely, such as one based upon the user/support dialogue, but I fear that there has been too much investment already in the current model.

Leave a Reply

*