The IT Skeptic - Comments for "ITIL V3 Incident Definition: Camels and Committees"

not far enough

skeptic — Wed, 14 Mar 2012 18:59:49 +0000

Yew it was a dumb thing to say buy you don't go far enough. One's relationship with one's customer(s) depends on several factors, one of which is compliance.
Others are performance, quality, fit for purpose, user satisfaction etc
Successful and continuing delivery of every single one depends on good internal practices (I hate the word processes)

hmm

technicalbridge — Wed, 14 Mar 2012 13:32:49 +0000

"no amount of internal process is going to improve or change your relationship with your customers"

Internal processes - IT or otherwise - are what make or break your relationship with your customers

Internal processes != complying with a standard

Yep you're right, but... you're not

DavidM — Wed, 14 Mar 2012 06:21:30 +0000

I've been in organizations that couldn't spell I T I L that somehow were quite functional. Doing an assessment of their capabilities made an interesting discovery. What they were doing, without knowing anything about ITIL, that they figured our either by vicarious learning, trial and error, or experience transferred from new hires aligned quite nicely with the practices ITIL describes. If ITIL is so bad and passe, how do you think that might have happened.

Oh, they get things done! :-)

The central driver in each organization was variants on a single question: "How do we provide exceptional value to internal users, customers, and partners?"

Btw, all of this is within the last 18 months.

Hmmmmm.....

David

preaching to the choir

skeptic — Wed, 14 Mar 2012 03:09:47 +0000

Hey, you know I agree with all that Ian. ITIL isn't perfect, needs plenty of improvement. Quit preaching to the choir :)

That's not the same as ITIL is useless or we don't need itsm.

ITIL needs help

ianclayton — Wed, 14 Mar 2012 00:25:31 +0000

Skep - come on. I'll give you some of the critics would struggle to come up with any form of alternative - but ITIL does need help. Any 'framework' would.

For example, it does NOT explain how to define a service. Nor does it properly reflect how one is brought to market and rolled out. Not in terms generally used by product managers trained in this anyway. Can I cite unbundling, bundling and positioning statements as a start. All absent. Incident management may 'restore a service' (assuming we know what a service is), but it fails to address run of the mill complaints management. Its request fulfillment 'process' is at best light and does not explain how it should work with a service request or service catalog. Problem management is half assed, and change does not walk you through the development of a change schedule, management of change across multiple locations (useful for cloud), or how to assess risk using concepts and methods generally used by risk mangers.

This said, it does contain a lot of useful guidance and does provide a solid framework. But it needs help to truly be adapted into a much wider 'service management' program. Like you, I'm tired of anti-ITIL folks - especially when they moan and groan without offering improvements or alternatives. Its not ITIL - its these folks and others who regard ITIL as the only source of all knowledge.

As for service management - you know my view on that - ITIL is not a good source and its certainly not definitive. There are more than 150 non-IT books I use to define the term and its source is product management/marketing. In fact ITIL now says that itself. So who is out there propagating the belief ITIL is service management? Those doing it are misrepresenting ITIL and frankly damaging the brand...

Buzz off

skeptic — Wed, 14 Mar 2012 00:01:16 +0000

I'd love to discuss but

(a) wrong thread. Try here or here or here or here or...

(b) I'm tired of debating with the anti-ITIL crowd.
You think you can deliver good services to customers without defining them?
You think you can deliver good services to customers without having your shit together within the system?
You think you can manage a multi-provider environment without owners for multiple practices including Supplier, Risk and Service Levels?
You think there is no room for doing improvement in a dynamic environment? No room for change control?
You think you understand service management in general and ITIL in particular when you call it "dinosaur"?

Great. ~~****~~Buzz off then and do so and quit bugging us.

Okay, I've followed this,

freecloud00 — Tue, 13 Mar 2012 23:46:26 +0000

Okay, I've followed this, and other related threads for some time now, and reached the point where I need to say something.

