ITIL Is Not a Cure-All!
I've done admin and systems design work in a few "ITIL shops". The reason that's in quotes is because, in my experience, being an ITIL shop involves paying 7 figures to an enterprise software vendor for service desk/change management software. The software is then deployed with zero customization, and every single ITIL process, including the ones that don't make sense for that particular org, are put in place.
This is the kind of environment where requesting a change involves the *entire* ITIL procedure, including filling out generic change management forms in the software with 150+ mandatory fields, the change management meeting, backout plan approvals, scheduled maintenance windows, post-change reports, etc.
Unfortunately, I wish there was a better way to do what ITIL sets out to do. It seems like you either have a situation where it takes 21 days and the CIO's personal approval to provision a network port, or mad cowboy admins from the local tech degree mill wreaking havoc on live systems 24/7.
The sad thing is, because of these cowboy idiots, those of us who take the time to properly learn the sysadmin trade are reduced to form-fillers and button-pushers. I'm all for planning a change properly and not getting yourself into a situation where you can't recover, but when it gets crazy, that's no fun either. (Example I've heard -- RAID 1 drive fails, change management process prohibits replacing the mirror drive without a million approvals, and the other drive in the mirror dies before the change can be approved! A zero-downtime change becomes a multi-hour outage...)
Ironically, VM technology makes things much more flexible, giving the cowboys even more power if you don't control it. I'm guessing the changes in ITIL for the virtual world are going to involve even further separation of duties (you'll have a "VM provisioner", a network guy, a storage guy, and a security guy all involved with any server build or change, etc.) ITIL is sold to CIOs and corporate boards as a complete cure-all for IT ills -- just have your staff follow this entire set of guidance and you will never have downtime. Reality is (a) the cowboy admins will find a way around it, (b) the processes are so paperwork-intensive that the environment stagnates because no one wants to go through the hassle to fix something, and (c) the better IT staffers will leave to work somewhere that gives them just enough freedom to keep things running.