What do you as an IT Service Manager do?
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
William Penn 1644-1718
the only ITIL says about an incident / problem mgr is that the roles should not be shared by the same person as the goals are diametrically opposed
Incident goal is to restore service
Problem goal is to find out the root cause if unknown
Incident goal is to restore service
Problem goal is to find out the root cause if unknown
John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
- thechosenone69
- ITIL Expert
- Posts: 268
- Joined: Tue Jun 05, 2007 8:00 pm
However you still find some companies combining the roles due to the lack of resources and it does have some advantages but as UK said its not recommended and its not ITIL and the disadvantages and issues it causes outweighs the advantages so try to avoid it 

Ali Makahleh
Configuration Management(Blue Badge),
ITILV2 Service Manager(Red Badge),
ITILV3 Expert(Lilac Badge) Certified.
“If you can't describe what you are doing as a process, you don't know what you're doing." W. Edwards Deming.
Configuration Management(Blue Badge),
ITILV2 Service Manager(Red Badge),
ITILV3 Expert(Lilac Badge) Certified.
“If you can't describe what you are doing as a process, you don't know what you're doing." W. Edwards Deming.
tco69,
as I prepare for yet another interview, I seem to be in a pedantic mood.
When you say "it is not ITIL" do you mean:
a) it is not best practice (even if it is best in the particular case?)
b) the ITIL books don't propose it
c) the ITIL books oppose it (in all cases)
[this is not an exam question because there are only three choices and I'm not going to say how many may be correct]
I merely ask because I am sure you have previously agreed that you cannot "do" ITIL and that neither ITIL conformance nor implementation are legitimate concepts.
I hold the view that it is perfectly possible to combine the roles so long as you understand the potential conflict of the goals and put process in place to manage that. Nevertheless it is preferable to separate the roles if you have the scale and resources to make that practical.
From the many job adverts I read these days I am well aware that many (including some very large) organizations routinely lump the two roles together and I seriously doubt if they have thought it through in most cases.
Now then, should I catch the 09.33 and arrive at 11.56, two hours before the interview, or should I take the 10.33 and hope it is less than half an hour late?
as I prepare for yet another interview, I seem to be in a pedantic mood.
When you say "it is not ITIL" do you mean:
a) it is not best practice (even if it is best in the particular case?)
b) the ITIL books don't propose it
c) the ITIL books oppose it (in all cases)
[this is not an exam question because there are only three choices and I'm not going to say how many may be correct]
I merely ask because I am sure you have previously agreed that you cannot "do" ITIL and that neither ITIL conformance nor implementation are legitimate concepts.
I hold the view that it is perfectly possible to combine the roles so long as you understand the potential conflict of the goals and put process in place to manage that. Nevertheless it is preferable to separate the roles if you have the scale and resources to make that practical.
From the many job adverts I read these days I am well aware that many (including some very large) organizations routinely lump the two roles together and I seriously doubt if they have thought it through in most cases.
Now then, should I catch the 09.33 and arrive at 11.56, two hours before the interview, or should I take the 10.33 and hope it is less than half an hour late?
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
William Penn 1644-1718
... or
d) nothing is ITIL
Now it is an exam question!

d) nothing is ITIL
Now it is an exam question!



"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
William Penn 1644-1718
- thechosenone69
- ITIL Expert
- Posts: 268
- Joined: Tue Jun 05, 2007 8:00 pm
yup, my director is stuck at home in Abandon for the last 2 days, she cant make it through to London 
So Diarmid, what i meant earlier was: that its not ITIL best practice and I dont recommend it my self. As UK mentioned earlier problem management is focused on identifying the root cause where as incident is focused on restoring incidents as quickly as possible..
But in some cases, some companies do mix the roles for several reasons, a most common one is the lack of resources. Also, I've witnessed this before. Where some IT companies DO NOT implement Problem management, although they have the skill set and resources and have a know error for a problem. But the management prefers to keep on fire fighting, to show their customers "value for money".. Sad but true.
Now assuming this is an ITIL V3 question, and I should choose the most relative answer. So its "D"