I don't profess to understand anybody's motives for sustaining ITIL (and its ilk), but at the end of the day -- it's defunct. I did research this for a while -- but then rapidly lost interest --

-- and this, IMHO, represents the *fundamental* difference between now, and the old world of ITIL and similar. Why is so much time being spent trying to improve the steam engine, when the rest of the world -- quite simply -- has moved on?

It doesn't matter what maturity level you're at, how well you comply with standards X or Y. It's the consumers who tell you how well you're doing by voting with their feet.

Ask RIM. Ask Nokia. Anybody who thinks they will survive over the next 18 months is seriously deluding themselves.

The evidence to support all of this is out there in the wild. I don't need to justify my position, because the results (sales figures, % market share, etc.) are public knowledge. So in an age where the consumer can impact the share price of Organisation X via Youtube, for instance -- what possible relevance has old-style stuff like ITIL got? Nothing. There is no justification for it whatsoever.

I've been around this industry for longer than I care to remember. But we're talking the early days of Netcool (I was the 3rd Netcool user on the planet), and I've grown with (and out of) that whole world of -- what's that famous buzzphase? -- people, process and technology.

Today, like it or not, is completely consumer-driven, and no amount of internal process is going to improve or change your relationship with your customers. I mean, at the end of the day, who cares if you're ISO27001 or whatever compliant? If you deliver on your promises, and your customer base like (+1, whatever) what you do, then what else matters?

There are outfits out there that get it (no names, no pack drill), and their ideas are already being adopted by globally known brands. How do they implement these new ideas / approaches / technologies? They simply turn them on, and watch what happens.

This is the only way to Get Things Done these days. It's the only way to avoid having dinosaur consultants crawling all over you with entirely inappropriate ideas for the 21st Century, derived from companies who only wish to preserve their old business models because they have no idea how to compete with what's already happening around them.

Discuss.

I was hoping you would actually

itsm_stephen — Tue, 04 Oct 2011 20:57:00 +0000

Answer one of these using your taxonomy rather than continuing to use ITIL.

Since you didn't, I thought I'd give it a shot...

http://www.itskeptic.org/itil-v3-incident-definition-camels-and-committe...

This would be a Fault. From there perhaps it would go to "Problem" (why isn't Problem part of this taxonomy? Shouldn't it fall under "Support" next to Fault?) and then perhaps Change. Hopefully it would skip Incident altogether.

So, in this scenario - no matter what it would be under the "Support" bucket - so, we can say that it is a "Support" issue if: the service is impacted (Inc), the service *isn't yet* impacted and the CI failure has been detected.

Problems are either of known or unknown causes. Known causes are Known Errors. Unknown causes are...Problems? The Fault is assigned to Problem Management where it is either KE or Problem. So a definition of a Problem can be: An unknown cause of one or more Incidents or Faults. Known Errors being: A known cause of one or more Incidents or Faults.

Why don't we just call it Error Management and have Known Errors and Unknown Errors? Just a thought.

So, from Problems/Unknown Errors or Known Errors we can move to Change Management and hopefully (with successful implementations) reduces Faults/Incidents.

I think I got that one alright.

http://www.itskeptic.org/itil-v3-incident-definition-camels-and-committe...

This one is again Fault. It is a detected CI that is "about" to cause an Incident. Follows like the above example.

http://www.itskeptic.org/itil-v3-incident-definition-camels-and-committe...

The bomb...I'd say...Fault! It speaks to the "imminent failure of a CI" (one can presume it is still Fault even if it is more than a singularly CI that is under threat).

It does get interesting here though. Would it naturally go from Fault to Unknown Error/Problem? Would we go from there to a BC plan? Or do you go from Fault to "Risk Management" to BC plan (or perhaps Problem to disengage the bomb). My gut says we go to Problem first. Well, actually, my gut says since I am in the same building as the DC that I don't quibble about details like this, and busy myself calling my wife as I quickly make my escape.

