Getting started - the first four processes...

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

The order IS important especially in ITIL 'greenfield' sites.

Personally I would 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).

Now, the ITIL purists out there 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 business 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. By now, you should have won over the hearts and minds of the IT management group and some folks in the business areas too. They have seen that this ITIL 'thing' actually delivers benefits.

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. You have a focus area to look at whilst setting up and implementing Change Management. You can use this a your initial benefits case for expending resource.

Once you've done all that - you need to systematically 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 post!

Disagree? Got your own smarter ways of doing things?

Please post your comments below and share with everyone your own experiences...