What do you as an IT Service Manager do?

[ITSM]

Hi,

as an IT Service Manager in a company that's fairly new with ITIL I find it hard to focus on what I really should focus on. I have a hard time trying to explain that it's really not my task to work in the SD daily, but to make the flow more efficient for the user as well as the company.

What do you do as an ITSM?

[Diarmid]

Job titles are a very poor guide to job roles these days. As someone trying to find a job I see this every day.

What does your job description say your job is?
What responsibilities have you?
What Performance measures are set for you?
Have you a breakdown of roles, perhaps with expected percentage of your time?
What objectives have been set for you?
Are there sufficient resources to do the things you don't believe/want to do? - do you control those resources?
Have you mapped out all the roles under your authority?
Do you have a plan to achieve performance of those roles?
does your plan balance the immediate service needs with the need for planning, development and improvement?
Can you demonstrate to your management that it is not necessary for you to be on the SD every day?
_________________
"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

[Probuddho]

Thank you ITSM and Diarmid I was exactly looking for this kind of a question, I would also like to know what ITIL says about the Ideal role of a incident and problem manager in an organisation.[/7113]

[UKVIKING]

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
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[thechosenone69]

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.

[Diarmid]

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?
_________________
"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

[Diarmid]

... or

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

[UKVIKING]

Take the early train as the crappy weather may make the later train non existant

and good luck
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[thechosenone69]

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"
_________________
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.

[Diarmid]

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.
_________________
"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