The scale of ITIL V3

[last updated 29th April 2009]

People are starting to realise how different ITIL v3 ("The Refresh") is from ITIL v2, and how much more extensive the scope and ideas are. There is no doubt that the re-engineering has been extensive. The following diagram makes that clear. A bit like a DOS-based command-line-driven utility being rewritten as a Windows GUI with workflow. The original routines are still in there somewhere but the manuals sure look different! Saying it is an add-on is like saying a Chev Corvette is an add-on to an LS1 V8 motor, or Windows is an add-on to MS-DOS. Sure ITIL2 is still in there somewhere but not so as you'd notice.

Even though OGC are trying to make ITIL3 more integrated than ITIL2, it is a good bet that users will concentrate on the Service Transition and Service Operation books (at least initially), in the same way as we focus on the red and blue books in ITIL2, so that ITIL3 will have its own "lost processes", as I call them. If true, this will serve to mitigate the increase in scale considerably.

Please forgive the fact that in any flat diagram there will be some over-simplifications or even distortions, but the key ideas this diagram tries to impart are:

  • ITIL2 is still there in ITIL3
  • Not only has ITIL3 expanded ITIL2 along the same dimensions that V2 considered (made it "longer" by over a dozen more processes) it has also expanded it in a whole new dimension (made it "wider", changed it from a line to a plane).
  • 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. Others aren't - they are specific to running a lifecycle.

With all of the process-like "elements" listed in the ITIL V3 Qualifications Scheme. See also ITIL V3 Processes and especially The IT Skeptic's Unofficial List of ITIL Version 3 Processes

Latest update: also includes the processes that OGC whitepaper says ITIL does not cover at all (neglecting 17 more COBIT processes only partially addressed by ITIL)

diagram of the difference between ITIL V2 and ITIL V3

This diagram is not copyright - it is placed in the public domain. It would be appreciated if you would retain the attribution to the IT Skeptic and place a link to www.itskeptic.org if you use it.

Sooner or later it is going to dawn on people that they do need to retrain (upgrade), they do possibly need to change the way they do things (service lifecycle), and there are more than twice as many processes to learn and implement.

Personally I think it is a good move - there had to be a quantum step and one assumes it is aligned with the majority of the feedback. People hate change so there will be much howling and gnashing of teeth, but in a few years I think we will view V2 as quaint. It might be quite a few years though, and in the interim I believe we will see two streams of ITIL: the big boys and the top guns doing ITIL version 3, and the lesser mortals and beginners doing ITIL version 2.

in February 2009 ITIL V2 Foundation exams still outnumbered ITIL V3 Foundation.

If you found this post useful, and you are a Facebook user, please Like this blog :

Comments

STILL no mention of project management

I am relieved to see that I hadn't missed something in my fruitless search of the manuals, as this mapping still reinforces that ITIL has deemed the project management process as obsolete and no longer a necessary part of managing change in IT. Thank Goodness; projects (and project managers) are such an annoying pain in the butt anyway, so I say good riddance. As long as we have a RFC and a release plan, what happens in between the two is of no particular concern.

T

Other OGC guidance

ITIL's publisher, the Office of Government Commerce, also publishes PRINCE2 project management guidance which I believe is referenced in both ITIL v2 and v3.

In the area of software engineering, they publish (or did publish) SSADM, which may be moribund - anyone know?

Charles T. Betz
http://www.erp4it.com

Mentions of PMBOK and Prince2 in ITIL V3

I wouldn't rate a namedrop as a reference.

OGC

OGC also have MSP, which is about program (programme) management and M_o_R, which is Risk Management.

we have Release Managers for that

Not just "between". Nor should a major Release Plan be executed with project management - we have Release Managers for that

Note: I have updated my post about the mysterious absense of PM in ITIL V3

ITIL & Prince don't meet

In my view this has always been ITIL's big weakness - it doesn't adequately deal with the interface between project management and service management .. having said this I haven't spent a lot of time on v3 yet, so hopefully this has been improved (how can it not be improved if they are looking more at SM lifecycle?)

better in V3

It is better in V3 but not much

The problem is not the structure but the content

Dear Skeptic
I do agree that V2 is getting old and quaint but I doubt that anybody will be doing V3 for a long time. The reason for my skeptism is that V3 is so badly written. The books are uncoordinated and conflicting.

One customer told me that there is already a clash of ITIL schools at his company. V2 and V3 trained people have different opinions on almost every operational process. For most IT Service managers the key issue is to improve the stability and quality of their services. The war of versions is not going to help.

organisations starting out on ITIL

I am recommending to organisations starting out on ITIL that they focus on the red and blue books of V2, and mix and match some good bits from V3 if they are up to it.

On the other hand, I don't think the V3 books are bad. i think they are quite good, some very good. Sure I'm critical of a number of aspects, but nothing is perfect. As user organisations mature in coming years they will get into V3 and find it useful, especially if forewarned about a few things :-D

I don't warn people off V3 because I think it is defective. I warn them off because it is too ambitious, too advanced. When you've been immersed in ITIL for years or decades, it is very hard to step back and see it as someone sees it who has only just now looked at it for the first time.

The really big bit missing is the meta-lifecycle - the lifecycle of implementing the service lifecycle. until some complementary book provides a path - a phased approach - to getting to V3, then V2 will remain a sensible first step.

useful bits

I admit there are useful parts in V3 and I'm pretty sure there are ideas that I have not yet understood. I have also noticed that subsequent materials have fixed some of the most glaring errrors in the original books.

In my environment ITIL is pretty new, most companies have been using it only a couple of years. I think the danger lies in hopping from V2 to V3 in the middle of V2 implementation. It takes time for people to really understand the concepts of itil and it does not help at all that suddenly there are 25 new processes and the barely familiar processes have changed.

My advise to my customers is: do ITIL V2, get ISO 20000 certified or use the standard as a maturity level goal, look at CobIT if you need more guidance. After you've done that, there will be a ITIL V4 or V3.1.

Can you give some examples of good bits

Dear Skeptic

Can you give some examples of "very good" parts in V3.

Br Aale

a very good body of knowledge

Lots of it! It is a very good body of knowledge. Sure it has its deficiencies, which we have discussed on this blog (somebody has to do it) but in general it is good stuff. in fact, it is easier to list the bits that are not good.

Should you start Your ITIL Journey with the CSI Book?

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?

Statistical data analysis

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

ITIL v2 vs v3

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

Broadly speaking

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

Interesting you should say

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

ICTIM

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 :)

I disagree, ITIL was two books

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

There's no light to see when

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.

It may have become common sense

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.

ITIL is common sense only with 20/20 hindsight

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...

I think people with common

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

Common sense is not so common

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.

Old trouble tickets

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

If the service hasn't been

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.

fair practice

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.

Do you really think it's

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.

judgement call

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.

True

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.

Consult the user/customer.

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.

ITIL should be more than 2 books

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.

Syndicate content