If you’ve worked in the IT industry it’s safe to assume that you’re familiar with ITIL or at least however it’s manage to manifest itself within your organisation. It’s probably one of the longest lasting ideals in IT today having been around for a good 20+ years in its current form, surprising for an industry that considers anything over 3 years archaic. Indeed anyone who’s been involved in implementing, maintaining or attempting to change an ITIL based process will likely call it that anyway and whilst I’m inclined to agree with them I think the problems stem more from the attitudes around these processes rather than the actual processes themselves.
Change management is by far the best example of this. The idea behind it is solid: any major changes to a system have to go through a review process that determines what impacts the change has and demands that certain requirements be met before it can be done. In an ideal world these are the kind of things you would do regardless of whether an external process required you to or not however the nature of IT tends towards many admins starting off in areas where such process aren’t required and thus, when they move onto bigger and better environments, processes like these are required to make sure they don’t unintentionally wreck havoc on larger systems. However change management is routinely seen as a barrier to getting actual work done and in many cases it is.
This is where the attitude problems start to occur. ITIL based processes (no one should be using pure ITIL, that’s crazy talk) should not be a hindrance to getting work done and the second they start becoming so is when they lose their value. Indeed the reason behind implementing an ITIL process like change management is to extract more value out of the process than is currently being derived, not to impede the work is being done. Essentially it should only be an extension of work that would be undertaken in the first place and if it isn’t then you either need to look at your implementation of the change process or why your current IT practices aren’t working with it.
Predominantly I think this comes from being far too strict with these kinds of processes with the prevailing attitudes in industry being that deviation from them will somehow lead to an downward spiral of catastrophes from which there is no escape. If these ITIL process are being routinely circumvented or if the amount of work required to complete the process outweighs the actual work itself then it’s not the people who are to blame, it is the process itself. Realistically instead of trying to mold people to the process, like I’ve seen it done countless times over, the process should be reworked to suit the people. Whilst this is by far more difficult to do than simply sending people on ITIL courses the benefits will far outweigh the costs of doing so and you’ll probably find that more people stick to it rather than attempt to circumvent it.Indeed much of the process revolution that has happened in the past decade has been due to these people rather than process focused ideals.
Whilst ITIL might be getting a little long in the tooth many of the ideals it touches on are fundamental in nature and are things that persist beyond changes in technology. Like many ideas however their application has been less than ideal with the core idea of turning IT in a repeatable, dependable process usurped by laborious processes that add no value. I believe changing the current industry view from focusing on ITIL based processes to people focused ones that utilize ITIL fundamentals would trigger a major shift in the way corporate IT entities do business.
A shift that I believe would be all for the better.
When you’re implementing an IT system there’s usually a couple well known paths that you can follow that will ensure it operates pretty much as expected. In the past this was what a good IT administrator would have been hired for as they would have been down these paths before and would know what should and shouldn’t be done. Over time companies began producing their own sets of guidelines which they would refer to as best practices, serving as the baseline from which administrators could create their own. With systems ever increasing in complexity these evolved from simple articles that would fit in a blog post to massive how-to manuals that detail nearly every step required to make sure you don’t bollocks up a system. This was the point where the excellent notion of best practices turned into a manual for those who had no fucking clue what they were doing and it shows with the level of competence I’ve seen in the various IT departments I’ve been privy to over the years.
Nearly every good system administrator I’ve met has been, for the most part, self trained. It usually starts out with a general interest in computers at home where they tinker away with their machines and usually end up breaking them in the most catastrophic fashion. This natural curiosity is what drives them to figure out the root cause of problems and is essential when they get involved in larger systems. Whilst training courses are all well and good they are unfortunately narrow in their focus and are, for the most part, designed to give a set of rules to use when first approaching the problem. After that the skills required (critical thinking, logical deduction, et al.) can’t really be taught and those seeking a career in this space lacking such skills typically didn’t make it past second level support.
However the distillation of industry knowledge into best practice documents has blurred the line somewhat between those who have the necessary skills to work at the third level and those below. The documents themselves aren’t to blame for this, indeed they are actually responsible for the industry as a whole becoming more reliable in delivering repeatable results. More it is the use of these documents by those who would not otherwise have the knowledge required in order to perform the tasks that these best practices outline. This is because whilst best practices give you a good idea of which direction to head in when you’re implementing or troubleshooting an IT system they do not cover the issues specific to your organisation. They can’t simply because they are unable to account for the almost infinite number of possible configurations and that’s were those key skills become a necessity.
A classic example of this that’s rife within the IT industry is the implementation of ITIL. Serving as the best practice to underpin all best practices within IT departments the ITIL framework has found its way into nearly every organisation I’ve had the pleasure of working for. As a basis for IT processes it works great, serving as a reference point that anyone who’s been trained in it can relate to. However by its very nature ITIL is just a framework, a skeleton of a what an IT department or organisation should look like. However too many times I have seen ITIL taken literally and business processes shoehorned into the bare bones framework with little thought to how much sense it makes to do so. Realistically whilst it is desirable to be ITIL complaint it’s more desirable to have business processes that work for your organisation. That is the difference between using best practices as a gospel and using them as a basis for a functional baseline on which to improve on.
The blame can’t be wholly aimed at those administrators either as it is the business’ responsibility to hold them accountable when the system doesn’t deliver as expected. Unfortunately too often best practices are used as a convenient scapegoat which wrongly puts the blame back on the business (“It doesn’t work like you expected? But it’s built to industry best practices! Change your process.”). In reality tighter specifications and rigorous testing is required to ensure that a best practice charlatan doesn’t get away with such behaviour but that unfortunately adds cost which doesn’t pass muster with the higher ups.
In the end those best practice sticklers are both a boon and a curse to people like me. Because of them I’m able to find employment anywhere and at a very considerable rate. However when I’m working with them they can make doing the right thing by the customer/business next to impossible, instead insisting that best practices be followed or the house of cards will come tumbling down. Thankfully due to my chosen specialisation being quite new there’s not a whole lot of best practices ninjas floating around and actual experience with such technology still reigns king. However with time that will change and I’ll be forced to deal with them, but that’s long enough into the future that I’m not worrying about it yet.
By then I’ll be working for myself, hopefully 🙂
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 😉