Change Management IT Approver Training stanford/services/changemgt

1. Change ManagementIT Approver Traininghttp://www.stanford.edu/services/changemgt 3 March 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 Approver role; and • Be prepared to approve (authorize) change requests.

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 authorization 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 peculiarities (mostly 1st time only), odd interface

5. Change Management Process Introduction to the IT Approver Role • The IT Approver is the person or group of people who are responsible for approving Change Requests in the Change Management System • The IT Approver can approve (authorize) Minor, Significant, and Major Change Requests in primary and secondary domains*

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 CM 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, sorted by whether each change does or does not require a change notice, appears as an Appendix to the Change Management Process Document.

13. Demo: Approving a Change Request (Email)

14. Demo: Approving a Change Request (Web) Production Environment URL: http://cmr.stanford.eduCM website (links to above): http://www.stanford.edu/services/changemgt Refer to QuickGuide for IT Approvers

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

16. Demo Result: Request Details Screen (Web)

17. Should I approve a Change Request via the Web App or Email? • Email • Notes can be included • No positive feedback from system to approvers (also means you won’t know if already approved) • You can CC initiator, other approvers or yourself for your records • No login to web app required • Your sending email address must match your address in Infra database Web Application Peculiar to use Yellow arrow/ownership Password requested but not needed Tasks vs. Requests nomenclature issues If multiple approvers in a domain, Tasks list shows current list of unapproved requests Instant feedback - can check status

18. What Happens After You Submit the Change Request? • (Specific details depend on the Stencil for the Change Request) • Approvers receive email asking them to approve (via email or web app) • Initiator receives a confirmation email • If a domain has multiple approvers, each receive the email and can take action. First to take action, however, is decisive (the domain-approval task is thus completed) (another reason to do CCs with email). • Then, if/when all approvers approve, initiator receives email notification that the task of implementing the change and closing the change request record are ready to do • If any approver disapproves, initiator receives email notification that the task of closing the change request record is ready to do • You cannot change the change request record when approving it. Solution: You as approver can reject it, and initiator 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.

19. 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 • 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 (using the browser BACK button may cause undesirable results, such as duplicate change requests being submitted) /

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

21. Known Issues, as of 12/14/05 There are some outstanding Infra issues that should be noted by all users. These are known issues that are not resolved:

22. Other Questions? Some Frequently Asked Questions (FAQ) What happens when there is a scheduling conflict? The Change Coordinator 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.

23. Key Links CM Production Environment: http://cmr.stanford.edu CM Website: http://www.stanford.edu/services/changemgt Email: oe-cm-project@lists.stanford.edu Project Web page: http://www.stanford.edu/dept/itss/projects/OE/change-management.html Process Document: 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)