The IT Skeptic - Comments for "The scale of ITIL V3"

Statistical data analysis

aroos — Tue, 18 Aug 2009 08:37:10 +0000

A long time ago I was a statistician and I used the CSI 7 step model as a model for statisticical data analysis. When I became a consultant I realized that the steps 1-6 are usually simple and easy but the step 7 is far more important and difficult.

A beautiful analysis and a great report is not enough. A typical problem is that if one uses an advanced statistical methodology, no decision maker understands it and is not willing to do anything about it. The goal of CSI should be to fix problems, not just show the symptoms.

My Improvent model would be something like this
1 Use CSI 7-step model to regognize symtoms
2 Find root causes by talking to people
3 Help people to find solutions to root causes
4 Support change to implement the solutions
5 Check results and go back to 4
6 If succesful, go back to 1

Aale

Should you start Your ITIL Journey with the CSI Book?

ianclayton — Sun, 16 Aug 2009 19:09:16 +0000

Skep - late to this chat but I felt I wanted to chip in a thought. In theory - an ITIL centric service management initiative should start with seeking out issues and tabling them as improvements, building a compelling case for an investment of scarce resources that many view as a diversion.

If we limit our reference materials to just ITIL V3 as a test of its applicability, that would take me to the Continual Service Improvement (CSI) book. In theory, the CSI guidance should help us define the reasons why IT Service Management and ITIL is good for us and our organization.

Again, in theory, the replacement guidance, dare I say best practices, are described in other books in such as way as to make for easy interpretation and application to the issues identified. Third party advice is important but I would suggest just as an accelerator, and to help reduce the risks and costs involved.

Unfortunately, some of the methods you might need (such as defining a problem and its impact) are elsewhere - check Service Operations, and incomplete (it does not actually explain how to do either but...). How to use and apply some of the methods presented in CSI are described better elsewhere (you will likely rely on Google here in finding good sources), and how to analyze the organization, identify stakeholders and their interests, missing completely.

Any attempt to implement the entire ITIL Service Lifecycle is at best foolish given the scope of control and number of pre-requisite artifacts and resource commitment. Starting with a particular 'process' area seems sensible but again fraught with risk - for example, what if we were running a hospital and decided to completely re-engineer one key operational aspect, such as appointment scheduling - in flight - without having suitably defined why, and the impact of such a radical change?

Has anyone out there actually started with defining the issues service management and ITIL will address, and in taking this approach attempted to use the CSI book as the tip of the spear?

ITIL should be more than 2 books

Visitor — Sun, 16 Aug 2009 09:16:04 +0000

You can look at ITIL from the point of view of success, but in general I would separate impact success evaluation of v2 vs v3 in terms of target audience. While techs may get more out of ITILv2 core, IT managers should be considered as a separate target audience and the success of ITIL for both v2 and v3 should be evaluated for them separately.

ITILv2 should be more than just the core books for any IT manager worth their salt. If not, I would seriously consider canning people who have no motivation to develop themselves and practices in their organization in more fronts than just ITILv2 core processes.

In terms of ITILv2 I think it remains a sad sight that technical experts in ICT management are required to maintain their certificates besides cramming down "Foundations" and company processes but many IT managers I've bumped into
- fail to educate themselves even as much to read through the whole ITILv2 bookpile (I mean its only a couple of thousand pages and frankly its pretty self evident. Material expected for a e.g. Cisco professional and expert level certicate tops that any day)
- start to bicker about something as useless as v2 vs v3

Its even sadder that so many IT managers have failed to read up on basics of service management and service marketing, leading of change or business-IT alignment and valuation. Or that they start to expect business to learn ITIL to communicate with them. Its like managers expect everything to be handed on a plate, without effort by oneself. This to me shows especially with v3, for which I'm constantly amazed how the IT managers view it as providing lots of "new information" (and how some of the official books fail on referencing proper content originators). In addition to being a rehash of v2, its also a rehash of information that has been out there way before v2.

Having been living through the yearly layouts in all companies I've worked for during last nine years, its quite sickening to see that ops guys byte the bullet in "efforts to improve cost-effectiveness" but incompetent managers just continue with their yearly "job rotation schemes", failing to drive long-lasting continual improvement or capability to drive change through standardization, automation, self-services and smart offshoring.

Granted, reading stuff doesn't guarantee anything and nothing tops experience. But to me it talks volumes if people start to complain that "there is so much to learn" or "this is too difficult". Who said life would be easy.

Consult the user/customer.

riCh chestMat — Thu, 30 Jul 2009 15:44:22 +0000

