Say it ain't so!! ITIL V3 Incident and Problem processes do not determine the affected service

This BOKKE (body of knowledge known error) has been posted for a day or so, hundreds of views. I was sure someone would say "no you idiot, service impact analysis is right here" but not one. It seems to be true.

ITIL V2 did suffer from something of an internal focus despite all the lip service paid to service, so to speak (see for example my article Service Catalogue is the Center of the ITSM Universe ). But ITIL V3 was supposed to bring the service to the centre. And yet we can log, categorise, prioritise, track, resolve and close an incident (or a problem) and never explicitly do a service impact analysis? The Service operation book even describes the attributes of an incident record (4.2.7) and none of them are the affected service(s).

To me this is a bit like the Road Code defining the give-way rules but never mentioning that what you give way to is other vehicles. Or perhaps it is more like the Road Code defining everything but the fact that you need to give way. The whole purpose for Incident Management's existence is to restore the service. How can you do that if you don't know what service is to be restored? How do you know which SLA(s) to apply? And how can you know you've restored it?

The ironic bit is that ITIL V2 Service Support says explicitly (5.6.2) that classification of an incident "is used to specify the service with which the Incident is related". Those words are gone from ITIL V3. In fact the whole activity of Classification has been replaced with Categorisation, a much more specific and geeky low-level activity.

While I'm asking inconvenient questions: where did incident matching go? Apart from one throw-away mention in the CSI book, apparently we don't do that any more either.

I'm left bemused by all this. It is not as if this is some of the esoteric new blue-sky stuff like SKMS - this is ITIL's heartland core competency. If we can't get Incident Management right... Dozens of people reviewed the Service Operation book. Nobody noticed that there is no step in the documented processes to work out which services are impacted by incidents and problems? I can only conclude that everyone involved were so deep into ITIL they lost sight of the basics that ITIL is supposed to be documenting.

The result is that nobody using the ITIL V3 books could implement an effective Incident Management process. Despite all my criticsim, I've supported ITIL V3 as fundamentally good sound useful guidance - this big hole shakes that faith.


Maybe not the language, but the intent

While the specific language about incident matching isn't in the Incident Management section in the Service Operation book (it is in Problem Management), I believe the intent is there in Section Incident Categorization. It talks about the granularity of categories, testing the categories to make sure their valid, etc. Combine that with the references to Incident Identification related to known errors, and the discussion in Investigation and Diagnosis. The behaviors regarding Incident Matching are there, just not the language.

Frankly, I had problems with the V2 ordering and wording. I don't know how you can match against problems and known errors without first doing some investigation and diagnosis. That part bothered me in V2, V3 made more sense.

Proper categorization combined with the other sections mentioned would appear to arrive at the same result as incident matching without some of the challenges I had with the way V2 expressed things.

Maybe it's me. :-)


That's not guidance

Charles and David

I don't believe activities as fundamental as service impact analysis or incident matching should be implicit or inferred. let's drop Change Management - we'll just make passing mention that there should be an approval process for Configuration Management CI updates - that's good enough.

Service isn't just another CI.

Come on! they missed them out! They are only there for people who already know what they are and can read the prints and spoor to recognise them. That's not guidance!

These are key essential activities and people need to be told to do them.

Don't need "incident matching" phrase

I guess I wasn't clear in my post. I do not believe the specific wording (in this case the phrase "incident matching") is that's important compared to the result. Tested categorization gets to the same end result and that is what the volume suggests.

As I said, strictly from a logical perspective, it's impossible to "match" anything without some investigation and diagnosis. That's one of the problems I had with V2. The logical flow was, in some cases, more about process than result. I found it somewhat akin to writing software tests without complete knowledge of the specific requirement under test. V3 does a better job in this area -- even without the specific 2 words.


Incident matching

There is no right point in the process for Incident matching. It is an activity that goes on from the moment an incident is opened until the moment the problem is closed. At any time someone might twig that there is a pattern here. if there is a formalisation of that activity then people will remember to do it, it will get recorded and acted upon. In addition of course it also includes formal analysis of categories and trending, but for me the key is to get the phrase "incident matching" in people's heads and train them always to be looking for that lurking pattern

