”TigerChange Mgt Policy

Policy Title

CCIT Change Management Policy

Executive Summary

The Clemson Computing & Information Technology (CCIT) infrastructure at Clemson University is expanding and continuously becoming more complex. There are more people dependent upon the network, more client machines, upgraded and expanded administrative systems, and more application programs. As the interdependency within the IT infrastructures grows, the need for a strong change management process is essential.

From time to time IT elements require an outage for planned upgrades, maintenance or fine-tuning. Additionally, unplanned outages may occur that could result in upgrades or maintenance. Managing these changes is a critical part of providing a robust and valuable IT infrastructure.

Change Management is a process, which by its lack of maturity can have the most dramatic impact on the business. Unapproved, unplanned, and uncoordinated changes can impact the business customer on a frequent basis. Additionally, without the ability to control when, how and by whom things are changed in the production environment, other processes such as Release and Configuration Management cannot be effectively implemented. A controlled Change Management process is a dependency for several other IT business practices.

Purpose

The purpose of the Change Management Policy is to manage changes in a rational and predictable manner so that staff and customers can plan accordingly. Changes require serious forethought, careful monitoring, and follow-up evaluation to reduce negative impact to the user community and to increase the value of IT resources and their resultant services.

Policy

Policy Coverage:

The Clemson Computing & Information Technology Change Management Policy applies to all individuals that install, operate or maintain IT resources and services.

Policies outline a set of plans or courses of action that are intended to influence and determine decisions or actions of a process. Policies provide an element of governance over the process that provides alignment to business vision, mission and goals.

 

Change Management:

  1. Process Scope – the scope of the Change Management process will only govern the risk and scheduling of production environment infrastructure component(s) changes associated with any of the CCIT service offerings found in the service catalog.
  2. Ticket/Logging and Completeness – any proposed CCIT infrastructure change will require a completed Request for Change (RFC) ticket and may require additional artifact(s) (Implementation Plan, Back out Plan, Validation Plan) dependent on a combination of risk and proposed implementation lead time of the change. The Change Manager has the authority to reject any request for change and/or change the risk score of any RFC ticket.
  3. Manager Approvals – the Change Manager assumes that all submitted RFC’s and associated artifacts have been reviewed and/or approved by the appropriate CCIT technical managers.
  4. Forward Schedule of Change – all approved changes will be entered on the Forward Schedule of Change calendar by the Change Manager.
  5. Change Freeze Periods – change restriction periods may be imposed (e.g. “academic and/or business”). If a change to the affected infrastructure corresponds to service(s) of the business that is requesting the freeze the Change Manager will halt the change and escalate the request to business and CCIT leadership for approvals. The Change Manager will provide a yearly change freeze calendar each December for the following year.
  6. Post Implementation Review (PIR) – each Request for Change (RFC) and associated task(s) must be reviewed for success and any identified post-implementation actions will be documented. All critical and high priority changes, all changes that were less than successful, changes that caused a high impact incident, or at the discretion of the Change Manager will be performed within five business days of the change.  A mandatory meeting will include at least the Requestor and/or Implementor, Change Manager, and leadership of the department.
  7. Unauthorized Changes – any unauthorized production configuration item change that was made without CAB authorization; this includes any deviation to any plans approved by the CAB. This type of change is not allowed under any circumstance. Only the Change Manager can classify an RFC as an unauthorized change type.  The Change Manager will escalate all unauthorized changes to the CIO and executive staff and request that a post implementation (PIR) review be added to the next available executive staff agenda.
  8. Related Incidents/Problems – changes that are fixes to incidents and/or problems must have the related Incident and/or Problem record(s) identified to the request for change ticket. The Change Manager, Incident Manager, and Problem Manager will meet regularly to review this.
  9. Emergency Changes – an emergency change is a change made to the infrastructure only during a major incident. The Major Incident Coordinator will approve and then ensure a post-mortem RFC will be created. The Change Manager will follow up with the Major Incident Coordinator to ensure this is being followed.
  10. Proposed Change Implementation Lead Date and Time – all requested change implementation dates must adhere to the Customer Risk/Lead Time guidelines.

Lead Date and Time:

Type of Change Lead Time from Submission to Approval Approval Process Required Documentation
Standard ChangeSame Day At leastNANA
Normal – Low Risk1 business day· Change Assessor for the department

· Change Manager

Documentation not required. Suggested to have the following in your knowledge base

· Implementation Plan

· Back Out Plan

· Validation Plan

Normal – Medium Risk1 week (calendar days)· Change Assessor for the department

