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.
ITIL = NOT FAILING
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.