http://www.itskeptic.org/itil-v3-incident-definition-camels-and-committe...

1) Theory: This would be a Fault. It would flow to Problem and so on.
2) Real Life: Unauthorized change, Fault, Known Error (why try to restart it, unless this is a prescribed action?), Problem (it turned out the prescribed action didn't work...so now it is an Unknown Error).....then Friday we have Incidents tying to the already opened Problem.

http://www.itskeptic.org/itil-v3-incident-definition-camels-and-committe...

I would disagree with this statement. Using our handy dandy taxonomy - I'd say what is being described as a "Risk" is actually a "Fault" and Problems are (as described above) Errors with an unknown cause - not to be confused Known Errors. Faults may be linked to Known Errors or Problems. To suggest that Faults (or Risks) can only be associated with Unknown Errors (Problems) is inaccurate.

http://www.itskeptic.org/itil-v3-incident-definition-camels-and-committe...

In order of the bullets...
*Incident (agree with Joe Pearson)
*I presume this has been detected and it is not causing an Incident. Therefore it defaults to Fault. If it is caused by a known error, it is of course linked to a KE.
*Like above, it is a Fault but this time linked to an unknown error - so linked to a Problem.
*How far into the future? What constitutes "imminent"? Could be Fault, probably then linked to a Problem. Or perhaps "Suggestion" that leads to Change? How are CSI items being captured? Through Suggestions? I could see maybe, this is a CSI item - Identified Risk: Hardware no longer supported in 6 months. Suggestion: Buy new hardware. Migrate to other existing hardware that is still supported. Move to the cloud!
*Suggestion? Proposal? Depending on the actual situation I suppose. If the value is degrading or will degrade at some point - what is your idea to "fix" that?

http://www.itskeptic.org/itil-v3-incident-definition-camels-and-committe...

It is a Fault. Leading to either Known or Unknown Error (Problem).

It seems like I've replaced the Incident Management bucket (http://www.itskeptic.org/itil-v3-incident-definition-camels-and-committe...) with the Fault Management bucket though.

Still, I think it is probably a worthwhile distinction to make.

Would you want your Faults to be higher than Incidents? Would you want most Incidents to be linked to KE and expect a higher % of Faults to be linked to Problems (Unknown Errors)? Would better Fault detection lead to fewer Incidents? Would this then link Fault and Event closely?

I think this is great stuff. Does anybody out there use anything like the IT Skeptic Taxonomy in real life?

122,000 That's how many

skeptic — Thu, 17 Mar 2011 18:11:14 +0000

122,000

That's how many angels can dance on the head of a pin by my reckoning.

Incident management is about restoration of service.

Incident management includes interaction with users.

Lets stick to basic principles and stop trying to make ITSM into something arcane.

A failed redundant device is clearly a Problem in the current ITIL taxonomy, as it will potentially cause an incident.

If we need a front end entity to track it before we determine it is a true Problem, then we need a Fault because by any common sense measure it isn't an Incident.

Why is this so hard?

Redundancy is something

Visitor — Thu, 17 Mar 2011 16:13:29 +0000

If a service that is supposed to be redundant, my expectation is that the redundancy is part of what is considered "normal" operation, not to mention I am likely paying more for such redundancy. A failure of a redundant component must be considered an incident. It would not be a Major Incident in most cases because the service is still availabile, but it certainly merits the visibility and tracking of an incident for multiple reasons.

If the redundant service is truely in "normal" operation, there would not be an elevated risk of a service outage. Quite literally I am paying for the overall reduction of risk of a service outage with a redundant service.

Should it matter how you subscribe to the definition?

Shaunn — Mon, 23 Feb 2009 22:49:11 +0000

This is an awesome thread! I can see both sides, but I personally subscribe to what makes sense to the business is at hand.

I can also see that if a faulty CI can be an incident; while it may not effect the services you provide to your customers, are you not a customer to a vendor consuming their services/products/software?

The "root cause" of this debate is obviously between what is ITIL, and what is practical. It may be ideal to have more processes to handle service impacting versus non-service impacting, but I bet when push comes to shove- the wallet will win. It is cheaper to tool a single flexible process with an emphasis on service incidents than to have to tool two different fault management processes.

Many IT organizations don't have the cash to purchase a successfully implemented Service Level Monitoring integration solution, or an effective CMDB. Without an great insight into what and where an impact is, risk management wins out.

The "if your not sure, open a ticket" behavior will surely win, especially in the more fascist operations.

Well, err hmm

JoePearson — Wed, 18 Feb 2009 08:12:43 +0000

"I think you missed one off your list Joe: the actual concrete classical Problem: an identified fault/break/mis-configuration/... that needs to be risk analysed, prioritised, and (usuall) fixed."

- This is pretty much what I meant by "An abnormal condition in some part of the managed environment". I was trying to use generic words and not reuse any of the terms we're trying to define. Unfortunately when you get too generic you lose all meaning!

On distinguishing concepts along natural fault-lines: yes, some distinctions are good, even great, and some not so much. My instinctive approach is to break everything up as much as possible (in a lab/dev environment of course!) and then see where unsuspected natural fault lines might have been. But don't drop the analysis if they don't seem obvious!

I think there are important, if not quite natural, fault lines not covered in the current terminology:
* affecting the users - breaching SLA (an incident) vs not e.g. due to being covered by a backup CI, not being in production, being within acceptable but not ideal parameters, ...
* affecting us now (an issue, in project mgt terms) vs potentially affecting us in the future (a risk)

These fault-lines may not be clear enough to earn the "best practice" label, but people designing ITSM capability that they hope to be robust had better at least give them some thought. (And stop assuming that ITIL has done all the work and is perfect grumble grumble.)

a great analysis

skeptic — Tue, 17 Feb 2009 21:24:58 +0000

What a great analysis!!!

I think you missed one off your list Joe: the actual concrete classical Problem: an identified fault/break/mis-configuration/... that needs to be risk analysed, prioritised, and (usuall) fixed.

yes there are all sorts of shades and gradations and variants. One has to be careful to not bag-and-tag too many of them, as I may arguably have done with Request. I don't think I have over-analysed there and I don't think you have here: the distinctions are useful. However when one comes up with lots of variants it always suggest to me that one is trying to break the stone along the wrong axis. A crystalline rock has a natural plane of fracture when it come scleanly apart into two crisp pieces. When one finds that natural plane of fracture, a thorny issue comes apart into a few nice clean pieces.

I feel ITIL's distinction between Incident and Problem is one of those. For me and many others in the 90s, this was an ah-hah! lightbulb splitting of the two concepts that seems facile now but was novel then. Now we mature and analyse mnore deeply, we can see that within Incident and within problem there is more to it. But we aren't breaking Problem cleanly aliong a new fracture line, we are busting it up into fragments. likewise with Request.

Am i making sense and am i right? Or is it that Incident, Problem and Request cannot be cleanly fractured further and can only be rendered into gravel? :)

