IT Change Control Process

1 Introduction
1.1

The Information Technology Change Control Policy1 was approved by the Information
Systems Committee in November 2009. This policy set out principles to minimise business
disruptions and impacts resulting from changes to the IT production environment.

1.2

The Policy did not define specific processes to be observed, but the need to write these was
identified in an implementation plan2.

1.3

This document defines the principles of the IT Change Control Process in more detail.

1.4

Much of what is described is already practiced within the University, this document
recognises and in some cases formalises existing good practice.

1.5

Appendix A contains more information on the various roles in the IT Change Control Process,
Appendix B contains more information on each stage in the process and Appendix C
illustrates the type of information required in a Change Request Record.

2 Definitions
2.1

An IT Change is any modification to the software, hardware or environment supporting a

business process. Although the change of data within a system is not generally an IT Change,
this distinction can often become blurred, as many systems are designed such that the data
they hold can fundamentally affect the way they work. For example, deleting a faculty record
in a student record system would have far-reaching consequences. Generally speaking, if a
data change is complex enough that it would be carried out by a support department, it
should be considered an IT change. If it is simple enough that it is normally carried out by the
users without any technical support, the change would not be considered to be an IT
Change. Some changes to a service are complex enough to warrant formal project
management. In this case, the project management will have all the necessary controls built
in to satisfy the Change Control Policy and without having to go through the Change Control
Process as well as the Project Management framework3.

2.2

The term Change Control generally covers two distinct but closely related issues:

Information Technology Change Control Policy (2009), Version 2, Philippa Spratt & Ian Ellery, November 2009
Implementing the IT Change Control Policy, Philippa Spratt & Ian Ellery, November 2009
3
The Change Management Process still applies to changes resulting from formally managed projects where
the service in question is not within the scope of the project.
2

2.2.1 Configuration Control records which versions of the components are compatible to make up
a particular version of the whole system. Closely related to this is the notion of Version
Control, which means recording the version of a system in production use at any given point
in time, and the ability to return a system to that version.
2.2.2 Change Management means the processes necessary to ensure that changes have been
approved from both business and technical perspectives before they are implemented.
2.3

Enhancements and Fixes. An Enhancement is an identified change to a system to alter the

required functionality of a system (for example to introduce a new report) or to respond to a
change to its environment (for example the withdrawal of support for a legacy database). A
Fix is a change to a system to rectify an identified failure to function as required. From the
point of view of IT Change Management, there is little fundamental distinction between
these types of change. Similarly, changes can be major (for example implementing a new
release of a corporate system) or minor. Again, the scale of the change does not
fundamentally affect the process4; however changes significant enough to be formally project
managed will thereby satisfy the Change Control Policy.

3 IT Change Control Scope

3.1

The scope of the IT Change Control policy comprises changes to all IT Services production
systems and underlying infrastructure, including changes to:
the Universitys shared IT infrastructure, including but not limited to hardware, software,
corporate applications, operating system, data and voice network and applications; and
environmental facilities supporting the Universitys shared IT infrastructure, including but
not limited to air-conditioning, water, heat, plumbing, electricity, and alarms; and
data and databases, whenever changes are applied without using production versions of
data entry programs; and
disaster recovery facilities.

3.2

It does not apply to changes to test or development systems, providing they are isolated
from the production environments.

3.3

A change includes a modification to an existing service, maintenance to an existing service or

a project to install a new or upgraded service.

3.4

Changes not covered by this policy include those that only affect an individual.

3.5

This Change Control Policy does not cover any changes to Business Processes that may be
required. It is the responsibility of the System Owner to ensure that any such changes are
implemented effectively and in co-ordination with the system changes.

4 IT Change Control Process

4.1
4

The high level process for IT Change Control is shown in Figure 1.

It is recognised that the scale of the change may affect the detail of how the principles of the IT Change
Management Process are implemented in practical terms.

1. User identifies
need

