The IT Skeptic - Comments for "I'm going to call root cause primary cause from now on"

Matrix

JamesFinister — Sun, 07 Feb 2010 20:25:09 +0000

Since part of the value that ITIL brings to the table is that it highlights the connections between things I guess it isn't surprising it had can be hard to find the right place to out things. Having said that some choices seem very arbitrary. As you say, an index helps but I'm sure there are better options. One of the great things about COBITis the MyCOBIT functionality that allows you to pull out what you want. In 2010 is a set of books still the best way to deliver ITIL?

You aren't suggesting Juan as an alternative ITIL reference are you? I'm sure I just read it that way the first time.

feels like the top of the jigsaw box is missing

skeptic — Sun, 07 Feb 2010 20:09:00 +0000

JVB's book Foundations of IT Service Management Based on ITIL® V3 pulls all the processes out and explains the lifecycle separately. As a result it is far more usable than the core ITIL books, and manages to squeeze all five books into one reasonably sized, portable book, apparently without sacrificing content. When I'm not arguing ITIL semantics with Juan, I use this book as a prefered ITIL reference.

However it lists SFA somewhere else again, as part of CSI under SLM, along with other analytical after-the-fact analysis techniques for future improvement. At least in one book with a good index one can find it quickly if you know what you are looking for

Processes trapped within a lifecycle?

ianclayton — Sun, 07 Feb 2010 18:00:54 +0000

Skep

I agree - SFA is a rename of the old war room styled 'fix it and find out why' session many of us were part of in the early days of operating and supporting systems. SFA was often the result of the analysis - and 3R the method used to recover, resolve and restore the systems (oh thats a USMBOK term not ITIL).

The ITIL glossary rather hands itself here by describing SFA as "an activty that identifies the underlying causes of one or more IT Service interruptions...". On page 108 of the Design book it also says, "Many of the activities involved in SFA are closely aligned with those of Problem Management.... performed jointly by Problem Management and Availability Management". In Service Operation (where Problem lives) we see a tie back to SFA on pages 76-77, but no clear explanation of who does what.

This nailing of processes to specific stages of the lifecycle is IMHO ITIL V3's biggest downfall. It causes readers to shuffle to and fro and buy Adobe Acrobat or similar to search across books, and miss connections. It was my suggestion from the get go that the lifecycle be explained (if need be in 5 books but it could have been one) separately and processes in a second book so they could be networked...

SFA is a technique a method. It its primary goal is to perform cause analysis it belongs in problem management. If it is a technique many can share in there might be a case for it being in a general technique area and referenced by many... so could CFIA and FTA...

Techniques are trapped within processes, processes are trapped within lifecycle stages and lifecycle stages within a service scheme that lacks a systematic approach. Result - feels like the top of the jigsaw box is missing...

I'l have an ITIL please

skeptic — Thu, 28 Jan 2010 20:44:00 +0000

I am sure the intent of ITIL is to be a compass. But that isn't how it is perceived by the market. The market wants out-of-the-box solutions and it buys an ITIL, sometimes two of them.

I'm not sure what one can do to stop people responding to it in this way. vendors could stop selling "ITIL out of the box" for starters (yes BMC I'm looking at you)

I spoke to someone whose large and technically savvy company has a plan, one item of which is to implement ITIL by March.

Dont mention IT

Glen — Thu, 28 Jan 2010 18:36:29 +0000

Glad you resisted....Sounds like you need a towel.
And its always the True North, Strong and Free! ;>

Attractive analogy

JamesFinister — Thu, 28 Jan 2010 17:02:15 +0000

Glen,

I like the analogy, and in v1 days I would have agreed with you. So much of what was ITIL in those days wasn't even in the books.

I am now going to resist the temptation to take the analogy to extremes.

I am not going to mention the difference between true north and magnetic north. Or mention the geo magnetic pole.

I am not going to mention pirate maps that are traditionally split so no one person knows the location of the treasure, or the need to have an "X" that marks the spot.

I will not even mention that as a guide it would be immeasurably improved by having the words "Do Not Panic" printed on the front cover.

ITIL is a compass

Glen — Thu, 28 Jan 2010 16:22:32 +0000

