ITIL doesn't add overhead

I'm intrigued by the endless repetition of the chant "ITIL slows things down". No it doesn't. Doing things properly slows things down.

Variations we also hear are "ITIL Gets in the way". or "ITIL adds overhead". I always tell clients that it is highly unlikely that the application of ITSM principles will save them money. I think those who sell ITSM or ITIL as a cost-saving tool are misleading clients or know little about ITSM. An improvement initiative will almost certainly add new activities, roles and even tools, as the client uncovers all this stuff they really ought to be doing but aren't.

Think of ITIL as your conscience. Or your Mum.

  • You really ought to be analysing UCs to ensure they match up with your SLA commitments
  • All calls should be recorded
  • perform a post-implementation analysis of failed changes
  • how can you allow production changes that have no backout plan?
  • there's no use promising availability levels if you can't measure them
  • it is a good idea to define clearly what you actually do, in terms that those paying for it can relate to
  • capture all proposals for new systems and prioritise them else you'll be swamped
  • governance of IT happens outside IT - who's giving you direction?
  • it is a good idea to think about how you will handle major incidents before they happen
  • IT disaster recovery planning is pointless unless done in the context of business continuity
  • clean your teeth

ITIL is a reference framework: we can use it as a reference against which to compare ourselves in order to see where there are gaps, where we could do better.

If your developers are charging into production in an uncontrolled manner without forewarning and training the users and without checking for clashes with changes to underpinning systems (the short name for that is "Agile"); if nobody knows exactly how much work your helpdesk does in a day; if you have too many outages or failed changes; if your suppliers ride roughshod over you because nobody holds them accountable; if nobody is settign policy around what users and business units can buy; if nobody in the business can tell you what is your most important service... if you need to improve your IT management then guess what: that is going to involve extra work. Somebody will need to do more.

Oh sure there are efficiency gains when you reduce rework, duplication and failure. But in the real world these are usually swamped by the increased workload of doing things that were never done before, or doing things better.

ITIL doesn't slow things down. Thinking about what you are doing slows things down. Writing down what you plan to do and what you actually did slows things down. Communicating and collaborating with other affected parties slows things down. Checking that you are not endangering the viability of the company slows things down. Performing the due diligence so that the Board of Directors can sign off their Sarbanes-Oxley commitments slows things down.

ITIL doesn't get in the way. Messy reality gets in the way of tech fantasy oversimplification. Our responsibilities to protect the company assets gets in the way of new toys. Our need to compensate for poor governance and policy gets in the way of nimble decision making. Unscrupulous vendor marketing gets in the way of building a consistent IT architecture.

ITIL doesn't add overhead. Reducing risk adds overhead. Increasing efficiency - ironically - also adds overhead. Improving quality adds overhead. Adding new systems and capabilities adds overhead. And of course increasing value adds overhead.

This "ITIL slows things down" crap is immature whining from tech cowboys who don't understand business. ITIL (or ITSM in general) isn't some extra optional accessory to the conduct of IT. ITIL (or COBIT or...) is a set of nagging reminders of all the things you ought to be paying attention to if you were doing your job properly. Real professionals are grateful for that.


great post Skep

great post Skep

> "If your developers are

> "If your developers are charging into production in an uncontrolled manner without forewarning and training the users and without checking for clashes with changes to underpinning systems (the short name for that is "Agile")"

Obviously you don't understand what Agile is. Or you wouldn't describe it in this way. What you do with that sentence is exactly the same as people who says "ITIL slows things down"... I understand and fully agree with your points about ITIL. But, please, try to understand Agile too. They have actually exactly the same goals, and can be put in place together.

Understanding agile

It's funny - I frequently hear people saying "We need to be more agile".

While they might *think* they're referring to "Agile" as a software development methodology, the real intention behind the statement is simply: "Do everything quicker" and, funnily enough, this leads to events happening much as the Skeptic describes...

I'm sure I've seen a Dilbert strip that's pretty near the mark on this too :)


Agreed. A colleague recently made the statement, "Too many people equate agility (Agile) with speed". Makes a lot of sense to me. Agility is about being able to change direction quickly and accurately. Agile, therefor, is about not committing your resources to one task/project for too long, so that they can be re-allocated elsewhere quickly, as the business requires.

My favorite (American) football player is Barry Sanders (, the epitome of agility. Was he fast? Yes, but lots of pro athletes were/are faster than him. What made him great was agility.

Fair point it was a cheap

Fair point it was a cheap shot. I knew it when I wrote it. But I still regard Agile with the deepest suspicion. As you say the analogy with ITIL is good: the theory of Agile is ok, it is the application of it that worries me.

I'm an IT Manager. And I've

I'm an IT Manager. And I've never heard of ITIL. Your article doesn't say what it is either only that we should pay attention! Please xplain what it actually IS.


Google is your friend. Specifically is your friend.

where have you been?

(Thank,you Matt. or ServiceSphere introduced me long ago to lmgtfy.)

I can understand not believing in ITIL or not prefering ITIL or even loathing ITIL, but to be an "IT manager" and not to have heard of ITIL I can only ask where the hell have you been for the last five years? Unless of course you are an IT manager on another planet.

I was just in an interview

I was just in an interview yesterday. The hiring manager is the acting CTO of the company and when I mentioned I was ITIL trained/certified he took a moment to stop, ask what ITIL was, and make a note to learn more about it.

Not shocked

I find those people all the time.

They probably never heard of COBIT or ISO anything (maybe...maybe 9000...but suspect).

My theory is: They get there because they knew something technical not because they knew about 'how to manage' people or IT. They knew how to install, configure, update, code, some 'nerdodine machine' of some sort and so they were promoted up the stack. What the heck do they know about processes or even accounting? Probably not much. Activity based costing? Never heard of it. Lean accounting? Nope. SERVQUAL? Is there a test for that?

I work with people who never heard of SFIA. Probably never will.

They don't want to improve anything. They want to take vacations and go to happy hour. Their motivation is probably more technology driven than actually management driven. They like new shiny things. Like the 'cloud' or Hadoop.

Syndicate content