2. Define Business
Risks / Benefits

Change Mgr

Business
User

Change Control

No

Production

Yes

6. Close request,
inform originator

1. Implementor
identifies need

2. Define Business
Risks / Benefits

1. Production
identifies need

2. Define Business
Risks / Benefits

8. Schedule

No

5. Proceed?

Test

Implementer

System
Owner

3. Valid
Change
Request?

4. Assess stakeholders
& systems affected.
Define Cost/Risk of
Implementing

7. Indicate
Relative Priority

9. Identify
Configuration
Items affected

Page 2

Business
User

Change Control

Fail

Change
Manager

12. User
Testing

Production

16. Sign Off

Pass

Pass

Fail

Page 1

Yes

10. Implement
changes

11.
Technical
Testing

Test

Implementer

System
Owner

14. Inform
Stakeholders

13.
Production
ready?
No

Figure 1 Process Diagram for IT Change Control

15. Go Live

5 Implications of the IT Change Management Process

5.1

Origination. Users requesting an enhancement will need to give due consideration as to the
value of the proposed change.

5.2

Evaluation. Before any decision is made, an assessment of the costs and risks is made,
together with a review of the stakeholders and other systems affected. This puts the decision
whether or not to proceed on a firm footing, and should reduced the likelihood of
unintended consequences of a change.

5.3

Decision to proceed and prioritisation. The analysis of the cost / risk / benefit will be carried
out by the individual to whom the ISSDG has delegated authority to make such decisions for
the system involved. This should ensure that resources are only committed to those changes
that will most benefit the organisation.

5.4

Timescales. The additional steps described above will inevitably introduce some delay to the
process compared with the historical approach. However, a well designed change
management records system should minimize any such delays, and the potential disruption
of poorly managed changes and diversion of resources to low priority requests are far more
serious risks to the organisation than the marginal costs of proper change management.

5.5

Business Processes. The System Owner must ensure that any changes to Business Processes
are planned and implemented effectively, and co-ordinated with the change to the technical
elements of the service.

Document control/change history

Version
1
2

Author(s)
JFN
JFN

Date
January 2010
13/01/2010

JFN

22/01/2010

JFN

26/01/2010

JFN

27/01/2010

JFN

1/02/2010

Circulation

Document approval and review

Approved by:
Date approved:
Review date:
Author(s):
Owning Department (s):

Information Systems Committee (ISC)

17th February 2010
February 2011
Jerry Niman
CIS and Computing Services

Comments
Draft
Draft, incorporating comments
from CIS Team Leaders meeting
Draft, incorporating comments
from Len Ryan and Mike Hewitt
Draft, incorporating comments
from Keith Gwilym ; 3 Appendices
added.
Draft, incorporating comments
from Lorri Currie, Ian Ellery, David
Hayling, Pete Ryan and Ruth Lewis
Draft incorporating comments
from Lee Soden

Appendix A - Roles in the IT Change Control Process

Business User. This can be anyone who uses the system concerned.
Change Manager. This is the identified owner of the system within the support department.
System Owner. This is the senior user identified as the person who is responsible for the system on
behalf of the organisation. For very minor changes, the System Owner may choose to delegate
authority for approving and prioritising changes to someone else, possibly an individual within the
support department. For changes involving alterations to Business Processes, the System Owner is
responsible for their effective implementation.
Implementer. This is the individual or group who will make the necessary changes.
Test. This is the individual or group who will check that the changes have been implemented
successfully from a technical perspective. It is strongly recommended that this role is carried out by
someone other than the developer.
Production. This is the individual or group who take operational responsibility for the production
system, and who therefore apply the final quality assurance checks before the change is released to
production.

Appendix B Steps in the IT Change Control Process

