Change Management Implementation Targets

[ViktoriaM]

Hey,
I'm trying to implement change targets in my organization. Some months ago we've certified ISO 20 000 and the leading auditor adviced us to implement targets for the different types of change, so we can provide service level to the customer . For example change with Law priority must be fully completed withing 10 business days, with Middle priority- 5 days, and so on. ITIL dosn't say anything about this kind ot targets.
Does any of you have tried to implement that kind of target, can you share some experience please.

[Diarmid]

ViktoriaM,

this is a strange notion.

Changes should be implemented when they are required In other words at a time agreed with the requester.

The time required to implement a specific change is more dependent on the work involved in doing it than on its priority and there is no obvious correlation between the two factors. Priority is about giving it the resources it needs ahead of less important tasks and behind more important tasks.

It would be strange to deliver a change a week before it was wanted in order to meet such a target, especially if the early delivery was damaging to the service.

To me a meaningful change completion target might be to achieve 100% completion on time and it would only be counted once the change review had verified it.

I suppose you could have 100% for high priority, 98% for medium priority and 92% for low priority changes. Of course to do this you have to remember that ASAP is not a valid date format.

Perhaps you should clarify with your auditor just what was meant.
_________________
"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

[SwissTony]

Hi Victoria, welcome to the forum....

We have targets in place....we seperate them for each approval stage, & each type of RFC (standard, normal, emergency, etc). My guess is that this is what your auditor is alluding to. With these measures in place there is a standardised timing that change requestors can rely on, and also provides guidelines for the approvers to do their job, instead of RFCs sitting & not being addressed by the approval groups.

Timing depends on your situation....

[ViktoriaM]

Thank you for the quick responce.

Diarmid,
I understand very well what you men because that's what ITIL is stating (or not) about change management.
The purpose of this targets are not for providing SLA to client, but for imternal quality. I really need to set some borders to my team, otherwise it seems to me that they are taking too long time to implement changes. How do you manage this?

SwissTony,
That's exactly what I ment by change targets, it seems that you've managed to implement those targets. Can you share please your approach. How did you found what exactly your time targets are? How did yout team met them? What happens if the target is not met?

[Diarmid]

ViktoriaM,

I hope I did not mislead you. I was not talking about SLA targets, although you could use those kind of figures in an SLA if you chose.

My real point was to emphasise that the time to complete a change is nothing to do with its priority. Tony covered the issue of the time to get started on the management process from receipt of request, and that is to do with priority.

But each change potentially requires different effort from different people and you can only go so far even in the planning part of the process to put general time limits. The more you want to do that, the more you have to be formally prepared to recognize the exceptions that cannot conform because of their nature.

Once you have got to agreement on the plan, all further measures should be against the plan only since the plan recognizes how long things take, when things are needed and when resources are available.

I do not distinguish something called "internal quality" although I understand what you are thinking. All quality is focussed on the customer, its just that some aspects may not be directly exposed to the customer's gaze.

If you feel that units or people are dragging their feet, then that is really a management rather than ITIL issue. I believe there are some threads already that talk about discipline and incentive and your approach to that area will be governed by the culture and attitude of your own organization.

However there are ways to underpin and promote this and they rely on you already measuring how long things take. Firstly if your customers are dissatisfied with the time taken then you discuss this to get a measure of the scale of improvement the customer would like and you put in place an improvement plan to achieve it. It may be the case that the level of improvement required will involve additional costs (more training, more staff, use of third party services, additional software tools etc.)

If the customers appear happy, then you still set up an improvement project and set yourself targets. This time you will be looking for a net reduction in cost and you will certainly not be increasing charges to the customer even if you provide them with great benefit.

The staff will be fully involved in the improvement initiative and will "own" the improvements. Investigations will establish what can be improved in order to reduce the times taken. It could be as simple as raising the priority of work on changes, additional training, better allocation of tasks in terms of competencies, redesigning procedures to improve communications channels or to eliminate bottlenecks. etc. etc.
_________________
"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