OPERATIONAL EXCELLENCE – CHANGE MANAGEMENT IT Initiator Training © 2006 IT Services Stanford University Page 1 Change Management IT Initiator Training

OPERATIONAL EXCELLENCE – CHANGE MANAGEMENTIT Initiator Training

© 2006 IT Services Stanford University Page 1

Change ManagementIT Initiator Training

http://www.stanford.edu/services/changemgt

March 6, 2006

Presented by John Klemm, Bill Heiser & Bill Bauriedel



Desired Outcomes for this Training Session

By the end of this training session, you will:

• Understand the basic concepts, definitions, and policies related to the new Change Management Process;

• Understand the scope and expectations related to the IT Initiator role; and

• Be prepared to initiate change requests via the web or via email.



Change Management Process Introduction to Basic Concepts

• The goal of Change Management is to ensure that standardized methods and techniques are used for efficient and prompt handling of IT changes to minimize the likelihood of disruption, unauthorized alterations, and errors.

• The Change Management process focuses on entering previously authorized change/implementation plans as a record into a system; obtaining approval for those changes; scheduling, implementing, and notifying key groups/staff/clients about those changes; and afterward reviewing changes.



What’s new or different about the new CM system?

• Modern web interface• Allows interaction via email (entering change notice, approving, closing)• Process has been formalized

– Lead-times of 3-10 days required for some categories of changes– New Change Advisory Board (tied into weekly Operations Review)– Buy-in from CM Steering Group and Executive Directors

• New application, relatively new vendor (Infra)• Complex application designed for a larger “change management process”• Still some issues: Missing features, login idiosyncrasies (mostly 1st time only),

unusual interface



Change Management Process Introduction to the IT Initiator Role

• The IT Initiator is the person who enters a Change Request into the Change Management System

• The IT Initiator submits and owns the Change Request



Change Management ProcessHigh-Level Process Flow

Change Planning Process

(includes approval from governance groups and business owners as well as design, development,

testing, etc.)

(optional)Emergency / FoOImplementation

Approval Implementation and Review

See Process Document for detailed process flows and detailed procedures

Initiate ChangeRequest (CR)



Change Management ProcessDefinitions: Change Management Terms

Change Request (CR) The request to implement an IT change that includes impact information, scheduling information, and Domain / Secondary Domain information

Change Categories

determined by the IT Initiator

• Major Change• Significant Change• Minor Change (General)• Minor Change (“Fixes of Opportunity / FOO”)• Standard Pre-Approved Change (SPA)• Special Category: Emergency Change

Change Priorities

determined by the IT Initiator

• Emergency (service is down)• Urgent (service is at risk)• Routine (service is not down; “business as usual” change request)

Note that Routine is the standard default priority.

In the new Change Management System, Change Request Category/Priority Combinations are called STENCILS



Change Management ProcessPolicy: Change Request Approvals and Lead-Times

Change Request STENCIL (Priority/Category)

Approval Required Recommended Lead-time

Emergency Retroactive approval (acknowledgment) required No minimum lead-time is required

Routine – Minor Domain / Secondary Domain authorization Three (3) business days (or as required by an existing SLA)

Routine – Minor FOO (“Fix of Opportunity”)

Retroactive Domain / Secondary Domain authorizations (acknowledgement) required

No minimum lead-time is required

Routine – Significant CAB AuthorizationDomain / Secondary Domain authorization

Five (5) business days (or as required by an existing SLA)

Routine – Major CAB MCR AuthorizationDomain / Secondary Domain authorization

Ten (10) business days (or as required by an existing SLA)

Urgent – Minor Retroactive approval (acknowledgment) required No minimum lead-time is required

Urgent – Minor FOO Retroactive approval (acknowledgment) required No minimum lead-time is required

Urgent – Significant Retroactive approval (acknowledgment) required No minimum lead-time is required

Urgent – Major Retroactive approval (acknowledgment) required No minimum lead-time is required

Standard Pre-Approved Change (SPA)

Pre-approved (SPA change requests have been previously reviewed and approved)

No minimum lead-time is required because no review is needed



Change Management ProcessDefinitions: Change Management Roles

Change Coordinator • Reviews and coordinates changes • Creates Standard Pre-Approved (SPA) Change Request Stencils• Creates compliance reports and performs ITS-driven audit reviews• Leads weekly CAB meetings; calls meetings of the CAB MCR

Change Advisory Board (CAB) • Meets weekly to review and gives final authorization to the Forward Schedule of Changes (FSC), which is the consolidated calendar of all authorized changes

