Egg or chicken?

[lv]

Hi all, I did the ITIL foundation a couple of years back, but have been out of that environment since then.

I've moved to an organisation that has Incident Managment but nothing else. It is apparent to me that Change Management is sorely needed!
Unfortunately I was a bit too vocal about my observations on the benefits of CM and the task has fallen to me!

I'm doing a lot of reading up on it, but am still struggling with whether to start with Change Managment or the implementation of a Configuration Database.
There seems to be a lot of conflicting information as to whether you need to start with a CD or if you can get CM in place first.

I'm in a decent position in order to get access to the key stakeholders of the business and the CEO is supportive - although not to the extent of having a dedicated team or lead on the implementation!

Can anyone give their opinion on which aspect to start on? I'm not looking for someone to hold my hand through it (although if anyone wants to ) but some pointers would be appreciated.

[UKVIKING]

The answer is the mice are responsible

Sigh. If you are in the UK, I recommend hiring Diarmid for 180 days to help you get the processes started and on track.

Now for the answer to your question. It depends.

I was in a similar situation. and the way I did it is as follows

I got Change off the ground first. It was easy to identify change requests and get the individuals / groups / to start to follow the process once developed

The Config mgmt process involved the system support team, the network support team and the key group the Data centre team as we hosted our kit in our own DC. It took longer to get the processes in place as we had to do several things
identify the kit
separate the kit into prod, etc
processes for adding, removing kit and 3party kit add, etc

then of course release mgmt

All three should be starte together but the process development cycle for each is very very different in time... usually
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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

[ChangeOfficer]

If you have change without config you may have trouble determining the scope of what is a change.

If you have config without change then even if you are able to document your environment's configuration you won't have the change process to govern it.

I suppose it comes down to which of the above is more of a pain point for you organization.

[UKVIKING]

CO

Exactly correct. As you start the CM process, you start the CfgM process and the RM process.

As you gather more info about the CIs, Services etc by asking in the CM process you slowly establish the CfgM process and the RM

Yes it is messy but it helps start the process

what usually happens is that once the snr mgmt hears this... and if the you the CM points it out to him... he may assign more staff to help you organize all 3 at the same time
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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

[Diarmid]

The underlying purpose of Change Management is to ensure that changes are performed in a controlled manner. You do not need a CMDB or Configuration Management to do this.

A CMDB that is not subject to Change Management is a hazard, not an asset.

However, without a CMDB Change Management can be very difficult, costly and exposed to significant risk.

Don't forget, taking away the capital letters, your organization is already managing your infrastructure and services and is already managing changes. Unless of course you are not yet providing services and do not have any computers.

How maturely you are doing this now, will be a major factor in deciding how to go about the improvements that ITIL has inspired (or provoked) you to do.

It makes sense to start on both (and, as John said, Release Management also) at the same time, but you can get some kind of Change Process up in two shakes of a cat's tail (don't tell my cats! - they're lambs really) whereas there is a lot of technical detail to resolve for the others.

I don't see why you can't start by sketching out the overview of the processes and then quickly put in place some form of Change Management that will evolve and mature as you get further down the track with the rest.

From that perspective, ISO20000 is probably the best guide for the initial Change Management process.

Hurry up with the offer. I've a couple of interviews next week.
_________________
"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

[ChangeOfficer]

I've talked to a few service management software vendors who emphasize that the CMDB is the critical starting point of IT Service Management as part of their sales process so that may be driving opinion in this area.

[Diarmid]

Knuts to software vendors.

Try this:

If you don't manage incidents, how do you ensure service to users and how do you know if you have problems?

If you don't provide a service desk, how do you ensure you know about incidents.

If you don't manage capacity, how do you ensure it won't all grind to a halt tomorrow morning?

If you don't manage service levels how do you ensure your customers get the service they pay for?

If you don't manage changes, how do you ensure anything will work again?

etc. etc. etc.

Of course each of these is probably easier to do if you have a CMDB, especially if you have a perfect CMDB.

But the real answer is that every site does all these things (and has pretty much all the information about its infrastructure and services somewhere), however adequately or otherwise and where you start is where the improvements will count most.

It's not often you get a chance to start from nothing and if you are not starting from nothing there can be no one single ideal route to take. "If I was going there, I wouldn't start from here" is not the right answer in the real world.

Perhaps these vendors have systems that don't function without a CMDB, but even then it could be quite skeletal to begin with.

If you do start with a CMDB, at the very least you have got to work out how to manage it and put that in place before you start. And once it is set up no one will be using it if you are not doing something else (such as incident management) already.
_________________
"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

[swansong]

[swansong]

[ChangeOfficer]

Did I say that it should dictate your policy?

I said it might be the source of this opinion.

[Timo]

My approach has always been that if there are not enough time and resources to develop config and release along with the CM process, then do your best diligence in those areas. Even something like high level guidelines will be helpful. Maybe incorporate some of the config and release crucial elements into the CM process. It's all about balance and common sense.

I often work with companies where IT departments are very small... so you gotta improvise