Change Management Process VERSION 1.0 Version Date: 1 May 2006
Table of Revisions REVISION NUMBER DESCRIPTION OF CHANGES (PARAGRAPH AND OR SECTION NUMBERS FOR REVISION TRACKING) DATE OF CHANGE REVIEWED / REVISED BY 0.1 Final Draft 2 2 06 Brad Lytle 0.2 Updated procedures to reflect Lotus Notes Change 4 25 06 Brad Lytle Request system 1.0 Formal Implementation 5 1 06 Brad Lytle UNCG Proprietary & Confidential 2
Table of Contents 1.0 INTRODUCTION... 4 1.1 SCOPE AND OBJECTIVES... 4 1.2 DEFINITIONS... 4 2.0 CHANGE MANAGEMENT PROCESS... 5 2.1 PROCESS IMPLEMENTATION... 6 2.1.1 STANDARD CHANGES, EMERGENCY CHANGES, AND OUTAGES... 6 2.1.2 RISK ASSESSMENT... 6 2.1.3 IMPACT ASSESSMENT... 7 2.1.4 CHANGE NOTIFICATION... 7 2.1.5 REQUEST FOR CHANGE APPROVAL... 7 2.2 ROLES AND RESPONSIBILITIES... 8 2.2.1 CHANGE MANAGER... 8 2.2.2 CHANGE ADVISORY BOARD... 8 2.2.3 CHANGE REQUESTER... 9 2.2.4 CHANGE ASSIGNEE... 9 2.2.5 CHANGE APPROVER... 10 3.0 CHANGE MANAGEMENT PROCEDURES... 10 3.1 CREATING REQUEST FOR CHANGES... 10 3.1.1 STANDARD RFC s... 10 3.1.2 EMERGENCY RFC s... 11 3.1.3 APPROVAL OF RFC s... 12 3.1.4 PEER REVIEW... 12 3.2 CHANGE ADVISORY BOARD PROCEDURES... 13 3.2.1 CHANGE ADVISORY BOARD MEETINGS... 13 3.3 COMMUNICATING PLANNED CHANGES... 14 3.4 INFORMATION SECURITY... 14 UNCG Proprietary & Confidential 3
1.0 INTRODUCTION The Information Technology Services (ITS) Change Management process is designed to control the implementation of all changes made to any device or application within the UNCG production environment. The academic and administrative requirements of the university demand highly available and functional technology services. The ITS Change Management process exists to ensure ITS can provide a high level of availability and integrity in the delivery of technology services. 1.1 SCOPE AND OBJECTIVES The scope of the ITS Change Management Process includes all infrastructure, applications, and services used by the UNCG client community for business or academic purposes. The objectives of the ITS Change Management Process are to ensure that: All Changes are properly analyzed, documented, and communicated to ITS staff and to all functional groups and clients potentially affected by, or involved in, their execution.* Details of all Changes are tracked and stored in a central Change Management System for the purpose of historical trending and reporting. Procedures required before, during, and after Change execution and the respective areas of responsibility are clearly documented and published. The proper analysis and testing is performed to assess the need for a change versus the potential impact of the change. No Change is executed without first being properly planned, documented, peer reviewed, tested, and approved. *For details, see Section 3.3 Communicating Planned Changes 1.2 DEFINITIONS Change CAB Change Manager RFC Any modification to the systems, infrastructure, or applications that comprise the UNCG production environment, with the exception of basic object administration tasks that do not affect service functionality. Change Advisory Board Organizational entity responsible for the assessment, approval, and planning of changes. Individual responsible for the overall Change Management process and its proper execution. Request for change A request to implement a Change within the UNCG production environment. UNCG Proprietary & Confidential 4
CMS UNCG ITS SOC Production Environment Change Management System Software tool or combination of tools utilized for the request, approval, tracking and details of changes. The University of North Carolina at Greensboro Information Technology Services Service Operations Center All system, network, infrastructure, and software that supports the technology services utilized by the UNCG client community for business and academic purposes. Environments utilized for testing and development are not considered to be production. 2.0 CHANGE MANAGEMENT PROCESS To ensure the integrity, consistency and availability of the UNCG technology services, all changes to the UNCG production environment will be tracked via a Request for change (RFC). RFC s will be entered into and managed via the Change Management System (CMS) to ensure Changes are centrally tracked, approved, reported upon, and enforced in a reliable and consistent manner. RFC s must be reviewed and approved by the Change Advisory Board (CAB) prior to execution to ensure a proposed Change does not compromise the stability of the production environment. Changes to the UNCG production environment must be: Implemented using the standard Change Management Process. Documented prior to, during, and after Change execution. Assessed for risk to the production environment, assigned the appropriate risk level and handled according to the level assigned. Submitted with implementation and rollback plans, as well as an assessment of the probability of failure. Peer reviewed by at least one other qualified staff member. Coordinated with all people required to implement and verify functionally. Classified and submitted through the Change Management process as the proper Change type to ensure all affected parties are aware of and prepared for the impending Change* Communicated to the appropriate user community if the change has any potential impact on the user base, including a temporary service outage.** Approved by the appropriate manager(s). Monitored and closed in a timely manner. * For Change type definitions, see Section 2.1.1 Standard Changes, Emergency Changes, and Outages **For details, see Section 3.3 Communicating Planned Changes UNCG Proprietary & Confidential 5
2.1 PROCESS IMPLEMENTATION While the Change Management process begins with the initial user request for change, the information presented in this section focuses primarily on those tasks necessary for the implementation of a production change. 2.1.1 STANDARD CHANGES, EMERGENCY CHANGES, AND OUTAGES As timing, impact and other factors vary due to the urgency and nature of some Changes, there is a need to define standards to differentiate between Standard Changes, Emergency Changes, and Outages. For the purposes of ITS process, these definitions are the following: Standard Change Any Change that is scheduled and receives approval for execution from the CAB prior to its execution. Emergency Change Any change that has a level of urgency that requires its execution to take place prior to the CAB having an opportunity to review and approve it. Emergency Changes must have a valid business justification and must receive approval from an ITS Manager and an ITS Associate Vice Chancellor prior to its execution. Outage An outage is a loss of one or more services delivered by ITS. Work done on infrastructure or applications supporting a service that is already unavailable due to an outage, are not considered a Change for the purposes of this process and do not need to follow the Change Management process. This work will be tracked via the Incident Management Process related to the outage. The Service Operations and Support group and Client Services must be notified of a planned change of any kind prior to its execution. 2.1.2 RISK ASSESSMENT An assessment of risk must be completed on any Change prior to its approval. This assessment should be done at a minimum of three points throughout the Change Management Process. They are: 1. By the Change Assignee at the time of creating the request. 2. By the Change Approver prior to approving the request to go before the CAB. 3. By the Change Advisory Board prior to giving final approval for the execution of the change. In assessing the risk level of a change, the following factors must be considered: Probability of customer impact Potential level of customer impact UNCG Proprietary & Confidential 6
Probability of success/failure Potential impact of failure Possibility of roll back Potential roll back or recovery time Once the appropriate level of risk is determined, it should be balanced with the level of need for the change prior to making the initial request or at each stage of approval. 2.1.3 IMPACT ASSESSMENT Below are guidelines for determining the appropriate level of customer impact: High Any service outage of a mission critical system or application, and/or multiple users are not able to perform their normal business functions Medium Service outage of a non mission critical system or application. Low Service interruption with no noticeable impact on end user s ability to perform their business functions. None No anticipated impact on the end user community. 2.1.4 CHANGE NOTIFICATION It is the responsibility of the Change Assignee to ensure: Any change to the production environment that has potential impact to service availability, performance or usage is communicated to the affected user communities.* All changes are communicated to the Service Desk, Service Operations Center, and Client Services. The Request for change is approved by the Change Approver. All of the above is completed prior to CAB review of the Request for change. All mass communication is sent via the ITS Communications Office. *For details, see Section 3.3 Communicating Planned Changes 2.1.5 REQUEST FOR CHANGE APPROVAL Standard Request for change A Standard RFC must receive two levels of approval prior to execution. The first approval must come from the Change Approver. The second approval must come from the Change Advisory Board. Emergency RFC An Emergency RFC must receive two levels of approval. The first approval must come from the Change Approver. The second approval must come from an ITS Associate Vice Chancellor. UNCG Proprietary & Confidential 7
2.2 ROLES AND RESPONSIBILITIES Within the Change Management process, specific roles and functions have been defined. Each role is ultimately responsible for completing specific tasks within this process. 2.2.1 CHANGE MANAGER The Change Manager is responsible for the overall facilitation of the Change Management process. Responsibilities of the Change Manager include: Coordinate and chair the weekly meetings of the Change Advisory Board. Facilitate the resolution of any schedule conflicts that may arise. Maintain the policies and procedures necessary to carry necessary CM functions. Grant access to the Change Management Database. Ensure any non standard notification of user communities or POCs is performed. 2.2.2 CHANGE ADVISORY BOARD The Change Advisory Board (CAB) is a group of individuals that represent various ITS and Client communities. This group is responsible for final review and approval/rejection of all standard RFC s. The CAB meets at a regularly scheduled interval to review all pending RFC s but can also perform their function remotely (email, telephone) if necessary. In addition to the normal CAB members, the Change Assignee (or a staff member sent in their stead) who has a pending RFC submitted for review by the CAB shall attend board meetings. All Changes are reviewed by the CAB during its periodic meeting. The CAB has the authority to do any of the following: Cancel or reject changes Approve RFC s as presented Re assess the risk level of a Change Re assess the impact level of a Change Request additional information prior to approval Note: Emergency RFC s, due to their urgent nature, may be performed without prior review by the CAB only if written approval from an ITS Associate Vice Chancellor has been received. UNCG Proprietary & Confidential 8
2.2.3 CHANGE REQUESTER The Change Requester is the person who initially requests that a Change take place. Often, though not always, this is carried out through initiation of a support request to the ITS Service Desk, which enters and tracks support actions in the Remedy application. In such a case, the action request is ultimately assigned to the person/organization whose function it is to implement changes of the requested type. The Change Requester must provide all the requirements and objectives for the change, including an explanation of the reason and justification for the proposed change. If the Change Requester does not provide adequate detailed information, the Change Assignee or Change Approver have the authority to require it before creating the RFC. In the event that the Change Requestor is also the Change Assignee, that person will have the responsibilities of both roles. The responsibilities of the Change Requester include: Initial escalation/request for change (via Service Desk, Call Tracking Software, etc.). Provision of business and technical requirements to the Change Assignee. Resolution or escalation of Change issues. Provide input to the assessment of the change s level of risk. Provide input to the assessment of the change s level of impact. Change planning and coordination. Review of the Change plan/documentation. Ensure the user community affected by the change is notified prior to the change implementation. Facilitate any required client testing before, during or after Change execution. 2.2.4 CHANGE ASSIGNEE The Change Assignee is the owner of the Change. This person will work with the Change Requestor (if it is someone else) to gather the appropriate information required to create and represent the RFC. Responsibilities of the Change Assignee include: Creation of the RFC including Peer Review of the change. Communication and coordination of Change testing and implementation. Meet with the Change Requester, as needed, to resolve any questions or problems with a proposed change. Update any related documentation after the change has been implemented. Update the status of the RFC and enter all necessary information into the CMS, which may be helpful for historical purposes. Follow up with the Change Requester to provide status on the implementation success or failure. Provide closure status in the CMS. UNCG Proprietary & Confidential 9
2.2.5 CHANGE APPROVER The Change Approver is the manager who provides the first level of approval to a RFC, allowing it to go before the CAB for review. In most cases, this is the manager of the Change Assignee. If that is not possible, the Change Approver can be any ITS manager or above. Responsibilities of the Change Approver include: Review all RFC s submitted by staff members of their group Ensure all necessary communication, coordination, documentation and testing has been completed properly on all RFC s prior to approval Approve all RFC s prior to them being submitted for review by the Change Advisory Board 3.0 CHANGE MANAGEMENT PROCEDURES Change Management procedures have been developed and implemented that take into account the impact of changes to UNCG s administrative and academic activities including system availability, user impact, system efficiency and currency/usability of documentation. A major goal of the process development effort was to establish a set process that facilitated the coordination of changes within the UNCG production environment. This process will be changed as needed. 3.1 CREATING REQUEST FOR CHANGES (RFC S) 3.1.1 STANDARD RFC S The creation and submission procedures for a Standard RFC are below, by area of responsibility: Change Assignee: 1. Complete a RFC via the Change Management Database in Lotus Notes. Completion of this request will require the Change Assignee to: a) Check the critical Events Calendar to ensure that the intended date for the change will not conflict with other activities. b) Assess the risk vs. benefit of the change (refer to Risk Assessment, section 2.1.2), and assign a risk level for the change. c) Have a peer review the changes and annotate that they have reviewed the change and concur with the planning of the change (see Peer Review, section 4.1.4) d) Communicate and coordinate with all necessary support and client personnel PRIOR to submitting the RFC.* UNCG Proprietary & Confidential 10
2. Once the RFC has been fully completed, submit for approval by the Change Approver. (This will initiate an email notification to the Change Approver(s) alerting them to the submitted RFC) Change Approver: 3. Review the RFC and Approve or Reject the request. Approval will advance the RFC to the First Level Approved status and a notification will be sent to the next level of approvers for review. Rejection will send a notification to the Change Assignee stating that the RFC has been rejected. Change Advisory Board: 4. Review the details of the RFC and approve or reject the request. Approval will advance the RFC to the Final Approval status. Rejection will send a notification to the Change Assignee stating that the RFC has been rejected. Change Assignee: 5. For approved RFC s, create a Remedy Case for the scheduled Change. Enter the Remedy Case # in the RFC. 6. Execute the Change at the scheduled time and update the Remedy Case appropriately. 7. After the Change is complete, indicate the appropriate Disposition of the Change in the RFC. Update the Remedy Case with any details of the Change and Resolve if appropriate. *For details, see Section 3.3 Communicating Planned Changes 3.1.2 EMERGENCY RFC S Emergency Changes are usually the result of actual or imminent hardware or software failures impacting or threatening to impact a UNCG technology service. They are implemented before the Change Advisory Board has had an opportunity to review them. These Changes must be associated with a Remedy Case and must still be communicated and documented in the Change Management process within 24 hours from the time of execution. In the event an Emergency Change is warranted, the Change Assignee will: 1. Notify a Director or above of the situation and that an Emergency Change is needed and receive written approval to execute the Change. 2. Notify the Service Desk and Service Operations Center and provide sufficient details to enable them to respond to calls from users who may be impacted by the change, as well as identify monitoring alarms that may be associated with the Change. Coordinate, as reasonable, any emergency communications necessary through the approving Director or above. UNCG Proprietary & Confidential 11
3. Execute the Change. 4. Once the Change is completed, notify the Service Desk and Service Operations Center and advise them of the success or failure as well as the current state of the impacted environment. 5. Complete a RFC within 24 hours of resolution of the Change execution and submit it for approval by the Director or above involved. 3.1.3 APPROVAL OF RFC S When the Change Approver is notified of a pending RFC, they will: 1. Review the RFC to ensure the appropriate actions have taken place, including but not limited to peer review of the proposed solution, plan for notification of the user community if required, and coordination of change with appropriate teams. 2. Approve or Deny the RFC. If the RFC is not approved, the Change Requester can take one of the following steps: a) Cancel the request completely, b) Complete the necessary steps as indicated at the time of Rejection, and resubmit the request c) Request that the request be forwarded on to the Change Approver s supervisor. The Change Approver s Rejection of the request will remain documented in the Change Management System. 3.1.4 PEER REVIEW Once a RFC has been completed and is ready to be submitted to the Change Approver for initial approval, the Change Assignee must request a review of the RFC from a technical peer with similar knowledge of the environment where the Change will take place. The technical peer will review the RFC and ensure that the specific technical steps planned appear to be correct. Once this is verified, the technical peer will update the RFC, indicating that they have reviewed the technical steps of the Change. Note: The technical peer chosen for Peer Review is responsible only for reviewing and validating the technical steps indicated in the RFC to complete the Change itself. This person is not responsible for ensuring other required steps (communication, coordination, scheduling, etc.) are taken. This responsibility is that of the Change Assignee, Change Approver, and CAB. UNCG Proprietary & Confidential 12
3.2 CHANGE ADVISORY BOARD PROCEDURES The Change Advisory Board (CAB) will meet periodically for the purpose of reviewing all pending RFC s. The CAB will either approve or reject each RFC during the course of the meeting. 3.2.1 CHANGE ADVISORY BOARD MEETINGS To prepare for the CAB meeting, the Change Manager will: Summarize and compile all RFC s received prior to the meeting start time into a report. This report will be called the Change Summary Sheet. The report must contain sufficient information for each change to ensure the Board members understand and can evaluate the change being proposed. The report contents will be further grouped by the following subcategories: New Requests Existing Requests Each report entry contains: Description of the Change Location of proposed Change Locations and user communities potentially impacted by the Change Impact on end user communities Name of the Change Requester Name of the Change Assignee Scheduled Date and Time for executing the Change Approval Status of the RFC Name of Change Approver Distribute the Change Summary Sheet to all members of the CAB prior to the scheduled meeting. During the CAB meeting, the members of the CAB will review and discuss each RFC as a group to ensure that it meets all requirements of the Change Management Process. The CAB may call upon the Change Assignee to answer any questions that may arise about their RFC during the meeting. All Change Assignees who have a RFC pending must attend the CAB meeting or send a representative from their department who can properly represent and discuss the Change. Failure to do so may result in the automatic Rejection of the RFC. Rejected RFC s can be updated and re submitted to the CAB for review at a later date. UNCG Proprietary & Confidential 13
3.3 COMMUNICATING PLANNED CHANGES All planned Changes that will impact, or have the potential to impact, a production service must be communicated to the users of that service prior to execution. All communication details must be coordinated by the Change Assignee and approved by the CAB PRIOR to being sent. All mass communication must be sent via the ITS Communications Office. The Change Assignee is responsible for notifying the Service Desk and Service Operations Center immediately before and immediately after the execution of an approved Change. If physical access to the machine room is required for an approved Change, the Change Assignee must be able to produce a printed copy of the approved RFC to Service Operations Center personnel before accessing the machine room to execute the Change. 3.4 INFORMATION SECURITY A staff member of ITS charged with Information Security will be a required member of the CAB and must attend all CAB meetings. ALL RFC S must be reviewed for information security implications prior to CAB approval. Considerations in this review include, but are not limited to,: Implications to the security of personal information (Social Security Number, Date of Birth, etc.) Implications to the security of university sensitive or confidential data. Implications to the security of university equipment. Compliance implications (HIPAA, FERPA, etc.) UNCG Proprietary & Confidential 14