We agree, now, but... original context was compared to V2

I agree there is no right point for incident matching in the broader context express in your note. However, the original context was a V2 to V3 comparison. It was within that scope that I was commenting and I'll stick with that (strictly in the V2 to V3 comparison -- V2 explicitly talks about known errors and problems). It is precisely because it's done throughout the process (or at least later) that I was uncomfortable with the V2 explanation.

I'm not concerned about the phrase... in fact, I'd suggest that since it is an ongoing process as more is learned about the incident, that "incident matching" is actully the wrong term since it suggests a shorter observation point, and a decision of once and done.


We need to define 'incident matching' better...

Skep, I am not sure I can agree with your hypothesis that matching can occur throughout the incident lifecycle - yet. In a book I'm finishing (about to be published September) I describe the 'Match' activity as a sub-activity within the Service Incident Management workflow. The description offered places Match as something performed most commonly within the DIAGNOSE major activity.

The purpose of the MATCH sub-activity is to determine whether a similar event/incident has occurred previously, or is occurring simultaneously. A MATCH of a previous incident can help by linking us to a description of what happened before and how we addressed it - perhaps the result is a scheduled change that has yet to be implemented. If we find similar events currently active it will help us with scoping the true impact.

In each case MATCH should help us expedite a resolution. I suspect that what we are all missing is a good description of MATCH, its objective, and outputs. I'm reviewing my writing as a result of this thread but still feel that MATCH effectively ends when a relevant match is found.

This still possibly leaves the MATCH concept open for resolution however. There is no doubt it can be invoked, with a different purpose but I suspect information on previous resolutions would be found on an original MATCH activity....

everyone's job

I think you are overrestricting an instinctive human activity to lock it on one place. Absolutely the prime place for matching to happen is during incident diagnosis. But it is not the only place.

A call-taker notices that is the third call like that in three minutes. isn't that matching?

A pattern gets missed during diagnosis but Level 1 support spot it when working on resolving three identical incidents. Isn't that matching?

It gets all the way through to problem management before anyone notices that these three problems are the same. Isn't that matching?

The service delivery manager looks at monthly reports and gets a hunch. Isn't that matching?

A customer or user looking from the outside can see a pattern that is missed by those deep in the woods. Isn't that matching?

Incident matching goes on all the time and should go on all the time by everyone. On a railroad every rail worker, whether track gang, depot staff, brakeman or driver, they all look up and watch a whole train roll past them. This isn't lazy sightseeing - it is an essential check for trailing equipment, loose loads, open doors, hot bearings, and joyriders. They wave (or nowadays radio) the all-clear to the conductor at the back. It is everyone's job.

Incident matching is an important activity. It should be explicitly described not vaguely alluded to. it should be drilled into everyone in IT operations. There should be documented process for reporting suspected patterns and acting on them.

Too much 'in ITIL' is open to inference

Skep, David

You have hit one of my nerves... too much of what is claimed to be in ITIL, is in fact in the mind of the reader (consultant/vendor/practitioner), not specifically in ITIL, and thereby assumed to be inferred. The fact that the ITIL V2 Service Support book was done and dusted way before the Service Delivery book was outed - is a clue and in part an excuse for the linkages between CIs, services and more importantly what was called a 'vital business function (see Availability Management)', but not for missing this key association completely in V3.

The need to interpret and infer smacks of lawyers and the law, with consultants and vendors playing the former role, and ITIL books the law. The need for courts of appeal and the Supreme Court (US) is clear. Many folks just want clear guidance that works. Ideas or concepts that don't work (based upon the premise of low overhead, support of a continuous improvement strategy and reducing costs), should be weeded out by someone... the 'laws' are change.

ITIL has no such structure except for the qualification scheme. Conferences do not debate what is good, bad and ugly - although for years I have pushed for them to do so. We have to assume that an ITIL Expert is indeed expert in what is in ITIL, I feel it should also include what is NOT in ITIL... by judiciously detailing what is. I know of more than once occasion where someone applying for a job based upon their ITIL credentials, explaining at length aspects of ITIL and how it should be 'implemented' that were simply not in the book.