Things that lack names?

JoePearson — Tue, 17 Feb 2009 16:48:54 +0000

Great post, great discussions ... allow me though to reiterate my preference for having participants identify themselves somehow :(.

I nearly replied to three or four of the sub-threads, but I'll summarise* my thoughts in one.

Regardless of what ITIL says or what the risk management community says, we have a bunch of concepts that can be split up to various levels ...

* Disruption of the current value of service to user (this is the undisputed part of ITIL's Incident)
* An abnormal condition in some part of the managed environment (infrastructure, applications, their configuration, ...) (I think this is close to "Known Error")
* An abnormal symptom not yet identified (fuzzily worded, but I think it's a concrete concept - close to "Problem")
* An identified risk of an abnormal condition emerging in the future (a "Problem"? or is this where ITIL fails to cover Risk? It doesn't properly match ITIL's definition "cause of one or more incidents)
* An identified risk to the future value of service to the user (a disputed part of "Incident"? a "Problem"?)

By abnormal I mean different from what it's supposed to be. This "supposed to be" concept crops up everywhere: a CMDB that doesn't cover it is useless. An SLA that doesn't cover it is useless. A monitoring tool that doesn't cover it is useless. And I think it's central here. Some "thing", some attribute of some CI, is not what it's supposed to be or is at risk of not being so.

If the CI is a user service, we have an Incident. Or a potential Incident. Some other CIs/attributes are almost certainly not what they are supposed to be (or we may not yet have learnt what they are supposed to be). We have to find them: root cause analysis.

If the CI is not a user service, we have something (now or soon) that may (or may not) impact user service (or other controls on the system). This is where we have too many concepts and not enough terms, and therefore we have confusion between incidents, events, problems, risks and "go away all you ITSM people, this is technical, we'll fix it".

* Yes, this was a summary

hmmm

M.McEvoy — Mon, 16 Feb 2009 15:38:14 +0000

1] Are you asking generally or being specific to infrastructure monitoring? I have always seen it as the way I described. Event Management, manages events and when necessary feeds the incident management process. Monitoring is a process to monitor the state as it is expected to be and generates events when this is not the case. This can be at the infrastructure level, application level or service level.

2] I didn’t say there were not related as clearly the framework relates to the processes and activities within it. But it is only best practice for the framework for Service Management and does not prescribe the actual day to day activities or the procedures needed to operate the service or the shape of the organisation required to do this or the tools (CMDB is an exception). This was the bit I had in mind when I said “real word”.

3] This is my point, ITIL names a set of processes and describes some of the activities within each, it only gives high level interrelationships i.e. an incident can trigger a problem. For a complete solution you need to design the actual service that fits with the requirements for your organisation. The flows for each process in the service model will show all the interrelationships. Security Management maybe very different in your organisation to someone else’s but both can follow the same ITIL framework.

This has been quite interesting discussion

aroos — Mon, 16 Feb 2009 07:50:31 +0000

Quite refreshing discussion. I think that this shows that Itil V2 and V3 are quite different at this basic operational level.

Here is how I see this Server scenario happening, first in theory and then in practice ;-)

