Standard Changes - When is an RFC Actually Required

Discuss and debate ITIL Change Management issues
Post Reply
User avatar
rlmx
Newbie
Newbie
Posts: 4
Joined: Mon Jun 01, 2009 8:00 pm
Location: Indianapolis, IN

Fri Jul 16, 2010 1:05 pm

When is an RFC required for a Standard Change?


User avatar
Diarmid
ITIL Expert
ITIL Expert
Posts: 1894
Joined: Mon Mar 03, 2008 7:00 pm
Location: Helensburgh

Sun Jul 18, 2010 4:32 am

That is entirely up to you.

In my opinion it is risky to perform any change without first asking permission. Whether you call this an RFC or something else is probably moot (except in the context of software-driven change management when it will depend on what your software permits you to do - I'm trying to be ironic here).

If you formally adopt a concept of "standard change" then you will define how to proceed with standard changes. I like the idea of having each standard change controlled by its own procedure which will define for that particular change what the change management requirements are and how change management should be effected, including authority, testing and scheduling (off the top of my head).
"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
User avatar
Curtis_Rowell
Newbie
Newbie
Posts: 1
Joined: Thu Nov 18, 2010 7:00 pm
Contact:

Tue Dec 14, 2010 11:03 am

rlmx wrote:When is an RFC required for a Standard Change?
An RFC should ALWAYS be required for a Standard or Assumed Approved change. However, the approval process is different for such a change because the risk level is low or nearly non-existent. But it is still a change and as such, should be documented.
User avatar
Diarmid
ITIL Expert
ITIL Expert
Posts: 1894
Joined: Mon Mar 03, 2008 7:00 pm
Location: Helensburgh

Wed Dec 15, 2010 4:10 am

At the risk of being misunderstood, I would suggest that "standard changes" do not necessarily have "low or nearly non-existent" risks. What each one does have is a clearly defined consistent context that is safely manageable by a repeatable process which can then be predefined.

Something is safe to do because it is well understood and well controlled both technically and managerially. Few things are genuinely low-risk unless they are done "properly". Patching is often cited as a candidate for being a "standard change", but an injudicious patch application can be disastrous. Patching is not low-risk.
"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
User avatar
SubbuA
Senior Itiler
Senior Itiler
Posts: 33
Joined: Wed Jan 27, 2010 7:00 pm

Sat Jan 01, 2011 4:23 pm

Please check if your organization has defined a process for handling standard change... If yes, there should a policy written on how to raise a standard change....

if there is no process defined, we can write one - but that is a job and not to be done for free

Regards,
Subbu A
Regards,
Subbu A
ITIL Certified and well experienced
Post Reply