Change Management• Controls the lifecycle of all changes
• Responsible 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 Requirements• Impact statement/assessment | • Implementation Plan | • Tasks or milestones needed to implement change | • Back out plan | • Anticipated downtime start and end times | •Draft customer notification of anticipated downtime | • Communications plan w/draft communications* | • Test Plan, Test Case, and Test Summary Report* | • Other plans as needed (e.g. capacity, transition, 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. Characteristics of a Standard ChangeLow 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-authorized change - CAB approval not required | Report weekly to CM/CAB |
Examples of a Standard ChangeAny change that does not alter the specification of a Configuration Item (CI) | Testing of an application, service or development 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 | **Therefore, 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 individually |
Note: This is not an all-inclusive list Standard Change Requirements• Notification of the implemented 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 implemented as a Normal Change including communications and other documentation as relevant.
• Entry into the event schedule by the Change Manager. |
Characteristics of a Standard Recurring ChangeReoccurs on a standard timeframe (weekly, bi-weekly, monthly, etc...) | Has same characteristics as a Standard Change but requires approval by the CAB | Report completed occurrences 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 ChangeAny change that does not alter the specification of a Configuration Item (CI) | Testing of an application, service or development project that will be introduced as a part of normal change | | | **It is possible for a recurring normal change that has been implemented successfully a couple of times to become a standard recurring change for future deployments. |
Note: This is not an all-inclusive list Standard Recurring Change Requirements• Notification of the implemented 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 implemented as a Normal Change including communications and other documentation as relevant.
• Entry into the event schedule by the Change Manager. |
| | Types of ChangesStandard | Standard Recurring | Emergency | Normal |
If a change is implemented outside one of these processes, it is an unauthorized change. NoteMost changes should go through the normal or standard change process. | Emergency changes should not occur very often. | If a change is implemented outside one of these three processes (standard, normal, emergency), it is an unauthorized change. |
Characteristics of an Emergency ChangeRequires 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 implementation or fix | ECAB approves |
The percentage of Emergency changes occurring in the environment should be very low. Examples of an Emergency ChangeA location is without a service | There is a severe degradation of service needing immediate action | A system/application/component failure causing a negative impact on business operations | An enterprise application is unavailable | A response to a natural disaster | A response to an emergency business need | A security breach requiring a patch to an enterprise server, enterprise application or a large number of workstations | Hardware malfunction 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-inclusive list Emergency Change Requirements• Submission of a Change Request within one business day after the issue has been resolved
• Post implementation review of the Emergency Change at the next CAB meeting
• May require submission of an incident report to the Change Manager and/or Security Administrator
• May require engagement of an incident response plan if the change request is the result of a hacker
• Communications may be needed |
Characteristics of a Normal ChangeTesting may be required | Not an emergency or standard change | RFC required w/ supporting documentation | CAB approves |
Examples of a Normal ChangeChange that results in business interruption during regular business hours | Changes in any system that affects disaster recovery or business continuity | Introduction or discontinuance of a service | Move new development projects into production | Create/update an image for a large number of computers | Apply/install an enterprise application upgrade, service pack, patch, hotfix, etc… | Apply/Install a server operating system patch, hotfix, service pack, etc… | Add, relocate or decommission a server | Implementing 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-inclusive list Normal Change RequirementsSee section: Change Request Requirements
• Also requires approval by the CAB |
Characteristics of an Unauthorized ChangeImplemented without approval of Change Manager or CAB | Requires submission of incident report & RFC; maybe incident response plan | Reported to Change Mgr & Security Admin | CAB determines… Valid? Reversed? Privileges revoked? Disciplinary action? |
Need more information?If you need additional information or need in-depth information, read the "ITI Change Management Process" document or go through the Change Management Process training material. |
|
Created By
Metadata
Favourited By
Comments
Change Management Process as used by the Office of Information Technology at the City of New Orleans
Add a Comment
Related Cheat Sheets