Consult the user/customer. Confirm workaround (includes don't touch whatever isn't working!). Raise problem (or known error if you know the cause). If the Customer won't provide the budget to fix then close the problem. You are left with a known error in your knowledgebase and no open 'tickets'. The servicedesk can handle repeat incidents. Your design people can see what improvements are possible. The business has accepted the risk of the widget performing the way it does.

Perhaps this is applying the Orange Juice test?

But you cannot prune your incidents without consulting the Customer. Those incidents belong to them not you.

True

supportthought — Thu, 30 Jul 2009 15:13:08 +0000

In practice long term fixes for low (business) priority incidents become stuck in the development backlog and may never be fixed, I have found that these can sit as low priority problems, with an open incident but that dosen't really offer any value:

The user is not too happy but understands the prioratisation of the fix.
The Problem manager spends valuable time following up on a fix that has already been deemed low priority.
The Development org (in this example) has to field questions and provide updates on an incident/problem that has already been catagorized as low priority, again spending valuable time.

I am not sure what ITIL would say about this, but taking a value based view I found that closing the incident, parking the problem and informing the user was a pracitcal solution.

The reality is that there was better things for all of us to be doing than spinning our wheels on the small stuff.

judgement call

skeptic — Wed, 29 Jul 2009 21:37:00 +0000

Ideally yes. I agree with everything you say as good practice. No it is not good practice to close them - I said that. But Reality says service desks are usually undermanned. And service desk operators keep incidents open with the best intentions - they have no visibility of decisions weeks or months later by Tech Support that the problem is too low priority to be fixed. I believe these trivial incidents accrete in even a moderately well-run service desk. At some point there comes a judgement call on whether they are worth keeping alive. Business pragmatics trumps ideal theory.

Do you really think it's

riCh chestMat — Wed, 29 Jul 2009 11:06:42 +0000

Do you really think it's good practice to close down old incidents without consultation because you failed to manage them properly in the first place? If you think incidents are trivial then put that in your SLA and get your customer to pre-agree that IT can decide which incidents they want to fix. why not? Help desks have been cherry picking quick fixes for years. If the user thought the workaround 'fixed it' then close the incident then and not months later. If you kept the incident open because the user wanted the underlying issue fixed then you are talking about problem management anyway.

The shame and confusion of calling users about stuff they have given up on should not justify fixing the stats instead of fixing the issues.

fair practice

skeptic — Wed, 29 Jul 2009 10:07:24 +0000

