Curious to see what information you all are requiring for your change requests. I have a fairly extensive list but am always looking to balance required information against value-add and time spent on completing the form to have the process not only effective but efficient as well.

CO - You pretty much hit the same information we have determined to be important but as I'm sure Viking will tell you, make it as rigorous or simple as your organization deems necessary (don't want to step on your toes there mate).

However you have given me a few ideas that I think we can use which may add more value over some of what we have now. Beyond your list, here is what we require
Impacted Service
Region (We are global)
Relation (to incidents, requests, etc)
Reason for change

We have the ability to run auto reporting on any of the fields so various management find the fields useful to help keep an eye on everything they are accountable for.

Hope this helps to give you some additional fodder for thought as yours did mine.

what kind of testing was done - this is kind of critical for application CM

CO,

The specific fields are not important, the impetus should be on

Proof there are plans - imp, back up , back out, pre testing, post testing
proof the deployment has been tested
proof that there is a team to do the work, date and time
proof of non CAB approvals - business, technical, etc etc
and of cource CAB approvals

For our culture having specific fields is critical since there is great resistance to the process and only what is explicitly asked for is provided. Having dedicated fields without getting ridiculous greatly reduces the back and forth.

This is getting slightly off topic but I have a question on the testing discussion here. From a purist ITIL standpoint, it is my understanding that the testing simply needs to be documented within the RFC or am I off base here? To put more context to my question, is it the 'job' of change management to dictate the level and types of testing to be performed based on the service line?

The approach we are taking as part of our CI program of work in 2010 is to work with the individual groups (apps, infra, etc) to develop underpinning processes for their individual domains which are inputs into the baseline CM process. So while we are not dictating the types and amounts of testing, we simply require they document the steps and results within the RFC.

You have to think in terms of your service management system rather than its components. The key here is authority to sign off testing. You don't approve a change implementation until the testing has been signed off (among other things). Where that authority rests will vary according to what is being changed. It may be that the authority is set by policy for specifics or it may be that, say, the CAB defines the authority in a particular case.
I would expect the Change Manager to have an input to the policy.

The testing criteria may also be established by the CAB, or in some cases they also may be pre-set for a particular CI, or, quite likely a combination of the two.

The very minimum that CM requires is that it is assured that the test criteria and the tests and their evaluation is all conducted by the right people with appropriate skills and authority. That is what it wants to see. CM is not interested in the test results per se, rather in that they have been properly assessed. It does expect other processes to be performed to the right standard.

In practice, I would be surprised if the CAB did not have at least some input regarding acceptance criteria, because the members are likely (and ought to be) knowledgeable in the area of the change._________________"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

I ask the following questions in the CAB or while approving the changes. Will the auditors of my organization catch hold of me?

Will there be an outage associated with this change?
When?
Is the outage scheduled within the SLA’s maintenance window ?
How long?
Who will be affected (internal or external customers)?
What type of outage will the customer see?
What type of calls may the Help Desk(s) incur?
In case of releases, What knowledge articles are already been provided by the projects folks, if, 1. Changes passes without impact, 2. Change passes with impact, 3. Change fails without impact, 4. Change fails with impact?
What are the impacts of a backout?
How long will this take to backout?
If change cannot be backed out, what is the impact during the “fix and go forward”?
How long before services are normalized?
What is the impact if the change is not implemented as scheduled?
Are there any dependant changes associated with this change?
Are there any dependent CIs/Services associated with the CIs/Service undergoing change?
Are the service owners of the dependent CIs/Services aware of the change?
What customer groups are affected by this change?
Are they aware of any planned outages?
What verification procedures are in place?
Who is participating in the verification of the change?
When is the verification scheduled?
What type of verification is being completed?
How soon can the Service Desk be informed about the progress of the change (in case of releases only)?
How can the service desk and technical functions be informed about the known design errors (in case of releases only)?_________________regards,

Vivek
"the only statistics you can trust are those you falsified yourself"
Winston Churchill

_________________"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

It's kind of neat to know that there are other strange people on the planet who find CM interesting_________________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