If we consider to sign SLAs with customer for CM, what we should enclose? For Routined Change perhaps we can put lead time etc in the doc, but for other type of changes, I am not sure what exactly we should mention since the target for Change is difficult to measure and commit, any suggestion? thanks in advance.

I thing that having SLAs for changes is dangerous. I will leave you to think why I might think that_________________DYbeach
ITIL V3 Release, Control & Validation,
ITIL V3 Operation SUpport & Analysis
PMI CAPM (R)

"In times of universal deceit, telling the truth will be a revolutionary act." George Orwell

Well..to me, this sounds like malpractice (or at least a grave misunderstanding). CM (to me) is an integral part of the IT/ITIL organisation. SLA:s are signed between the customer and the entire IT organisation via the Service Level Mgmt, not between the customer and a "subprocess" such as CM.

You will understand the implications of this, if you think a bit.

Example: A VIP customer could easily dictate/force a change with no business case by pointing at the SLA. Absurd. And totally non-ITIL, IMHO. "Fast lane"-thinking.

This is what we have RFCs and CABs for.

Would you let your customer sign a SLA directly with Problem Mgmt, too? I think not....

Your SLA (between customer and SLM, NOT CM) should contain the framework/routine for any changes. RFC > CAB etc. No lead times should be given whatsoever. This way, the customer will understand that any change requires resources and planning, and they will understand the need for them to be a part of the change, instead of just pointing with the whole hand._________________---------------- bragging line -----------------
V2 Combined Practitioner (service support)
Problem Mgr

An SLA on Change Management is the second most idiotic thing I can think that a company can implemt

The first is buying a tool without defining the underlying processes.

The prime reason is the following example

1 - you have approved a change for implementation by the microsoft team on Saturday from 1500 - 1600 local time. The work will require 3 web servers going down for maintenance and brought back one hour later.

2 - As the implementation team is the production support team, the engineer in question doing the work is the same team member providing support for any Microsoft oriented incidents

3 - at 1455, the microsoft servers - that provide the income generating area of the site go down. At 1500, it is realized that this is a critical P1 / Major Incident issue. Not on the same servers being maintainanced

4 - so what should the Production support team do

If there is a SLA on the change mgmt process, they must meet the SLA by implementing the change
But Incident Mgmt also has a SLA

So the duty SD lead is in a quandry, since the company put SLAs with service credits ($$££$££) as a recourse, what should he / she do ?

Stop the change and give service credits for failure to implement change
and work on the MI
or
ignore the MI and work on the change - giving service credits for the failure to deal with the MI

Granted, this is an extreme and most unlikely happening.. (it did happen) but w/o SLAs

The Changes if approved are implemented on a best endevours basis. There should be no SLA against CM at all.

The OLAs with CM process are another kettle of fish

But, what if you are providing service to customers - external and they have CM that you must implement.

Sigh. Then there should be an SLA against the service request itself not the change request and there should be clear understanding on the level of service (change implementation) and the standards for implementing the work and it must match the environment structure of the client more so than the service provider_________________John Hardesty
ITSM Manager's Certificate (Red Badge)

Excellent John - (sorry off topic) am happy to know that my company falls within the #1 idiotic things they can do! Seriously though, we did do that but truthfully they did it before they adopted ITIL. We're kind of stuck with it right now due to budget cuts though...

SLAs are for services. Change Management is not a service. It is how you manage changes to services.

I think SLA for problem management comes a close third and I have seen it proposed often enough.

Of course, you could provide a change management service for a customer, but it would not be an IT service unless the customer was an IT service provider. And you would use the customer's change management system, even if you had to make it up as you went along._________________"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

Just to emphasize, and please correct me if I'm wrong.
CM is "the other way around" stuff to SLA.
SLA is an agreement between Service Provider and a customer, it emphasizes the customer's need to goodies from the Service Provider.
On the other hand, CM lead time, for instance is the CM's need from its counterpart (other functions, processes, customers) to give adequate time to assess a change request (impact, risk, cost, etc) before implementation.