Show Menu

Change Management Cheat Sheet by

change     management     itil

Change Management

• Controls the lifecycle of all changes
• Respon­sible for formal assessment of a new or changed IT service
• Ensure that risks have been managed
• Helps determine whether to authorize the change.
• Enables beneficial changes to be made with minimum disruption to IT services.

Change Request Requir­ements

• Impact statem­ent­/as­ses­sment
• Implem­ent­ation Plan
• Tasks or milestones needed to implement change
• Back out plan
• Antici­pated downtime start and end times
•Draft customer notifi­cation of antici­pated downtime
• Commun­ica­tions plan w/draft commun­ica­tions*
• Test Plan, Test Case, and Test Summary Report*
• Other plans as needed (e.g. capacity, transi­tion, and release and deployment plans)*
(*) These items aren’t required for every change. However, if you are unsure if it is required for your change request please check with the Change Manager.

Charac­ter­istics of a Standard Change

Low in risk, impact and visibility
Relatively common
The tasks are well known, documented and proven
There is a defined Roll-Back plan
Testing may be required
RFC Submitted into SDP
Pre-au­tho­rized change - CAB approval not required
Report weekly to CM/CAB

Examples of a Standard Change

Any change that does not alter the specif­ication of a Config­uration Item (CI)
Testing of an applic­ation, service or develo­pment project that will be introduced as a part of normal change
**Some standard changes are not documented in the change management process; but instead are documented in incident management process using a ticket submitted to the Service Desk.
**However, a normal or emergency change may be triggered by a ticket in the incident management process
**Ther­efore, it is not a standard change just because it started as a ticket within the incident management process… you must evaluate each change or trigger indivi­dually
Note: This is not an all-in­clusive list

Standard Change Requir­ements

• Notifi­cation of the implem­ented change to the Change Manager by the start of the weekly CAB meeting.
• A change request and/or incident report if determined that it should have been implem­ented as a Normal Change including commun­ica­tions and other docume­ntation as relevant.
• Entry into the event schedule by the Change Manager.

Charac­ter­istics of a Standard Recurring Change

Reoccurs on a standard timeframe (weekly, bi-weekly, monthly, etc...)
Has same charac­ter­istics as a Standard Change but requires approval by the CAB
Report completed occurr­ences to CM/CAB
Low in risk, impact and visibility
Relatively common
The tasks are well known, documented and proven
There is a defined Roll-Back plan
Testing may be required
RFC Submitted into SDP

Examples of a Standard Recurring Change

Any change that does not alter the specif­ication of a Config­uration Item (CI)
Testing of an applic­ation, service or develo­pment project that will be introduced as a part of normal change
 
**It is possible for a recurring normal change that has been implem­ented succes­sfully a couple of times to become a standard recurring change for future deploy­ments.
Note: This is not an all-in­clusive list

Standard Recurring Change Requir­ements

• Notifi­cation of the implem­ented change to the Change Manager by the start of the weekly CAB meeting.
• A change request and/or incident report if determined that it should have been implem­ented as a Normal Change including commun­ica­tions and other docume­ntation as relevant.
• Entry into the event schedule by the Change Manager.
 

Types of Changes

Standard
Standard Recurring
Emergency
Normal
If a change is implem­ented outside one of these processes, it is an unauth­orized change.

Note

Most changes should go through the normal or standard change process.
Emergency changes should not occur very often.
If a change is implem­ented outside one of these three processes (standard, normal, emerge­ncy), it is an unauth­orized change.

Charac­ter­istics of an Emergency Change

Requires immediate attention
Usually in response to break/fix issue. They should never occur because of poor planning.
Restoring service, preventing an outage or repairing an error that is severely impacting business
Testing reduced or forgone
ECAB notified verbally or via email
RFC submitted w/in 1 business day of implem­ent­ation or fix
ECAB approves
The percentage of Emergency changes occurring in the enviro­nment should be very low.

Examples of an Emergency Change

A location is without a service
There is a severe degrad­ation of service needing immediate action
A system­/ap­pli­cat­ion­/co­mponent failure causing a negative impact on business operations
An enterprise applic­ation is unavai­lable
A response to a natural disaster
A response to an emergency business need
A security breach requiring a patch to an enterprise server, enterprise applic­ation or a large number of workst­ations
Hardware malfun­ction has required a SQL database to be restored to another server
Corrupt data from an interface requires the database to be restored from backup
Reboot of a domain controller in a network outage situation
Nola.gov website is down
Note: This is not an all-in­clusive list

Emergency Change Requir­ements

• Submission of a Change Request within one business day after the issue has been resolved
• Post implem­ent­ation review of the Emergency Change at the next CAB meeting
• May require submission of an incident report to the Change Manager and/or Security Admini­strator
• May require engagement of an incident response plan if the change request is the result of a hacker
• Commun­ica­tions may be needed

Charac­ter­istics of a Normal Change

Testing may be required
Not an emergency or standard change
RFC required w/ supporting docume­ntation
CAB approves

Examples of a Normal Change

Change that results in business interr­uption during regular business hours
Changes in any system that affects disaster recovery or business continuity
Introd­uction or discon­tin­uance of a service
Move new develo­pment projects into production
Create­/update an image for a large number of computers
Apply/­install an enterprise applic­ation upgrade, service pack, patch, hotfix, etc…
Apply/­Install a server operating system patch, hotfix, service pack, etc…
Add, relocate or decomm­ission a server
Implem­enting a new domain policy
Upgrading domain controller
Install or relocate a printer that is high impact for a mission critical function
Changes to active directory
Hardware failure to be fixed by a vendor
Note: This is not an all-in­clusive list

Normal Change Requir­ements

See section: Change Request Requir­ements
• Also requires approval by the CAB

Charac­ter­istics of an Unauth­orized Change

Implem­ented without approval of Change Manager or CAB
Requires submission of incident report & RFC; maybe incident response plan
Reported to Change Mgr & Security Admin
CAB determ­ines… Valid? Reversed? Privileges revoked? Discip­linary action?

Need more inform­ation?

If you need additional inform­ation or need in-depth inform­ation, read the "ITI Change Management Proces­s" document or go through the Change Management Process training material.

Download the Change Management Cheat Sheet

3 Pages
//media.cheatography.com/storage/thumb/corlisspt_change-management.750.jpg

PDF (recommended)

Alternative Downloads

Share This Cheat Sheet!

Like this cheat sheet? Check out our sponsors!

Readable.io is a collection of tools to make your writing better. More readable content means higher conversion rates and better reader engagement. Measure website and document readability, measure keyword density and more!

Click Here To Get Started!

 

Comments

corlisspt corlisspt, 19:51 22 Jan 16

Change Management Process as used by the Office of Information Technology at the City of New Orleans

Add a Comment

Your Comment

Please enter your name.

    Please enter your email address

      Please enter your Comment.

          Related Cheat Sheets

          Innovative strategies for change Cheat Sheet
          Motivation Theory Cheat Sheet