I have always said that ITIL is a compass. It does not dictate a path, it points a direction.
Once you can identify true north, you can navigate to where you need to be.
Read Brian Johnsons (One of the originals) comments at CA, the focus has always been on providing guidance.

My first use of ITIL came from a need to improve my organization. I knew something was missing in our overall perfromance, but had no insight into what it was. ITIL was a head slap. I could compare my current state against a conceptual model written in the language I used.

2nd thought paraphrasing Alexander Kist, he used to say that ITIL was nothing more than the translation of the science of business into IT language.

v1, v2, or v3...its all about "here's something you can use to improve your delivery capabilities." Use the pieces of ITIL that make sense based on your needs.

2 cents for what its worth.

What exactly is ITIL...

JamesFinister — Thu, 28 Jan 2010 15:23:40 +0000

....is a question I ask myself more and more as the years go by and COBIT and ISO/IEC 20000 mature.

It clearly isn't rigorous enough to be a standard.

We know it isn't a methodology.

A lot of it is not IT specific in origin and possible application*

What exactly do we mean by a framework?

And when people talk about implementing ITIL, especially about having implemented v3 on top of v2, what exactly have they done? I don't hear lots of conference sessions about financial management of IT, or the use of simulations to predict systems failures. Problem management activity kicked off pro actively rather than in response to an incident?

Is it just a fireside chat?

Perhaps a guide to driving cultural change?

No wonder people end up confused. ;-)

* I'm still not sure what unique IP ITIL has delivered to the marketplace. I might argue that the value lies in the way it identifies the interconnectedness of disciplines that pre ITIL were seen as their own little worlds.

The market already thinks it is getting one framework

skeptic — Thu, 28 Jan 2010 10:07:00 +0000

The market already thinks it is getting one framework. "what? there is something other than ITIL?" Don't kid yourself on what percentage of the ITSM marketplace have even heard of ISO20000 or COBIT

but when they do find out, they're confused and bemused, and often annoyed.

The swami

JamesFinister — Thu, 28 Jan 2010 09:45:32 +0000

Rob,

You haven't started to channel the swami have you?

An uber-framework would be logical and useful, but I don't see the market clamouring for it.

Neither do I see the mechanisms in place that would enable such a framework to be developed effectively without it being hijacked by self interest at several levels.

It is, though, a beautiful dream.

Perhaps the one catalyst that might be productive would be a non-partisan ITSM educational programme?

no obstacle

skeptic — Thu, 28 Jan 2010 08:07:33 +0000

ISACA are already licensed to use ITIL content in COBIT etc There's no obstacle there that a simple signature doesn't fix

yea the uber-framework shall come, brothers and sisters!!!

IP

JamesFinister — Wed, 27 Jan 2010 20:18:20 +0000

Rob,

Being pedantic there is undoubtedly an IP and copyright issue about how material is shared across boundaries that we need to recognise. It is unfortunate but true,

Can I balance that by saying I would add "revenue streams" to your why nots?

We can place some faith in the commonality of authorship across the frameworks, which is often forgotten by those who try and posit an inherent tension between them..

Perhaps we need an overarching qualification scheme that would consider them all in context?

SFA

skeptic — Wed, 27 Jan 2010 18:49:00 +0000

While we are on the topic of RCA, why is Service Failure Analysis under Availability in Service Design? Why not put all the techniques together?

(I love that acronym SFA. "What did you find out?" "SFA")

why not?

skeptic — Wed, 27 Jan 2010 18:33:42 +0000

"ITIL cannot openly embrace both COBIT and ISO 20000"

Other than stubbornness and parochialism, why not?

In a decade's time there will be an uber-framework - the market demands it

Standard +

JamesFinister — Wed, 27 Jan 2010 14:14:13 +0000

Of course we already have a standard in ISO/IEC 20000, but we have to be realistic about what such a standard can achieve. Anyone contemplating a new standard should not under estimate the work required. The mandatory aspects of a standard need to applicable across a wide range of situations which can limit their usefulness, however.

I was/am very fond of the BSi's "Achieving BS15000" range of books.

It is a pity that ITIL cannot openly embrace both COBIT and ISO 20000 as the core of ITSM, and focus instead on the practicalities of doing ITSM, the options and choices that can be made without compromising ITSM, and on genuine ITSM best practice. I'm all for biue sky ITSM thinking, for instance, as long as it is clearly signposted as such. I'm less keen when it is embedded amongst more basic requirements.