• Reviews Standard Pre-Approved (SPA) requests and Significant Change Requests

• Conduct Post-Implementation Reviews (PIRs) of Significant and Major Changes, or any change that resulted in a service outage

CAB: Major Change Review Committee (CAB MCR)

• Subset of the CAB that meets as needed to review and give final authorization to Major Changes

Stakeholder(s) • Person (or persons) interested in changes to specific items; Stanford is using Mailman distribution lists (lists.stanford.edu) to manage notification mailings to stakeholders



Change Management ProcessDefinitions: Change Management Roles

Domain / Secondary Domain Authorizers (Approvers)

• Authorize (approve) Minor, Significant, and Major Changes in particular domains

IT Change Initiator • Uses the Change Management System to initiate a Change Request

Customer • Business User for whom the Change Request is being submitted

EQUIVALENT TERM IN THE CM SYSTEM:

Approver The person (or group of people) responsible for approving Change Requests.

EQUIVALENT TERM IN THE CM SYSTEM:

Officer or Request Manager

The person who submits and owns a Change Request. [an Infra term]

Continued from previous page



Scope of the Change Management Process

All production services, as well as all services with agreements that specifically state service levels and environment up-time (e.g., SLAs), are subject to the Change Management process and policies.

Change Management

Software

Application

Server

Operating System

Client

Hardware

See the OECM Process Document for a full list of the types of changes covered, including an expanded version of this diagram.



Additional Detail:Configuration Changes Covered by the CM Process

Any configuration change that can impact an existing SLA and/or is identified by a workgroup as having a significant negative impact on a service and affecting multiple users should be managed through the Change Management process.

A list of typical changes normally handled by each workgroup that require a change notice appears as Appendix B “Scope of the Change Management Process” including a list of configuration changes that do or do not require change notices.



Demo: Submitting a Change Request (Web)

Production Environment URL: http://cmr.stanford.edu (https://InfraAppProd.stanford.edu)Refer to QuickGuide for IT Initiators



Demo: Checking Status of a Change Request (Web)



Demo Result: Request Details Screen (Web)



Reference: Template for Submitting an Email Change Request

ADDRESS: [email protected] SUBJECT LINE: [createrequest]

REQUIRED FIELDS:[Stencil: ][Primary Domain: ][Change Title: ][Class: ][Type: ][Item:][Description: ][Schedule Date/Time:][Source: Email]

REQUIRED FIELDS:Note: do not use square brackets except as specified below

[Stencil: xxxxxxx] e.g. Routine - Minor[Primary Domain: xxxxxxx] e.g. Student & HR Systems[Change Title: xxxxxxx] up to 80 characters[Class: xxxxxxx] e.g. App-Student/HR - must be a valid

Class

[Type: xxxxxxx] e.g. HRSA-Technical - must be a valid Type

[Item: xxxxxxx] e.g. HRSA-Technical-CI - must be a valid Item

[Description: xxxxxxx] can span multiple lines

[Schedule Date/Time: mm/dd/yyyy hh:mm:ss] the hh:mm:ss is optional. If left out,

the time will be 00:00:00. Any part of the time may be left out. Eg. hh=17 becomes 17:00:00 and hh:mm = 17:30 becomes 17:30:00.

[Source: Email] required for email submissions



Reference: Template for Submitting an Email Change Request

OPTIONAL FIELDS:[Secondary Domains: xxxxxxx] e.g. Windows Systems, Unix Systems (each additional domain separated with a comma. Each must be a valid domain name.)[Secondary Item:xxxx,yyyy] specify here if the items aren't shown in the pick list[Activity: xxxxxxx] e.g. reboot or additional capacity or application upgrade,

etc. - must be a valid activity[Outage Start Date/Time: mm/dd/yyyy hh:mm:ss][Outage End Date/Time: mm/dd/yyyy hh:mm:ss][Install Plan: xxxxxxx] Install plan goes here[Backout Plan: xxxxxxx] Backout plan goes here[Impact Analysis: xxxxxxx] Impact Analysis goes here[Notes: xxxxxxx] Notes go here[Tested: xxx] Yes or No[Maintenance Window: xxx] Yes or No[Standard Pre-Approved Change Template: xxx] Yes or No[Cross Reference: xxxxxx] enter CPT number, otherwise leave out this line. It is for

