Change Management Standard and Procedures. Information Technology

Transcription

1 Change Management Standard and Procedures Information Technology

2 Contents Introduction... 3 Purpose... 3 Scope... 3 Procedures... 3 Communication... 3 Change Management... 4 Types of Changes... 5 Process... 6 Definitions... 8 Review... 9 Revision History Approvals Page 2 of 11

3 UTRGV IT Change Management Standard and Procedures Introduction The Information Resources infrastructure at The University of Texas Rio Grande Valley (UTRGV) is dynamic in nature and is constantly changing to meet the mission of the University. Maintaining and preserving the highest possible levels of availability of Information Resources is a fundamental goal at UTRGV. The UTRGV IT Change Management Standard and Procedures document serves as a supplement to the UTRGV Information Security Manual and UT System Policy 165 (UTS165). Purpose The purpose of this document is to set forth the change management processes and to ensure secure, reliable, and stable operations. The Change Management Standard and Procedures document provides a frame of reference whereby all changes to Information Resources (e.g., hardware, software, infrastructure, data, and communications facilities) occur in a rational and predictable manner and within a controlled environment so that planning can occur accordingly, and so that contingency plans exist in the event changes do not go as expected. In addition, the standard serves as a vehicle for identifying, communicating, planning, testing, approving, implementing, and documenting changes to UTRGV s Information Resources. Scope This document applies to any action or change that affects any production or associated environment systems that house UTRGV s Information Resources, including but not limited to all UTRGV workforce members (e.g., faculty, staff, student workers, interns, contractors, vendors, consultants, volunteers, etc.) who own, operate, or maintain information resources. Procedures Every change to UTRGV Information Resources including computer hardware, computer software, operating systems, applications, database, data, network, security, and telecommunications systems is subject to the Change Management standard and must follow all applicable Change Management Procedures. A Request for Change (RFC)should be made for all scheduled and unscheduled changes using the Change Request Form in ServiceNow. All changes affecting computing environmental facilities (e.g., air conditioning, water, heat, plumbing, electricity, and alarms) should be coordinated with and reported to the appropriate college, school, unit or department managing the systems in that facility. Communication Communication before, during, and after the change is a key component of the change management process. Adequate information and advance notice for change request should be provided, especially if a response is needed. It also should be clear to whom people should respond, if a response is expected. Page 3 of 11

4 Change Management Change Advisory Board The Change Advisory Board (CAB) is charged with reviewing and approving changes for implementation in the Production environment. CAB membership is appointed as specified in the Change Management Charter. Emergency Change Advisory Board The Emergency Change Advisory Board (ECAB) provides advice in the event of a declared emergency change. This role is a subset of the full advisory board and may be called upon at any hour of the day to approve the emergency request for a change. Change Manager The Change Manager is the process/system owner responsible for the day to day execution of a process/system. The Change Manager will review and approve changes that have been pre approved by Change Advisory Board. The Change Manager will escalate all other changes to the CAB for review and approval. Responsibilities of the Change Manager include the following: Authorizing proposed changes that have been pre approved by the CAB Submitting proposed changes to the CAB that have not been previously pre approved by the CAB Verifying that the documentation has been adequately prepared Verifying that the appropriate test plan has been successfully completed and documented Verifying that sign off documents have been completed Verifying and authorizing the back out plan Verifying the test results of the back out plan Communicating the outcome of the change request to the Initiator and stakeholders Change Management Coordinator The Change Coordinator owns the Information Technology Service Management (ITSM) Change Management Process and oversees the IT Change Management Calendar within the ITSM tool. He or she develops and communicates the Change Management process, supports procedures, and advises departments on all needed processes. Additionally, the Coordinator ensures that changes to services and applications follow change management process to reduce issues in production environment. The Change Management Coordinator also collaborates with IT Management Team to ensure compliance with the Change Management Process in all aspects of change preparation, communication and implementation. He or she receives, reviews, records, categorizes and distributes Change Requests and follows up as necessary to ensure that key stakeholders and customers receive the appropriate types of communication, and that proper planning and testing has taken place prior to a change occurring in production. Acts as the designated Chair for the Change Advisory Board and Emergency Change Advisory Board. The Change Management Coordinator conducts reviews and audits for completed change requests to ensure that objectives have been met and investigates any unsuccessful changes. He or she collaborates Page 4 of 11

