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.
You bring up some excellent points, but let me play “devil’s advocate”:
How (or why) do you rework the process to fit the people?
Not only is turnover fairly high, but the IT industry is frequently disrupted by new technologies that would restructure how departments work. Do we change processes to fit each worker, and each new technology that would change a process?
If we did that, there would be too much wasted time in learning a more complex, more temporary system, where we wouldn’t be able to apply Quality Control practices because we’re constantly “changing our measuring stick”.
There are fundamental aspects of ITIL that work (change management is one of them) however most organisations, at least the ones I’ve worked in, try to get people to adhere to the strict ITIL definition of the process. Whilst this might work in some ideal cases more often it results in massive additional overhead that doesn’t provide enough value to justify its existence. What I’d advocate instead is using ITIL as the basis for a process that’s tailored to your environment/organisation as whilst it might not be portable it most certainly will provide more value.
The processes should be the result of collaborative work among all who will be involved in it and thus, whilst IT turnover might be high, the overall process structure shouldn’t fluctuate greatly over time. Should your entire organisation end up replacing itself then of course so should the process, but it wouldn’t be redone each time you hired someone new. Instead I’d advocate reworking the process when it’s found to no longer fit with the current norms of your organisation. This could come at any time, even if your organisation was relatively static.
It’s the rigid application of strict ITIL practices that’s detrimental to an organisation’s IT health, not ITIL itself. Using ITIL as it was intended, as a basis for developing your own processes, would yield far better results and would probably see many more IT workers willing to engage in shaping said processes.