I see from "The Joel Test for sysadmin jobs" question on ServerFault that no one said the company better be using ITIL or they wouldn't work there. In fact, no one mentioned ITIL at all.
Is ITIL a fad? Is it too cumbersome to be practical? Do you have to be a certain size for ITIL to work well?
The ITIL definitions of "incident" vs "problem" are interesting, but in a fast-paced help desk environment, have organizations really found it useful to distinguish between the two?
Absolutely. ITIL is not a set in stone 10 commandments that have to be followed to the letter.
It's simply a foundation or a framework to operate out of.
The real problem comes in the interpretation. If you take ITIL to a level that circumvention becomes easier than implementation, it will never work. But when properly implemented, IT Service level goes up, and Sysadmin stress goes WAAAAY down!
Anyone who implements ITIL dogmatically is a fool (and they told me that on an "official" ITIL course).
You can/are supposed to adapt and adopt parts of it to your needs. It's obviously nuts for a one IT person shop to try and implement ITIL, when most of the conversations between the various "areas" of change management, release management, etc are actually going to take place inside one person's brain but having said that, at the other end of the scale, if you just got offered a fortune to be internal helpdesk manager for Microsoft or HP or Apple or whoever, with users and helpdesk callcentres all over the place, how could you possibly do the job at all without ITIL or something similar as a guideline?
I really should add at this point that we've implemented incident vs. problem management for our helpdesk and it has been very helpful.
ITIL isn't a on/off decision, you gradually roll out the things that are relevant for your environment and tackle the areas which cause the most friction/pain in your organization.
For example: If your helpdesk is being overwhelmed with requests it helps to start categorizing them, analyzing the sources and decide on actions to alleviate the situation.
It's really just a set of best common practices and rules which have proven themselves to work in organizations.
What I like most about ITIL, is that it defines a common language to use when talking to IT pros from other companies, even more so in the European multi-lingual multi-cultural environment. ...
issue management, problem management .. etc. are understood and mean the same.
Besides that, I agree with Robert Moir: Anyone who implements ITIL dogmatically is a fool
ITIL is a tool .. not your salvation.
In my experience ITIL has also been a framework that allows support staff and IT staff to hold their ground against unreasonable demands from the business and implement real solutions to technology problems as opposed to "quick fixes" and "WE WANT IT NOW CUZ IT'S COOL!" demands.
I have worked in an organization that used "business-serving changes" as a an excuse to destroy, bypass, or override nearly every standard IT tried to implement (hardware, software, authentication systems, storage systems, etc.). That company failed and was purchased by a company that lives and breathes ITIL in the support model.
I made the transition to the new company and not only is life better for IT staff, but in the long run the BUSINESS is happier because they get a stable environment, and they actually get better support and new technology FASTER because there are defined standards for support which feed into defined standards of technology. When a standard is upgraded, we know what our upgrade path is, and we know it can be applied to a very wide swath of our deployed systems. This allows us to move along that path much quicker.
We DO still have a proess for allowing business units and various app devs to request "special" equipment or services, but since we do charge-backs this is VERY "expensive" budget-wise for those requesting it. The ITIL framework gives you the
Yup, but while your at it why don't you take a good look at your organizations procedures and support requirements, talk with the managers and users what kind of support level do they expect if they have to make a trade off between money. Then document this and the procedures used to do your job. What you actually did is the same as what all these ITIL/ISO stuff is about too.
Knowing standards like ITIL makes the above task easier because you have a framework which results in the right questions to ask to cover the task completely, but the most important thing is documentation about:
Splitting down the documentation to the lowest entity (like a single task) is tremendous amount of work but as soon as you do that you probably discover that large amount of tasks done now manually are either unnecessary, can be automated and/or can be delegated.
Taking a in-depth harsh look at your organization is never popular or easy to do but it will result in a better understanding of the company and help you be more profitable by just stop doing things that are unnecessary and delegating tasks down to a lower pay level.
What really is going to make you unpopular is when you do these kinds of standardization is that often you inadvertently describe that a lot of management layers are only there because of themselves and that cutting them out will likely improve communication and performance.
The idea of ITIL makes a lot of sense, unfortunately in my experience it's often a tool to allow support/operations staff to get their way over, and slow down, business-serving changes.