The reality is we end up with masses of trivial incidents where as far as the user is concerned the workaround "fixed" it, then the incident hangs around waiting for a problem resolution that never comes. Users are puzzled when called back months later to ask them if it's Ok to close it when we clean up the incident queues, and sometimes can't recall the incident. We can sound more incompetent than thorough. I think in all but the highest maturity shops it is fair practice (there's a new term!! ™!™!) to close ancient and trivial incidents without referring to the user - not pretty just pragmatic.

If the service hasn't been

riCh chestMat — Wed, 29 Jul 2009 07:46:53 +0000

If the service hasn't been restored then technically you can't close an incident. Raising a problem or known error doesn't mean you can close the incident.
Prgamatically speaking though you can do that if the users and customer are happy for you to close their incident. They will need a workaround of some kind though. Of course workaround can also - pragmatically speaking again - mean users avoiding a function or doing it manually. For something like an application with a release cycle the business might accept a function misbehaving until the next release - in which case Problem Management can be more appropriate than Incident.

Old trouble tickets

aroos — Wed, 29 Jul 2009 06:38:19 +0000

A high percentage of Service Desks that I have visited have had a common problem. They have a large number of very old incidents in their ticketing system. These old tickets make their statistics worthless and they do not know what to do with the tickets.

A closer look shows that these are usually Known Errors that are not going to be fixed and sometimes Problems which are waiting for resources.

Following ITIL (V2) they can set up separate queues for Problems and Errors and clear their Incident Management system.

Btw. V3 is missing an important cog in the machinery as it lost Error Control. All environments have their list of Known Errors waiting to be fixed.

Aale

Common sense is not so common

skeptic — Tue, 28 Jul 2009 20:40:49 +0000

In my IT experience "Common sense is not so common" (attrib. to Voltaire but actually not)

I'm beginning to suspect that what we call common sense is in fact learned good practice, and the sites with the most "common sense" are in fact the ones that have had the most fresh ideas, via consultants and staff churn, and the ones with the least "common sense" are the ones that have remained closed little IT Romanias of impoverished long-serving staff inventing their own wheels... but I don't have enough data to be confident of it.

I think people with common

riCh chestMat — Tue, 28 Jul 2009 20:31:10 +0000

I think people with common sense have been doing problem management for years. They just didn't know it had a name.

ITIL is common sense only with 20/20 hindsight

skeptic — Tue, 28 Jul 2009 18:49:39 +0000

I think ITIL is common sense only with 20/20 hindsight.

The distinction between Incident and Problem is only obvious after you hear it. Apparently for some people it is the same with the need for a Problem Management process, for a consolidated event console, for mapping CIs to services, for measuring service levels at the user, for OLAs...

It may have become common sense

aroos — Tue, 28 Jul 2009 11:04:36 +0000

I actually guessed that someone would point this out. The concepts have become common knowledge for a lot of people. But they have not been that always and can still be new for some people.

There's no light to see when

riCh chestMat — Tue, 28 Jul 2009 09:06:10 +0000

There's no light to see when you are talking about common sense. The feeling I got and one that is shared after interviewing colleagues who later take a v2 or a v3 foundation is that we knew this stuff already but now we have a common language and framework to organise around.

I'm unsure how we could call ourselves professionals if we only read the minimum. Then we'd just be MCP/MCSE after talking crams and twenty practice exams.

I disagree, ITIL was two books

aroos — Tue, 28 Jul 2009 07:21:18 +0000

ITIL is the core red and blue books, 10 processess and a function. That was the core which caught the attention and made ITIL a success story. OGC tried to broaden the scope with those additional books which were written well over ten years later and were dismal flops in sales. There was no training and certification and only a few read the books.

The key ideas in ITIL were the Service Desk, incident, problem and change management processes. Quite important was the separation of incident, service request, problem and error. The rest of the two V2 books is useful but without the core it would not have been the hit it was.

I have never worked in an IT department, my IT career was in customer service or sales of IT services, that might be the reason why I cannot see the service view as a great step forward. The process view is useful as helps techies to see the bigger picture. I sincerely doubt if anyone sees the light after a V3 Foundation as a lot of people have seen after a V2 Foundation course.

Aale

ICTIM

skeptic — Thu, 23 Jul 2009 11:49:54 +0000

On a first glance ITIL V2's ICT Infrastructure Management certainly does have a lot of it in there. The lifecycle (Appendix K) is hardly front of house, of course, and the flowcharts K2 and K3 are truly ugly, but it certainly appears there is little new under the sun :)

Interesting you should say

Miles N — Thu, 23 Jul 2009 11:35:18 +0000

Interesting you should say the "lost processes", most of what you mentioned was in ICT Infrastructure Management. Which described the service lifecycle. After doing Service Manager, I remember doing ITIL process design a number of years ago and processes were described as starting as if they came from thin air, as in statements such as "Ëvent occurs". Then studying ICTIM gave it all a place in a time scale.

What V3 basically did was put the two back together. Let everyone back in on the secret....

And for those of us with ICTIM certificates, OGC was generous enough recently to grant us points for upgrade to V3 - a year too late! Shrugs!

Miles
ICTIM Bigot

Broadly speaking

skeptic — Wed, 22 Jul 2009 23:02:57 +0000

Broadly speaking Ajay what you say is true. As i said above in the post

There was actually much more to ITIL2 than the ten processes in the red and blue books, but often you wouldn't know it to hear folk talk. Some of the processes making ITIL3 "longer" are these "lost processes" being brought back into the core.

But only broadly. I only know three books from V2 at all well so I'm prepared to be corrected here but I belive portfolio, event, request, knowledge, evaluation, testing (of service) and a number of other processes are not in V2, certainlky not explicitly and I think not really at all

Absolutely I agree "V3 is well packaged and shown with a service view, but V2 was shown as process view" which is why I tried to sort out the processes

ITIL v2 vs v3

Ajay — Wed, 22 Jul 2009 12:52:34 +0000

I agree that there are a lot of new processes being added into V3 like supplier management, evalation, access management etc. In my view there isn't much difference between V2 vs V3.

If we recollect the ITIL v2 framework, there are books like Service Support. Service Delivery, Planning to implement ITIL/ITSM, Security Management, Application Management, The business perspective, ICT Infrastructure Management. Now, if we look at ITIL v3, there are 5 books namely Service Strategy, Service Design, Service Transition, Service Operations, CSI.

Now, if we had read The business perspective book from V2 framework, then it is mostly similar to Service Strategy book of V3 framework. As we know Service Support processes from V2 is part of Service Operations & Transition in V3 and Service Delivery from V2 is part of Service Design and so on...

In a nut shell, V3 is well packaged and shown with a service view, but V2 was shown as process view.

Hope my views were helpful