1. CHANGE CONTROL PROCESS SEPTEMBER 22, 2008

2. 212/16/2015 Purpose  a methodical approach for capturing, managing and implementing IT changes  ongoing management of changes and enhancements in a single, standard tool  integration and ongoing communication of changes between users and IT  user, and ultimately customer, service levels are maintained The Change Control Process ensures:

3. 312/16/2015 Definitions A Change Request (CR) is defined as any activity that will alter or impact overall scope (as defined in the SOW/Charter/Requirements), schedule and costs A CR May Include (but is not limited to)…Disposition A change to existing system configurationCR A change to an existing development object such as an interface, report, form, etc CR A change to the production scheduleCR A request for new hardware or softwareCR Establishment of a new security roleCR An Emergency CR May Include (but is not limited to)…Disposition Mainframe/interface failure of any critical production applicationEmergency CR Reboot of a production serverEmergency CR A CR is NOT…Disposition Request for additional resourcesProcurement Request for a logon or password changeIT Services Support Line Ticket User needs to be added to an existing security roleSecurity Liaison Approval

4. 412/16/2015 Change Request (CR) Priorities Change Requests will have varying priorities which will drive required response and resolution time. PriorityDefinitionResponse SLA Resolution SLA CriticalSignificant issue that impacts the ability to make/ship/sell product or has a financial impact. The CR will have an impact on multiple departments/users and/or customers. Resource focus area. TBD HighAny change that impacts important business processes/systems, may require an outage impacting a large number of users and/or affects critical hardware/ software components. Resource focus area. TBD MediumAny change that does not impact critical business processes and does not affect critical hardware/software components. Typically impacts only a small group of users. Resource constrained. TBD RoutineMinor problem or cosmetic change which does not impact daily process and/or for which a work around is available. Resource constrained. TBD

5. 512/16/2015 Guiding Principles  A CR can only be logged by an IT resource and can only be initiated from an IT Work Request, Break/Fix IT ticket or internal IT request  Change requests must be approved by the Change Control Board (CCB) prior to the initiation of any work. CRs will not begun unless estimated hours have been defined, and priority of CR is assigned in work stream.  If a change is created as a result of a Break/Fix IT ticket, the ticket will be closed and the CR # referenced in the Break/Fix IT ticket. Changes resulting from an IT Work Request must have the IT Work Request attached to the CR  The Change Manager is responsible for all facets of the change, including ongoing management and communication of the change until its complete disposition  The change requestor or knowledgeable business contact must participate in testing and confirm acceptance of the change at a CCB meeting prior to promotion of a change to production  Weekly CR Release Notes will be published to provide formal communication of completed CRs and those due the next week The following guiding principles are critical to the success of the Change Request process:

6. 612/16/2015 Change Control Process Update process as appropriate for your project. Ensure key components always include review of CR against original scope, impact analysis, decision making board and formal approval and inclusion

7. 712/16/2015 Process Steps Ref ID Process StepDescriptionInput/OutputTime HorizonOwner 1PROCESS INPUTS: Break/Fix Ticket Scope Change IT Work Request A change request can be initiated through one of the following means: 1) Created as a result of an existing Break/Fix ticket. If the ticket is an enhancement, an IT work request must be created 2) Created as a result of an approved IT Work Request from the business or IT Input: Break/Fix Ticket, IT Work Request Output: CR As requiredIT, Business 2Reference Break/Fix Ticket # and Business Contact(s) Email in CR If a CR is initiated as a result of a change request, the original Break/Fix ticket # must be referenced in the CR. Additionally, the original requestor or appropriate business contacts email addresses should be provided for inclusion in the CR. These individuals will be required to participate in testing execution. Input: Break/Fix ticket Output: CR As requiredChange Manager 3Close Break/Fix Ticket w/ Reference to CR # and Change Manager The Change Manager will work with the Break/Fix Queue Manager to close the Break/Fix ticket. The CR# and Change Manager should be referenced in the Break/Fix ticket resolution field, and the Queue Manager and Change Manager will work with the user(s) to engage them in necessary CR activities. Input: Break/Fix ticket Output: CR, Closed Ticket As requiredQueue Manager/ Change Manager 4Submit Approved IT Work Request to Business Partner for Attachment to CR The business will complete an IT Work Request form when requesting independent production system changes. Once approved, the form will be submitted to the Business Partner for attachment to the related CR. Input: IT Work Request Output: CR As RequiredBusiness Contact 5Initiate a New Change Request in Incident Tickets Tool Based on one of the 2 inputs above, a CR will be initiated in an Incident Tickets Tool. Required fields will be filled out initially and additional detail provided based on CR priority. NOTE: A CR can be created in Incident Tickets Tool before an IT Work Request is created but the CR cannot be approved until it is completed and attached Input: Break/Fix Ticket, IT Work Request Output: CR As necessaryChange Manager

