Home » ITIL » Beware the Pragmatic ITIL® Man

Beware the Pragmatic ITIL® Man

In any organization, there are bound to be legacy systems, and they present a management challenge unlike any other found in the IT arena. As IT projects progress through their lifecycle, there comes a point when upgrades are no-longer viable and new technology needs to be introduced.

In an ITIL® aware environment, the tipping point for replacement is one that is identified well in advance so that the orderly replacement of the said system is then arranged.  Either purchasing a turnkey solution or developing the replacement from scratch, ITIL provides the mechanism for that orderly transfer.  The full Service Lifecycle, from Service Design through Service Transition into Service Operation, will see the easy disabling of legacy systems with a smooth introduction of new services.  At least that’s what the panel-set used in an ITIL training course alludes to.

The reality can sometimes be somewhat different.  The main strength of ITIL is its pragmatism.  At every stage, the practitioner is encouraged to remember that ITIL is not intended to be rigidly applied.  IT professionals are reminded that they must make the process work for the business by applying its principles with flexibility.  ITIL must be fit for purpose.  It must meet the business’s needs, and therein lies the conundrum.

In my own experience, “doing ITIL” has often failed to deliver everything that was intended.  Agreed I worked in some environments, retail and media come to mind, where completing 60% of a project’s deliverables was thought to be a success.  Even in banking, a delivery rate of 80% of the original targets was similarly regarded as success.  The reality is that once a project has started, it will always be at the mercy of changing priorities, no matter how carefully you follow your Prince 2 (or any other methodologies), some original problems will still remain long after the project is completed.  Some would say that this flexibility, this preparedness to adapt and change is the paradox that lies at the heart of ITIL.

Take one specific organization, media, TV, youth music – you work it out…..

Over a period of years, this particular organization had grown, slowly at first and then over a 5-10 year period at meteoric rates.  Infrastructure had struggled to keep up with demand, and the upshot was that the organization was delivering email to its staff using three mail platforms.

The big issue was that the organization took pride in saying “we do ITIL” because they had run a project to define and implement ITIL.  The problem was that this project suffered, like all other projects, from scope creep.  Budgets change, and that means scope changes follow inevitably.  Sure enough, the project was re-classified, and instead of doing ITIL across the board, some systems were identified as not being important enough to be ITIL’d.   The thinking said if it’s a legacy system, it can’t be that important so let’s leave it alone.  Let’s not capture the critical data, the configuration details, the operating procedures and anything else to ensure we can continue to operate this system.

One email system was used for a small team (no more than ten individuals), and because there were not many people using the system, it dropped off the ITIL horizon and remained outside the scope of the project to document and record.  Now, like all good legacy systems, this email system just chugged along, day in and day out, talk about reliable!  Over time, the skills and knowledge associated with this type of communicating were lost.

For various reasons (something to do with the mail-stack they told me afterwards), mail items would be delivered to the wrong address.  Not just within the group of ten.  Any mail item going anywhere near this system from elsewhere in the organization and from the outside world ran the intermittent risk of being delivered to the wrong address.

Needless to say, with no knowledge or documentation to go on, email services had to be suspended.  All users of this product had their mail service suspended because you simply couldn’t run the risk of emails going astray, whilst a solution was being sought.  Ironically, whilst it was a small group without service, there was a level of pressure to restore service that came from a much wider community within the business.  It was far more than this small group of 10 that were impacted by the service outage.

This had an impact across the entire organization as email was widely used for this small group, like any other group, to stay in touch. Remember not to throw the baby out with the bathwater though.  So ITIL, the saviour of the Service Lifecycle had provided us with a structured process to manage how systems were handled effectively throughout the entire lifecycle but, ironically, has also provided the approach to ensure that our original baseline, against which the Service Lifecycle was measured, was flawed.  Perhaps some more effective risk assessment would have made handling a disaster easier.

Tags: , , , ,

About this author:

Angel Prusinowski

Angel is a leading ITIL® instructor at Ashford Global IT.

Leave a Reply

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.