1.0 Introduction

A major challenge within any organization is the ability to manage change. This process is even more difficult within an IT organization. Hundreds, if not thousands, of servers, software applications, databases, networking equipment and ancillary devices result in an environment difficult, if not nearly impossible to manage.

The challenge to the organization is not so much maintaining the environment, rather in managing the changes involved in that maintenance. Establishing a process to manage all changes within an environment is so difficult not many organizations can effectively do it.

Making changes to the components comprising an IT system most often stem from the need to improve that service. The reasons for improving a service arise from the need to correct a problem, implement an enhancement that will improve service quality, or implement a change that will reduce service costs. The challenge is to implement a system change that achieves the reason for the change without jeopardizing the integrity of that system or service.

Effective change to IT Systems requires a Change Management program that addresses the risks, business continuity issues, impact, resource requirements, benefits, communication requirements, approvals, and implementation plans associated with the change.

The objective of this document is to define the Change Management program and processes for the Department of Clemson Computing and Information Technology (CCIT) at Clemson University. The Change Management processes presented in this document are based on the Information Technology Infrastructure Library (ITIL) methodology for IT Service Management best practices.

The goal of the CCIT Change Management program is to:
Ensure standardized methods and procedures are used for efficient and prompt handling of all changes to IT Systems, in order to minimize disruptions to service delivery, improve service quality, and reduce service delivery costs.

2.0 Purpose

This document is provided to define the environment, and processes regarding the implementation and use of a Change Management Program for the Department of Computing and Information Technology.

3.0 Scope

The procedures identified within this document are applicable to all units within the Department of Computing and Information Technology at Clemson University. All units and areas of the organization will participate in the change management procedures outlined including the documentation of all changes within the CCIT system environments.

4.0 Change Management Concepts

This section describes general concepts and definitions associated with the Change Management process. It contains the definitions of Change, Change Management, Request for Service and Request for Change, as well as descriptions of the Major Phases of Change Management, the difference between project change control and Change Management, release planning, change logs, change metrics, Forward Schedule of Changes and critical outage planning.

4.1 The definition of Change

For the purposes of this document, Change is defined as: The addition, modification, or removal of approved and supported production hardware, firmware, software, applications, facilities, systems, services or associated documentation that support an IT Service or System. An IT System consists of integrated production systems (hardware, applications, documentation, training, customer support, consultation, etc) that deliver value to the IT Customer per the Customer’s expectation.

4.2 The definition of Change Management

Change Management is defined as: The process of controlling IT System changes in a manner that assures minimal disruption in service delivery or degradation in service quality.

The Change Management process, in general, is responsible for controlling alterations to IT components that comprise an IT system and typically encompass the following major areas:

• physical facilities
• hardware
• communications equipment
• applications
• customer support
• procedures
• policy

While the Change Management process provides the mechanism for approving (or denying), proposed Changes, the decision authority for approving changes lies with the Change Manager. In order to make sound decisions, the Change Manager relies on input from the Change Advisory Board (CAB) and any other reliable sources of information.

As its name implies, the Change Advisory Board (CAB) functions in an advisory capacity to the Change Manager and, in turn, to CCIT. The CAB is comprised of at least one representative from each division within CCIT. The Change Manager is a staff role within CCIT, while the members of the CAB are appointed by management of the individual divisions within CCIT.

4.3 The Major Phases of Change Management

Managing Change requires a commitment from management to reduce risk exposure and the severity of disruptions, thereby improving service quality and increasing customer satisfaction. The fundamental activities of Change Management consist of planning, controlling, managing risk, minimizing disruption, communicating, implementing, and measuring change. The Change Management process consists of three primary phases. They are:

• Collect Inputs:
  • Process RFCs (Requests for Change)
  • Process FSCs (Forward Schedule of Changes, i.e. a calendar of planned changes)
  • Manage Activities:
  • Filter RFCs
