Requests for Change

[Funk]

Hi There,

I've recently taken over responsibility for a helpdesk function & am looking to introduce some basic change management. At present all change & project requests are done on an ad-hoc basis, mostly by word of mouth, & are a complete nightmare to keep track of - I mostly find out about things the day before they're required!

I'm wanting to formalise this & introduce an RFC document so we've got an audit trail, as well as capturing all of the information we need up front. I'm meeting some resistance to the changes I'm wanting to make - the next person who says "But, we don't do it that way here!" is going to get a severe beating - so I'm keen that the new document should be fairly user friendly/idiot-proof! I've been looking in the Change Management section of the Service Support book but this is going into more detail than I really need at present (e.g. we wont have a CAB in place). It gives details of everything that should be in an RFC, but its a bit like a recipe with ingredients but no instructions on how to mix them!

Any suggestions where I go from here?

Cheers

[itilimp]

I'm no expert but for what it's worth...

If you're meeting a lot of resistance I'd start small with some processes (supported by forms where necessary) for standard changes before launching a full change management process. That way when they see the benefits/problems that are eliminated by one change process they will be more willing to try others.

e.g. New starters, leavers, office moves, etc.

1. Identify which areas are causing you most hassle right now.
2. Identify what problems are actually being caused by lack of change mangement
3. Quantify how much time is wasted
4. Translate time wasted into a monetary figure for management to understand
5. Implement a slimline process to ease things in then develop from there.

If it's too onerous people will just bypass it.

Ideally you want to have a session with your collegaues and have them brainstorm what the problems are then show them how a process could help eliminate/mitigate those issues. If you're in the situation of 'we've always done it this way' then it may be hard to get them to open up in this kind of way - but you have to start somewhere

Oh.. I just noticed you are from a borough council! I work at a district council down south myself so know exactly the kind of resistance you are meeting

[Rache]

In my last role on a small project for 6 month i set in place a very small scale process using PRINCE methodology but very simple. I created a simple excel log and a simple form detailing the change and a RFC number then boxes to be filled in by impactees (this could change with the change or be set depending on your organisation) our CAB/CCB as it was called only consisted of 3 people a project manager someone from IT and someone from Operations we did ensure that FInance / Budgetry holders had impacted the form. The CAB/CCB function was done via email / tele conference and it simply said has the change been agreed if it was yes the change was accepted and then went on to be scheduled / implemented if not it was for the author of the change to revisit / liase with the impacters to rejected it. We only had 3 changes and never had a RFC that didnt get accepted but it provided the relevant audit trail.

[Ed]

Having already gone this route - this is a tough call - I introduced a paper based Change Management process into ourcompany, because we were having all sorts of problems with servers/ processes crashing around our ears.

The major thing is buy-in from senior management - it you can get their backing you are halfway there, because you can grow teeth with a CM policy document that insists that not complying is a possible disciplinary offence.

Our form is a word document that traps a Change Summary, Business Impact, Date, Time & duration of Change, Implementation steps Regression steps, testing, sign-off. we also use the form to collect Serial Nos, locations etc for hardware installs

Although we are med/small we have a virtual CAB (all our signatories)
Implementer, Service Desk, Service Account Manager, Peer Reviewer, Operations & Change Management. We don't meet it is all handled by E-Mail.

We limited our remit to the 'Live' area only unless it was a hardware install.

You have to keep pushing on and educate your users - we saw major improvements after approx 2 years and have continued to inprove the service ever since.

The more people you can get through the Foundation course the easier it becomes (You start singing from the same hymn sheet).

I could go on for hours, but I don't want to send everyone to sleep

I hope this helps

Regards

Ed