5 with all IT departments so they can create routine change requests to minimize the number of changes that go before the Change Management Committee. The Coordinator also generates regular reports regarding change requests including number approved, number completed, and number rejected, based on types and categories. Finally, the Coordinator ensures departments are in compliance with the change management process and if necessary, communicates with respective department head regarding non compliance. Types of Changes Emergency Change An emergency change may occur when a critical service is down or severely impaired with disruption to business and/or student activities. Additionally, an emergency change may be required due to a security vulnerability. Regardless of the urgency of the situation, the ECAB must give approval when an emergency change is required. Emergency changes that have been implemented must also be classified, documented, and presented to the CAB during the next meeting. Break/Fix changes required within or outside normal business hours will be handled by the service owner following the IT Alerts procedure. An Emergency Change will be documented within the next business day by submitting an Emergency Change Request Form in ServiceNow. IT Alerts Procedure Link: spx?sourcedoc=%7b1f13a728 4e21 465a bb98 4caac23955ba%7D&action=default Routine Change (ITIL: Standard Change) A routine change is a change to a service or infrastructure for which the approach is pre authorized by Change Management. An example of this change includes upgrades and maintenance on current systems. Routine Changes are often low impact and have low risks. This change must be submitted and documented using ServiceNow, and may or may not require scheduling. Communication must be sent out to the affected users. Comprehensive Change (ITIL: Normal Change) A comprehensive change is a change to a service, process, and infrastructure raised as a Change Request using the Change Request Form in ServiceNow. The workflow requires approval from the Change Manager and must be reviewed by the CAB. Comprehensive changes originate from: Incidents (Issues Reported) Service Requests Projects (Upgrades of software, implementation of new services or applications, decommissioning of services or applications) Page 5 of 11

6 Process Plan the Change When planning the change, the Initiator and Change Manager are responsible for the following: Determining if the change is an emergency, routine, or a comprehensive change Identifying the need for changes to production processes or systems Following the appropriate Change Management Process (Emergency, Routine, Comprehensive) Determining the timeframe for the change Working with the appropriate people to schedule the planned change Identifying the individuals involved in testing the change Maintaining communications with stakeholders as the change progresses from inception to implementation Assuring that approvals occur within the needed timeframe; alternatively, obtaining alternate approvals Verifying and documenting the outcome of the changes and rating their success Test the Change Every change must have a verification plan which will assure the change is made successfully. The verification plan may include pre testing in a test environment, or alternatively breaking the change into sufficiently small increments that can be tested in off hours using production environments for systems that do not have a test environment. The results will be documented and verified as part of the change management process. The individual testing the change is responsible for the following: Developing an appropriate test plan Developing an appropriate verification plan Identifying any inadvertent consequences that might result in stability or security issues Verifying successful test results: resolving and re testing any issues Documenting test results Communicating test results to the data owner Developing, testing and documenting a back out plan Verifying back ups beforehand when production environments are used Approve the Change The change request, test results and sign off document must be presented to the appropriate approver for review of the change to be implemented. Any exceptions to the above must be justified due to its urgency or non negotiable due date, and reason for the exception. Page 6 of 11

7 Each member of the Change Advisory Board (CAB) is responsible for reviewing comprehensive changes within ServiceNow. The individual must review the change to determine whether their area is affected and to ask any necessary questions of the initiator. A meeting with the Initiator and Change Advisory Board may be necessary to review the requested change. If a meeting is required, the Initiator must be present to answer any questions or address any concerns the Change Advisory Board may have. The Change Advisory Board (CAB) should assess the risks and benefits of either making the change or not making the change. The CAB reserves the right to alter the change plan, make recommendations and/or send it back for revisions if the change proposal is unacceptable or requires additional work. Implement the Change The Change Advisory Board authorizes the change to be implemented. Only changes that have been approved may be implemented in a production environment. The implementation team is responsible for the following: Obtaining authorization from the appropriate Change Manager to migrate the change Ensuring adequate staff is available to migrate the change Communicating the migrated change to the appropriate Change Manager Migrating successfully tested changes to the production environment Validate the Change After implementation of a change, validation of the change must occur in order to verify if the change was successful. If validation fails, the change must be reverted using its back out plan. Document the Change All change requests must be formally documented, classified, and prioritized in ServiceNow to ensure they are planned for accordingly. The Initiator, Data Owner, Custodian, Change Manager and those involved in the Change Management Process are responsible for reviewing the documented changes for correctness, completeness, and adherence to standards and procedures. The Change Request Form in ServiceNow contains detailed information about the change and is required for changes submitted to the Change Advisory Board. All change requests must be maintained in ServiceNow for awareness that a change is being or has been implemented. Page 7 of 11

