Engineering IT Change Management
Engineering IT Change Management
Scope
ITIL defines a change as ‘the addition, modification, or removal of anything that could have an effect on IT services’.
The following entities are within scope of the Change Management process:
- All production client services and service components that are defined in the IS&T Service Catalog, and their related configuration items (CIs).
- These include but are not limited to virtual components (servers), hardware components (servers and chassis’), software components (applications and databases), data storage components, networking components, power components, racks, data centers, and documentation (policies, procedures, agreements, and guides).
The following entities are out-of-scope of the Change Management process:
- Services that are not in the current IS&T Service Catalog.
- Desktop installations, moves, additions, and changes
- Printers
- Non-production systems that support the testing, development, and quality assurance platforms associated with defined production services.
KEY CHANGE MANAGEMENT CONCEPTS
Changes are categorized into four types based on the required workflow and approval procedure. The types are:
- Standard Pre-Authorized-Change that is pre-approved (by the CAB) based on change model.
- Normal—Change that follows normal approval flow by the Change Manager or CAB depending on the scope and risk.
- Urgent—Change that must occur prior to prescribed lead time as requested by the Service Owner or Service Component Manager and is approved by the Change Manager or the ECAB.
- Emergency—Change implemented as soon as practical to restore service or avoid service outage. The change can be documented after the fact and is approved (directly or implicitly) by the Service Owner or Service Component Manager.
Change Scope
- College – All of the College of Engineering
- Significant – Two or more departments
- Department – A Single department
- Minor – Five or less clients
Change Risk Assessment
Risk assessment is based on the following required “yes or no” questions:
- Will service be interrupted or degraded?
- Are two or more teams required to implement the change?
- Is there a single point of failure (SPOF)?
- Is this a new or high-risk routine activity?
Each “yes” answer increases the risk profile of the change. ServiceNow assigns a numerical value to the RFC based on the number of ‘yes’ responses to these questions. That ‘risk number’ translates as follows:
- Four equal Very High
- Three equals High
- Two/One equals Moderate
- Zero equal Low
Other Questions
Three additional questions are included in the risk assessment section of the RFC. These questions are not used to determine the risk value of the change. They are used to determine if additional approvals or configuration item updates are needed for the change. These questions require a ‘Yes’ or ‘No’ answer.
- Is Security approval required?
- Is Client approval required?
- Is a configuration item update needed?
Change Status
The status of the change will adjust via ServiceNow workflow or manual action depending on where in the lifecycle the change happens to be. The values and meanings are:
- Draft-the RFC has been opened, is a work in progress, and has not yet been requested
- Open-workflow changes status to open after the RFC has been requested for approval
- Pending-the RFC has been manually placed in a pending state by the CAB or Change Manager
- Closed-the RFC has been manually changed to closed when the work has been completed (successfully or unsuccessfully), the post implementation review is completed, and any CMDB updates have been made
Post Implementation Review
When a change is closed, the post implementation review field will be presented via ServiceNow workflow. The appropriate value should be selected prior to updating the change. These current values are:
- Completed successfully – all work in the implementation plan was completed, the work was completed within the planned start and end date/time, and the change did not cause incidents
- Completed with issues – all work in the implementation plan was completed. However, there were some issues encountered during the implementation that did not prevent the change from occurring.
- Unsuccessful backout steps successful – the change was unsuccessful and the backout steps were executed successfully before the planned end date/time
- Unsuccessful extended beyond window – the change was unsuccessful and the backout steps were executed successfully. However, the backout extended beyond the planned end date/time.
- Unsuccessful extended beyond window and caused incidents – the change was unsuccessful, the backout steps extended beyond the planned end date/time, and incidents were created as a result.
- Withdrawn – change was withdrawn before implementation