1) Theory
On Thursday evening Operations notices server down and report to Incident Manager, who decides that this a major incident because while the service is ok at the moment, it will not be ok on Friday Morning. The IM assembles a Major Incident Team and alerts Problem Management. While the Major Incident Team starts preparing a workaround to ensure stable service, the PM team finds out that there has been an minor change where the server has been upgraded and decides to suggest an emergency change to revoke the upgrade. This is accepted and service is back to normal before midnight.

2) Real life
On Thursday afternoon Dave decided to do a minor upgrade on of the servers before he started his long weekend. Assuming no trouble appeared, he could then upgrade the rest of the servers on Monday morning. He knows he should make a change ticket but who cares, everybody has started bypassing the processes. When Operations notices the server being down they restart it a couple of times but it goes down again. They try to contact the Operations Manager but the whole Management Team is having their monthly two day Strategy Session and cannot be reached. The Function and Process managers run in circles but cannot decide who is in charge so nobody does anything useful. On Friday morning the company launches an important marketing campaign but the servers crash and the campaign fails.

Aale

can see where you are coming from

skeptic — Sun, 15 Feb 2009 20:28:33 +0000

OK i can see where you are coming from, there are indeed faults that one would want to let the business owner know about, and we do need to prepare for the potential incident by referring to the SLA. I struggle to see where Level 1 come in but i defer to your greater experience. I'd be shippping it direct to Level 2 as a Problem.

but there are no bulletins to go out, no users to be followed up, no multiple incidents to be linked, no need for callcentre operators to be briefed, no problem diagnisis, no workarounds .... a great deal of incident process is still irrelevant

