Change Management Standard

I. Statement

Technology organizations require a process to manage proposed changes to production systems in order to assure the highest performance and availability of the systems we provide for the state.

II. Purpose and Principles

A. The purpose of this standard is to provide a set of rules and guidelines so that workers will clearly understand the required change management process.

B. In conjunction with this standard is a document titled “OIT Enterprise Services Change Management Process” which will help workers identify the reason for a change, the risks posed, elements to consider when planning, how to document, how best to ensure success and prevent damage, how to communicate and to whom, and how to learn in order to improve future change process.

C. Beyond the scope of this document but as an allied best practice, system administrators, programmers and others involved with change must develop a specific change management process for each system, particularly regarding appropriate testing processes, version control, quality control, change approval, and disaster recovery.

III. Applicability

A. This standard is intended to manage proposed changes to production systems by

1. Core Technology Services (CTS) IT staff that administers, manages, or modifies any computer or network systems used by others.

2. Any non-CTS personnel who can modify an enterprise system.

IV. Responsibilities

A. Change Manager is responsible for the change process communications and monitoring of all assigned changes.

B. Change Advisory Board reviews all changes that will cause any possibility for risk of service impact as well as scheduling conflicts that may arise. The Change Advisory Board serves as “facilitators” for all proposed changes.

V. Guidelines

A. All Request for Changes (RFC) will be submitted via Footprints by the Change Initiator at least two CAB meetings (Thursdays at 10:00) prior to the planned change. Changes submitted with only a single CAB review may result in an implementation delay. At a minimum, the CI will include in the RFC the following actions germane to the requested change. The information will contain nothing that would compromise system security. Any substantial modification of the information requires re-notification.

B. Non-emergency changes must be posted to allow for one (1) CAB reviews prior to execution, unless there are extenuating circumstances or your division manager approves the short notice. Short notice change approvals must be annotated in the RFC.

C. Follow your plan’s checklist step by step. If as you proceed you find you have omitted anything, add it to the RFC in order to document the steps you actually took. If you find yourself deviating significantly from your plan or if you find you underestimated the risk, STOP, RETHINK, DOCUMENT, BACK OUT if necessary.

If the change causes a system malfunction and the back-out process does not work as planned, you are in a disaster management mode. You must communicate the status immediately to your director, stakeholders, and the help desk and the CAB. Your director will work with the system’s owner and may decide to convene an incident management team to assist you. This team will handle communications, document the recovery effort, and assist in any effective way possible.

D. A document titled “OIT Enterprise Services Change Management Process” further defines specific planning steps, implementation guidelines and procedural requirements in approaching the change management process.

VI. Definitions

A. Change – An action that has a distinct possibility of having a noticeable impact on an enterprise or agency production system.

B. Change Manager (CM) (Approving management entity) - Responsible for the change process communications and monitors all assigned changes.

C. Change Initiator (CI) – The individual requesting a change.

D. Change Advisory Board (CAB) - A group of Information Technology professionals that reviews all changes that will cause any possibility for risk of service impact and for scheduling conflicts. Serve as ‘facilitators’ for all proposed changes.

E. Enterprise System – A system managed and operated by CTS for the benefit of one or more outside agencies.

F. Stakeholder – A person or group that has an investment, share, or interest in a computer system, or is a subject matter expert or contributor to that system.

VII. References

A. OIT Enterprise Services Change Management Procedure - Use of Change Management Procedure

B. Change Control Directive

VIII. Document Information

A. Document Reference Number: 13

B. Category: Computer Environment and Platform

C. Adoption Date: 10/24/07

D. Effective Date: 10/24/07

E. Review Date: 10/24/09

F. Point of Contact: Office of Information Technology: Bob Corum, Network Operations Supervisor, telephone: 207-624-8895.

G. Approved By: Richard Thompson, Chief Information Officer

H. Position Title(s) or Agency Responsible for Enforcement: Greg McNeal, Chief Technology Officer, telephone 207-624-9471

I. Legal Citation: 5 M.R.S.A. Chapter 163 § 1973. Responsibilities of the Chief Information Officer, paragraph 1B “Set policies and standards for the implementation and use of information and telecommunications technologies, including privacy and security standards…”

J. Waiver Process: Waiver requests must be submitted in writing to the Chief Information Officer.