Change Management IT Initiator Training stanford/services/changemgt

1. Change ManagementIT Initiator Traininghttp://www.stanford.edu/services/changemgt March 6, 2006 Presented by John Klemm, Bill Heiser & Bill Bauriedel

2. 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.

3. 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.

4. 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

5. 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

6. Change Planning Process (includes approval from governance groups and business owners as well as design, development, testing, etc.) (optional) Emergency / FoO Implementation Implementation and Review Approval Change Management ProcessHigh-Level Process Flow Initiate Change Request (CR) See Process Document for detailed process flows and detailed procedures

7. In the new Change Management System, Change Request Category/Priority Combinations are called STENCILS Change Management ProcessDefinitions: Change Management Terms

8. Change Management ProcessPolicy: Change Request Approvals and Lead-Times

9. Change Management ProcessDefinitions: Change Management Roles

10. Change Management ProcessDefinitions: Change Management Roles Continued from previous page

11. 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. See the OECM Process Document for a full list of the types of changes covered, including an expanded version of this diagram.

12. 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.

13. Demo: Submitting a Change Request (Web) Production Environment URL: http://cmr.stanford.edu (https://InfraAppProd.stanford.edu) Refer to QuickGuide for IT Initiators

14. Demo: Checking Status of a Change Request (Web)

15. Demo Result: Request Details Screen (Web)

16. ADDRESS: change-management@infraappprod.stanford.edu SUBJECT LINE: [createrequest] REQUIRED FIELDS: [Stencil: ] [Primary Domain: ][Change Title: ] [Class: ] [Type: ] [Item:] [Description: ] [Schedule Date/Time:] [Source: Email] Reference: Template for Submitting an Email Change Request 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

17. 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

18. Demo: Submitting a Change Request (Email)

19. Should I initiate a Change Request via the Web App or Email? • 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 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

20. 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.

21. 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 thatTask 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) /

22. 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: • Users can subscribe to a Mailman list to receive “all” notifications about changes affecting a given domain • 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

23. 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.

24. Other Questions? 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.

25. 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_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