1. Change Management for MIS “The Interim Is over” Thatcher Deane Sep 28, 2011

2. AGENDA  Where we are  Where we’re going  The new Change Process  Tool support: KBOX  TIPS / FAQ  What’s next?  Questions

3. The Basics  Change Management (CM) Provides a formal, consistent and efficient methodology facilitating successful Changes while minimizing the impact of those Changes on services and operations. The primary Objectives of Change Management are: Communication Assessment Logging Scheduling Testing and Plans Reporting Configuration Management

4. Where we are  Major Interim Process Limited Scope (Major) Change Manager did most of the work Change tickets owned by Change Manager Request for Change (RFC) isolated Word Form Limited | Parallel tracking in KBOX Manual preparation of Stats and Forward Schedule of Change (FSC)

5. Where we are  Major Interim Process Stats (Feb 25, 2010 – Sep 19, 2011)  Total Changes 147  Successful 112  Unsuccessful 9  Cancelled 4  Changes triggering Incidents 77 A record of what we did, when we did it and how it turned out

6. Where we’re going  New Change Management Process Broader scope Fully Documented More Self-service Clarified Work flow More Distributed Work load Process Supported by a tool (KBOX)

7. Where we’re going  What else New Change process is a prequel to other ITSM Processes (Incident, Request and Problem)  Documented in the same format  Statuses specific to work flow  Use of separate KBOX Process Queue How it was built  Informed by templates and Interim experience  Tailored to our organization  Built with tools on hand

8. What’s not new  Process Basic Process Flow Tracking our work Exercising professional care  Tools KBOX (our work management tool) RFC (Request for Change)

9. What’s new  Scope increase  Distinct approval step  Change tickets in your KBOX ticket list  Linking Changes to and from Incidents  Start on linkage of Change to Config Items  Terms Successful – Followed the Change implementation plan – not necessarily fixed the targeted Incident or Request Requester – Replaces submitter

10. Scope of new Change Process (1/3)  The addition, modification, or removal of anything (hardware, software, process, procedure etc.) that contributes to or could impact an IT Service.  Three types of 'Managed' Changes: (1) Normal Change – ‘Change’ (2) Standard Change (3) Emergency Change

11. Scope of new Change Process (2/3) (2) Standard Change - Changes that are low risk, low impact, pre- approved, and well documented. Standard Changes are managed via the Request Fulfillment Process, not the Change Management Process. An example of a Standard Change is provision of a new computer. (3) Emergency Change - Change of an urgent nature but in the same scope as a Normal Change, where the addressed Incident impact and urgency do not allow for all steps of the Change Management Process to be competed before the Change is implemented. Emergency Changes have a faster approval process but require, after the fact, the same level of documentation as a Normal Change.  Un-managed Change - Any Change that is undertaken without the support of this Process. That is, a change that has no Change ticket opened and no RFC filed against it.

12. Scope of new Change Process (3/3) (1) Normal Change, (a.k.a. Change) include, in the production environment or data center: a) addition, significant reconfiguration or removal of network devices such as routers, bridges, switches, firewalls. b) addition, significant reconfiguration or removal of storage devices such as SAN servers, SAN storage c) addition, significant reconfiguration or removal of file, application, web or other servers d) significant modification to the standard desktop or impacting an entire business function e) significant modification to application infrastructure or functionality f) significant modification to Internet or Intranet Web infrastructure or functionality g) addition, significant reconfiguration or removal of Database infrastructure or services.

13. Documentation for your Binder  Process Flow Diagram  Process Description Executive Summary  Extracts from full Process Description Definitions Process Procedures  Request For Change (RFC) Template

14. Work Flow: High Level Five Activities Role Primarily Responsible for each Activity KBOX Statuses and Owners during each activity

15. Work Flow: Detail Activity Tasks Responsible Roles

16. Process Description (1/2)

