I'm going to call root cause primary cause from now on
Three loosely connected thoughts about root cause:
Ian Clayton said here recently that root cause is seldom found. Dammit he's right. Causes don't normally arrange themselves in a nice tree all leading back to one. There are several fundamental contributing causes. But I do think one of them usually stands out like the proverbial. So instead of calling it root cause I'm going to call it primary cause. Sure the other causes contributed but this was the biggest contributor, the primary.
Another thought based on something Ian said (Clayton is one of the great thinkers of ITSM), root cause ...er... primary cause analysis is something you do AFTER the fact as part of the review and wash-up. In the heat of the crisis who gives a toss what the primary cause is - remove the most accessible of the causes. Any disaster is based on multiple causes. Anyone who watches Air Crash Investigation knows it takes more than one mistake to cause an accident.
Put another way, all complex systems are broken [link fixed now, sorry folks]. It is only when we allow the broken bits to line up the right way that it fails.
What all this is getting to is that removing any one cause of an incident will likely restore service.
Then when we have time to consider what happened and take steps to prevent a recurrence, we should probably try to address all causes but if we need to focus efforts then the primary cause is the one.
Which implies that a key factor in deciding primacy is how broad the potential is for causing more incidents.
Another thought here, based on that excellent paper linked above: many times the person "to blame" for a primary cause was just doing their job. All complex systems are broken. Every day the operators make value judgements and risk calls. Sometimes they don't get away with it. There is a fine line between considered risks and incompetence - we have to keep that line in mind. Just becuase they caused it doesn't mean it is their fault. Think of the word "fault" - what they did may not have been faulty, it may just be what they have to do every day to get the job done. Too often, when they get away with it they made a good call, when they don't they get crucified.
Made in New Zealand 
Comments
SFA
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")
Processes trapped within a lifecycle?
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...
feels like the top of the jigsaw box is missing
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
Matrix
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.
Why can't you have more than one root cause
Looking through the dictionary, there seems to be a couple of uses of the word "root" that refer to a singular entity, but most do not. Why cannot there be multiple root causes to a problem. Some of these roots are stronger than others in the causal relationship to the problem, but they are all important. In most critical system, a root cause is actually the combination of multiple events which result in the resulting problem (aircraft investigation is like this). Its the combination that creates the root cause.
Search the the root cause, can be the process of looking for a collection of a events that resulted in the problem.
Rather than create more terminology, maybe just modify the definition, or the message. Not sure it even needs redefinition from my basic perusal of the documents..
$0.02
Brad Vaughan
Definitions
I guess it is not creating more terminology, but uncluttering existing definitions. The name "root cause" is highly influential and leeds people to believe that their is exactly one cause of their pain and if that is removed life will be perfect bliss. As we all know, that is not really the case.
I would suggest another name change: root cause analysis should be reduced to cause analysis, since it should investigate all (relevant) causes of an incident / problem. Each cause is equivalent to a problem and should be assessed by a cause analysis again. Then it can be adressed. See http://buzina.wordpress.com/2010/01/18/root-cause-vs-cause-analysis for a more detailed description (this post triggered me to express a long existing idea, thanks!).
Regards,
Marc - http://buzina.wordpress.com
What about event and incident
Marc
Very good description of the complexity of root cause. It clearly is not a good way to separate incident and problem.
Now I have realized that the separation of incident and event is also unclear. The definition of incident prescribes (Why?) that a failed mirrored disk is an incident but according to event management it is clearly an event. As it has not affected customers, it can be only noticed by monitoring and event management does not need to lead to incidents. In practice it makes sense that Ops fixes the event as it sees it and it makes no sense to activate incident management as this is a standard procedure. In a large data center disk failure is a routine event.
It makes much more sense to define that event management handles self observed issues and incident management concentrates on those cases where there is a customer directly involved. An event becomes an incident when a customer reports it. This separates the processes nicely, EM has no customer/user and IM has always a customer/user.
In both cases problem management is needed when there is a risk that the event/incident may recur with potentially adverse effects.
Aale
Calling Names
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
Two or more cultures
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.
Event vs. Incident
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.
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.
Interesting idea
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
That depends ;-)
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...
Standard +
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.
why not?
"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
IP
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?
no obstacle
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!!!
The swami
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?
The market already thinks it is getting one framework
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.
What exactly is ITIL...
....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.
ITIL is a compass
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.
Attractive analogy
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.
Dont mention IT
Glad you resisted....Sounds like you need a towel.
And its always the True North, Strong and Free! ;>
I'l have an ITIL please
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.
a Fault and an Incident
Yes, I agree. I distinguish between a Fault and an Incident for that very reason.
An Event might indicate an impacted service - an Incident - or a potentially impacted service or other internal issue that needs fixing - a Fault.
A taxonomy of service Responses should be created based on the different workflows and actors/responsibilities. An Incident requires an entirely different workflow to a Fault - they have nothing in common except "something is wrong".
We went into that here and here
Event not always fault
Events can be good, bad or informational. Or even uninformational ;-)
Examples:
Event: customer user requested access to a new printer
Event: capacity on storage array nears a quota
Event: new service enters the pipeline
Nothing wrong in those cases. Okay maybe the 3rd as it means that a project manager is going to get some work. I hear God kills a kitten every time that happens ;-)
Back in 1931
I wrote something along this theme in http://thinkingproblemmanagement.blogspot.com/2008/09/root-cause-is-not-...
Heinrich termed it multiple causation (way back in 1931) What other people knew 80 years ago, IT is reinventing today.
Carrot or weed
Roots are different. Sometimes there is just one juicy carrot and in some cases it is nearly impossible to kill the damn weed.
I think IT problems can have similar variety.
Aale
System theory and primary causes
I was reviewing systems theory and finding gems in John Sterman's Business Dynamics such as one main point about how we use models to make decisions, all models are wrong, and we can't ever know all that there is to make a complete decision. A root or primary cause of a problem or an undesirable output in a large system would just be seen as a system that wasn't well understood when an input was made incorrectly for the desired output.
Maybe we should call a root or primary cause a primary input or an incorrect input. But Sterman also said that people don't understand systems easily so people won't have a clue about what an input is, and even less about stock and flow. So back to the root cause which isn't understood either. At least if you use primary cause, you make people think a little. I'll try it out in my next Business Analysis class and see how it flies.
Can someone actually look at problem management theory?
Skep, first - flattery will get you everywhere - appreciated. Calling the cause you choose the 'primary' cause is not a bad idea at all. At least it reflects what has happened, someone has selected that one for action. I just wish we would all respect other practices, outside of IT that actually invented and use today many of the concepts and methods I repeat in my contributions. The root cause, also termed the 'TOP' cause, is voted there, and ys it can be by one person if need be - the problem manager, as part of the cause analysis effort.
Along the way we have passed through presumptive, contributing, and control barrier cause related terms. What is more important is a crystal clear representation of what happened, what is believed to be the reasoning by each cause, which ones we want to, and are allowed to address, and the action plan going forward to address them....
This is why frameworks like ITIL fail us. There are many years of heritage in this area. We were given the most basic descriptions in ITIL V2, and an opportunity was wasted in V3 to describe what is probably one of the most important practices to get right - assuming we all have problems...?
Don't forget - seek out problem management sources that are not IT... try healthcare - they actually work - well mostly...
A dilemma for the authors
Ian,
I have the same thoughts about the financial management and supplier management aspects of ITIL, but I think it is a genuine dilemma for the authors.
Do you say "Look, this is a specialist field in its own right. Go and read these sources"
Do you try and integrate the key aspects of best practice from elsewhere in to ITIL itself, hopefully giving it a distinctive IT spin
Do you try and sum up best practice iin a quarter of the pages needed to do it justice, and hope people will realise they need more in depth knowledge to understand it?
Part of my angst about "ITIL v3 Experts" is so many of them only know about these specialist areas from what is in the ITIL books and exams and haven't even read the basic texts on the subject. Conversations with them can end up like having a theological debate with someone who has only ever read the verses inside of Easter cards
Awareness is the first step in gaining knowledge.
I like the fact that ITIL brings up these subjects.
First, it puts concepts of analysis, fianance and business in terms and context that an IT professional can recognize. Second, their absence may lead some to conclude that they are not important or relevant in the Service Manager arena. With Google, Wiki and the local library, there are simple ways to delve into any topic. Let ITIL vX point the path, make us aware that these principles exist and are relevant. Then it is up to us as professionals to do the research, refine our approach and understand deeper concepts.
On an aside, I have often thought that the challenge with problem management has more to do with the politics of the role than its execution. A Problem Manager needs to be extremely politically aware. It is unfortunate but true that sometimes they shoot the messenger. Before embarking on a quest to uncover root cause / primary cause, you first need to ask if the senior managers are going to welcome your efforts to prove where there are flaws.
Couching findings in language that identifies the cause without assessing blame is an art.
ITIL points the way
I agree with Ian's points.
Glen, if ITIL is to point the way into other useful bodies of knowledge, then it needs to stop
a) reinventing them e.g. 7-step CSI, utility/warranty, service owner...
b) renaming them to obscure their origins
c) failing to cite the sources or further references for anything. It is one thing to vaguely list a bibliography at the end of some books. it is another to place references at useful points in the text - these are few and far between in ITIL
d) ignoring important bodies of work completely e.g KCS, BiSL, ASL...
Ignorance is not Bliss
Ian, et al, I agree that ITIL needs to recognize other sources; have commented to that effect here and elsewhere.
But consider that the whole conversation we are having about those other methods and frameworks is partly because they are described in ITIL. written for IT professionals to recognize and understand good practices that they need to consider and where appropriate adopt.
I read the ITIL books, they trigger AHA moments. This in turn drives research into the concepts.
Ignorance is Not KNowing that you Don't know. - In many cases you will then get an ill conceived response.
ITIL has many flaws, but it gets people thinking about things they did not necessarily know about.
Knowledge and awareness begins with Knowing what you dont know.
I have taught and consulted with ITIL and ITSM for years. When I say ITIL points the way, I mean that ITIL is the way many of the IT professionals I meet are introduced to management (Finance) and marketing (SLM) concepts, in terms that they recognize.
When we talk, align with the business or integrate with the business, we are really saying you Must use the business language and concepts to sell your solutions to your non it peers and senior management. So far, ITIL has proven to be an accessible medium that triggers the awareness.
2 cents on a Thursday morning on a divergent tangent.
unconsciously ignorant to consciously ignorant
I agree that ITIL moves some folk from unconsciously ignorant to consciously ignorant :) But
1) many many IT people do ITIL training and now think they are informed and educated. they remain ignorant of other bodies of knowledge. Some international trainers and assessors are apparently ignorant of other bodies and unable to accept anything but ITIL as the bible truth.
2) as I posted above ITIL points the way so very very badly. in the specific example here of root case, does ITIL point the way or does ITIL suggest it is the last word?
3) i think the majority of ITIL trainees never really read the books. for them ITIl is the training they had and how often does ITIL training suggest ITIL is merely a map to broader knowledge? I'd suggest not very often
The curse of the v3 expert
I think it is fair to say a lot of us are very uneasy about people claiming the title "v3 expert" just because they have done an exam of that name.
1) I was one of the quality reviewers for v3 but I would not claim to be an expert in v3, and taking the bridge exam wouldn't alter that. I think it will take me a least another year to explore the content of v3 enough to feel I'm expert in it. For instance, despite grandiose claims, I have yet to find an organisation that has "migrated to v3" that is doing anything I wouldn't have expected them to be doing under v2 or even v1.
2) Also as a reviewer of v3 I know how many basic mistakes are in it.
3) Thank goodness, they would be even more confused of they actually read the books;-)
ITIL has always been about more than the books. That didn't matter 15 years ago when anyone who was anyone in the ITIL world knew each other. It does matter now. It also matters that people coming out of ITIL training having seen an entire profession or skill reduced to a couple of slides should not believe they are expert in those areas.
I think we all, pretty much, want people to realise that the world is a lot bigger than ITIL.
Think Customer
Glen
You make a few good points but I would like to take you to task on one.... Yes the ITIL books translate many pre-existing (business) concepts into IT terms, but all too often at the cost of the original definition. Take the Service Strategy book - its actually trying to describe much of what takes place in a product marketing arena. Some of the terms are reworded, many key concepts missing (I am writing to this in a pocket guide).
There are so many examples of vital concepts that ITIL and its proponents (often vendors) now trumpet as must-haves, service portfolio, service catalog, configuration management database, service knowledge management system. But how many of those who have written about these and now recommend we build, buy or borrow them have actually seen one, or better still made one? All of these have relatives outside of IT and ITIL and when found offer a wealth of information.
Ignorance of the true source and method = huge risk of failure.
The ITIL books are often positioned by some as the definitive source. In fact they read that way and they seldom give credit to outside sources. We should expect consultants, vendors and trainers to be honest when discussing IT Service Management (which is much bigger than ITIL) and how ITIL can help. But I fear some feel it may mean they lose an opportunity. All this focus on whats missing is a danger - it distracts us from what service management should be all about - customer satisfaction, successful customer outcomes (SCO) and so on... the customer....
So remember, when someone suggests ITIL to you, or a service management 'must have', ask how they feel this helps the customer thingy...
Back to ITIL. ITIL is both lucky we have Google, and undone by it. If you search on Google for help you may find millions of hits and then be faced with the challenge of working out what represents good advice or counsel. So some fall back on industry 'experts'. We need more experts in ITSM not ITIL, to help us understand not whats in ITIL, but whats not...
Use ITIL to fill in the blanks of what represents a service management system, and service provider organization.... designed to think customer.... this will help you understand teh difference between incidents and problems, and how to transform the IT organization into a (customer) service provider...
As for your last comment - absolutely! It is a skill every problem management must possess to state a problem and its impact, and then describe the likely causes, without apportioning blame (unduly). A skill... a soft skill... seldom taught in any ITSM/ITIL practitioner class I've seen...
ITIL vs SERVICE MANAGEMENT
Hi Ian,
I have always considered ITIL to be distinct from SM. It considers itself 'good practise' in other words an accumulation of experience or body of knowledge.
Wheras SM is based on the concept of a 'service' which is defined in terms of a CMDB. To me both service and CMDB are not clearly defined and lead to confusion. ITIL for all it's faults is a framework take it or leave it wheras SM and iso20000 is a standard based on unclear concepts.
Rgds Rob.
Service Management v ITIL
Skep (Perhaps these belong in another thread)
Rob
Well I agree that ITIL is distinct from Service Management. Then you got me.... Did you mean (ITIL) is good practice an accumulated BOK? Well it has a case for both but... really? ITIL ws all about 'best practice' until someone at the OGC was rumored to have said it did not qualify and that may be in part why the best practice reference was removed from the V3 covers (?). Anyway, define the difference between best and good practice - ITIL can't.
Body of knowledge - about ITIL yeh.
Service management is actually based upon the concept of a goods-service continuum and born out of necessity within PRODUCT MANAGEMENT to design products that have more custoemr interactivity and stickiness. IT Service Management you would think is IT's application of service management concepts and methods to their challenges - well you would be wrong. Typically IT has reinvented service management, with dismal results.
ITIL is not a take it or leave it framework, its being positioned as a take it only option. It is NOT inclusive. SM is not a standard, ISO20K I'll give you is. Service Management as I have blogged elsewhere, and offered here, is a systematic METHOD for managing the provision of services to customers and ensuring that successful customer outcomes (SCO) are achieved and customer satisfied. ITIL has elements of that mantra in its opening gambit but then slumps into an oh so traditional inside-out and process, technology, service view...
ITIL in its quaint way actually started out to help us do service management, for IT. Somehow the readers proponents of ITIL and ITSM seem to have forgotten that, and therein lies the singular reason why most ITSM/ITIL projects 'fail the customer', and I believe their original mission. Unfortunately they truly are being tagged IT Service Management initiatives.....
struggling with your post
Hi Rob
I'm struggling with your post. if ITIL is "an accumulation of experience" then please point to who has experienced SKMS. And if CMDB leads to confusion may I point out that CMDB's popularity stems mainly from ITIL's promotion of the concept, which sits CMDB firmly at the centre of many processes within ITIL. It occurs to me that you may be refering to a different ITIL than the one I'm familiar with
What is this "SM" of which you speak that is "based on the concept of a 'service' which is defined in terms of a CMDB" and is a standard along with ISO20000? Disregarding OGC's top secret standard for ITIL product compliance, I'm not aware of any standard other than ISO20000.
And the idea that a service can be defined in terms of a CMDB has me completely stumped.
Perhaps I'll ask the ITIL Wizard.
Concepts
Rob,
Funny you should say that. In recent months I've been struck again and again by the lack of a simpler conceptual model at the heart of ITSM that would enable us to make judgements about the value of frameworks, standards, processes tools and innovations.
Concepts might not be quite the right word, since it has connotations of theory. I'm thinking more about statements defining the reality that ITSM addresses. I think I've used the term axioms elsewhere.
That there is something or things that people call a service, and that BAU IT provides and which needs to be managed is a basic concept. How we fully define what a service is belongs in a framework.
James
The lifespan of a good problem manager
In an immature organisation I reckon a good problem manager is lucky to survive two years, but they can achieve incredible things in that time period.
My personal preference would be for ITIL to focus on IT specific issues where it can add value and to emphasise the value of working with professionals in other knowledge domains. I would rather that someone went and talked to a management accountant and explained to them the issues around costing an IT service than that they try and do marginal costing themselves from the content in ITIL.
In the early days ITIL really was an IT manager's qualification, designed for and taken by senior managers who often already had a good grasp of some of the subject areas, or who had direct access to the specialists in those areas. I don't think that is the case any longer and the modern audience have different requirements.
A Service Management professional's 'Bucket List'
James
Might not be totally appropriate but I finally wrote down my own bucket list that I felt a service management professional should aspire to know - it was driven by some of the absolute crap marketed as training syllabii and my complete frustration in the general thrust of ITSM training. In there somewhere are a few generic items I feel a problem manager need to be tooled in... the list is here at my blog http://ianmclayton.com/?p=301
Item #9 is a definite.... add the ability to identify stakeholders, their interest, and how something impacts them, oh and the ability to state the problem and its impact without blaming anyone - staying neutral - and the problem manager might last a bit more.... oops one more - patience of a saint and obstinance of a mule - thats two but who's counting...
The perils of neutrality
Ian, I like it a lot, but the peril of being a neutral is that you end up upsetting twice as many people.
Recent debates have made me realise how important a knowledge of the scientific method, logic and psychology are, and proper audit skills.
I'm increasingly favouring a set of ITSM standards akin to those I'm used to as a professional auditor such as
http://www.theiia.org/guidance/standards-and-guidance/ippf/standards/full-standards/
A problem shared...
James - you reminded me of what my mum would say when she was alive - "a problem shared is a problem doubled (not halved)".... not very charitable I know but oh so true on too many occasions....