· CAB

· Change Manager

Documentation not required. Suggested to have the following in your knowledge base

· Implementation Plan

· Back Out Plan

· Validation Plan

Normal – High Risk2 weeks (calendar days)· Change Assessor for the department

· CAB

· Change Manager

· Implementation Plan

· Back Out Plan

· Validation Plan

Normal – Critical Risk1 Month· Change Assessor for the department

· CAB

· Change Manager

· Implementation Plan

· Back Out Plan

· Validation Plan

Emergency ChangeNA· Major Incident Leader

· Deputy CIO for the department (or designee)

· Security Deputy CIO (or designee)

NA

  1. Risk Scorecard– each Request for Change (RFC) will be categorized and given a risk score based on the severity of impact plus the probability of the change implementation failure. The Change Manager has the authority to modify the risk score of any submitted request. Possible Risk scores are: Critical, High, Medium, and Low.
  2. RFC Implementation Completion & Validation – the Change Manager requires that the implementation team and the validation team provide the following information in the ticket.
    • Actual Start date/time
    • Actual End date/time
    • Additional implementation notes
    • Validation notes
    • Change the status to review
    • Communicate the results of the implementation to the stakeholders
  3. Trend Analysis & Metrics – request for Change (RFC) and associated tasks will be analyzed by the Change Manager on a regular basis to detect trends. The results of this analysis will be documented and distributed to stakeholders. The Change Manager will create and distribute metrics to the IT Service Management Director and CCIT Executive Staff in a timely manner.


Number of RFCs resulting in an Incident

      • Description – this may be the most significant indicator of the effectiveness of the process as making changes without impacting the business is what Change Management strives to do. Ideally this number would be zero.
      • Measurement Procedure – a count of all Incidents created during the period that were related back to specific authorized Request for Change (RFC) or tasks identified within the RFC. This metric will be used to show monthly trends to the organization.


Percent Expedited RFCs

      • Description – expedited changes pose a potential risk to the business, as they are introduced in an accelerated time frame. This number should be a small percentage of the overall changes.
      • Measurement Procedure – a count of all expedited requests for change (RFC) divided by the total number of changes for the period.


Number of RFCs not successful

      • Description – unsuccessful changes were those that did not produce the expected result or were not able to be implemented. Both are indicators of poor testing, inaccurate requirements or incorrect implementation instructions to mention a few reasons.
      • Measurement Procedure – a count of all requests for change (RFC) unsuccessfully implemented during the period. This metric will be used to show monthly trends to the organization.


Number of RFCs successfully implemented

      • Description – speaks to both the volume of changes being made and the success factor. This metric should be trended over time with an increasing percent of successful being the desirable trend.
      • Measurement Procedure – a count of all Requests for Change (RFC) successfully implemented during the period.


Number of authorized RFCs by Type

      • Description – an indication of the volume of requests and tasks passing through the Change Management system. May be used to justify headcount or reallocate resources.
      • Measurement Procedure – a count of all Requests for Change (RFC) authorized during the period.


Number of RFCs rejected

      • Description – may be indicative of poorly conceived Request for Change (RFC), poor planning or lack of communications (e.g., people were not aware that a system they were proposing changes to was soon to be replaced).
      • Measurement Procedure – a count of all Requests for Change (RFC) rejected during the period.

Total Number of Request for Change (RFC)

      • Description – Presented by period, by type, and priority and depicted over time will indicate a trend that can be observed and acted upon. Types of changes to be tracked include: Normal, Standard, Emergency, Expedited, and Unauthorized.
      • Measurement Procedure – Simply a count of all RFC’s, by type, priority, created during a period of time.
  1. Process Documentation
      • The key roles for the Change Management process will be clearly defined and communicated to the IT organization. The Change Manager and IT Service Management Director will ensure this information is stored and distributed to the stakeholders.
      • Change Management Policies and associated procedures will be published and made available to the stakeholders by the Change Manager and IT Service Management Director.
      • Policy Reviews – Change Management Policies will be reviewed and updated and presented to the stakeholders on an annual basis or as needed by the Change Manager and IT Service Management Director.
  1. Standard Change (Pre-Approvals)
        • Any normal change that has been CAB approved and successfully implemented one time can be considered as a candidate for a Standard Change. All Standard Change requests (pre-approvals) must be submitted to the Change Manager and be approved by the CAB initially.
        • The Change Manager will review all approved standard changes periodically. Any standard change can be revoked and reviewed by the Change Manager and the CAB.
        • The Change Manager will work with the relative IT teams and the CAB to approve certain maintenance items at their discretion with the support of IT leadership.
        • The Change Manager is authorized to remove any change from a standard type.
  2. Maintenance Windows – all changes must adhere to the published Maintenance Windows. Any change outside of this window must receive additional executive approvals at the Change Manager’s discretion.
  1. Revisions to an Approved RFC
    • Any revision or modification to an approved RFC/artifact (additional CI’s, changes to the implementation plan, back out plan, validation plan, or implementation window) will be submitted to the Change Manager with appropriate lead time. This will require additional approvals by the Change Manager, CAB/eCAB, and/or IT or business leadership prior to the new implementation.
    • If an RFC will be cancelled or postponed the Change Manager must be consulted as soon as possible to update the forward schedule of change and communications sent to the stakeholders in a timely manner.
    • If an RFC will be cancelled or postponed the Change Manager must be consulted as soon as possible to update the forward schedule of change and communications sent to the stakeholders in a timely manner.

