#^@$!*% ITIL! (How to keep ITIL from becoming a 4 letter word in your organization)
It’s a story that’s been told a thousand times in a thousand places. It starts with with a sweet seduction often driven by beautiful images and conversations of how perfect the future is going to be. Pretty soon there is an engagement and formal consummation of the relationship. Sure things go well for a while and everyone seems happy, but pretty soon, the stresses of the relationship bear down and cracks form in the foundation of our love. The next thing you know, you are browsing seedy websites and looking for a way out.
The questions you have to ask yourself is, how did I get here in my relationship with ITIL and why did something that seemed destined for a long and fruitful pairing, go so astray?
The short answer is that it is not uncommon and you certainly are not the only one to have to deal with this shame.
I have talked with many people over the years who have been in this place at one time or another in their IT organizations. They started to “Implement ITIL”, trained most of the organization to a Foundation level, rolled out a few processes and maybe even implemented a new tool. Somewhere along the way though, it stopped being fun and in many cases the amount of change inflicted upon the organization has left a sour taste in the mouths of many including members of the IT Management team. People start to question your results and the mountains of money that have been spent in what was supposed to be a transformational investment.
I personally have lived this pain in more than one organization and learned a lot about what causes these types of programs to fail, in many cases before they even start. At one particular place early in my exposure to ITSM and the joys of ITIL, we were even forbidden to utter the word “ITIL”. In this particular case one of the Directors in IT (who strangely enough happened to be in charge of the Continual Improvement Program) decided that there was no value in ITIL and that we should instead focus all our energy on Six Sigma projects instead. A handful of us true ITIL believers (hey I was young and impressionable back then), even went so far as to start a “Guerilla ITIL” program, secret closed door meetings and all (more on that approach in a different post).
In all of the cases that I have seen where ITIL gets a bad reputation one thing remains constant, the fact that all of the organizations hung all of their hope on this magical, mystical ITIL Framework. We approached it with an awe and fascination typically reserved for heads of state and over hyped pop-culture fixtures. We put it up on a pedestal and gave it godlike status, worse we bought our own BS and actually believed that ITIL alone would save us from all of our previous Technology transgressions. If only we could train all the staff, build all of our processes and get a new tool to replace that old one we had customized to the point that we were 3 full versions behind what the vendors were currently peddling.
So off we went like happy lemmings down the path that all of the “experts” told us we should go down. We trained 20 people at a time and pretty soon we all were walking around talking about Incidents and Service Requests and Service Catalogs. Then came the hard work, trying to convince everyone else that we had the secret to make things better that no one else did. We labored and we toiled and we had meetings upon meetings. Pretty soon we had most of the organization convinced that we could “do ITIL”.
And that my friends is where we began to pave our our fast lane to IT Hell. One good intention after another led us to a place where people were frustrated, processes were more broken than fixed, and management no longer had the stomach to keep pushing through. Had we had to the courage to step back then and re-evaluate we might have salvaged some of what we were doing and managed a lot more success than we ended up with, but we kept pushing and eventually a lot of people fell back into doing whatever it took to get things working tactically than rather than work with us on the strategic vision we had been painting for them.
One of the things I learned from that experience and a lot of subsequent others is that there is no silver bullet, and that we needed to put more faith in ourselves than we put into a framework that was intended to be one of many tools at our disposal.
Folks, in this industry we keep looking for simple and easy approaches that tie all of our problems up in one box with a neat little bow, but the reality is that we live in very complex environment that change in many cases faster than we can plan to react to it. For us to assume that a single best practice or methodology is going to solve all of our problems is a delusion, and one we have happily been selling ourselves on (with no end of help from the myriad vendors peddling their wares) that dream.
There is no one size fits all, there is no “ITIL in a Box”, and something that works for one company almost certainly won’t directly translate to another. The path to success is typically long and requires a fair amount of heavy lifting on the part of many parties, including the Businesses we in IT are tasked to support.
Any organization looking to transform their IT Organization needs to go into it with their eyes open and a clear understanding of the journey they are planning to embark upon. A good Service Management program will use tools from any number of disciplines (ITIL, CobiT, Six Sigma, MOF, Lean IT, Agile, etc) and use those tools appropriate for the job at hand. Hanging all your hopes on a single tool to build a house will yield very predictable results. Further, when you are marketing and selling this dream within IT and to your business, you can avoid further pain by not getting too hung up on the language of one framework or another and focus on the language of the business itself. Talk about results and the impacts you intend to make on the business (both positive and negative, because surely in the course of building there will be times you may cause pain), it is always best to prepare folks for the journey by giving them the best idea of where the journey is going to take them before you put them on the bus.
Secondly, DO NOT underestimate the amount of energy you will have to put into managing the People side of the program. Organizational Change Management, will be one of the single most important aspects of the program, in many cases it will have a greater bearing on your success than your processes themselves.
We often use the phrase “People. Process. Technology.” in our industry and I recently had to remind a tool partner that there is a reason why we order them this way:
People – In order to be successful, we need to arm our people with the Skills and Tools (not SW in this case) they need to be successful as individuals and to support the overall goal of the ITSM Program and the organization itself. We also need to realize that different people in different roles need different skills and different tools to support those needs. Blanket or Shotgun blast approaches to training skills will seldom yield the desired results. Spend the time and build the skills for the best practices you will be employing, the processes you will be implementing and the roles they will be fulfilling.
Process – You have to be sure and identify the processes your organization needs in place to appropriately support the business and it’s processes and vital business functions. It is very easy to get caught in the trap of trying to check off as many processes from the best practice frameworks as you can to get some sort of corporate “Merit Badge” equivalent. Focus on the right processes, at the right time, with the right level of maturity.
Technology – Technology should exist solely to enable the processes that you have put in place and engineer the labor out on non value add process activities. If technology adds unneeded complexity or forces you to materially change the way your process is designed, then you probably need to re-evaluate your technology strategy. Technology capabilities will almost certainly constrain your process design from time to time, but once those constraints begin to impact your ability to effectively deliver your process outcomes, it is time to begin looking for a new technology.
At the end of the day, your ability to be successful directly depends on your ability to assess the problems you are facing, identify the tools needed to fix each of those problems and your skill in wielding those tools as they were intended to be used.
Till we meet again,