hmm. not sure how much of each process you plan on having up and running before you start on the next, but from my Problem Management Practitioner point-of-view, I think I would have been sunk without some kind of Change and Config being there first.
/Sharon E

My vote, and it's a biased one, is to implement them all at once. The organization that tries to roll them out one at a time will spend a fortune, over time, and will have a bunch of processes and point solutions tools that don't integrate and compliment each other properly.

If you find a tool, like ours, that can provision a platform of solutions for each of the domains mentioned, all at once, then all you have to worry about is focusing on the process definitions and implementation, which can be done rather quickly once the tools are in place.

Remember, if you roll out one process at a time, you will need to pick tools to support that process. The tools you pick or build will rarely, if ever, be compatible to the tools you are going to pick and use for all of the other process domains. What this will lead to are very expensive post deployment costs, associated with the integration of all these individual point solutions.

If you can, I think SLAs should be one of the last products of an ITIL implementation. SLAs need to be based on reliable metrics, with processes and procedures in place to collect and monitor them. All too often SLAs are cut first based on myth, and far too much time is spent trying to meet unrealistic goals.

I may as well add my current thinking in regard to the processes mentioned. Take into account the fact that we are not yet formally implementing ITIL where I work, I'm kind of slipping ideas for working practice through the back door until we get the official go ahead!

1a. - Part of SLM - defining the services before...

1b. Service Desk and Incident Management- I think that a relatively mature incident management and service desk are needed before putting anything on top of them to help understand what it is you are actually dealing with.

2. Change - If you aren't dealing with faults, then you are dealing with changes to the service, configuration, etc. So I think this process is important before you start on configuration otherwise you have no control over what is there and how it is updated.

3. The rest of SLM - WIth the first parts in place, you should have the basis for some measuring and be able to create a reasonable SLA with realistic expectations.

4. Config - This is important to support all the other processes, but as I already said, there is no point having it without a good change process in place.

5. Problem - Out of the processes mentioned I view this more as a 'nice to have' and put in once the basics are right and everyone is working together. If you have enough people to put it in alongside Incident management then great, we don't.

I'd be listening to the people who have actually done it in the real world rather than me

Good point on the change, config, and release. I tend to see the change and config a little like the chicken and the egg quandry. You don't want to have config without change for the reason I stated above, but equally you don't want change without config as you want to know what you are impacting. The answer, do both!

Ideally the three go in at the same time due to the dependencies between processes.

In the same way ideally you'd look at service desk, incident, and problem as a group correct?

I honestly don't think there is any easy or right answer to this one. No matter which processes you opt for, you'll always be missing out on the benefits that are brought about by having all of the processes.

I suppose the real question is which benefits do you want to achieve first, then implement the processes that help you get there... Thoughts?

However, they gave me more questions than answers since my teacher at the ITIL Service Manager course gave the following order and reasons of initial processes to start with:

1. Service Level Management - In order to define what to deliver and what the requirements are.

2. Service Desk, Incident and problem - In order to start delivering what customers expect.

3. Config and Change - In order to handle changes of the infrastructure.

Those processes show the quick-wins best and will then handle the risk of loosing commitment after first year. In a pure best way according to ITIL my teacher said starting with Config and Change would be best, but then you could have hard time getting attention after a while since implementing those processes will cost and doesn't show the quick-wins as good as the previous suggestion. Any thought about this?

I guess there is no single way (right or wrong) of how to do this, so it was interesting to get all your oppinions.

your teacher is pretty much on the money. I would suggest the following clarifications might be helpful:

Services are the heart and soul of the ITIL framework - everything revolves around this concept and without it you are just doing better technology provision. So yes SLM is the obvious strating point.

The good news is that Service Definition (and Service Level Management in general) is probably the most scalable process in ITIL. If you start by simply producing rudimentrary Service Definitions, perhaps a simple catalogue of services, and in the absence of mature customer relations you can implement Service Level Objectives (unilateral) to stand in for missing SLAs.

That will be enough to kick start your Service Desk and Incident management process. These too can be scaled effectively. The trick is to keep them in scope, and not to overload them with compensations for the missing processes. The example I site most is the tendency to build an initial incident classification schema that categorises your infrastructure. Totally unecessary - a simple service / symptom type schema can support all you incident managment objectives and produce excellent business information.

The usual step then is to implement problem and change mangement.

Problem management is less problematic than you might think - because most of the 'firefighting' you curently do is probably that. The hard part will be to build the process connections between you incident management and problem management processes to ensure that problem management is being driven by the service quality imperitives your incident management process should be identifying.

Change management can be scaled also. Of course it is best if configuration management is in place - but there will be a lot of standard changes you can begin with. Secondly, you are already changing things without config management. There is a lot in change management that can be of value even without a CMDB to update, because it will introduce formal assessment, approval, planning, back-out planning etc. (Of course these are more effective with advanced config data, but that doesn't mean these disciplines have no value in their own right.)

And finally config management: This can actually be scaled. As I said you are already dealing with the infrastructure anyway - to whatever level of competancy. So instead of trying to build a total-it-universe picture, and aim straight at delta-audit capability, think of the CMDB as a 'picture' of your infrastructure - an abstraction. or representation that you use in management control processes. There is a differrence between 'accuracy' and 'detail' - in both pictures and CMDBs. (A picture of the earth from the moon has less detail than a picture from orbit, but it is just as accurate). In the CMDB accuracy is actually more important than detail.

Which is a long winded way of saying you can scale a CMDB from the top down. Start with your Services, and populate the CMDB first with simple records representing the major systems that produce them. Apply change and configuration management controls at that level - it can be done, because that's already what's going on in the heads of your technology owners anyway. Then as you develop and mature your processes, and especially your service definition model, you can extend the scope of the CMDB 'down' into the detail of the infrastructure, until you get to the point where the cost and returns are balanced according to your overall service management objectives.

I caution against the concept of 'quick wins' however - that always leads to dissapoinment. Rather I advocate realistic 'scope'. Learn how to objectively assess Service Management process maturity before you do anything, then set the initial maturity levels you are aiming for realistically. Make sure you identify the true value that can be achieved at the target level and promote that. Remember everyone who delivers more than they promise succeeds

Personally I know what it's like to slog away for two years and never seem to get anywhere, and I know what it is like to work for six weeks and return real demonstrable value.

I cannot imagine to have controlled Changes withouth at least some basic Configuration Management.

Problem Management I would put somewhere at the end of your list.

I don't think it is possible to implement processess one by one and that's it. You have to implement part of SLM, part of Change Mgt., part of Configuration Mgt. and then again and again until you reach satisfactory level.

It is a very good recomendation to see ITIL deployment as a big, long-term project, which products are handed over to Operations.