The process owners are currently residing in the Process Improvement Staff function, but we are thinking of pushing the "ownership" into the organisation (I like to elaborate on all process ownership, but lets stick to SLM first).

As I said, Process Ownership currently sits in the Staff Org Processes. We would like to move it to the organisation. But where do you put them?

One idea is to give the ownership of SLM to all the Area Managers. Because they are already quite overloaded, it might do good to give them all one (1) Service Level Manager for their area.

On the other hand, If I were a Service Level Manager arranging top notch services towards a business, I would want to report directly to the CIO and 'advice' or 'enforce' the area's to be 'compliant' to the Service Level Management processes.

I would like to ask your advice - since the place is one thing, but there is also the power, the politics, the (hidden) agenda's,...

SLM is very visible, but it seems to come to having an SLA first and then adhere to the process (maybe), something I would like to avoid at all cost.

Hmm... I'll be interested in responses to this one as in the few contacts I've had I hear a lot of people trying to reorganise their organisatin based on processes which I happen to think is a little counter-productive.

ITIL doesn't require the process owner to be a line manager. They MUST however, have the authority to manage the process and others should be answerable to them where this is concerned.

So rather than the traditional hierarchial structure, you'd be looking at process management across functions (which is afterall the partly the point of processes being cross-functional, to improve communications!).

Having said that, my personal feeling is that changing people's working patterns and beliefs is the real issue here (especially in government organisatoins). It may be that if the process owner is a 2nd line support member of staff, other staff (particularly 3rd line and development etc.) will not follow process instruction given by this person as they are not senior to them within the organisation. Once the belief is challenged so that they realise not every process owner needs to be a manager, then off you go.

Another thought... everything I've said so far applies to most processes. In the specific case of Service Delivery however, I do believe that this SHOULD be a management position, someone on an equal footing to be able to negotiate services with the various service areas you are supporting, then having the clout/authority to ensure that the various ICT functions actually deliver those agreements.

My expectations at the moment are:
Incident management process owner to be a helpdesk supervisor or team member.
Problem management a member of 2nd/3rd line support.
Configuration management - someone who has the kind of personality that enjoys attention to detail and doesn't mind some administration.
Capacity management - member of the server team who enjoys ensuring 'their' network is in tip top shape
Availability managment - perhaps another member of a server team?
Release Management - a member of your development/infrastructure team?
Change management - perhaps a member of the development or support team? Most likely a team leader.
IT Service Continuity - perhaps infrastructure/support?
Financial management - you have a finance section so someone there.

*looks on with interest to see what the people with real world ITIL experience have to say*

Hi there, as a Service Level Manager I have the following observations to make on your query:
In theory where the Service Level Manager sits in the business should be irrelevant if they have been empowered to do their job to the full scope and they have buy-in from all levels of the business. Nice theory but I have not really seen this work in practice, especially not in government sector where the office politics are rife and people may only be responded to in accordance with the pecking order.

I'm not sure how many services you have, but having a Service Level Manager for each area might be overkill, but I have also observed that making other people (e.g. area managers) also responsible for Service Level Management means that it probably won't get done as it's not their primary focus, and if it does get done each one of them will be doing it in a different way.

You also talk about process ownership, perhaps seperately to actually performing the process mechanics. Owning the process can really be done by anyone sitting anywhere in the organisation who has a vested interest in that process, and they can quire capably perform other job functions too.

Having a central Service Level Management function reporting directly to the CIO certainly helps if that's where the clout comes from, but its important to remember that while the SL Manager might manage some tasks of people, they do not manage the people.

I think where the Service Manager sits in the organisation will depend greatly on the scope of SLM - and the general 'philosophy' that is dirivng it.

In many cases the focus is on the 'L' - monitoring and maintaining service 'levels' - as defined in SLAs. SLAs tend to focus primarily on quantifiable events, such as availability, response times to incidents, and etc.

Service Level Management, however, can involve much more. Ideally the SLM is responsible for managing a formal cycle of service development, improvement, and reporting - and manages services as a 'portfolio' - of which the Service Catalogue is a small part. In this approach the SLM would also be functioning as a 'Customer Relationship Manager' within the organisation.

In either case the SLM need not be a line manager per se. However in the more expanded role, (and depending on the size of the organisation) the SLM would probably require a team - A Service Management Office if you like (for whom they would be line managment).

Service Level Management in this case would finction much the way in-house project management offices work - and would probably work quite closely with project managment to ensure project methodologies included SLM specificc products and inputs - at specific stages of any project.

Like project management Service Level Management would also have a valuable role producing methodologies for infrastructure groups, to ensure that policies could be translated into practice in a way that ensures the Service development cycle, and Service improvement plans, are adhered to and supported.

This is slightly different to the idea of having an ITIL project office - which is more appropriate to the implementation phase. Even ITIL specific processes can become mis-aligned without clear direction. Service Level Management is ideally suited to provide this coordinating function.

In such a role, the SLM would report at a very high level - ideally to the CIO, and would not be the line manager for other staff. They would however, be setting some of the key parameters within which other managers would be expected to operate.

(BTW: What I have heard of ITIL V3 indicates this is the direction the OGC will take the next refresh - with the SLM being broken into three distinct chapters, and project management's role being accorded a much more integrated place in the framework.

What is particularly interesting about the next refresh, is that up until now ITIL was drawn from an analysis of what the industry was doing best. Now we have got to the point where so much of the industry is applying ITIL in some way, that the best practice ITIL implementations are going to be fed back into the library. Which is great news.)