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:

1 Information Technology Change Control Policy (2009), Version 2, Philippa Spratt & Ian Ellery, November 2009

2 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.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 The high level process for IT Change Control is shown in Figure 1.

4 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.

Change Control

B

u

s

i

n

e

s

s

U

s

e

r

T

e

s

t

C

h

a

n

g

e

M

g

r

S

y

s

t

e

m

O

w

n

e

r

I

m

p

l

e

m

e

n

t

e

r

P

r

o

d

u

c

t

i

o

n

1. User identifies need

2. Define Business Risks / Benefits

4. Assess stakeholders

& systems affected.Define Cost/Risk of

Implementing

Yes

5. Proceed?

No

8. Schedule

9. Identify

Configuration Items affected

Page 2

3. Valid Change

Request?

No

1. Implementor identifies need

1. Production identifies need

2. Define Business Risks / Benefits

2. Define Business Risks / Benefits

7. Indicate Relative Priority

6. Close request, inform originator

Change Control

P

r

o

d

u

c

t

i

o

n

T

e

s

t

I

m

p

l

e

m

e

n

t

e

r

S

y

s

t

e

m

O

w

n

e

r

B

u

s

i

n

e

s

s

U

s

e

r

C

h

a

n

g

e

M

a

n

a

g

e

r

10. Implement changes

Page 1

Pass

14. Inform Stakeholders

Yes

15. Go Live

11.Technical Testing

Fail

12. User

Testing

13.Production ready?

Fail

Pass

No

16. Sign Off

Figure 1 Process Diagram for IT Change Control

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 Author(s) Date Circulation Comments

1 JFN January 2010 Draft

2 JFN 13/01/2010 Draft, incorporating comments from CIS Team Leaders meeting

3 JFN 22/01/2010 Draft, incorporating comments from Len Ryan and Mike Hewitt

4 JFN 26/01/2010 Draft, incorporating comments from Keith Gwilym ; 3 Appendices added.

5 JFN 27/01/2010 Draft, incorporating comments from Lorri Currie, Ian Ellery, David Hayling, Pete Ryan and Ruth Lewis

6 JFN 1/02/2010 Draft incorporating comments from Lee Soden

Document approval and review

Approved by: Information Systems Committee (ISC)

Date approved: 17th February 2010

Review date: February 2011

Author(s): Jerry Niman

Owning Department (s): CIS and Computing Services

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 Enhancement or Fix

Requested by (Business User) Date

Description

Business Benefits and/or Risks

Assessed by (Change Manager) Date

Stakeholders affected

Systems affected

Cost of implementation

Risks of implementation

Decision by (System Owner or nominee) Date

Approved / Rejected

Priority

Scheduled Implementation Date (Change Manager)

Configuration Items affected identified by (Development) Date

Item Version before change Version after 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