17. Process Description (2/2) Goal Objectives Statuses Metrics Roles Policies Governance Activities Initiate Authorize and Schedule Review and Assess Implement and Verify Review and Close  Standard Sections:

18. RACI Chart by Task / Role

19. Process Definitions

20. Process Procedures  Work instructions for Changes in KBOX

21. Request For Change Template  The RFC is for the information that will not fit into the KBOX ticket screen. Instructions for the RFC Tips for dealing with a Word Form

22. Tool support: KBOX Changes  New ‘Process Queue’ allowing Change Process Specific screen fields Change Process Status settings Linkage (baby steps) to Configuration Items  Lookup into KBOX assets  Free form field

23. The Change Process Queue (1/3)  Something New at the New Ticket button Use Process Queue ‘Change’ for New Changes You will not see the other Process Queues for Incident, Problem and Request Fulfillment until those Processes are rolled out. Everything else (New Incidents and Requests) use the The MIS HelpDesk Process Queue.

24. Change Process Specific Layout Mostly fields obvious, but instruction in labels and detailed instructions provided in Procedures Document. Moved some items from RFC to Change ticket screen

25. Process Specific screen fields Statuses relate only to the lifecycle of a Change not to Incident or Request.

26. Single list for dependent Orgs

27. Linkage to Configuration Items (1)Look up CI touched by Change in KBOX here… (2) If you want a more complete look up / list of KBOX asset items go to this link… (2) If you don’t find it or have more than one, enter here…

28. The Change Process Queue (2/3)  Seeing C along with I and R tickets.

29. The Change Process Queue (3/3)  Then sort, if needed, on column

30. KBOX Screen Shots: New Ticket

31. KBOX Screen Shots: Ticket Example

32. TIPS –Show owned or submitted To Shows tickets you own or you submitted: use View By Active Tickets

33. TIP – Custom Views To Create and Save a Particular Ticket List View Create a Custom View

34. TIPS – URL to All Process Queues To Shows tickets you own or you submitted in all process queues, rather than navigate via the ‘View By’ drop downs, just go to this URL: To Shows tickets you own or you submitted in all process queues, rather than navigate via the ‘View By’ drop downs, just go to this URL: http://tkbox/userui/ticket_list.php?QUEUE_ID=A LL&ORDER[]=QUEUE_NAME&ORDER_R EV=1

35. TIPS – KBOX Asset Extract  http://countyintranet/Computer_Inventory/ind ex.asp http://countyintranet/Computer_Inventory/ind ex.asp

36. TIP – Email comments and attachments to KBOX tickets  Easy way to attach RFC and other docs to a Change Ticket.  Specific TIPS in Process Procedures Document  Each process queue has different email address: admin@kbox.co.maui.hi.us (The MIS Help Desk) admin@kbox.co.maui.hi.us change@kbox.co.maui.hi.us (Change) change@kbox.co.maui.hi.us  Sender must be a KBOX Owner for the process queue, that is MIS staff.

37. TIP – Email comments and attachments to KBOX tickets

38. FAQ  Where do I find the Documentation about all this, including this presentation?  The usual place: http://intranet.co.maui.hi.us/index.aspx?NID=611 MIS Services > MIS Division > MIS ITSM Improvement Program > Active ProcessesMIS DivisionMIS ITSM Improvement Program

39. FAQ  When does this take effect? Start of Business, Mon Oct 3 rd  What if I’m not clear if something is a Change or can’t tell if it is a Normal or Standard Change? If the documentation is not clear, consult with a Section Head or the Change Manager.

40. What’s Next  For Change Management Change Models Finding all the Standard vs Normal Change distinctions Process adjustments as needed and scheduled tune ups (CSI)

41. The End Mahalo, especially to those of you who:  Created and support the Test KBOX environment  Had a Change under the Interim Major process  Read the Full Change Process Description document  Commented on the new Change process beta KBOX  Assisted beta testing of the new process  Reviewed earlier versions of this presentation QUESTIONS? and COMMENTS!