In the US in particular, we have a habit of calling out words we don’t care for, words that represent something reprehensible to us, as being a ‘4 letter word’. Never mind if the word really doesn’t have four letters in it, if it connotes something bad, it’s usually considered a 4 letter word – a ‘swear word’ – to merely utter it. And it’s those four-letter words that get the *Bleep* when we watch TV or hear them on some radio broadcast.
Words like WORK might qualify.
It might not look it at first glance, but for many, Information Technology Infrastructure Library is a 4 letter word. (It gets closer when you use its friendlier acronym, ITIL (Pronounced IT’LL if you’re in the UK – which makes for many more pun opportunities than the US version that sounds like ‘IDOL’.)
But I digress.
The Information Technology Infrastructure Library didn’t really take long to earn its 4 letter word – stripes (If they give out stripes for such a thing)… It started out being called ‘GITIM’, which as we can plainly see, is a 5 letter word.
Not only didn’t it roll off the tongue, but it wasn’t fully baked yet when it was referred to as Government Information Technology Infrastructure Management. That was way back in the 1980s… practically ancient history now, when the CTTA (Another 4 letter word?) in Britain (the Central Computer and Telecommunications Agency) identified a need for standardization.
It couldn’t have happened at a better time, particularly given the business and political climate in Britain saw a fall of ‘Centralization’ and a surge in the privatization of many functions during this period– some of which included the need for the military in Britain to maintain a set of standards over how information was to be provided them, during times of war or peace.
Privatization meant that control over the ‘How’ things got done, or even the terms used to refer to activities taken in the name of getting things done, was no longer centralized, and was instead, thrust into the realm of private businesses. Here, without intervention and planning, it would be destined to become a proverbial ‘Tower of Babel’, with every business speaking its own language, using its own methods (that were often proprietary to that specific business), and generally paying no attention to how this all looked or worked. Fortunately, someone was planning for this and looking to stem such an impending doom.
While this was going on across the pond, back here in the US, there was barely a ripple. Information Technology was still largely being managed stateside in the same ways it had always been – with I.T. often ‘wagging the dog’ of the business – despite the fact that IT for most organizations were nothing more than the tail. (And a ‘bobbed’ tail at that). Here in the US, it was a ‘Tower of Babel’ already… No one spoke the same language of IT (My ‘Problem’ was your ‘Incident’), and IT felt a little like the wild, wild west.
As the Brits started moving towards this standardization by developing a framework in which to nestle the best practices and terminologies being ferreted out, the first series of ITIL Books (The actual “L” in our 4 letter word, the Library) was being published as ITIL V1. Such was the heady times of the 1990s when it was becoming clear that IT, and the things it could provide, became ‘awoke’. It wasn’t a complete library by comparison to today’s’ books, and didn’t address much outside of basic Incident/Request handling… but it started getting terms in place that could be built upon; a language that others could use.
And virtually all of those ‘others’ were businesses in Britain and the UK, who began adopting the tenets of this new Framework despite the human nature based dislike for change. (Which, when coupled with the word ‘Management’, became another 4 letter word known as Change Management).
It wasn’t as if the US wasn’t involved. Representatives from IBM and Microsoft et.al. were intimately involved in writing these first standards. But it seems the standards crafted for Britain under the initial ITIL V1 books was destined to remain largely on the other side of the Atlantic. They were made for ‘someone else’s problems’. (Or is that, Incidents?)
Around the time that the ITIL V2 books were being produced in 2001, interest here in the US was on a slow uptick. Some larger training organizations began delivering training for ITIL to those businesses who had heard about it and fancied themselves on the ‘bleeding edge’ in both technologies and in the machinations necessary in order to properly manage it. Also around this time, we saw Microsoft looking to parlay their role in crafting some of the ITIL book verbiages, into their own, initially proprietary method for managing IT, known as Microsoft Operations Framework. Subsequent revisions and updates (MOF 4.0 was released in 2008) have become free for download. While not as comprehensive as the ITIL books, some like the concise nature of the documentation in Microsoft’s processes – and the fact that there is no Certification as there is within the ITIL Framework, while others prefer the more comprehensive nature of the ITIL books. It’s likely no coincidence that ITIL V3 arrived on the scene in 2007, to be followed by Microsoft’s own update to their standards, a year later.
So, organizations in the states were faced with ‘something new’ in that most of the ITIL concepts were foreign in more ways than one, despite the fact that in Europe, ITIL was becoming a hotbed of activity, with certifications and the examination bodies necessary to evaluate success, popping up in response to this growth. In addition, there were then as now, competing thoughts (And even ‘standards’) that created more division than unity behind a single way forward.
But with change comes fear. And with fear comes all of the reasons why we shouldn’t do this thing over that other thing. (With ‘that other thing’ often being the tried and true logic of “When unsure – do nothing”.) These changes proposed by even the early ITIL books – that IT should listen to the Business – that IT should standardize on terminologies and methods to ensure the work we do is repeatable in a consistent way and that we’re all speaking the same language when we talk about what we do, were approached by those who did not wish to see such change, as a call to arms. The resistance, it seems, was born right along with ITIL. The first vestiges of our 4 letter word, were taking shape. And many of them began gathering weapons for the coming resistance war.
Many of those ‘weapons’ were formed innocently enough. Organizations wanted to adopt something that would be a ‘Magic Bullet’ and solve all of their IT (And other) woes. IT managers and directors who had been screaming for years that a consistent, standard approach would save them countless headaches, saw in the ITIL framework, a validation. Often, it was middle management who was pushing the hardest to enact these standards within towering organizations, as those individuals saw the battles lost, and were directly ‘in the trenches’ with their staff, hoping for the Cavalry to come riding in on white horses and save them so they could win the ‘war’.
ITIL became to them, that shining beacon on the hill.
The problem (In the literal sense) was that these efforts to grow ITIL within the early adopter organizations were being led by what amounted to a grassroots effort. While these can be (And are) effective means of raising awareness of an issue – when it comes to making changes at the highest levels of an organization – the place where any lasting change in corporate think and corporate action needs to stem… well, everyone walks on the grass.
So despite acquiring those earlier ITIL certifications (I was personally certified first under ITIL V2 in the mid to late 1990s) and coming out of those sessions fired up to make the needful changes and get the companies we represented, on track for the future, we were all met with a sense of disdain and loathing when upper management needed to endorse these efforts and alter the structure of the organization to match.
It was one thing to spend money and send some folks off to get training in what I’m sure many believed was the latest IT “Fad’, it was quite another to look into the organization itself and make those changes, dictum.
Besides, didn’t changing things cost money?
Where would that money come from?
Whose time would we tap into to make it real?
In those early days, as today, those questions were fired (Not necessarily aimed) like cannonballs in response to meetings meant to instill a sense of inspiration and drive towards making those best practices a reality. And those who now knew the benefits of the processes best (Because they were certified and were now in-house experts) had no easy, quick answers to those questions. There was little in the way of cost/benefit analysis in those heady times. It was a way forward. It wasn’t ‘Rocket Science’, it seemed so simple on paper… why couldn’t we do it?
Usually, there’s more than one reason these great ideas don’t get off the ground initially. And this one was no exception. In addition to the money, and the time, there was the specter of ‘Complexity’.
ITIL is just too complex, was the phrase I’d hear over and over again, as I’d worked to champion these efforts as a grassroots participant. Look at all those books! No one will remember all that!
Never mind the fact that for most organizations, the processes (I’m being generous here in my use of that word) they used to manage their IT infrastructure were already beyond complex, into the realm of the highly complicated and rarely repeatable. What our 4 letter friend ITIL was trying to introduce was a sense of consistency, and actual, repeatable, processes, while the folks rejecting that notion were of the belief they were already ‘just fine’ doing it ‘their way’.
These factors began to erode many of the early efforts to instill organizations stateside with those ITIL best practices, and many of them are, unfortunately, still the hobgoblins of today’s ITIL discussions.
Progress comes – albeit slower than we’d like sometimes. But the early failed implementations by some of the largest and purportedly, brightest, left many wondering how to avoid that whole scenario. And we got into full-blown 4 letter word mode, then.
But time marches on, and since then we’ve seen both ITIL V3 (Circa 2007) and ‘ITIL 2011’ also known in its simplest term of ‘ITIL’, which is basically ITIL V3 set in an updated library. The pendulum is swinging back – the resistance has been worn down by the proven results that ITIL can bring an organization. Cost/benefit analysis has shown that companies who make this investment of time, and money, and who understand that it isn’t done overnight, or in the name of ‘Complexity’ but in the name of overall simplicity, are reaping its benefits. Benefits such as reduced time to resolve business disruptive issues (we call them Incidents), or minimizing the impact of Changes to our environment so they don’t create Incidents (that result in downtime, that costs money and trust) or the ferreting out of underlying root cause reasons for those Incidents to begin with (we call that, Problem Management) thus preventing calls to the Service Desk and saving more money on staff (Not to mention, having happier customers who don’t have to call about the same things over and over again).
These and many other benefits are beginning to take the stigma out of ‘Drinking the Kool-Aid’ that ITIL has been described as feeling like.
Want to realize your own ITIL benefits? I’m proud to say we can help you do that here at Flycast Partners. And we’ll let you use any 4 letter words you’d like since we know they won’t be directed at us.
But one of them won’t be ITIL.
About the Author
Gregory A Gielda is a Sales Engineer for Flycast Partners. Greg has many years of ITIL training and implementation under his belt and is both ITIL V2 Manager/Practitioner Certified, as well as ITIL V3 Certified. Greg lives on a hobby farm in Wisconsin, and in addition to talking about tools and processes, provides Flycast Partners with a series of Webinars on tool agnostic Process (Our ‘Fool Series’) as well as on various ITIL topics.