At the core ITIL sort of says there are 10 things that you should be doing, and goes into a lot of detail about what those things are. It goes a lot further then that, sub dividing all of those things again and again, but most places only need to look at that first list and figure out how many they do at all, and how many they do well. Most places do about 6 or 7 at all and only 2 or 3 well.
ITIL tells you what you should be doing, not how to do it.
The other large part of ITIL is the terminology, which also forces a way of thinking. An example of an incident is when the user rings to complain that something is working and you get the user up and going using typical help desk processes (reboot the server for example). The problem is that the system broke in the first place, which might be a more complicated and expensive fix.
While this may seem like trivial example or simply common sense it is a difficult concept for many people to grasp. The idea that when you fix an incident you still have to track the problem and try and resolve it, even when you have no users screaming at you is not in tune with most IT support organizations. Sure it happens on an ad-hoc basis (eg saying over lunch "you know, we really need to fix that firewall, its always crashing") extending this to something systematic is difficult.
ITIL is not just a way of managing IT organizations, maybe not even a way of managing IT organizations. Its just a set of ideas and guidelines. I think is a good thing to hold an IT department against to see how much of a job they are doing (how much, not how well). It is bloody hard work simply to try to "do a better job", no matter what guidebook you are following.
The most difficult part of implementing ITIL is getting it pushed down to those people who do the work. I agree that it is a waste of money sending everyone in the organization on a training course to learn the same thing, but no organization is going to improve simply if the management starts using a new set of terminology, it has to be pushed down to the people who actually do the work. They need see how the work they are doing fits into the higher level processes, and how these help deliver the IT service.
It puts peoples roles in perspective, they need to see what part they play in delivering service, but that every one around them is also playing a part. Sometimes people don't see the flow on effect of not doing a good job because they don't see how they fit in to the scheme of things, not other people think that they are so much more important then anyone else and don't realize that they can't deliver service just by themselves, other people form part of the chain.