8 All change requests must include at least the following: Date of submission and date of change Nature of the change Indication of success or failure o Change Successful o o o o Change Successful but had a few issues Change Successful but exceeded the planned end time Change Backed out Change Cancelled it was never started Status of change Change control documentation such as diagrams, schematics, processes must be updated to reflect the current state after the change (i.e., all documentation must be updated before the change request can be closed). An index must be maintained of revision levels to identify current official revision. Definitions Change: Any addition, modification or update of an Information Resource that can potentially impact the operation, stability, or reliability of a University network or computing environment. Change Management Coordinator: Owner of the Information Technology Service Management (ITSM) Change Management Process and overseer of the IT Change Management Calendar within the ITSM tool. Acts as the designated Chair for the Change Advisory Board (CAB) and Emergency Change Advisory Board (ECAB). Ensures implementation and completion of the Change Management Process. Runs reports including the number of approved, number completed, and number of rejected change requests. Change Management: The process of controlling the communication, approval, implementation, and documentation of modifications to hardware, software, and firmware to ensure that information resources are protected against improper modification before, during, and after system implementation. Change refers to: Any implementation of new functionality Any interruption of service Any repair of existing functionality Any removal of existing functionality Change Advisory Board (CAB): Group of people appointed to review, approve/reject a change request. Change Manager: Individual accountable for any and all changes within his or her area of responsibility. Usually the process or system owner. Page 8 of 11

9 Custodian: Guardian or caretaker; the holder of data; the agent charged with implementing the controls specified by the owner. The custodian is responsible for the processing and storage of information. The custodians of information resources must: Implement the controls specified by the approved change request Provide physical and procedural safeguards for the information resources Assist owners in evaluating the cost effectiveness of controls and monitoring Implement the monitoring techniques and procedures for detecting, reporting, and investigating incidents. Custodians include Information Security Administrators, University information technology/systems departments, vendors, and any third party acting as an agent of or otherwise on behalf of the University. Data Owner: The manager or agent responsible for the function that is supported by the resource or the individual upon whom responsibility rests for carrying out the program that uses the resources. The owner is responsible for establishing the controls that provide the security. The owner of a collection of information is the person responsible for the business results of that system or the business use of the information. Where appropriate, ownership may be shared by managers of different departments. Implementation Team: UTRGV employee or employees responsible for implementing the change. In most comprehensive changes, there are several people that are responsible for making the change i.e. server administrator, application administrator, database administrator, etc. Information Resources (IR): Any and all hardware, software, infrastructure, data, and communications facilities. Initiator: Individual who initiates a change request and is responsible for the specific change from the moment it is requested until its implementation. The Initiator is responsible for in depth understanding of the nature of the change and must be present at any meeting held to approve or reject the change. Review The Chief Information Officer shall review this standard annually. Page 9 of 11

10 Revision History Date Version Description Author 1.0 Replaced The University of Texas Pan American with The University of Texas Rio Grande Valley (UTPA to UTRGV) throughout the document including cover page. On Page 3, removed the words Resources and Operations from Introduction section. On Page 3, remove the word Information Technology from Procedures section. On Page 8, changed wording from Vice President for Information Technology to Chief Information Officer. 17 JUL On Page 4, Emergency Change section, changed wording from Vice President for Information Technology to Chief Information Officer. Deleted extra spaces on Page 4 under Responsibilities of the Change Manger & Page 5 under Test Change section. Removed extra comma on Page 6 under Approving Change section. 18 JUL Restructure contents of document. Added the Types of Change category on Page 6, added the Process category on Page AUG Continue changing document structure. Added definition of a Routine Change on Page 6. Added Change Management Coordinator on Page 5 and in the definitions on Page AUG Added definition of a Comprehensive Change on Page 6. Updated the Revision History and Table of Contents. Esther Dominguez Lizeth A. Solis Lizeth A. Solis Lizeth A. Solis Lizeth A. Solis 26 OCT Made changes based on Dr. Graham s feedback Lizeth A. Solis 21 DEC Proofreading and minor edits Anne Toal 05 JAN Finalized Draft Anne Toal & Lizeth Solis 12 JAN Approved and signed by Dr. Graham. Updated signature page Lizeth Solis Page 10 of 11

11