HOWTO: Strangle Yourself With ITIL.

Looking back over my short 6 year career I’ve noticed that I’ve never really worked for any smaller organisations. Probably the smallest team I ever worked for was a group of 20 people on the National Archive’s Digital Preservation Project but even there I was technically part of the larger group of 200 or so people responsible for archiving things of interest for the Australian public. Probably the largest team I was in so far was at Unisys with my team consisting of around 30 people and the section I was a part of had well over 400 staff catering to all aspects of IT for a large government department. Working in such large environments has its benefits, such as lower amounts of responsibility and the opportunity to heavily specialize, but these are easily overshadowed by the drawbacks of needing that many people: managing the lot of them.

For the most part though I’d agree that its required. The last thing you need in a large environment is some cowboy system administrator making wide reaching changes which end up affecting thousands of people or loose process definitions which end up confusing the heck out of anyone trying to get some work done. Once you reach a critical mass of users and staff formalizing your procedures and policies starts to bring tangible benefits and is the basis for the industry buzzterm Six Sigma. However it seems that organisations that are intent on strangling themselves to death with rigid frameworks seemingly looking upon the horror they’ve created with rose coloured glasses.

Take for instance change management. At its heart it’s all about making sure that you don’t go changing things that will inadvertently affect other things and ensuring that all required stakeholders are informed of these decisions. When I was trained in ITIL I instantly recognised the benefit of such processes and was quite thrilled to see it accepted at the first real workplace I had ever landed a job at. Once I had become familiar with its implementations though my view of the glorious world of ITIL compliant processes was tainted with the harsh reality that for the most part it’s completely unachievable.

My current workplace is a glorious example of this. In what supposed to be a relatively progressive workplace (they had 1.0 revisions of blade servers here, a risk very few took) the change process is still done manually. I.E. if I need to change something in the environment I need to fill out a change request (fine, that’s part of ITIL), print it out (hmmm ok sure), take it around to all the service owners and get them to sign it (ummmm what?), get the Global Service Delivery manager and CIO to sign it (argh, why are they never in their office? Oh right they have more important things to do) and then give it to the change manager (total time spent doing this, around 2 hours). The Change Advisory Board (which contains all the service delivery managers) then meets once a week to discuss the changes they’ve already signed and so spend 30 minutes confirming that they actually signed the changes. Oh and they might ask how the previous changes went, maybe.

The above example demonstrates quite aptly how a vision of a process becomes horribly bastardized in the hands of those who don’t really understand it. Worse, even though the process is known to be horribly flawed, nothing has been done to change it in the many years it has been implemented. It seems everyone is content to gripe about how bad it is yet when improvements are made they amount to nothing more than rearranging the deck chairs on the Titanic, giving the impression something is being done when really its not (*cough*management theater*cough*). Couple that with the apparently abhorrent idea of scrapping the entire process and rebuilding it anew and you’ve got a recipe for one bad idea to exist for eternity, right up until the whole organisation collapses upon itself in a flurry of industry buzz words and frameworks.

Many people who’ve come from smaller organisations and start ups often tell me this is a symptom of larger organisations, where bureaucracy reigns supreme. I can’t refut this position as I’ve never worked in such a situation although I’m doing my darnedest to get there. Logically it holds true as the fewer people you have to consult to do something the less time it will take to get it done, and the less likely that one of them will want modifications to your idea. After seeing so many organisations hang themselves on the ITIL/Six Sigma/Lean noose I’ve got to wonder if its the frameworks themselves are flawed and the smaller organisations are immune to their tragedies simply because they haven’t tried to implement them.

Maybe I’m just sour because I’ve never really been in a position to change these processes. Ever since I started working I’ve seen ways that things could be improved only to be told that they just wouldn’t work, no matter how I spun it. There’s the very true possibility that my view of the world is total crap and all my ideas would generally not work but evidence is mounting that non-traditional approaches to business work, especially in our information rich Internet world. The time is fast approaching for me to put up or shut up and hopefully my ideas will work out for the best.

Or I’ll fail miserably and come crawling back to the world of IT support, secretly crying in the corner of server room somewhere 😉

One Comment

Leave a Comment
  1. To date the largest company I’ve worked for had 50 people. In a couple of weeks I kick off at Defence as one of their chief Linux grunts. Something tells me their implementation of ITIL will make yours seem like JFDI.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.