Way back I recall the itSMF user group rightly shouting out to us all something to the effect that ITIL "should be adopted and adapted". Hear hear! Adopted as a key element of an overall service management initiative designed to satisfy customers by providing the right service based functionality, at an acceptable level of quality and cost. Adapted, meaning common sense or other better practices are considered and blended in with any ITIL suggestions to arrive at a pragmatic solution that remains open to continuous improvement - using good ideas from any source.

Service Management is not ITIL, it is in fact a universally applicable approach that exists today in the business realm as a subset of Product Management. IT Service Management (ITSM) is a creation of the IT department, generally without any reference to the greater service management universe. Driven largely by the ITIL framework it remains a superset, with ITIL a contributor, and a valuable one.

Where are the (real) conferences on ITSM?

Descriptive vs proscriptive

Given the specific intent that the ITIL be descriptive framework, I don't have a problem with a need to interpret. However, as I tried to express in the clarification to my post, in this case I prefer the organization and guidance in the V3 SO volume for the reasons cited in that post.

We're in complete agreement about "adopt and adapt" -- that is the very nature of a descriptive framework. It has to be adapted, and that requires some interpretation. I also don't believe that every organization needs every single process described precisely they way it is in the V3 core books. From that perspective, they represent more of an ideal than a requirement.

What organizations should not do with V3 is cherry pick one or two processes and ignore lifecycle consequences/connections and then claim to be "doing ITIL."


Experiences applying ITIL should come back into the main BOK

I've been using ITIL as reference framework for the past 10+ years and have learned a lot about IT Service Management and transforming IT organizations into a more effective business focused service provider. I've been involved in the creation of the ITIL v3 books. Indirect through the involvement of my colleague in the Advisory Board and direct as a reviewer. My experience is that there are a lot of people who have read (or believe they have read) the Service Support and Service Delivery books who think they understand Service Management. From my perspective they tend to approach ITIL from a very mechanic, fragmented and incomplete view on the IT Business. They seem to believe it is all about processes (the how) instead of services and value (the what). When we tried to help updating the ITIL material we've come across a lot of these people and they found it very difficult to understand our experiences with a more integrated and holistic business view on IT service management. Thus, Incident and Problem Management will probably be correct from their mechanical ITIL view but are missing the point (it is about restoring the service to the business and not about solving incidents or problems). And it is this limited view which has allowed an ongoing discussion as well on the differences between infrastructure and application incidents and problems. A discussion which is irrelevant to the business.

In the ITIL3 books I've found traces of an integrated view on the IT Service Management business. Some of the so-called principles in the ITIL books are a good start to use as basic requirements for a integrated framework or architecture of IT Service Management. Based on these principles consultants and users of Service Management should be able to construct how they want to deliver IT services to the business. Best, good, whatever, practices are then examples of how these principles can be applied. In the Netherlands we distinguish between the print and the spirit of the law. A lot of the ITIL discussions are about the print and not about the spirit. Unfortunate it is very Anglo-American to discuss print and the loopholes in the law, that is one of the reasons they are so many lawyers I assume. I rather discuss the spirit and intentions of the law. Maybe a more Dutch approach to ITIL and Service Management might be a good thing in this case.

Anyway, it should be the experience of the user community challenged by driven evangelist as Jan, Ian and Skep which should lead to a better framework over time. And thus I'm wondering when the discussion will be on what a good Service Management framework should be all about.

Paul Leenards

"ITSM is dead, long live Service Management"?


As many already know, I'm a strong advocate of service management as defined and used by Product Management for years. It is largely well defined in these non-IT circles and actually quite different from the descriptions we read about regarding IT Service Management (ITSM). In recent months I have detected a movement "out there" amongst the ITSM and especially the ITIL supporters to drop the IT on ITSM and move ahead with the remaining words, without respecting what is there already, and what has gone before. Deja, deja vu. In doing so there is a risk of not leveraging a wealth of lessons learned and 'best practices', and reinventing many, many wheels. Why?

Increasingly, traditional ITIL centric blogs and organizations are speaking of 'Service Management'. Does that mean we have given up on implementing ITSM already? Perhaps its too difficult. Perhaps its too "IT".

