1. Information Technology Division Executive Office for Administration and Finance IT Service Excellence Committee (ITSEC) Sept. 19, 2011

2. TopicDesired OutcomesDiscussion lead Allotted time August KPI review Discussion of KPI volumes in order to determine opportunity areas Tom/All10 min Systems Criticality Rating Initiative Teeing up for a coming discussion on Application Criticality Tom/Dan/Ron25 min Change Management Review of proposed Change Management discussion for ISB Ron/Deb Seaward 30 min FY 12 Plan Review proposed goals Tom5 min Roundtable News of member activity All15 min 2 Agenda

3. 3 Augusts Incident Activity by Priority

4. August Incident Activity by Category 4

5. Background: Critical Systems designation 5 In 2009 in response to Pandemic planning exercise the Commonwealth undertook effort to identify critical services – led by both EPS, EHS (Dept. of Public Health) and MEMA A Senior level pandemic readiness committee across the Executive staff was formed and supported by an IT committee and by a expert business continuity consultant (members included Dan Walsh, Curt Wood, Ron T., etc.) Across the Executive Office, identified the Essential Functions (ESFs) and then the critical IT systems that support them across Health, Safety and Financial Services Initial focus of Pandemic planning was on loss of personnel and effect on critical services There were multiple Tiering levels and priorities assigned A list was developed which identified approx. 200 applications and their priorities (see appendix) There is a need to fully operationalize this work because it drives: Disaster Recovery and Business Continuity Planning Back-up Service Restoration in terms of Incident Management System Design choices

6. Executive Sponsorship to operationalize 6 In August of this year Dan Walsh and Claudia Boldman from ITD brought forth a proposed classification scheme to formalize the process of defining system criticality- see appendixsee appendix Categories: Vital, Important, Supporting This work was endorsed by the CIO Cabinet (and ITD Executive Committee) The CIO Cabinet directed that the Commonwealth’s Service Excellence program operationalize this classification scheme (actually Emmet Millet had raised the need for having a formal approach to id critical systems) Objective is to move beyond “loss of personnel resources” to a more normalized approach – loss of IT service Why this committee has been asked to lead this work Aligns well with the overall thrust of Service Excellence program & ITSEC has the necessary representation Some ITSEC members have been engaged with their business partners to determine SLO levels (i.e. and thus some understanding of levels of expected support) The ITSEC has done very good work to map business driven examples of Incident Impact and Urgency into an Incident Prioritization model * Maureen Quinn from ITD who supported this effort

7. Considerations/questions 7 Considerations- the customers would drive the classification, i.e. this is a business call If a system is classified as being of a certain criticality, then it must meet certain minimum technical standards and be subject to certain policies, D/R requirements (i.e. designed such that 2 nd data center capabilities can be leveraged) Availability- expectation Supportability: runs on a supported OS, supported version of DB, supported h/w, etc. For new systems in design phase, a critical classification would be determined and if a system was designated as a Commonwealth Critical system (i.e. Vital classification) certain design characteristics must be incorporated Significant Changes to Systems classified as vital would be made visible through a commonwealth-wide Change Management process Retrofitting of such system designation to existing systems and implied level of technical compliance- i.e. there is a price associated w/ designating a system as mission critical This work was driven by a sense of urgency during the 2009 pandemic awareness (H1N1 Flu virus) – how can we re-ignite that sense of importance on the business side?

8. Establish SE Culture Offer of Enterprise Service Delivery tool Commonwealth Policies, Processes and Metrics for Incident Management Develop Commonwealth SLOs and SLO Reporting Commonwealth Policies, Processes & Metrics for Change Management Common H/W & S/W Asset Mgt tool Institute single Commonwealth Virtual Operations Culture 8 FY 11 Q2-Q4 We Are Here Model fully implemented FY 12 FY 13 ITSEC established Internal ITD Pilot- Monthly LOB/SLO Rpting Single Metrics reporting Framework established ITSEC Wiki presence ITD COMiT implemented 1 st Sec. Adoption COMiT 2 nd Sec. Adoption COMiT Follow-on COMiT Adoptions or integrations Incident Priorities Defined & ISB approved Incident end-to-end Model defined ITD LOB/SLO reporting to Customers ITD BSLO customer metrics Change Types & Stnd Windows Defined & ISB approved Weekly CW wide Change Calendar ITD weekly CM Calendar published All ITD h/w s/w in Enterprise toolCommonwealth h/w s/w in Enterprise tool Operational Framework Defined and agreed Monitoring tools rationalized/integrated in support of end to end SE model Education & Marketing plan ITSEC Road show ITSEC Day & Symposium Commonwealth- wide Reporting of Incident metrics CIO endorsed Service Excellence Program 3 year Road Map

9. Change Management – Context 9 At our 8/22 meeting, Donna P. raised the question of focus on Change Management (CM)- this co-incides with our FY 12 committee objectives Objective: Obtain ITSEC approval to have a collective initiative on Change activity Change meaning both Change Tickets and Service Requests Rationale: One major challenge is minimizing the impact of Change on our Production Environment A second important challenge we face is the often conflicting demands of Incident Management and Service/Request Management A large part of what our Helpdesks are managing volume wise is Customer Requests Start with Change Management, then work on Service Requests Ron offered to share one approach to CM at the next meeting Measurement As Secretariats begin to adopt a Change Management & Service Request processes, we would begin to gather that data in a manner similar to our Incident Metrics ITD and EHS would initially begin reporting Change metrics as this data becomes available