So Diarmid, what i meant earlier was: that its not ITIL best practice and I dont recommend it my self. As UK mentioned earlier problem management is focused on identifying the root cause where as incident is focused on restoring incidents as quickly as possible..
But in some cases, some companies do mix the roles for several reasons, a most common one is the lack of resources. Also, I've witnessed this before. Where some IT companies DO NOT implement Problem management, although they have the skill set and resources and have a know error for a problem. But the management prefers to keep on fire fighting, to show their customers "value for money".. Sad but true.
Now assuming this is an ITIL V3 question, and I should choose the most relative answer. So its "D"

Ali Makahleh
Configuration Management(Blue Badge),
ITILV2 Service Manager(Red Badge),
ITILV3 Expert(Lilac Badge) Certified.
“If you can't describe what you are doing as a process, you don't know what you're doing." W. Edwards Deming.
Configuration Management(Blue Badge),
ITILV2 Service Manager(Red Badge),
ITILV3 Expert(Lilac Badge) Certified.
“If you can't describe what you are doing as a process, you don't know what you're doing." W. Edwards Deming.
Weather report for yesterday:
N-u-L: mainly sunny
Derby: clear in mid-morning; some snow around tea-time
Leicester: heavy snow late morning; light snow tea-time
Birmingham: all I know is that lots of trains were not going their from Leicester in the late morning
If I can just add a bit on Problem Management, its ultimate goal is problem resolution. So-called (I always say that) root cause analysis is a core activity on the path.
There is a very interesting discussion on linkedin (Does a Major Incident automatically lead to the creation of a problem record?), in which some contributors get focussed on the root cause.../PM relationship, one even proposes that if you do any root cause... you must be doing problem management and ITIL says so (his words - I laughed but not out loud).
I think it is a meme (refer Dawkins if you are curious, but don't blame me because I don't agree with him either) cementing the link; a bit like his example "For the sake of auld lang syne" which translates as "for the sake of old times sake" and is not what Burns wrote; But even knowing this it is hard not to fall in after much repetition.
My other theory is that (ex-)techies (I'm one but I can only prove it if you resurrect an old 1906A or possibly a 2966) make the link because it is the techie bit of PM and bang in their comfort zone.
My third theory is that it's because ITIL overemphasises it and has done so since the original version (sometimes referred to a v1 - but just ITIL to me). I think this happened with an eye to problems with system performance on increasingly complex mainframes as that was a good part of the background of the early ITIL developers. They realized the concept (find the real cause- but they still called it root cause) was generally applicable.
Weather update: it's snowing this morning in N-u-L which is really aweful. I was brought up to believe that Saturdays were sacrosanct and nothing should interfere with football matches, not that I can afford to go nowadays.
N-u-L: mainly sunny
Derby: clear in mid-morning; some snow around tea-time
Leicester: heavy snow late morning; light snow tea-time
Birmingham: all I know is that lots of trains were not going their from Leicester in the late morning
If I can just add a bit on Problem Management, its ultimate goal is problem resolution. So-called (I always say that) root cause analysis is a core activity on the path.
There is a very interesting discussion on linkedin (Does a Major Incident automatically lead to the creation of a problem record?), in which some contributors get focussed on the root cause.../PM relationship, one even proposes that if you do any root cause... you must be doing problem management and ITIL says so (his words - I laughed but not out loud).
I think it is a meme (refer Dawkins if you are curious, but don't blame me because I don't agree with him either) cementing the link; a bit like his example "For the sake of auld lang syne" which translates as "for the sake of old times sake" and is not what Burns wrote; But even knowing this it is hard not to fall in after much repetition.
My other theory is that (ex-)techies (I'm one but I can only prove it if you resurrect an old 1906A or possibly a 2966) make the link because it is the techie bit of PM and bang in their comfort zone.
My third theory is that it's because ITIL overemphasises it and has done so since the original version (sometimes referred to a v1 - but just ITIL to me). I think this happened with an eye to problems with system performance on increasingly complex mainframes as that was a good part of the background of the early ITIL developers. They realized the concept (find the real cause- but they still called it root cause) was generally applicable.
Weather update: it's snowing this morning in N-u-L which is really aweful. I was brought up to believe that Saturdays were sacrosanct and nothing should interfere with football matches, not that I can afford to go nowadays.
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
William Penn 1644-1718