|
• 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)*
|
|
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-authorized change - CAB approval not required
|
|
Report weekly to CM/CAB
|
|
Any 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
|
|
Reoccurs 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
|
|
Any 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.
|
|
Standard
|
|
Standard Recurring
|
|
Emergency
|
|
Normal
|
|
Most 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.
|
|
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 implementation or fix
|
|
ECAB approves
|
|
A 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
|
|
Testing may be required
|
|
Not an emergency or standard change
|
|
RFC required w/ supporting documentation
|
|
CAB approves
|
|
Change 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
|
|
Implemented 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?
|
Change Management Process as used by the Office of Information Technology at the City of New Orleans
Cheatography n. The art of mapping complex subjects into clear, instantly navigable reference guides.