Disciplinary Actions

The Change Manager will escalate all unauthorized changes to the CIO and executive staff and request that a post implementation (PIR) review be added to the next available executive staff agenda.

Definitions

Change Management: The practices of ensuring all changes to Configuration Items are carried out in a planned and authorized manner. This includes ensuring that there is a business reason behind each change, identifying the specific Configuration Items and IT Services affected by the change, planning the change, testing the change, and having a backout plan should the change result in an unexpected state of the Configuration Item.

Change Advisory Board (CAB): A CAB is an integral part of a defined change management process designed to balance the need for change with the need to minimize inherent risks. A CAB is comprised of representatives of the key functional areas of CCIT, customer representatives, security office, service desk and Service Management staff. The CAB is responsible for oversight of all changes in the production environment. Plus the changes may involve hardware, software, configuration settings, patches, etc.

Change Advisory Board/Emergency Committee: The CAB/EC is a subset of the full CAB responsible for assessing and approving urgent changes as a result of a system or service Incident.

Change Management Governance: Process governance defines the authority and oversight that is required to assure that the process is fulfilling its goals and objectives. Governance consists of the set of guidelines and resources that an organization uses to facilitate collaboration, communication and conformance. Process governance covers process ownership and management, process communication, process tool development and feedback (reporting) mechanisms. Governance ensures that everyone is complying with the policies and procedures of the process.

Governance Points

Statement: Governance ensures that everyone is complying with the policies and procedures of the process.
Rationale: The Process Owner needs to ensure that governance is defined to ultimately ensure compliance.  A regular review should be performed to identify and implement new areas of governance (i.e. governance points).
Role: Change Process Owner

Accuracy and Completeness

Statement: Request for Change (RFC) records must be spot-checked for accuracy, completeness and compliance to policies and procedures.
Rationale: The usefulness of the Request for Change (RFC) information as well as reporting is only as good as the data entered.  Inaccurate timestamps or steps taken to implement a change will only contribute to frustration and misleading metrics.
Role: Change Manager

Adherence

Statement: Change Management record/process review sessions held to ensure that all change are being captured, that data has been entered accurately, and that the record was routed correctly.  Adherence to the process is reviewed and action items identified.
Rationale: If employees are not adhering to the activities and policies of the process, changes are not likely to be implemented in a consistent manner, nor in a cost-effective manner.  Given the potential severity of incidents that may result from poorly implemented changes, it is essential that everyone be adhering to the process.
Role: Change Process Owner

Process Assessment

Statement: Conduct periodic assessment of the process to determine if the expected benefits are being realized and that the process is working.
Rationale: Processes are living entities and as such must be assessed periodically for their effectiveness.  This can also be an opportunity to demonstrate the value that the process had brought to the organization.
Role: Change Process Owner

Orientation

Statement: Provide people new to the process with the necessary starter set of information to be productive as quickly as possible.
Rationale: Throwing someone into a process without appropriate training and level setting is asking for trouble.  This activity will ensure that new staff are brought up to speed on what’s expected of them as well as how they are to perform their duties in the process.
Role: Change Manager

Mentoring

Statement: Identify and provide coaching or mentoring to individuals or groups that are having difficulty executing policies or have failed to consistently follow documented procedures.
Rationale: Ensuring that individuals are equipped with the information and tools that they need to perform their role within the process will increase their productivity and their contribution to the success of the process.
Role: Change Manager

 

Reviewed
October 3, 2023

Related Policies
Confluence Website

Questions
Email: Change_Manager-L@clemson.edu