Overview

Change Management is a systematic approach that defines the process and implements the procedures for recording and tracking the details of the service environment as it undergoes change.  The steps involved in using ServiceNow to submit and implement change requests are detailed in this document.

This document covers the IET process version 2.4 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 for a one-off change that is not recurring or doesn't fit a pattern that can be quantified as a standard change and is not an emergency.  

v2.4.4

 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:

1. Under the Change module, click Create New
2. Click on Normal: Changes without predefined plans that require approval and CAB authorization.
3. Fill out the Request for Change form. The required items are (Note that some of these items are on different tabs):
   1. Configuration item: Select the business service or CI that will be affected by the change.
   2. Short description: A short description of the change.  Use keywords that will readily identify the change and are easily searchable. 
   3. 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.
   4. 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.
   5. Assigned to: The person who will drive the change forward.
   6. CAB: The Change Advisory Board that will assess the change.  For IET this is the 'IET CAB'.
   7. Service managers: The group of service managers that will assess the change.  Usually the same group as the Assignment Group. 
   8. Justification:  Explain why this change is necessary.  Include the risk of doing nothing in this field.
   9. Implementation plan: How this change is being performed. This should be detailed enough so that somebody can follow these steps and repeat the process.  
   10. Risk and impact analysis:  List three risks/impacts:
       1. 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?
       2. 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? 
   11. Backout plan: How the change can be reverted.  List the steps.
   12. Test plan: How the change will be tested prior to and after implementation.  
   13. Communication Plan: How will you communicate?  Who is the target audience of the communication?  When will you communicate?  
   14. 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?
   15. Planned start: The planned date/time that change will be implemented.
4. 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.  
5. 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 Access 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.

If your change requires tasks to be completed by other groups, create change tasks and assign them to the appropriate service queue.   

Service Manager(s) Assessment

The change will now be in the Assess stage.  Once a member of the Service managers group has approved the change, it will move to the next phase.  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.  

The change request needs to be in the Authorize state in order to be considered for the CAB.

Change Advisory Board Assessment

The change will now be in the Authorize stage and reviewed at the next CAB meeting.  Once a member of the CAB group has approved the change, it will move to the next phase.

If the requestor needs to make changes to the ticket after CAB approval, including implementation date, then 

Schedule Change

The change will now be in the Scheduled stage.  Once the change is ready to be implemented, perform the following steps:

1. Verify the change information is correct and the Schedule is correct.
2. Click the Implement button

If the scheduled change date needs to be modified at a later time, the ticket must be reviewed by the CAB for conflict resolution.  Contact the CAB manager to 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.  

When the change is implemented, do the following:

1. 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.
   1. Enter a Description
   2. Set the Configuration item
   3. Set the Assignment group and Assigned to
   4. Set the State to the appropriate value
   5. Enter your work notes
   6. Close the task.
2. 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
   1. Enter a Description
   2. Set the Configuration item
   3. Set the Assignment group and Assigned to
   4. Set the State to the appropriate value
   5. Enter your work notes
   6. Close the task.
3. Click the Review button

Do not edit the content of the change ticket except for the subordinate change tasks after approval.

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 CAB manager will review and close the change.  

The change will now be in the Review stage.  This now returns the ticket for post-implementation review of the change by the CAB.  You need not do any further work on the ticket.  The CAB will review the content of the change and associated tasks, then:

1. Choose a Closure code for the change.  Choose successful if there were no issues with the change and it was implemented as described.  Choose successful with issues if you had to make modifications to the implementation plan or had other deviations in order to implement the change.  Choose unsuccessful if you could not complete the change.
2. Enter any Resolution notes you may have.
3. Click the Close button

Do not modify the closure code based on change related incidents.  

Close Change

The change is now closed.