Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: E24A
New Today: 0
New Yesterday: 49
Overall: 148341

People Online:
Visitors: 57
Members: 1
Total: 58 .

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

Note: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


The Itil Community Forum: Forums

ITIL :: View topic - Change Request required fields
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Change Request required fields

 
Post new topic   Reply to topic    ITIL Forum Index -> Change Management
View previous topic :: View next topic  
Author Message
ChangeOfficer
Newbie
Newbie


Joined: Jan 27, 2010
Posts: 17

PostPosted: Thu Feb 04, 2010 5:58 am    Post subject: Change Request required fields Reply with quote

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)
-------------------
Back to top
View user's profile
changeborg
Itiler


Joined: Jul 15, 2009
Posts: 41
Location: United States

PostPosted: Thu Feb 04, 2010 6:51 am    Post subject: Reply with quote

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.
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3318
Location: London, UK

PostPosted: Thu Feb 04, 2010 6:46 pm    Post subject: Reply with quote

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
Back to top
View user's profile
ChangeOfficer
Newbie
Newbie


Joined: Jan 27, 2010
Posts: 17

PostPosted: Fri Feb 05, 2010 2:14 am    Post subject: Reply with quote

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.
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3318
Location: London, UK

PostPosted: Fri Feb 05, 2010 3:29 am    Post subject: Reply with quote

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
Back to top
View user's profile
ChangeOfficer
Newbie
Newbie


Joined: Jan 27, 2010
Posts: 17

PostPosted: Fri Feb 05, 2010 4:13 am    Post subject: Reply with quote

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.
Back to top
View user's profile
changeborg
Itiler


Joined: Jul 15, 2009
Posts: 41
Location: United States

PostPosted: Fri Feb 05, 2010 5:06 am    Post subject: Reply with quote

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?
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Fri Feb 05, 2010 7:25 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send e-mail
ChangeOfficer
Newbie
Newbie


Joined: Jan 27, 2010
Posts: 17

PostPosted: Sat Feb 06, 2010 12:36 am    Post subject: Reply with quote

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.
Back to top
View user's profile
viv121
Senior Itiler


Joined: Dec 15, 2007
Posts: 113

PostPosted: Thu Jul 15, 2010 7:24 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send e-mail
DYbeach
Senior Itiler


Joined: May 25, 2008
Posts: 413
Location: Sydney, Australia

PostPosted: Thu Jul 15, 2010 9:29 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send e-mail
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Thu Jul 15, 2010 10:18 pm    Post subject: Reply with quote

What is the relationship between these two observations?

Timo wrote:
I thought ITIL was for lonely people Embarassed


DYbeach wrote:
Love this! It feels like family.

_________________
"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
Back to top
View user's profile Send e-mail
viv121
Senior Itiler


Joined: Dec 15, 2007
Posts: 113

PostPosted: Thu Jul 15, 2010 10:28 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send e-mail
DYbeach
Senior Itiler


Joined: May 25, 2008
Posts: 413
Location: Sydney, Australia

PostPosted: Thu Jul 15, 2010 10:58 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Change Management All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops © 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest © 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.