Overview
ITIL Change Management is the disciplined process used to control the lifecycle of all changes to IT services, infrastructure, applications, and related configurations. Its purpose is to ensure that standardized methods and governance are applied so that changes are introduced with minimal disruption to business operations, while maintaining acceptable risk levels and ensuring traceability, accountability, and proper evaluation. The steps involved in using ServiceNow to submit and implement change requests are detailed in this document.
This document covers the IET process version 3.0 to submit and perform a normal change using ServiceNow. A normal change can be any level of risk. It is any change that is new, discrete, and unique to the IT infrastructure. Normal changes need CAB and sometimes X-CAB approval. A Normal Change is any change that is not pre-approved and requires evaluation, risk assessment, and authorization before implementation or doesn't fit a pattern that can be quantified as a standard change and is not an emergency. Normal changes go through the full Change Management process
v3.0.0
Process
The Service Manager is responsible for driving the change forward. The Service Manager needs to ensure that the Service Owner and all stakeholders have been consulted before taking the change forward to the CAB for approval. The change initiator gets initial approval for the change after consulting the Service Manager. This starts the process. When the change has been approved by the Service Manager and Service Owner, the change initiator needs to submit the CAB ticket for approval.
The Service Manager can delegate any of these tasks to the change initiator.
Submit Request for Change
The IET change management process tool is ServiceNow. You must be a ServiceNow user in order to uses this process.
To submit a new Normal Change:
- Select 'Change' and click Create New
- Select 'Change model' or 'fit for purpose'. Do not select standard change.
- Under Models select 'Normal'.
- Fill out the Request for Change form. The required items are (Note that some of these items are on different tabs):
- Short description: A short description of the change. Use keywords that will readily identify the change and are easily searchable.
- Description: A full description of the change to be performed. This should be sufficient to give the reader a solid overview of the proposed change.
- Configuration item: Select the business service or CI that will be affected by the change.
- Service Offering: Select the service that this CI is part of. If there is no appropriate Service Offering, then it can be created using https://kb.ucdavis.edu/?id=11667
- Assignment group: The group that is driving the change forward.. If the change has tasks to be completed by other groups, use change task to assign work. This is also the group whose members will approve the change. If you want the approver group to be different than the implementation group, then you can assign it to the approver group initially, and after approval the assignment group can be changed to the implementor group.
- Assigned to: The person who will drive the change forward.
- CAB: The Change Advisory Board that will assess the change. For IET this is the 'IET CAB'.
- Justification: Explain why this change is necessary. Include the risk of doing nothing in this field.
- Implementation plan: How this change is being performed. This should be detailed enough so that somebody can follow these steps and repeat the process. This can reference outside documentation or have attachments that clarify. The notes tab can also be used to clarify and expand on the implementation process.
- Risk and impact analysis: List three risks/impacts:
- Known impact of the change. How long will the service be down because of the change? How many users will be affected? What changes will the user see?
- Failure risk. What is the probability of something going wrong, and what is the impact of that thing going wrong. What is the worst case, and how long will it take to recover?
- The risk of not going forward with the change ---- This is the justification field.
- Backout plan: How the change can be reverted. List the steps.
- Test plan: How the change will be tested prior to and after implementation. List if this has been implemented on dev/test, or explain why this is not possible. List the steps for testing post implementation and the people who will do that testing.
- Communication Plan: How will you communicate? Who is the target audience of the communication? When will you communicate? Most changes are posted to slack channge #change. Impactful changes are posted to status using https://kb.ucdavis.edu/?id=02288 with at least two days notice.
- Disaster recovery effect: How does this change effect disaster recovery plans? Do they need to be modified to provide for a new service? Do they change the plan because this change makes the service more resilient? Most often this is left blank.
- Planned start and end date: The planned date/time that change will be implemented.
- Save the form. If you are ready to move forward with the approval process, proceed to the next step. If you are still working on the CAB ticket or waiting for stakeholder input you can just leave it 'saved' without requesting approval.
- Click the Request Approval button. This is required for the ticket to move forward for review.
IET CAB tickets must be submitted by 1200 hrs on Monday in order to review the CAB ticket at the Wednesday CAB meeting. They may be in either the Assess or Authorize state by the Monday cutoff. In order to be reviewed at the CAB, the change ticket needs to be in the Authorize state. You must click 'Request Approval' in order to have the ticket added to the CAB schedule for review.
If your change requires tasks to be completed by other groups, create change tasks and assign them to the appropriate service queue.
Service Manager / Approver Assessment
The change will now be in the Assess stage. Once a member of the Assignment Group has approved the change, it will move to the next phase (Authorize). It is the Service Manager, or their designee's, responsibility to ensure that the stakeholders give this change sufficient review and input. If the change arrives at the CAB without stakeholder review, CAB approval will be delayed until that review is complete.
If the Approvers of the change should be different than the implementor, then you can first assign the change to a group of approvers using the Assignment Group, then change it to the group implementing the change after approval.
The change request needs to be in the Authorize state in order to be considered for the CAB.
Change Advisory Board Assessment
After initial apprioval, the change will now be in the Authorize state and reviewed at the next CAB meeting. Once a member of the CAB group has approved the change, it will move to the scheduled phase.
Generally no changes beyond implementation notes can be made to the change ticket once it has been approved. If the requestor needs to make changes to the ticket after CAB approval, including implementation date, then consult with the change manager to determine if the change should trigger an additional CAB review.
Schedule Change
The change will now be in the Scheduled stage. Once the change is ready to be implemented, perform the following steps:
- Verify the change information is correct and the Schedule is correct.
- Click the Implement button
If the scheduled change date needs to be modified at a later time, the ticket may need to be reviewed by the CAB for conflict resolution and proper notification. Contact the CAB manager to determing if this is necessary and to potentially have it added to the agenda again.
Implement Change
The change will now be in the Implement stage. Two new tasks will be created as part of this stage:
- Post implementation testing.
- Implement.
These two tasks are optional to fill out.
When the change is implemented, do the following:
- Open the Implement task. List any issues encountered while implementing. Success. Modifications to the procedure. Notes that will be beneficial the next time a similar change is implemented.
- Enter a Description
- Set the Configuration item
- Set the Assignment group and Assigned to
- Set the State to the appropriate value
- Enter your work notes
- Close the task.
- Open the Post implementation testing task. Fill out this change task to identify what steps were taken to verify the service was operating as expected after the change
- Enter a Description
- Set the Configuration item
- Set the Assignment group and Assigned to
- Set the State to the appropriate value
- Enter your work notes
- Close the task.
- Click the Review button
Do not edit the content of the change ticket except for the subordinate change tasks after approval except as discussed above. The implementation notes can also be added to the notes tab.
Review Change
Reviewing the change is the responsibility of the service manager. If the change is successful, the service manager can close the ticket. If the change was successful with issues or unsuccessful, the service manager shall ensure that the closure notes reflect the issues.
The service manager can delegate to the implementor the closing of the ticket, but is still responsible for recording any issues for changes that were unsuccessful or were implemented with issues.
After recording closure notes, click close.
The change is now closed.