system use only[Secure Information: xxxxxx] secure information goes here[Business Requestor: xxxxxx] name must be a business user defined in the system[Business Requestor (If not in CMDB): xxxxxxx] any name can be entered here[Requestor's Organization: xxxxxxx] must be a valid organization as

specified in the system



Demo: Submitting a Change Request (Email)



Should I initiate a Change Request via the Web App or Email?

Web Application• Easy to use• Choices in menus• No worries about typing labels• Instant feedback• Consider for infrequent or variable (different types of entries) use

Email• Templates can be made• Notes can be included• No login to web app required• Resubmit after correction (on initial entry failure, or on approver rejection)• Your sending email address must match your address in Infra database• Consider for frequent or repeated (same type of entries) use



What Happens After You Submit the Change Request?

• (Specific details depend on the Stencil you choose)

• Approvers receive email asking them to approve (via email or web app)

• Initiator receives a confirmation email

• Then, if/when all approvers approve, you receive email notification that the task of implementing the change and closing the change request record are yours to do

• If any approver disapproves, you receive email notification that the task of closing the change request record is yours to do

• You cannot change the change request record after submitting it. You cannot cancel it either. Solution: An approver can reject it, and you can submit a new change request.

• You can check the status/history of the change by going into the web application, finding the Request, going to the detail page (yellow arrow), and looking at the history section.

• Instructions for closing a change request record appear in the email you’ll receive - you can close it via email.



General Usage Tips for the New Change Management System

• Change Request = (Initiation Task + Notification Task (automatic) + Approval Task + Implementation Task)

IMPORTANT NOTE: tasks = requests

• Clicking for any Task or Approval means that you are actioning that Task or Approval and that you now own it - to “disown” it without taking action (if you need to), choose “forward” and send it back to your group

• When entering the date and time for a change request, specify time first, then select the date (if you select the date first, then the box closes having selected the date with the current time); note that date and time must be formatted in 24-hour/military time

• Avoid using the browser BACK button; instead use the application BACK button (if you use the browser BACK button, you will likely see undesirable results)

/



General Usage Tips, continued

• BOLD fields on the “Request Entry” and “New Task” web pages are required; all other fields are optional; the email template on (Page#) also specifies which fields are required as opposed to optional

• Two types of notification emails: a. Users can subscribe to a Mailman list to receive “all” notifications about changes

affecting a given domainb. Users can subscribe to another Mailman list to receive “limited” notifications about

changes for a given domain (i.e., user would receive notifications of Significant, Major, and Emergency changes only)

• Particularly when submitting email change requests, [square brackets], syntax, and spelling are critical; pulldown choices must be entered exactly as they appear in the web pulldown menu(s)

• IMPORTANT NOTE: It is not possible for a user to make changes or corrections (e.g., of spelling, to add another item) to a change request once it has been submitted; for critical correction, the Change Coordinator may make edits



General Usage Tips, continued

• Multiple concurrent sessions are not allowed: Due to the way the application’s licensing mechanism works, a single user can only have a single instance of the application in use at any given time. This includes logins via the web interface and via email submissions. This means if you are logged in to the web interface, and submit a request (or approval) via email, your web session will be logged out.

• Errors during request entry require re-selection of file attachment (if any)

If you select a file attachment while submitting a Change Request, and encounter an error (e.g. an incorrectly specified Schedule Date/Time), the file attachment selection is cleared. In this case you need to re-select the attachment. This is by design due to security concerns in the web application.



Some Frequently Asked Questions (FAQ)

Other Questions?

What happens when there is a scheduling conflict?The Change Coordinator or (more likely) the Change Advisory Board (CAB) will work with the parties requesting the conflicting date/time to resolve the conflict. Essentially this is a negotiation.

How do you delegate approvals during vacations, when someone’s out sick, etc.?There should be multiple approvers per domain. It is their responsibility to hand off approval responsibility if one is out.

How do you pick the right stencil?Use the Process QuickGuide to guide your decision-making.



Key Links

Web Site (w/ link to web application): http://www.stanford.edu/services/changemgt

Web Application: http://cmr.stanford.edu (for http://InfraAppProd.stanford.edu)

Email: [email protected]

Process Document (available at Web Site above): https://www.stanford.edu/services/changemgt/documents/OECM_Process_Document_v2.7.pdf

HelpSU (for issues reporting and help): http://remedy-prod.stanford.edu/cgi-bin/helpsu2?pcat=cms (Category=Administrative Applications, Type=Change Management, Item=*General)

Project Web page: http://www.stanford.edu/dept/itss/projects/OE/change-management.html

Documents

OPERATIONAL EXCELLENCE – CHANGE MANAGEMENT IT Initiator Training © 2006 IT Services Stanford University Page 1 Change Management IT Initiator Training