Implementing Change Management

[Chris]

I was sent on an ITIL course because our company wants to institute formal change management. We already have an SLA (though not exactly as described) and a Help Desk. We have rudimentary Configuration Mgmt, no formal release or problem management - although these are practiced. I am wondering about the wisdom of starting with Change Mgmt. Do you think it's a good idea? We already have Incident Mgmt in place, with a Help Desk and some escalation procedures. Opinions??

[Harvey]

I have heard that simple Service Desk, Incident, Problem, and Change management is a good starting point.

Could I ask you to describe how your Configuration Management currently works?

[Ace-Server]

Chris,

I've rolled out Helpdesk, Incident, Problem and Change twice in two different organisations over the last 10 years...here's my advice based on my own practical experience...

1. The order IS important. Personally I roll out the essentials of each process in this order...

a) Helpdesk - calling acceptance, logging, basic fixes, tracking, escalation, transfer to incident and problem mgt functions, call closure. You know the basics. But do them properly. Have SLA's with target response and fix times in there for the Helpdesk and underpinning support teams to follow.

b) Incident Management. Formalise procedures and have dedicated staff managing live incidents. Your aim to for these people to succesfully coordinate the restoration of 'normal service' to your organisation.

c) Problem Management. Include root cause trending, analysis, investigation (with the IT support teams and/or experts) and eventually elimination.

d) Change Management. In poorly controlled environments you will find that 20 - 80% of all incidents are (in some way) caused by failed changes. Therefore it is important to establish the Change Management function quickly after (a), (b) and (c).

The purists may disagree with this order - but I feel for a commercial organisation to operate profitably you really need to minimise system and service downtime by having an effective communication channel into IT (the Helpdesk), an effective level of support from IT (incident management) and some confidence that repeat major incidents (or high impacting ones) won't happen again (Problem Management).

Once this stream of processes is in place - it's then much safer, cleaner and easier to introduce a sound Change Management function.

If you think about it you'll also know (from your incident and problem data/reports) exactly where the pain is coming from with respect to failed changes. It could be Infrastructure upgrades, it may be poorly implemented projects - whatever.

Once you've done all that - you need to sysstematically re-visit each one and make it more robust, more efficient and deliver a greater output compared to the running cost of the function. Sexy things like shared service centers can be created (where resources do all four roles and work flexibly). But that's a whole new area.

I hope you find this useful...please feel free to respond back with further questions/thoughts...

Good Luck!

[Guest]

Thanks for your responses. Since I sent this request, I've been on another training course, one in which I learned about Change, Configuration, and Release management. Great course and I'm motoring on with Change Management.

Sorry Harvey, I never answered your question! Our Config management is quite rudimentary at this time as it turns out! We have a person who records all of our inventory - this is a clerk level. The product we use is Magic Service Desk and has quite a good configuraiton module but I don't think we've been using it properly. We've just undergone a project to enhance the product and probably add the Change Management component to it.

I'm struggling now with setting up an ARCI matrix. Is this job security??
Chris