8. 812/16/2015 Process Steps (continue) Ref ID Process StepDescriptionInput/OutputTime HorizonOwner 6CCB Conducts Preliminary Review to Authorize CR for Estimating New CRs will be reviewed by the CCB during the weekly Monday meeting. If the CCB approves the CR to move forward to the estimating stage, proceed to step 8. If the CR is rejected or deferred at that point, proceed to step 7. Input: CR Output: Preliminary CR disposition As necessaryCCB 7Set Status to Cancelled, Update Comments and Notify Impacted Parties If the CCB rejects the CR, the status will be set to Cancelled and the CCB will include rejection reason details in the comments. An automated email will then be sent to the appropriate business and functional contacts to alert them of the disposition. Input: CR Output: Cancelled CR As requiredCCB 8Provide all Detail/ Specifications Necessary to Complete Change Request All necessary details must be attached to the CR, so that the assignees have all the information required to act upon the request. The Change Manager will be responsible for coordinating necessary details between the requestors/business contacts and technical teams and ensuring sign off. Input: Functional/ Technical requirements Output: Updated CR As requiredChange Manager 9CCB Conducts Final Change Request Approval Review Once all necessary detail has been provided/updated on the CR (including specifications, effort, priority, etc), the CCB will conduct a final review to approve or reject the CR. If the CR is approved, the CCB must establish an appropriate priority level and production date based on resource availability. NOTE: A CR MUST have estimates before it can be approved. Input: Updated CR Output: CR with disposition As requiredCCB 10Update Status and Send Automated Email w/ CR Disposition If the CR is not rejected, the CCB will update the CR with the appropriate status (i.e. Executing, Deferred, etc). Based on the established workflow, an automated email will be sent out to alert impacted individuals of the status. NOTE: If a load file layout change results, these changes must be pushed to the developer Input: Updated CR Output: Approved CR As requiredCCB 11Change Manager Manages CR Through Development Completion The Change Manager will serve as the single point of contact for managing the CR through design to development, and will ensure that production dates are kept accurate/current. They will liaise between the business and IT to ensure the CR is completed as requested. Input: Updated CR Output: Approved CR As necessaryChange Manager

9. 912/16/2015 Process Steps (continue) Ref ID Process StepDescriptionInput/OutputTime HorizonOwner 12QA Conducts Testing Readiness Assessment Once the CR is ready for testing, QA will review to ensure that the necessary environments are established, test scripts are developed and all QA checklist items are complete. If the CR completes QA readiness, the status will be updated and proceed to step 14, else repeat step 13. NOTE: If a CR is approved as an Emergency after hour request, the QA Analyst step will be skipped for expediting. Input: CR Output: CR (Test in QA) As requiredQA Analyst 13Complete Detail Testing Execution Once the CR is approved for testing, the QA Analyst will act as the single point of contact to coordinate testing activities (i.e. test script development, test data setup, etc). Testing should include unit, string, integration, regression and UAT and must include the original requestor or appropriate business contact identified as the test validators in the CR. If the CR has been successfully tested, proceed to step 15, else repeat step 14. NOTE: A detailed testing procedure will be provided by the QA Team Input: CR (Test in QA) Output: CR (Test in QA As requiredQA Analyst, Test Validators, Change Manager 14Set Status to PROD Approval and Review for Migration Once testing is complete as confirmed jointly by the business, IT and QA, the status will be set to PROD Approval and reviewed for production migration. Input: CR (Test in QA) Output: CR (PROD Approval) As requiredQA Analyst 15Promote Change to Production Based on Migration Schedule Changes will be reviewed for approval into PROD via the change control migration process. Changes will be promoted during 2 windows (TBD by ITPD). Emergency requests will be handled on a case by case basis. Input: CR (PROD Approval) Output: CR (Deploy to PROD) As requiredMigration Manager (or designee) 16Set CR Status to Complete in PROD Once the Change Manager confirms the change has been successfully migrated in Production, the CR status is updated to Complete in PROD and notifications are distributed by the Change Manager. Input: CR (Deploy to PROD) Output: CR (Complete in PROD) As requiredChange Manager

10. 1012/16/2015 Process Steps (continue) Ref ID Process StepDescriptionInput/OutputTime HorizonOwner 17Verify Change in Production Once the change is in production, the appropriate business contact(s) and Change Manager will verify that the change is working as designed in the Production environment. Input: CR (Complete in PROD) Output: CR (Validated in PROD) As requiredBusiness Contact(s), Change Manager 18Publish Weekly CR Release Notes Release Notes will be published to IT and appropriate business users to communicate CRs that have been completed and moved to production as well as those scheduled for migration during the week. Input: CR (Complete in PROD) Output: CR Release Notes TBD (Wednesday/ Friday ?) CCB

11. 1112/16/2015 Key Roles & Responsibilities The following Roles/Responsibilities are pivotal to proper execution of the Change Control Process. RoleResponsibility Business Contact Participate in testing/final approval of CR prior to deployment Business Partner (BP) Executive level management for all CRs Coordination of priorities across the business Collect and review approved IT Work request forms for input into CR process Change Control Board (CCB) Review all CRs for completeness and validity. Disposed CRs as approved, rejected or deferred Change Manager Ensure CRs are completed appropriately and thoroughly before presentation to the CCB, including CR single point of contact for functional and technical specifications and estimates Manage the full life cycle of the CR from open, development, testing and closure Provide ongoing communication to impacted parties as to CR progress Migration Manager Approve and implement changes for migration into production QA Analyst Ensure testing environments are properly available/established Validate cutover, deployment and transport sequence

12. 1212/16/2015 CCB & Code Migration Calendar The CCB will meet during the following times to review open CRs: CRs will be migrated to production based on the following schedule, with the exception of approved emergency CRs DayTimeParticipantsFocus MondayTBDCCB/IT OnlyReview current list of CRs, prioritize based on resource availability, disposition, update status ThursdayTBDCCB, Impacted Business Users/ Stakeholders Review list of new and active CRs with impacted business users and stakeholders DayTimeCR Cutoff Period WednesdayTBD? on Wednesday SaturdayTBD? on Friday

13. 1312/16/2015 Contact Information For additional information on this process, please contact… Contact NameEmailPhone PrimarySteve Keanenskeane@uchicago.edu773-203-4486 SecondaryDeneeta PopeT-9dpope@uchicago.edu773-702-8869