Today we have an insight into applying ITIL® to a real business situation from Damovo's ITIL Expert Andy Prentice. Andy discusses the challenges faced when trying to use ITIL as a set of rules instead of a framework. Come down to Brighton for your ITIL Foundation course to begin your ITIL Training.

After I had achieved my ITIL Expert certificate, I decided to join a number of forums/groups on LinkedIn to discuss my favourite subject – ITIL – with like-minded individuals, much to the amusement to my colleagues who see the exercise as me overly-indulging in ‘geekdom’.

Admittedly, there have been a few discussion threads and responses that have made me chuckle and sit back in shock in equal measures. But there has been one debate in particular that has divided opinion and has reminded me of the importance of remembering that ITIL is a framework to work towards and not a set of hard-and-fast rules to live or die by.

The question posed was “Should a Password Reset be treated as an Incident or a Service Request or a Change Request?”

My initial reaction to the question was simple; it’s a service request.

Why? Because when I request my password to be reset (typically on internet websites that I rarely use – or a service which required a password strength beyond my ‘usual’) it is because I am the reason it needs resetting – i.e. I have forgotten it and therefore I am my own root cause to this break in service. In fact, I would be embarrassed to call it a break in service so I’ll just ‘request’ that the Service Desk kindly throw me a bone…

It would have been remiss of me not to consider the logic behind the other options though.

Change Request?

Well, yes, my Service Request is a pre-approved change request so I can see the logic in suggesting this as an option. But, as a pre-approved change request it does not need to follow the formal Change Management process, seeking CAB approval, having the risk and impact evaluated and mitigated, with a plan for implementation – all that just because I was silly enough to forget a password? No thanks…

Incident?

But the system isn’t broken… the Access Management process isn’t experiencing a break in service; I am experiencing a break in service and there is no contract between myself and my IT department to include such issues under a scope of works!

So there I was thinking that the ‘like-minded individuals’ would all echo my sentiments almost word for word. 108 comments (and counting) later, I was very wrong.

Some individuals agreed with the Service Request approach and very quickly picked out the classic ‘it depends’ position-on-the-fence which ITIL likes to perch itself firmly but comfortably - and there were plenty of people pointing out that self-service was a key approach to dealing with such requests, but what really surprised me were the number of people who were voting in favour of it being an Incident.

I have to say, some of them had some compelling cases too; when I read the question, my first thought was ‘Password Reset = my log-in details’ and therefore I was the root cause to any issue. But many people were pointing out that applications can go wrong and cause passwords to be ‘reset’ – or even human error from a different angle whereby an administrator somewhere on the network has done something wrong and caused passwords to change (perhaps even changing the wrong password) – in such an occurrence I would be logging an incident…!

This last scenario reminded me of a major incident I happened to find myself in the middle of during the Queen’s Jubilee celebrations in 2012; on the day of the barge parade on the Thames (when it was very wet and HRH looked as impressed as an 80-something does when asked to stand in the rain on a boat for several hours) and I was a Service Manager for the public transport provider in our nation’s capital.

Imagine the scene; I was already on high alert with my customer being under some major media attention! It just so happened I was also the on-call Manager for my company.

Whilst there were thousands of people in London, the last thing I wanted was for my customer to experience some sort of major incident – even less so with any of the services I was accountable for! And then the phone rang… my Service Desk filled me in on an incident that had been logged with them whereby an analytics function in one of our applications was unavailable for the end users – it wasn’t stopping them from completing their function, but it was a nuisance.

This happened to be for a mission critical department and therefore the agreed Service Levels in place were a suitable reflection. The big issue however was not the malfunctioning application, but moreover that we were unable to log onto the server to investigate the issue and affect a relevant repair. Immediately my thoughts turned to human error – on our side – that someone has forgotten the log-in credentials; not the case. Perhaps they were looking at old credentials and that I could sort the issue by confirming the current credentials; again, this was not the answer. The only possible answer was that someone had changed the password… but who?

Being the eternal cynic, I start blaming my own engineers; my fingers had been burned in the past so it must have been us, right?  Meanwhile my customer contact has seen the major incident alert go out and he wants answers; what do we mean we can’t log on to our own server? Why not? Who has been changing passwords? Was it done under Change Management? Why not? Why why why…!

We came up a blank – we have no record of anyone touching the servers in recent weeks, so unless it was done at network level… That’s it! Whilst the server is our asset, it was located on the customer network and subject to the customer’s domain and group policy – someone had rolled out a Change to the group policy that morning which had a knock-on effect:

It changed the username of our administrator account.

The analytics part of our application was tied to our administrator account; as that no longer existed, the application was unable to meet its own access management criteria.

So here I had a precise, real-life example of when a Password Reset was indeed an incident.

Reflecting on this, I reminded myself precisely why to remember the ‘it depends’ part of what my training has been teaching me…

As an aside, another point being mentioned in the LinkedIn debate was that people often raise Password Reset requests as Incidents because they attract a quicker resolution SLA than Service Requests – “hours instead of days” was the description. This point profoundly reverberated with me; my aforementioned customer would raise Incidents for items that were actually Problems or Service Requests purely because they knew that the Incident would be responded to (and, if the Service Desk did not pick up on the incorrect classification, resolved) quicker than following the proper process.

To me, just because it's a Service Request does not mean it should have a lesser resolution time than an Incident; all ticket types should have a relevant SLA agreed between IT and the Business to ensure that it is resolved within appropriate timescales to avoid a potentially large impact.

This debate ended for me in one thing; a deep sense of satisfaction that internally we have got it right – when we raise Password Reset request, as Service Requests, we do so safe in the knowledge that our SLA has been set appropriately so that we don’t have to wait ‘days’ or even ‘hours’ (plural) before our expectations are met. Good Service Design at work…!