IT Change Management Policy

Policy Subject

ITS011 - IT Infrastructure and Systems Change Management Policy

 

Purpose

 

 

Information Technology (IT) infrastructure is critical to the effective operation of the University. The Office of IT Services strives to continually maintain and improve this vital resource. However, as our infrastructure (and the University) has grown, it has become more complex.  As our interdependencies on and between systems, continues to grow, it is essential that we carefully manage changes to the infrastructure. Even the most well-intentioned change can cause unexpected hardship to technology users if the implications of the change are not planned in advance.

The purpose of the Change Management Policy is to manage changes in a rational and predictable manner so that staff 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 our IT infrastructure.  The purpose of this policy is not to frustrate change or to question the rationale of changes. Rather, it is to make sure that changes have their intended impact while avoiding unintended consequences.

 

Scope

 

This policy covers all changes (additions, deletions and modifications) to an information technology resource regardless of who initiates it.  It encompasses changes to the live environment which includes:

  • the University's shared IT infrastructure, including but not limited to hardware, software, operating system, data and voice network and applications; and

  • environmental facilities supporting the University's 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 live versions of data entry programs; and

  • disaster recovery facilities.

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

A change includes a modification to an existing service, maintenance to an existing service or a project to install a new or upgraded service.

 

Policy / Principles

 

General

1. Any change to an information technology resource must be performed in compliance with the University's IT Infrastructure and Systems Change Management Policy and Procedures.

2. Changes require two steps of approval : prior to commencing the development or testing of a change (a Change Request) and prior to releasing the fully tested change into the live environment (a Release Request).
 

Return To Top
 

 

Exemptions

3. There are no exemptions to the IT Infrastructure and Systems Change Management Policy.

4. An "emergency change", which is defined as a repair to a current breakage and / or a change required to prevent an imminent breakage in the live environment, will, by necessity, proceed through the abbreviated and more immediate form of Change Request process as documented below.

5. All other changes must proceed through the Change Request Approval Process before being implemented.

6. Certain changes occur regularly, for example, adding a PC to the network.  Once a change has been approved once, it may be advertised as a "pre-approved change".  This means that all subsequent iterations of the change during the specified period are likewise approved, possibly with conditions.  A list of pre-approved changes is maintained by IT Services.

Return To Top
 

 

 

Change Request Approval Process

7. A Change Advisory Board (CAB) of relevant IT Services staff, appointed by the Director IT Services, will meet regularly to process Change Requests in accordance with change management procedures.  A representative from the work area proposing the change is invited to attend the CAB.

8. The CAB will be chaired by a Change Manager who is appointed by the Director IT Services.

9. Change Requests must be submitted in accordance with change management procedures so that the CAB has time to review the request, determine and review potential failures, and make the decision to allow or delay the request.

10. Change Requests must be endorsed by the System Owner prior to being submitted to the CAB.  Relevant administrative and academic staff must be consulted about the impact of the change prior to it being submitted to the CAB.

11. Change Requests must receive CAB approval before proceeding.

12. The CAB has the authority to deny a Change Request (or send it back to the requestor for further detail and study) for reasons including, but not limited to, inadequate planning, the timing of the change will negatively impact a key business process or if adequate resources cannot be readily available.

Return To Top
 

 

Pre-Approved Changes

13. The CAB is responsible for identifying repeated or potentially repeated  Change Requests (for example, adding a new PC to the network, manipulating data in a non-critical database, performing preventative maintenance on a piece of hardware) and considering if pre-approval status should be granted.

14. The CAB will maintain a list of pre-approved changes and any conditions that accompany the pre-approval.

15. Pre-approved changes do not require a Change Request or a Release Request.

Return To Top
 

 

Emergency Change Requests

16. Emergency Change Requests must be submitted to the Change Manager in accordance with the change management procedures.

17. The Change Manager has authority to approve emergency "Change Requests" after consultation with the System Owner and relevant IT groups.

18. The Change Manager has authority to approve the emergency Change Request in conjunction with the Director IT Services and/or Deputy Director IT Services where the System Owner and / or relevant IT groups are not available.

19. The Change Manager must report all emergency Change Requests to the System Owner and the CAB in accordance with the change management procedure.

Return To Top
 


 

 

Release Requests

20. A "release" is part of a Change Request, all of a Change Request or multiple Change Requests that are tested and introduced into the live environment together.  A Release Request must be raised for all changes, including emergency changes once the change(s) has been fully tested.

21. Release Requests must be submitted in accordance with change management procedures so that the ITS Operations Manager has time to review the request, determine and review potential failures, and make the decision to allow or delay the request.

22. The Operations Manager has the authority to refer the Release Request back to the CAB if it is not consistent with the approved Change Request(s).

23. The Operations Manager has the authority to deny a Release Request (or send it back to the requestor for further work) for reasons including, but not limited to, inadequate backout plans, the timing of the change will negatively impact a key business process, inadequate communication and / or training for the user base and IT support staff or if adequate resources cannot be readily available.

24. Release Requests must receive approval from the IT Operations Manager prior to the change being released to the live environment.

25. The Operations Manager will communicate the details of the release to business users and IT staff and arrange for the Release Request to be actioned once the Release Request has been approved.

Return To Top
 

 

Process of Appeal

26. The process of appeal for Change Requests denied by the CAB is via the Deputy Vice Chancellor and Chief Operating Officer. 

27. The process of appeal for Release Requests denied by the Operations Manager is via the Deputy Director ITS and / or the Director ITS.

28. The process of appeal for Release Requests denied by the Director ITS is via the Deputy Vice Chancellor and Chief Operating Officer.

29. Appeals must follow the change management procedure.

Return To Top
 

 

Unauthorised Changes

30. Changes that do not comply with the Change Management Policy and Procedures are classified as 'unauthorised changes'.

31. IT Services resources will not be made available or committed for an unauthorised change. 

32. IT Services has the authority to reverse any unauthorised changes that cause, are suspected as causing, or have the potential to cause disruption to other users of the services.

Return To Top
 

References
and Further
Information

Policy issues should be directed to the Director, IT Services

 


Approval


This policy was approved by the Deputy Vice Chancellor and Chief Operating Officer on 24 November 2008.