ITIL is “Not Failing” Instead of Lean “Success”

The entire purpose of ITIL was to manage failure and that’s why working in companies using ITIL structure is such a miserable work life. ITIL is focussing on the problem of failure instead of creating success. Welcome to the mis-managed IT world where “not failing” is also “not good” infrastructure of 2014.


In the late 90’s, IT was becoming more and more critical to companies but a general lack of discipline among IT practitioners led to problems. People were configuring systems on the fly, asset management was poor, there was little sharing of systems and so forth. These problems became more and more common and widespread that aa entire consulting discipline sprang up to address these problems. It took a few years but a bunch of rather conventional business processes were pulled together and called IT Infrastructure Library (ITIL).

There were relatively few people who understood IT at the time and those who did understand it were busy fighting the fires and standing up new systems in the dot-com gold rush of the era. As a result, ITIL has almost no relevance to actual IT problems but lots of relevance for the expensive consultants who designed them and lined their pockets with consulting revenue to implement them. Which was sort of fine. Because just like the Six Sigma in late 1980s and the Quality Assurance era of early 1990s and era in the la that it wasn’t actually that important which processes we used as long as had some discipline and structure. IT did get better but ITIL is focussing on the problem of failure instead of creating success.


The major failing of ITIL was that it focussed on NOT FAILING.  All the processes were intended to reduce outage and prevent projects from running late or over budget. That’s not being successful that is  “not failing”.

Project initiation  = scoping the solution so you don’t fail by missing the target.

Change Management = intended to reduce risk of change so you don’t have an outage failure.

Project management = intended to ensure compliance (i.e. no abuse or variation failure), Progress (running late = failing) , budget control (prevent fiscal failure).

Service management = management visibility ( no unexpected surprises = no failure)

Instead of implementing a system that focusses on success we have implemented a system that focusses on “not failing”. This is what makes everyone miserable. Who wants to deploy a system that “doesn’t fail”. Deployed “on time” isn’t a success, it’s a “didn’t fail” result. Project finished on budget is not a “win”, it’s a “not fail” outcome.

The only time I get to do something exciting and successful is when I do it outside of ITIL process. That’s when I win because I didn’t “not fail”.


If you have had the luck of working on a project that uses Lean methodology, or Scrum or Kanban then you will know what I mean. No one focusses on “avoiding failure”, everyone focusses on winning, or better or best. We make trade-offs for “good enough” because that is still winning.

Instead of working on a project that “meets the scope of works” or does the bare minimum, DevOps is about changing and adapting to find a successful way to implement IT.

Avoiding Failure Examples

ITIL avoids failure by making one change a year.

ITIL avoids failure but buying only what the project needs.

ITIL avoids failure by reusing process that were designed for a different process but its to hard to change them.

ITIL avoids failure by selectively choosing to ignore technical realities. This creates technical debt.

ITIL avoids failure by using big and expensive technology because “new technology might cause failure”

I could go on and on. ITIL forces a problem path that avoids failure and prevents success.

I want to Win.

ITIL is an emotional poison that sucks the inspiration and joy from technology and reduces us to grey people who can evaluate their lives in terms of “didn’t fail”. I have spent two decades of my professional living a grey zone of never winning and never failing.