whatever the current orthodoxy amongst the big boys, as represented by ITIL, I don't think that over-rules asking the question: why doesn't incident management focus on restoration of service and leave other emergencies for other procedures? I think you cause no end of confusion by announcing to IT "we have a priority 1 incident here. no put the phone down, no one is impacted yet"

of course if ITIL leaves no room for further improvement...

P.S. thanks for sticking with a long and robust debate - your input is much appreciated :)

Replace bomb with JCB...

JamesFinister — Sun, 15 Feb 2009 15:08:22 +0000

...and you have a typical example we used to use in the classroom, even back in v1 days.

Yes you have a major incident that needs fixing, because if the bomb goes off or the JCB digs through the power cable then service will be disrupted to all users. Incident has both high impact and high urgency, hence high priority. I would probably default (and in some of my previous lives finding a bomb near a data centre was quite likely) to invoking the DR plan so that even if the bomb goes off there is no disruption to service. Is it a service request? Hmm, perhaps, if I have a tried and tested SOP for invoking and implementing the DR plan. My personal jury is out on that one.

Obviously my risk assessment, done as part of several capabilities my IT department has, will have identified it as a risk that needs mitigating, but now it has actually come to pass it becomes an issue.

But post event I will still do a separate problem review to find out what lessons have been learnt and to try and avoid it ever happening again, at all the sites I'm responsible for.

The old Microsoft source book for the help desk used issue in a different, but useful way, meaning a generic weakness such as poor HR procedures.

Insufficient

Visitor — Sun, 15 Feb 2009 15:07:20 +0000

“Visitor you are completely locked into the straightjacket mindset that urgent = incident.”

No, the point was not that it was urgent. The point was that it was not normal service operations. This is the narrow tendency I refer to.

An existing impact to service is not required to invoke the need for an incident.

And, JVB, this is not an academic exercise. While an extreme case, it is one of many use cases taken from real world operations in industry. The line you and Skep have drawn around IM may be appealing conceptually, but it has shown itself to be insufficient in practice. Its been tried by me and many other practitioners. (And I have to ask, JVB, if this model you keep referring to has been validated in real world ops.)

Infrastructure operations for HP, IBM, EDS, GM and Toyota, for example, on the hook for billions of dollars of customer contracts or business operations, rely on the concept of “non-impactful Incident.”

Why? Because of non-normal scenarios (nowhere near as troublesome as a bomb) that have produced no impact, but cannot, should not, be treated as fault or problem. They require the invocation of an incident and all its attributes; business notification, customer centricity, SLA reference and L-1 support.

So I respectfully disagree.

straightjacket mindset that urgent = incident

skeptic — Sun, 15 Feb 2009 06:21:00 +0000

Visitor you are completely locked into the straightjacket mindset that urgent = incident. NO IT DOESNT. A bomb would be an urgent problem indeed, or as JVB says an urgent risk, or an urgent fadurkin' fault I don't care, BUT IT ISN'T AN INCIDENT.

Look, by categorising incoming requests we assign an appropriate process/procedure/whatever to it. Incident management is customer-centric. it is about getting the customer's people back on the air with minimum impact.

An incident requires that we notify the business that their service is impacted. An incident rquires that we refer to the SLA to see what performance is expected of us. incident management calls in Level 1 to determine if there is a problem. Etc etc. If a service is not impacted, if we have proactively uncovered a problem before there is an impact, then none of that is required. It is an entirely different set of procedures to resolve a problem. An incident is managed by the service desk, problems usually are not.

Even when a failed CI DOES impact a service, it is not Inc Mgmt that fixes the failed CI. It is Problem Mgmt. Inc Mgmt just tries to minimise the grief for the customer and users until it is fixed. So what is the point of bringing Inc Mgmt into it if there is zero impact on customer or users?

Once again, the incident process/procedure is not the only way to deal with something urgent.