A few years back IBM and analysts (amongst others) resurrected terms such as 'Business Service Management' and 'Information as a Service', in attempts to better describe why the corporation invests in IT, and to describe IT's role and what the customer communities expect of IT. Vendor led definitions of concepts and frameworks are for one legitimate reason - to differentiate their offerings from others.

ITSM seems to have generally avoided this fate and remains in the professional domain. However, it has for many years lacked both a crisp definition and 'body of knowledge'. ITSM has failed to evolve in a mature fashion and frankly suffers from multiple personalities. It is defined, bent, and stretched to fit any vendor, consultant, trainer, or practitioner need.

My view is that ITSM is a transformation method for an IT organization that wishes, or is required to operate as a service provider organization. ITSM is also a systematic method for managing the provision of information services (remember that old name we once had!), from a known quality and cost perspective. If we can as a profession agree on a common definition we may be able to better assess, judge and value the contributions of those asking us to buy their wares.

Frameworks or standards that are represented as containing guidance, best practices, or similar, should position themselves against the commonly agreed term ITSM... As I indicated preferably one created and managed by the professional community it represents...?

Back to my closing comment on the previous blog entry - where is the common definition of ITSM? How can professionals 'own' this definition? Where are the forums and conferences that help evolve and mature ITSM as an open industry set of methods?

ITSM is a transformation method


Do you see USMBOK as
(a) "the common definition of ITSM" or
(b) "service management as defined and used by Product Management...respecting what is there already"
or both?

BTW "ITSM is a transformation method for an IT organization that wishes, or is required to operate as a service provider organization" is about the best defintiion of ITSM I can recall seeing

The purpose of the USMBOK...

Hhmm... No I do not see the USMBOK as the common definition of ITSM. That task must be one addressed by the professionals that live and work in that community practice. Nor do I feel it is a common definition for the existing Product Management realm. I wrote the USMBOK specifically to respect and span both, offering perhaps the first 'holistic' and universally applicable view.

There is no doubt that concepts and methods exist within what we know today as ITSM that would benefit the non-IT service management community. That said, I feel we in IT have far much more to learn from the non-IT realm.

I also feel that ITSM is uniquely IT's view of how it will provide information system based services. The USMBOK does not specifically target the IT community - it is designed to speak service management and act as a body of knowledge for any professional community wishing to be a customer sensitive service provider organization (as per my stunted definition of ITSM).

The challenge of any advice or guidance centered framework is to offer a viable goal or destination that translates to real benefit, and a pragmatic transformation method by which to begin and sustain the journey to that goal.

Although its a 'proprietary framework', the USMBOK is designed to be open and inclusive and to allow leveraging and recognition of any useful information source. It is increasingly used by advocates of frameworks such as ITIL and COBIT as a decipher mechanism, providing a more complete definition of the target, role-based responsibilities, and filling in gaps that can lead to project failure.