Death to bloody ITIL. I want to win.

  • Etherealmind

    Most people don’t get this. Here is the argument, just remember that we generalising:

    1. The business doesn’t trust IT to get it right. IT lets the business down 20 years ago. In business process, nothing really changes much so this remans a “fact” .
    2. Executives and “leaders” don’t understand IT and can’t see that technology is a profit centre through productivity gains. They will invest in marketing and products for profits, they should also invest in IT for profits.
    3. Spending the minimum gives the minimum results.
    4. The minimum result is the closest we can come to “not failing” without actually completely implementing a bad and useless system. If we wanted to be successful, the business would invest appropriately to get the best and win.

    Hope that makes sense.

    • returnofthemus

      1. In an ever changing business and regulatory environment businesses are having to make significant investments in IT admist a whole host of spurious vendor claims.

      2. Executive teams and business leaders understand IT is becoming more integral to their businesses, however stlll have to balance IT with a range of other business priorities, as investing in IT does not automatically translate into profits.

      3. A clearly defined strategy should dictate how much you spend and what you spend it on, spending for the sake of spending is not a strategy.

      4. The minimum result is ‘reducing cost’, so it’s hard to see how ‘not failing’ comes into the equation.

      Probably one of the most gross misrepresentations of ITIL I’ve ever read, no it didn’t make any sense at all, but it was very entertaining!

  • Rob England (The IT Skeptic)

    Get rid of these bloody left and right arrows so I can write a comment will ya?

  • Rob England (The IT Skeptic)
  • Sergej Pioch

    The gist of the matter. Absolutely!

  • Etherealmind

    I’ve experienced this when working with engineering companies and it’s soul crushing to work with those projects. I sometimes wonder if people would prefer to work on production lines instead of more creative and somewhat inspiring work process that gives some ability to deliver outside the box. ITIL and its ilk prevent that completely.

  • Etherealmind

    ITIL is just another manifestation of business concepts from the 1970’s. Six Sigma, QA, ITSM/ITIL are all aspects of the same thing. Theory: make a process static, prevent change and then thing can improve because you can measure the improvement.

    Except that in IT, ‘things’ change faster than a process can defined. The process is pointless by the time it is implemented. And IT velocity is increasing far beyond the capacity of any process to adapt and manage.

  • drambui

    Interesting. I suppose it is a matter of perspective. I always saw ITIL as enabling success while recognizing and being transparent about the history. There are many paths to successful it service management. ITIL, COBIT etc. try to optimize that path.

  • ZaneFounty

    Agree 100%, its a pity that organisations are only just starting to realize the short comings of ITIL as it is now mandated in contracts

  • Etherealmind

    There is potential for them to co-exist in large teams where there is enough participation. But for most IT teams I feel it will be DevOps since it get things done.

  • Stef Knaepkens

    Hi Greg, you definitely made a point here. I was among of the first ITIL Service Managers in Europe. At that time we defined ITIL as “IT Infrastructure Library”. It’s good to know that it all started with a small set of lightweight books filled with good advice on how to keep the system “up”. Indeed, not failing meant continuity at that time and in the 90’s keeping the system up was the most important thing to do. As of ITIL V2, the library became a broader management instrument and I have used it with great success for turning IT operations departments into service organisations. However, infrastructure soon became a commodity and many organisations started to outsource this domain either in full or partly, which in fact made ITIL obsolete. The invention of ITIL V3 marks the point where I really turned away from it. This version totally missed the point. It tries to embrace the complexity of the business, but puts the IT system in the center. I once bought the ITIL V3 books, I even studied them, but I got quickly frustrated as it is all narrow-minded. In the current dynamic business environment, there is no place for a dinosaur that focusses on control and stability.

    Although ITIL was my passion, bread and butter, in my current role as business manager in a IT driven company, I don’t see the benefit of ITIL anymore. I’d rather be inspired by marketing, sales, operations, strategy and other models (there are plenty). In our IT, we work based on SCRUM, but ITIL is of no use. I hope that every (IT)manager is smart enough to stop thinking in terms of ‘ITIL implementation’. ITIL should never be the goal. The only goals are customers, profit and growing the business. And maybe there ares some cases where ITIL really helps, and I’d love to hear recent success stories. Someone?

  • postwick

    ITIL is neither success nor non-failure. ITIL is a set of ideas. It is how you apply those ideas within your environment that determines whether you are “not failing” or “succeeding.” The people who don’t succeed at ITSM when using ITIL are the ones who think it is a blueprint rather than a framework, a set of ideas.