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: ITIL, operations

This entry was posted on April 9, 2009 at 7:48 am and is filed under Featured, Infrastructure and Operations. You can follow any responses to this entry through the RSS 2.0 feed.