• Manage Change requests
  • Manage the Change process
  • Chair the CAB (Change Advisory Board)
  • Review RFCs
  • Close RFCs
  • General administration
• Produce Outputs:
  • Report FSC status
  • Report RFCs status
  • Publish CAB minutes and actions

4.4 Change Management vs. Project Change Management

Changes to IT elements that are part of a development project – applications, hardware, documentation, or procedures – are not under the jurisdiction of the IT Change Management process. They are, however, subject to Project Management change procedures. Project Managers are expected to work closely with the IT Change Manager to ensure smooth implementation of project outputs into the production environment. This coordination is handled through the Production Readiness portion of Change Management.

4.5 Requests for Change (RFC) vs. Request for Service (RFS)

It is essential to understand the difference between a Request for Change (RFC) and a Request for Service (RFS). Many organizations misclassify Requests for Service as Requests for Change which results in an over-burdened Change process. In general, Requests for Service are procedural (low risk) and often handled by the Service Desk.

A Request for Service is characterized as:

A Change that can be made under strict, well defined procedural control and is therefore (virtually) risk free.

Providing computer access for a new employee, installing a telephone, replacing a damaged piece of equipment, or resetting a user’s password are examples of a Request for Service (RFS). They all follow a well defined procedural control.

In contrast, a Request for Change can be characterized as:

A proposed Change to any component of the IT infrastructure or any aspect of an IT system where the proposed Change could adversely impact service delivery.

Upgrading a production server, reconfiguring a Local Area Network (LAN), or changing the procedure for changing passwords are all examples of a Request for Change as there is inherent risk to the integrity of production environment components and the systems they support.

 4.6 Request for Change (RFC)

Requests for Changes (RFCs) are triggered for a wide variety of reasons, from a wide variety of sources that include:

• Required resolution of an Incident or Problem report
• User or Customer dissatisfaction expressed via Customer liaison or Service Level Management
• A proposed upgrade to some component of the infrastructure (hardware, software, Service Level Agreement, application)
• Changed business requirements or direction
• New or changed legislation
• Location change
• Product or service changes.

Requests for Change can be concerned with any part of the infrastructure or with any service or activity. Some examples include:

• Hardware
• Software
• Facilities
• Data network
• IT infrastructure management procedures

The following items should be included in an RFC form, whether paper or electronic:

• RFC number (plus cross reference to Problem report number, as applicable)
• Description and identity of item(s) to be changed
• Reason for Change
• Name, location and emailof person proposing the Change
• Date the Change is proposed
• Change Type
• Impact and resource assessment
• CAB recommendations where appropriate (which may be held separately, with impact and resource assessments, where convenient)
• Authorized date and time of change implementation
• Back-out plan
• Actual implementation date and time

4.7 Forward Schedule of Change

Scheduling Changes for implementation should meet business schedules rather than IT schedules. In order to facilitate this, Change Management should coordinate the production and distribution of a Forward Schedule of Changes (FSC). These documents should be available to everyone within the IT organization, as well as its customers.

The Forward Schedule of Changes (FSC) contains details of all the Changes approved for implementation and their proposed implementation dates. Once agreed, the Network Operations Center (NOC) should communicate any planned additional downtime to the User community at large, using the CCIT System Notification System.

By planning a Change using schedules to support implementation plans, it is more possible to predict the impact of the Change. By examining the records of similar prior implementations (lessons learned) the certainty level of current predictions can be improved and help ensure that the Change will proceed smoothly.

5.0 Roles and Responsibilities

This section describes the major roles and responsibilities associated with the Change Management process. It contains the descriptions of the Change Manager, Change Advisory Board, Change Requestor and the Change Owner.

5.1 The CCIT Change Manager

The Change Manager is ultimately responsible for the integrity of the Change Process and is the sole authority for approving Requests for Change. It is an important role for the organization that requires excellent organization, communications, negotiation, analytical decision making, and leadership skills. The Change Manager chairs the Change Advisory Board (CAB). A list of responsibilities for the Change Manager role is outlined below:

• Receive, log and allocate a Request Type in collaboration with the requestor, to all RFCs. Reject any RFCs that are not within guidelines.
• Issue an agenda of RFCs to be reviewed, discussed and approved to CAB members in advance of meetings.
• Present all RFCs at a CAB meeting
• Chair all CAB meetings.
• After consideration of the advice given by the CAB, authorize acceptable Changes.
• Issue FSCs, via the Operations Calendars
• Send appropriate communications to users regarding any planned maintenances affecting services
• Review all outstanding RFCs awaiting consideration or awaiting action.

5.2 The CCIT Change Advisory Board

The CCIT Change Advisory Board (CAB) is a body that exists to assess and provide input to the Change Manager in the assessment and approval of Changes. When a CAB is established, its appointed members should be personnel capable of ensuring that all Changes are adequately assessed from both a business and a technical viewpoint. To achieve this mix, the CAB should include personnel with a clear understanding of the customer business needs and the user community, as well as the technical development and support functions.

• The CAB membership should be comprised of:
• The CCIT Change Manager
• A representative from each CCIT division and/or major administrative group
• May include:
  • applications developers/maintainers (where appropriate)
  • experts/technical consultants (as needed)
  • services staff (as required)

 

Fig 1.0

 

The main duties of the CCIT CAB members are:

• Review all submitted RFCs prior to the weekly meeting. As appropriate, determine and provide details of their likely impact, the implementation resources, and the ongoing costs of all Changes. Follow up with the Change Manager or Requester with any questions or issues prior to the CAB meeting when possible in an effort to resolve anything outstanding.
• Attend all CAB meetings. Consider all Changes on the agenda and provide input on which Changes should be authorized as well as interject any technical questions that may need to be considered prior to approval.
• Participate in the scheduling of all Changes to ensure that there aren’t any conflicts with other established events
• Be available for consultation should an Emergency or Unplanned Change be required
• Provide advice to the Change Manager on aspects of proposed Emergency or Unplanned Changes

CAB meetings represent a potentially large overhead on the time of members. Therefore all RFCs, together with the FSC and the announcement, should be circulated in advance. Relevant papers should be circulated in advance to allow CAB members (and others who are required by Change Management or CAB members) to conduct impact and resource assessments.

In some circumstances it will be desirable to table RFCs at one CAB meeting until a particular issue can be resolved, or because there is a need for a more detailed explanation before CAB members take the papers away for consideration in time for the next meeting.

A typical CAB agenda should include a review of submitted RFCs, as well as any other related topics related to Change Management

When conducting the impact and resource assessment for RFCs referred to them, the CAB should consider the following items:

• The impact the Change will have upon the customer’s business operation in accordance with the Critical Dates Calendar
• The effect upon the infrastructure and Customer Service, as defined in a related Service Level Agreement, and upon the impact on capacity and performance, reliability and resilience, contingency plans, and security of the service
• The impact on other services that run on the same infrastructure (or on software development projects)
• The effect of not implementing the Change
• The IT, business, administrative and other resources required to implement the Change, covering the likely costs, the number and availability of people required, the elapsed time, and any new infrastructure elements required
• The current schedule of Changes
• Additional, ongoing resources required if the Change is implemented.

Based upon these assessments, and the potential benefits of the Change, each of the assessors should indicate whether they support approval of the Change. CAB members should also decide whether they are content with the Request Type assigned by Change Management and be prepared to address any alterations they see as necessary.

CAB members should come to meetings prepared to make decisions on which Changes should be approved to proceed with the proposed change,.

Note that the CAB is an advisory body only. If the CAB cannot agree to a recommendation, the final decision on whether to authorize Changes, and commit to the expense in resources involved, is the responsibility of the Change Manager. Depending on the nature of the Change, references to Service Level Agreements may be required. In some cases, Customer sign-off may be required.