10. Vision 10 End State: Changes to the Commonwealth-wide IT Production environment will be managed and controlled through a formal change process under the responsibility of a Commonwealth Change Advisory Board (CCAB) A Commonwealth Change Advisory Board will be supported by similar boards at the Secretariat level established to advise the CCAB in the Assessment, prioritization and scheduling of Changes. The scope of changes covered by this policy would be based on a collective agreement across the Secretariats Metrics would be published similar to those of Incident Management by the ITSEC resulting in a demonstrated collective improvement in the stability of IT Services across the Commonwealth

11. Sharing of a Change Management process 11 Background: Process been in place for several years, we are constantly working to improve it, i.e. we just introduced a real-time Change Dashboard* We are very excited about other groups moving forward in this area and see it as a real win Process and Procedures are documented here (click on Procedure) :Procedures http://www.mass.gov/?pageID=itdintranetsubtopic&L=3&L0=Home&L1=IT+Service+Management+(ITS M)&L2=Change+Management&sid=Aitdintranet Weekly Change Management is always open to representatives from other Secretariats Forward Schedule of Change http://osgdashboard.anf.govt.state.ma.us:83/scripts/comit_forwardschedule. asp?MyMonth=9&MyYear=2011http://osgdashboard.anf.govt.state.ma.us:83/scripts/comit_forwardschedule. asp?MyMonth=9&MyYear=2011 *Daily Change Dashboard: http://osgdashboard.anf.govt.state.ma.us:83/scripts/comit_chgdaily-1.asp http://osgdashboard.anf.govt.state.ma.us:83/scripts/comit_chgdaily-1.asp

12. Gaining traction around CM- what does it take? 12 1. Obtain Executive level support for adopting Change Management 2. Designate a single Change Owner—for the Secretariat level 3. Establish a monthly or weekly CAB (Change Advisory Board) 4. Draft a documented change process and policy a) Should have well defined categories of changes b) Criteria for approval (i.e. Testing plan, adequate notice, emergency changes) 5. Establish some kind of ticketing system- even if manual spreadsheet 6. Start reporting basic metrics… # successful ; # failed; # of emergency changes 7.Implement a Post Implementation Review (PIR) process

13. Proposal 13 Establish a monthly (to start with) Commonwealth-wide Change Management meeting Really looking initially to sponsor an information exchange i.e. doesn’t need folks to have a formal change calendar or change process currently in place A Single Representative for each Secretariat -- sharing can be very informal Representatives would have a broad view of change activity across their Secretariat Each Representative would speak to known significant change activity planned for the upcoming month in their area ITD would include it’s Service Account Managers as additional resources Criteria for discussion: Type of changes: Infrastructure or Application changes Scope: (As determined by this Board)-- High level: Change activity that will or possibility that it could affect other Secretariats if unforeseen issues arise Major application release events such as NMMIS, ALARS, etc but small application changes would excluded Major infrastructure changes: new Main Core switch, Internet changes Expected numbers: no more than 8-10 total changes at first Benefits: Help one group avoid collusions (i.e. ITD making changes and being unaware of concurrent changes to same environment being made by another Secretariat) Provide an awareness of major change activity and enable quicker incident resolution on change induced outages

14. Next Steps 14 ITSEC members provide names of representatives for a Commonwealth-wide CAB (CCAB) by Oct. 7 th ( 3 weeks) Idea presented to 10/11 ISB meeting by ITSEC members Deb Seaward schedules first meeting for 3 rd week October Tom/Deb to work off-line on pre-work to help structure discussion and prepare our first FSC (Forward Schedule Change) with direct Secretariat access ITSEC debriefs at following meeting

15. Caveats/Considerations/Concerns 15 We know folks are in different places in terms of maturity What kind of visibility do folks have in their respective areas ? This work requires executive level support

16. 16 Continue Implementation Enterprise Service Delivery tool for Secretariats – Q1-3 Develop Common Policies, Processes and Metrics for Change Management and Request Management - Q2 Expand delivery of Incident KPI reporting to include breakdown by service categories and formalize definition of Response Time – Q2 Complete Definition of SLO’s in support of Service Catalog’s for 50% of ITSEC membership – Q2 Complete migration of ITD and begin migration Secretariats to a common hardware & software asset management tool- Q3 Continue development of Service Excellence culture- complete ITIL training through eLearning at practitioner level for Incident, Change and Configuration (as appropriate) Q1-4 ITSEC - Proposed FY 12 Goals

17. 17 Appendix

18. Service Request and Change Tickets Proposal As Secretariats begin to adopt a Change Management & Service Request processes, we would begin to gather that data in a manner similar to our Incident Metrics 18 **SLO meaning that the (Scheduled finish time- Schedule start time) is greater or equal to the (actual- finish time – actual start time), then SLO is met.

19. 19 Change Management Procedure

20. 20 Change Management Procedure (con’t)

21. Commonwealth Change Management Policy- a sample framework for future consideration 21 Change Type and key Change Management business rules Change TypeAssessment required CAB approval required Emergency CAB approval required Only Change Manager approval required Change Manager or Duty Manager (if off hours); LOB Owner and Product Owner (always) and (where appropriate) Customer agency IT executive approval required NormalNo (this requirement may possibly come at a later point of maturity in several months) Standard Emergency

22. Classification of Critical IT Services That Support Essential Commonwealth Functions 22

23. 23 Classification of Critical IT Services (con’t)

24. 24 Classification of Critical IT Services (con’t)

25. 25