OPERATIONAL EXCELLENCE – CHANGE MANAGEMENT
IT Initiator Training
Change Management
IT Initiator Training
http://www.stanford.edu/services/changemgt
March 6, 2006
Presented by John Klemm, Bill Heiser &
Bill Bauriedel
© 2006 IT Services Stanford University
Page 1
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENT
IT Initiator Training
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.
© 2006 IT Services Stanford University
Page 2
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENT
IT Initiator Training
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.
© 2006 IT Services Stanford University
Page 3
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENT
IT Initiator Training
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
© 2006 IT Services Stanford University
Page 4
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENT
IT Initiator Training
Change Management Process
Introduction to the IT Initiator Role
© 2006 IT Services Stanford University
•
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
Page 5
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENT
IT Initiator Training
Change Management Process
High-Level Process Flow
Change Planning
Process
(includes approval from
governance groups and
business owners as well
as design, development,
testing, etc.)
Approval
© 2006 IT Services Stanford University
(optional)
Emergency / FoO
Implementation
Implementation
and Review
Initiate Change
Request (CR)
See Process
Document for
detailed process
flows and detailed
procedures
Page 6
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENT
IT Initiator Training
Change Management Process
Definitions: 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
© 2006 IT Services Stanford University
Page 7
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENT
IT Initiator Training
Change Management Process
Policy: 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 Authorization
Domain / Secondary Domain authorization
Five (5) business days
(or as required by an existing SLA)
Routine – Major
CAB MCR Authorization
Domain / 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
© 2006 IT Services Stanford University
Page 8
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENT
IT Initiator Training
Change Management Process
Definitions: 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
© 2006 IT Services Stanford University
Page 9
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENT
IT Initiator Training
Change Management Process
Definitions: Change Management Roles
Continued from previous page
Domain / Secondary Domain
Authorizers (Approvers)
•
Authorize (approve) Minor, Significant, and Major Changes in
particular domains
EQUIVALENT TERM IN THE CM SYSTEM:
Approver
IT Change Initiator
•
The person (or group of people)
responsible for approving Change
Requests.
Uses the Change Management System to initiate a Change Request
EQUIVALENT TERM IN THE CM SYSTEM:
Officer or
Request
Manager
Customer
© 2006 IT Services Stanford University
•
The person who submits and owns
a Change Request. [an Infra term]
Business User for whom the Change Request is being submitted
Page 10
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENT
IT Initiator Training
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
Hardware
Operating System
Client
See the OECM Process Document for a full list of the types of
changes covered, including an expanded version of this diagram.
© 2006 IT Services Stanford University
Page 11
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENT
IT Initiator Training
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.
© 2006 IT Services Stanford University
Page 12
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENT
IT Initiator Training
Demo: Submitting a Change Request (Web)
Production Environment URL: http://cmr.stanford.edu
(https://InfraAppProd.stanford.edu)
Refer to QuickGuide for IT Initiators
© 2006 IT Services Stanford University
Page 13
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENT
IT Initiator Training
Demo: Checking Status of a Change Request (Web)
© 2006 IT Services Stanford University
Page 14
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENT
IT Initiator Training
Demo Result: Request Details Screen (Web)
© 2006 IT Services Stanford University
Page 15
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENT
IT Initiator Training
Reference: Template for Submitting an Email Change Request
REQUIRED FIELDS:
Note: do not use square brackets except as specified below
[Stencil: xxxxxxx]
[Primary Domain: xxxxxxx]
[Change Title: xxxxxxx]
[Class: xxxxxxx]
e.g. Routine - Minor
e.g. Student & HR Systems
up to 80 characters
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.
the time will be 00:00:00.
the time may be left out.
becomes 17:00:00 and hh:mm
becomes 17:30:00.
[Source: Email]
© 2006 IT Services Stanford University
If left out,
Any part of
Eg. hh=17
= 17:30
required for email submissions
ADDRESS: changemanagement@infraap
pprod.stanford.edu
SUBJECT LINE:
[createrequest]
REQUIRED FIELDS:
[Stencil: ]
[Primary Domain: ]
[Change Title: ]
[Class: ]
[Type: ]
[Item:]
[Description: ]
[Schedule Date/Time:]
[Source: Email]
Page 16
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENT
IT Initiator Training
Reference: Template for Submitting an Email Change Request
OPTIONAL FIELDS:
[Secondary Domains: xxxxxxx]
separated
[Secondary Item:xxxx,yyyy]
[Activity: xxxxxxx]
e.g. Windows Systems, Unix Systems (each additional domain
with a comma. Each must be a valid domain name.)
specify here if the items aren't shown in the pick list
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
© 2006 IT Services Stanford University
Page 17
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENT
IT Initiator Training
Demo: Submitting a Change Request (Email)
© 2006 IT Services Stanford University
Page 18
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENT
IT Initiator Training
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
© 2006 IT Services Stanford University
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
Page 19
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENT
IT Initiator Training
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.
© 2006 IT Services Stanford University
Page 20
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENT
IT Initiator Training
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)
•
© 2006 IT Services Stanford University
Page 21
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENT
IT Initiator Training
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 domain
b. 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
© 2006 IT Services Stanford University
Page 22
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENT
IT Initiator Training
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.
© 2006 IT Services Stanford University
Page 23
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENT
IT Initiator Training
Some Frequently Asked Questions (FAQ)
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.
Other Questions?
© 2006 IT Services Stanford University
Page 24
OPERATIONAL EXCELLENCE – CHANGE MANAGEMENT
IT Initiator Training
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: oe-cm-project@lists.stanford.edu
Process Document (available at Web Site above):
https://www.stanford.edu/services/changemgt/documents/OECM_Process_Document_v
2.7.pdf
HelpSU (for issues reporting and help): http://remedy-prod.stanford.edu/cgibin/helpsu2?pcat=cms (Category=Administrative Applications, Type=Change Management,
Item=*General)
Project Web page: http://www.stanford.edu/dept/itss/projects/OE/changemanagement.html
© 2006 IT Services Stanford University
Page 25