1. Identify Need. The Business User, Implementer or Production identifies the need for an
enhancement or fix. The originator is expected to establish that the issue really is a change
request rather than a support issue. This would typically be done in collaboration with the
support department for example to distinguish between finger trouble and a genuine
issue affecting the service as a whole.
2. Define Business Risks / Benefits. The originator identifies the benefits to the organisation of
implementing the change, and/or the risks of not implementing it. In the case of
enhancements, the emphasis is likely to be on the benefits of implementation. In the case
of fixes, the emphasis is likely to be on the risks of not implementing. A change request is
raised.
3. Pre-screen Change. The Change Manager pre-screens the change request before carrying
out a full assessment. If the request is one that falls outside the scope of the Change
Management Process (for example, it is a support call or service request requiring no system
change, it is a routine data change or it is a change complex enough to warrant a formal
project) it can be rejected at this stage.
4. Assess Change. The Change Manager identifies the people and other systems potentially
affected. The Change Manager also estimates the cost and risk of implementing the
proposed change. In doing this, it may be necessary to consult with the implementation
and/or production teams.
5. Decide to Proceed. The system owner (or in well defined circumstances, their nominee)
considers the benefits, risks and estimated cost of the proposed change, and decides
whether or not it should be implemented. Where there are impacts on other systems, it
may be necessary to liaise with the owners of those systems before reaching a decision.
6. Close Change. If it has been decided not to proceed, the Change Manager closes the
change request and informs the originator.
7. Indicate Relative Priority. If it is decided to proceed, the System Owner indicates the relative
priority of this change in the context of the other commitments of the people involved in
implementing and testing it. This may well require consultation with the management of
the support department involved.
8. Schedule. The change manager plans when the change will be developed, tested and
implemented. It is particularly important that sufficient time and notice is allowed for user
testing, and that adequate contingency is built in for the change failing one or more of the
testing stages. This may require consultation with the stakeholders as well as with the
developers.
9. Identify Configuration Items Affected. The developers identify which configuration items
(software, hardware, documentation, test schedule, support processes. training material
etc) that will be affected, and record the current versions of each.
10. Implement Changes. The changes are made and alpha tested (i.e. tested by the team
making the changes).
11. Technical Testing. The changes are beta tested (i.e. tested by an independent team), and
any necessary regression testing performed (i.e. running through a standard set of tests to
ensure that existing functionality is maintained in the new version).

12. User Testing. The user tests the revised system to confirm that the bug has been fixed, or
that the enhancement meets the new functional requirement, and that the system has not
been changed in any other way.
13. Production Testing. The production team check that all previous checks have been carried
out, and that they will be able to provide operational support for the changed system. They
plan the implementation, with appropriate backout options.
14. Inform Stakeholders. The Change Manager informs the identified stakeholders that the
change will be going into production, and when this will happen. Where re-training is
needed, the Change Manager ensures that suitable arrangements are in place.
15. Go Live. The production team implement the changes.
16. Sign Off. The change manager closes the change request.

Appendix C IT Change Request Record

It is necessary to have a record of the process for each IT Change. Ideally, this would be an online
system, with appropriate checks and workflow built in. The following is just a mock up of a
change request record to illustrate the information that such a system would need to gather. The
detail of how the IT Change Management Process is implemented might vary between
departments, but they must comply with the principles defined above. Similarly, it is permissible to
use a template approach to simplify the processing of minor, relatively routine changes, as long as
the principles are adhered to and the controls not unduly weakened.

IT Change Request
System
Change Request Number
Requested by (Business User)

Enhancement or Fix
Date

Description
Business Benefits and/or Risks

Assessed by (Change Manager)

Stakeholders affected

Systems affected

Cost of implementation

Risks of implementation

Date

Decision by (System Owner or nominee)

Date

Approved / Rejected
Priority

Scheduled Implementation Date (Change Manager)

Configuration Items affected identified by (Development)

Date

Item

Version after change

Version before change

Changes made by

Date

Tested by

Date

User tested by

Date

Accepted for production by

Date

Stakeholders informed by

Date

Change made live by

Date

Change request closed by

Date