The USMBOK (see uses Lean Thinking as its primary transformation method, not ITSM. The transformation implied is from an organization focused on infrastructure (or anything else come to that), to one performance managed by customer satisfaction, achieving the customer's desired results, and cost effective execution of provider activities.

What do we mean by "identify" and "effect"?

In this thread, what is meant by "identify" and what is meant by "effect"?

Also, I thought a service was a CI. If we identify all CIs affected by an outage, does that mean we have ID'd the service?

Applying Lean/TOC viewpoint, I would think that ID'ing the revenue dependent on the service would be the top priority. How many organizations have automated revenue dependency for prioritization? Definitely plays as tacit knowledge.

Your pesky modeler,

Charles T. Betz

Its the activity (process) not the service...

Charles - hello there - been a while...

I could not find the reference to identify or effect in the thread - may be the altitude as I am on wireless flying across the USA (!). Anyway, can I assume identify means 'determine if an incident has occurred' and effect is 'determine who is impacted and to what extent'?

If so, these are exactly the types of guidance all need in a framework. It should spell out what the major activities are in a work or process flow, with succinct descriptions, and allow us all to indulge in defining dos and donts around each activity. For example, "all events should be inspected to determine if they warrant the recording of an incident".

The definition of what constitutes an incident now becomes an imperative. A service is a CI for sure, why else build a CMDB if its not to map what makes a service valuable. Perhaps more importantly a service is comprised of many activities the users perform and the buyer invests in, that can be chained to form a process, yet have individual service level objectives (sorry targets - ITIL).

The effect upon a CI (here I assume an activity not a service since an activity can be effected and degraded wile a service can remain operational and relatively healthy), of an event, should be inspected and if a service commitment threatened or breached, an incident raised. While doing this the effect of impact upon a particular community or stakeholder could be inherited from a prior definition - perhaps resulting from a business impact analysis (?).

Rules or 'best practices' should be formed based upon the required sensitivity needed within each organization to track events that effect service LEVELs.

Lean cares about customer satisfaction, results and wasteful activities. Knowing what customer activities are important is a pre-requisite to applying lean methods, and frankly being successful at service management. I'll be running a webinar on some of this next Friday August 21, folks can register here for free .

So the path to successful CMDB, service management initiative and application of Lean leads through definition of important (vital) customer activities - I discuss this (Incident Management) and more in the USMBOK publication.

Driving to pass your test....and just driving

I think what we'll see happening here is exactly what happened at V2. There were the books...which let's be honest most people didn't read, and then there was a free floating, tacit, whatever you want to call it cloud of knowledge that was loosely based on the books.

I remember teaching things in the V2 Manager's classes that I knew weren't in the books, but that I knew would get marks in the exam because they made sense. The danger is at V3, people need to understand the theory perfectly to pass the exam, and only then can they start 'playing' in the real world.

It's the difference between the way you drive to pass your test, and the way you drive in the real world.

Books will never be perfect, no matter how many times they are reviewed. It would have been nice to see the ITIL books issued in a way that allowed for updates - perhaps a loose leaf binder style. In the absence of that, I think the ITIL community will need to treat the books as a starting point, and build up from there.

BTW - I'm not in anyway saying that this isn't a shocking oversight!


As an ITIL v3 reviewer....

...I probably presumed more than I should have done. And you always think someone else will pick up things you miss

I had a stupidly short time to do the review in, and made many hundreds of comments. I've never even checked how many of them were actually accepted.

But even with the ISO review process that feels horribly pedantic and goes on forever I'm sure we make basic mistakes because we are too close to the subject and make too many presumptions.

I suspect v2 was read a lot more than v3 is. And I worry that v3 doesn't distinguish between therory and actual good practice.

The key question for me is always " What is likely to happen if I don't do what ITIL says?"

Deja Vu? Descriptive versus Prescriptive

This is one of more than 500 observations I made in a contentious book published against V2 some 3 years back. The volume of issues I found were largely due to how many were reading V2 at the time - as a prescriptive guide. Although not specifically called out within ITIL V2 the general response from those involved in its generation was, that it was developed as a descriptive, information reference. At the time the audience clamored for more 'how to', and I suspect expected more of that in V3.

My V3 analysis, as yet to be published, has uncovered 1500+ observations, largely due to the expanded coverage. However, this figure remains somewhat unfair as it half assumes the books are quasi prescriptive. The books do have a much more authoritative language, implying the guidance is what you should be doing to be successful.

The fine line between Foundation-level guidance and 'best practice' advice is one we as an industry have yet to draw, especially for ITIL. The Guide to the USMBOK is specifically designed to provide a framework to which detailed how to can be attached. The 650 best practice statements the Guide contains are higher level with the occasional dip down for critical aspects - such as the relating of significant activities to the overriding goal of service commitments and what is termed 'vital mission activities' performed by the customer.

Its online companion now has over 5500 statements and it should reach 10,000 by early 2010, thats 250 per knowledge area, or approximately 20 per major activity, and including ITIL v2 and V3.

Any specific guidance should be uniquely identified and clearly presented as such. This is how Skep is able to quote statement 555 from USMBOK. A unique reference allows debate and 'continuous improvement'. ITIL's guidance is embedded in the overall storyline and lengthy paragraphs (I have found 500 actual 'best practice statements' in V3 and carried forward over 1000 from V2)

So, for now, assume ITIL's purpose is to provide a descriptive framework of the practices, their major activities, key concepts and terms, and the more significant elements of guidance. This is in line with the removal of the 'best practice' logo. We need to check as a professional community the extent to which the ITIL framework is that - a framework for the attachment of community led best practices.

I feel a deja vu moment for V3 - so similar to the V2 epiphany as its popularity and dependence grew...

To be fair

...I looked at COBIT DS8: incident matching is there but there is no check that service impact is assessed, no mapping of an incident to a service, except implicitly via mentions of SLAs.

Nor does ISO20000-1 or 20000-2 make it explicit, just mention of SLAs

Nor does ITSM Library's ITSM An Introduction

USMBOK does make it explicit in Best Practice 555

copying ITIL errors

The reason that ITSM Library's content is in line with ITIL is because it had to be in line with ITIL....
The reviews were done by itSMF reps and the owner at that time was itSMF - so we had to follow ITIL by the book. This meant that we had to include all the errors ITIL contained. Of course we tried to cover up most of the errors we ran into, by simply avoiding the text, but we were often required to put the errors back in position :-(. We also tried to add text elements that were not explicitly mentioned in ITIL, to 'glue' the missing pieces together, and most of those were accepted (or just overlooked), but bigger additions to the ITIL core text were most often rejected - no matter how true they were in terms of 'best practice'. Although the GIGO effect definitely blurred the quality of the books, we tried very hard to simplify the ITIL core text, and to avoid most of its flaws. I think we've succeeded in making a number of books that were not worse than the originals ;-). Re-ordering the lifecycle information and the functions and processes information was a major improvement to the core books, although the chief architect was very cross with us - but then again, wasn't this discussion about the lack of architecture, amongst others?
The new ITSM Library books will no longer be only looking at ITIL, nor will they copy ITIL errors without a warning. The books will reference all other relevant frameworks or familiar practices, to reflect 'global best practices'. But they'll al have an architectural core that makes sure they're state of the art.

I wonder if we missed these

I wonder if we missed these things because they were in V2 and kind of obvious sense for most of us. We expect it to be there so much that when we don't see it we believe it is coming up soon or recently passed.
If there's some truth in that then that begs the question: How many of the reviewers of V3 had not read V2 and if none then why? I guess this is where the audit is needed.

the wood for the trees

Plenty of the reviewers were ITIL-literate. I think they couldn't see the wood for the trees: so busy arguing arcane points they missed the obvious. Or maybe reviewing just means reading: you pick up edits but you miss the big picture. Reviewing concepts not just words is hard

The idea I wanted to put

The idea I wanted to put forward but failed to was that there could be a case for having a couple of reviewers who knew their stuff but - somehow - had not read V2. Some people who knew what to look for but weren't too close tot he material to be objective. Heaven knows how you would find or select these people though.

call-centre-centric cult

oh duh! gotcha. Finding someone who knew service management but not ITIL? That's be like looking for three wise men in Australia.

Actually the HDI and some of the other call-centre-centric cults keep to themselves - some of them may not be tainted by ITIL. Trouble is that call-centre experts would keep dropping the book after ten minutes, then start reading a new section.

They'd bring in some cheap

They'd bring in some cheap labour who can only read picture books and 'train them up'. As soon as they get to a word they don't understand they'd escalate instead of looking in the glossary. The ones who show signs of thnking for themselves would be sacked for not reading the pages fast enough.

Welcome to the small club of unbelievers

Good observation. Please check Proactive Problem Management while you have SO book open.

As I have been writing (trying to) my V3 Foundation course based on the 3.4 Syllabus I have been thinking why everybody seems to accept the V3 structure as a solid while there are so many serious errors and holes. I suppose it is just human nature, it is big and impressive so it must be ok.

A few days ago I saw a shocking news film of a Chinese hotel building falling to a river. Buildings are not supposed to fall but they will do it if the foundation is eaten away by water. I thought that this is what may happen with the whole ITIL. You can fool all the people for a time and some people all the time but not all the people all the time. Sooner or later more and more people will realize that a ITIL V3 has just too many errors to be useful.


Syndicate content