That depends ;-)

mbuzina — Wed, 27 Jan 2010 13:08:53 +0000

If it is important or not - that depends on what you are targetting:

Do you want to create a standard to which the IT as a whole has to stick to? Then you have an important conflict on hand. It must be solved by specifying measurable criteria for deciding which of the four endpoints you can / have to take.

Are you writing "just" best practice guidance, no it is not a big conflict. It is still up the implementer to decide what is what. And they can say "it depends on the business need" (just as I did by stating it depends on the meaning of the word impact).

I (and I guess many others) would prefer a body of knowledge to emerge which would try to become a standard (and one which has improvement methodologies that is needed for that). So the best practice should hold itself against the rigour of testing that a standard required. And then issues like this have to be solved.

Marc Buzina
http://buzina.wordpress.com/2010/01/27/the-past-the-present-and-the-futu...

Two or more cultures

JamesFinister — Tue, 26 Jan 2010 20:18:11 +0000

Most NOCs I've worked with think of everything as an event, but only certain ones as incidents - which might not be the same ones as the service desk because they are more pre-emptive but have less of a business view.

Dealing with language across value networks is something we need to address, ITIL still presumes a short supply chain - a "three link coupling". in reality we are going to find the same words used consistently from the perspective of the person using them, but seeming different to other people. My supplier DOES have a SLA with me, but it isn't the SLA my customer things of.

Interesting idea

aroos — Tue, 26 Jan 2010 16:07:39 +0000

Marc

The past/present/future is interesting analogy, I think it can and should be applied but does it work here?

According to ITIL is quite clear that an non-impact event is an incident (...that has not yet impacted...). At the same time it is quite clear by ITIL that event management can fix things without awakening incident management, it can bypass IM and request a change or even raise a problem. EM has four different ways to handle an event and only one of them is by IM. There is a conflict, no doubt about that.

The question is: is it an important conflict as one can always say it depends. Which is usually true, btw. I'm not sure.

Aale

Calling Names

mbuzina — Tue, 26 Jan 2010 14:09:01 +0000

Another one Aale: I have seen it exactly the way you described in a large IT company, but the names were different: Events were called Incidents and your Incidents were called Service Requests!

That definition was thrown out due to misunderstanding between the IT service provider and its client.

Marc

Event vs. Incident

mbuzina — Tue, 26 Jan 2010 14:00:09 +0000

Hi Aale,

To me all is about impact. An Incident means that I have an impact upon a service, while an event does not (yet) know if it has an impact upon a service. I would not wait for customer reports in generating incidents from events, since the quicker I work on an incident, the quicker I can resolve it. If an event indicates that a service (or multiple services) are impacted (unavailable, slow, etc.) I would generate an incident from the event (if there is no incident about this already). If I deem it to be serious I can immediatly spawn a problem as well and I have a tripplet, an event that tells me that something happened, an incident that tells me to get the service up again and a problem that reminds me to avoid this in the future.

Event = The Past
Incident = The Present
Problem = The Future

If a single redundant broken disk is an incident (with impact on the service) also depends on my service definition. If I define my service to have a fixed level of resilliance against failures, then yes one drive may impact the guaranteed quality. If the redundance is just IT internal desgin to achieve other service qualities (e.g. Availability, Continuity, etc.) than it is not an incident (it may become a problem without ever being an incident then ;-)

Your approach is very clean and easy to explain and may be implemented pretty well, but I would still like to see those events and incidents together that have an impact on services. SLAs will focus exactly those.

Marc - http://buzina.wordpress.com

P.S.: Thanks for letting me find the past/present/future analogy, it is a new idea for me as well.

The IT Skeptic - Comments for "I&#039;m going to call root cause primary cause from now on"

Matrix

feels like the top of the jigsaw box is missing

Processes trapped within a lifecycle?

I'l have an ITIL please

Dont mention IT

Attractive analogy

ITIL is a compass

What exactly is ITIL...

The market already thinks it is getting one framework

The swami

no obstacle

IP

SFA

why not?

Standard +

That depends ;-)

Two or more cultures

Interesting idea

Calling Names

Event vs. Incident

The IT Skeptic - Comments for "I'm going to call root cause primary cause from now on"