When emergency problems arise, there may not be time to convene the full CAB, and it is therefore necessary to utilize processes such as online voting and email notification to CAB members

5.4 Change Requestor

The Change Requestor (CR) is the staff member submitting the Request for Change (RFC). Any staff member within CCIT may submit a Request for Change. The Change Requester will work with the Change Manager to ensure that the RFC is complete and accurate.

5.5 Change Owner

The Change Owner (CO) is identified in the Request for Change (RFC) form and is responsible for seeing to the planning and implementation of the proposed Change. The Change Owner may be a developer, subject matter expert or the Change Requestor’s supervisor. The Change Owner may also be responsible for communicating the Change to the appropriate parties, such as the customer and keeping the Change Manager informed throughout release cycles.

6.0 The Change Management Process

All members of the CCIT organization are authorized to request changes. Otherwise, innovation might be stifled or important concerns may go unreported. All Changes should be approved by the Change Requestor’s, manager/supervisor.

Fig. 2
Standard RFC Workflow

6.1 The Emergency Change Management Process

Emergency changes should only be issued if there is loss of service or severe usability problems to a larger number of Users, a mission-critical system, or some equally serious problem where immediate action is required. Depending on the urgency of the change to be made, the CCIT Change Manager will determine whether or not there is time to include the CAB members.

It may not be possible to update all Change Management records at the time emergency actions are being completed (e.g. during overnight or weekend working). It is, however, essential that manual records are made during such periods, and it is the responsibility of the Change Manager to ensure that all records are completed retroactively, at the earliest possible opportunity.

Fig.3
Emergency RFC Workflow

6.2 Unplanned RFC Process

Unplanned change requests should be reserved for changes that are a result of urgent security updates, to address system performance issues, and application updates that address functionality issues that should not wait on the normal Change Management Process. Unplanned changes should be kept to a minimum. Any RFC that does not qualify as an Emergency RFC and is not submitted using the established submission timeline may also be classified as Unplanned.

Fig.4
Unplanned RFC Workflow

7.1 Logging

All RFCs received will be logged and allocated an identification number by the Change Management system. The Change Manager will make sure all actions are recorded, as they are carried out, within the Change Management system. If this is not possible for any reason, then they should be manually recorded for inclusion at the next possible opportunity. Details to be included in the RFC are:

• Requestor or Initiator
• Date submitted
• A clear description of the change requested, detailing systems involved
• The reason for the change – is it an enhancement, a new implementation etc? How will the University benefit from this implementation (if that is appropriate)?
• Evidence that thought has been put into a back out plan is also important. If the implementation of this change fails, you will need to back out to ensure normal University operations are not affected.
• The date and time you request to implement the change
• The duration of the maintenance
• Anticipated impact
• Type ( Normal, Emergency, Pre-approved, Unplanned)
• Status
• Comments (Notes if applicable)

7.2 Filtering

As Changes are logged, the Change Manager will consider each request and filter out any that are totally impractical or incomplete. These will be returned to the requestor, together with brief details of the reason for the rejection.

7.3 Change Management Meetings

Unless specified otherwise, Change Management meetings are held weekly on Wednesdays at 1:30pm to review any outstanding change requests. Minimally, the Change Advisory Board (CAB) members should attend this meeting, as well as the Change Requestor (CR) or Change Owner (CO) for each Request for Change.

Chaired by the CCIT Change Manager, the purpose of this meeting is to review all requests, as represented by the CR or CO to the CAB. Additionally, the meeting is open to all CCIT Staff Members for informational purposes. By providing an overview of the change, its impact, duration and purpose all attendees will have the opportunity to raise any concerns or questions regarding the change.

Approval or disapproval of RFCs will lie with the Change Advisory Board, which must take into account any issues raised by attendees in the meeting. For those RFCs where a decision cannot be reached, the Change Manager holds final decision authority.