A Request For Change is based upon the need to modify a standard set by the organization - for any number of reasons. Some of the reasons include:
Changing
the system in response to an incident, SLA issue, or problem
Changing
the system in order to keep up with business unit changes
Regular
patch, upgrade, and security management
Compliance
and regulatory changes that mandate system changes
No matter what the reason for initiating the need for change, all proper change management models begin with someone filling out the organization's Request For Change (RFC) documentation. The RFC will either be a Word form or online form that contains all of the relevant information about the proposed change. Because the change advisors who will be reviewing the RFC are going to ask a great deal of "who, what, when, how, and what if" questions about the proposed change, the RFC must be able to describe those issues as much as possible in an effort to make the process as simple as possible. The reason that the RFC has to be in a "form" format is so that the information recorded in the RFC is standardized and can be consolidated with other "like" requests for change.
Here is the basic information that the form has to have filled out before it can be submitted for review. There is additional information that the review group will fill out later, but this will suffice for getting the ball rolling.
Basic information
Control
ID: is the unique ID assigned to the request so that it can be tracked.
Request
Date/Revision Date: is the initial date that the request was made so that
the date can be taken into account for priority and scheduling purposes. The
revision date should also be added in case (and many times this happens) the
RFC has to be changed before it can be submitted.
Status:
reflects the lifecycle status of the change, which should be any of these:
- has been accepted,
- is in committee for review,
- should be revised,
- is declined or approved,
- is scheduled,
- requested change is in progress,
- requested change has been released, or
- requested change has been documented and completed.
Schedule
Date: is filled out once the RFC's proposed change has been scheduled. This
should correspond with a name being filled out in the Approved By field.
Approved
By: is the name of the Change Manager or Advisory Team member who has
authorized and approves of the change taking place.
Change initiator information
This information provides detail about the person requesting the change, the system or asset in question, the reasons for the change, and what might happen if the change doesn't take place.
Requester's
name and contact info: should reflect the person's name, desk or cell
phone, and e-mail address for later contact and clarification if necessary.
System
or Asset affected: reflects whatever identification methodology your
organization uses for their systems and assets. The reason for an ID and not a
name is for definitive reference, as we know that some of you name your
computers "Homer Simpson" and other silly things.
RFC
Title: refers to the RFC by something other than its ID.
Reason
for change: states whether this change is for regular patches, updates, the
business might have changed, or that this is the result of a problem or
incident. Whatever the reason, state it plain and simple.
Implication
of ignoring the change: presents your case for what will happen to the
system or asset in question (or the organization for that matter) if the change
is not approved.
What you want to change and what it will affect
Proposed
change description & implications of the change: lists what,
precisely, you intend to change. If you are adding a patch, what is it
patching? What will happen once the patch has been applied? If you are
replacing a card, adding software, whatever, you'll want to state the change
being made. And, you'll also want to state the implications of the
change. If you are upgrading your software, the implications will more than
likely be that you will lose some type of backward compatibility, or that
others might have to upgrade with you. You will also want to state any legal
or compliance implications of the change.
All
configurable items and staff that will be affected by the change: lists the
asset(s) being changed as well as any other asset on the device or within the
system[1].
This means that you'll need to communicate with the system's configuration
manager if you don't know which assets there are for the system. Also, if any
staff members are going to be affected, you'll want to list them.
All
other devices on the network or external users that you think the changes might
affect: considers anyone or anything that will be affected by
the change. For instance, if you are changing the DNS address, anyone
attempting to find the device at the old address will be left out in the cold
if they aren't informed of the change.
Your proposed change plan
Proposed
change plan: covers how you propose that the changes be made to the
system of the IT asset using a step-by-step method. The change plan should also
include an estimated amount of time that it should take to make the change.
What we've found very useful is that if there are standard changes (such as
patch plans, software and hardware upgrades, etc.), these have their own
procedures so that the procedure can be reference here.
Resources
needed to make the change: covers all of the resources (including people)
that are needed in order to effect the change. This should also cover the
proposed cost of the change to ensure that you have the appropriate budget.
Proposed
roll-back plan: covers the course of action you'll plan to take if the
change can not be implemented properly. Most patches can be rolled back. Some
upgrades (especially Windows XP Service Pack 2) cannot be rolled back.
Suggested
change priority and category: covers the priority that this change should
have, and the category that the change should fall into. The priorities are:
- Low: the change is not pressing.
- Medium: to gain the benefit of other changes, this change should be made.
- High: the change is important for the organization and should be implemented at the earliest convenience.
- Emergency: should only be used when the organization is being put at great risk if the change is not implemented immediately.
The categories are:
- Standard: is a change that has been performed many times (and has a procedure attached to it) and has therefore become a part of the operational methodologies of the organization.
- Minor: is a change that is more involved than a standard procedural change and that has consequences that would affect a small number of people. This number should be pre-defined by your organization.
- Significant: is a wide-spread change that would affect an entire business unit or operational department. This type of change has almost nothing to do with standard procedures and therefore will incur more resources to enact the change (as well as affect more resources adversely if it fails).
- Major: is a change that would ensure your next position is that of a fry cook at McDonald's if it fails. This type of change, should it fail or the change take much longer to enact, could affect the organization materially (another definition you should have in place before you begin to put change management into action).
There, that's the information that the person(s) filling out the change form need to know and state in order to get the form approved and into the hands of the change manager.
[1] The term system here refers to all devices and IT assets that must work together to support the business unit's goal.
| This is a sample of what is available in the Change Management Kit, which includes a PDF guidebook, an Excel audit worksheet, and the professionally designed forms you'll need to get you started. |  |
 |