Change Request required fields

[ChangeOfficer]

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.

I require:
Change Type
Implementation start/end
Group responsible
Implementing group (if different)
Business owner
Reason For Change
Business Impact
Change Description
CIs impacted
Implementation steps (and who is responsible)
Test Plan
Test Results
Post Implementation Validation Steps (and who is responsible)
Communication Plan
Rollback plan
Risk Assessment (Risk description and mitigation)
-------------------

[changeborg]

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.

[UKVIKING]

CO and CB

How about the release environment path

what environment used for testing
when

how about the testing type

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

and proof the change followed the appropriate process / workflow
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[ChangeOfficer]

I capture the testing details (environments, type) in the test plan.

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.

[UKVIKING]

CO

Yes. I do know that having specific fields forces the unwilling to do what is required

I was talking first in generalities

Here - I have 3 (4) distinct environment types - production, qa/(test), test, development for each application grouping area

This is based on release mgmt criteria - run and maintain and design and build.

And then there are the 'custom'ized specialized apps - that need the same 3/4 set up

The CM process - forms, fields - forces the user via LOVs to choose - development environments or QA or Test or production -

the testing i break down into

acceptance
unit
system
regression

etc etc etc

as the world is primarily is a Appl support world
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[ChangeOfficer]

Would probably be of benefit to me to more explicitly document the types of testing done as that is one of the main points of contention for us.

[changeborg]

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.

Is this bass-akwards?

[Diarmid]

cb,

I don't know what "a purist ITIL standpoint" is.

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

[ChangeOfficer]

Change Management should be validating that the testing conducted was sufficient to minimize risk to production.

If a change was tested but there are differences between the dev/qa/test environment and the prod environment then risks exist and should be documented.

You might say that not all changes require full regression testing or performance testing so those things may need to be looked at depending on the type of change being done.

You may want a different person testing than who did the design and implementation. This may not always be possible depending on your resources available.

Ideally you want to define as many of the testing requirements as possible but there are barriers to doing so.

Ultimately the CAB must evaluate how a change was tested, who was responsible, what environments, etc and decide if the risks are outweighed by the business need for the change.

[viv121]

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

[DYbeach]

Love this! It feels like family.
_________________
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

[Diarmid]

What is the relationship between these two observations?

[viv121]

Its like there is just one way to moksha/salvation/god god and there are a number of ways to reach there. I felt that ways.
_________________
regards,

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

[DYbeach]

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