Change Management Policy

Introduction

The purpose of this policy is to document the way that we manage changes that occur to CiCS-maintained information technology in a way that minimises risk and impact to the university. It will also define a Change as understood by CiCS and to describe the accepted Interim Change Management procedure.

Definition of a change

For the purposes of this document and for CiCS, a change will be defined as anything that transforms, alters, or modifies the operating environment or standard operating procedures of any system or service that has the potential to affect the stability and reliability of the infrastructure or disrupt the business of the University.

Changes may be required for many reasons, including, but not limited to:

  • User requests
  • Vendor recommended/required changes
  • Changes in regulations
  • Hardware and/or software upgrades
  • Hardware or software failures
  • Changes or modifications to the infrastructure
  • Environmental changes (electrical, air conditioning, data centre, etc)
  • Unforeseen events
  • Periodic Maintenance

Policy

It is the responsibility of CiCS to manage the life cycle of all the systems supporting the University´s business and technical objectives. As such, all the processes and procedures relating to change control and management are set out in this document.

There are two categories of changes that are permitted. They can either be Pre-approved or CAB-approved and of these categories, there are four types: Minor/Routine, Major/Significant, Emergency/Unscheduled and New Development

NO CAB-approved change should be implemented without:

  • A request for change (RFC) being raised via the Interim Change Management Form.
  • Approval by the Change Advisory Board
  • An approved, documented plan of the sequence or steps for implementing and releasing the change into the live environment. This should be stored in an appropriate place e.g. wiki, shared drive, etc
  • Evidence demonstrating the fact that this change has been tested in a pre-live/staging environment first.
  • A rollback/mitigation plan in case of failure.
  • A post-change test being documented to check that the change has been successfully applied.

Incidents

Some incidents may or not may not be related to a change, but where a change has caused an incident then it will be possible to trace this back to the person responsible for make that change. The Change Manager will facilitate a review meeting and a report will be generated and fed back to the Change Advisory Board.

Scope

The scope of the Interim Change Management Policy and the procedures contained within it are applicable to all members of CiCS and its authorised colleagues and are related to the management of changes to all CiCS managed live IT systems or services.
Exclusions
This is not a system for customers to request changes or enhancements to any service or system; there are already other mechanisms in place for this such as the SER system.

Risk

By proactively planning and managing changes for the benefit of users, we should be able to deliver a better and more reliable experience to our customers; this should be done in line with the University´s business needs. If not properly controlled, changes could be made which will have a negative impact on the University and could prevent people from fulfilling their roles. Changes could also be made by individuals who are not fully aware of the impact on other areas of the University. All changes should undergo a risk assessment to determine the probability of it occurring and the impact it would have on the University.

Roles and Responsibilities

The Change Manager ensures that changes follow the Change Management Procedure and will review the policy to ensure that it is up to date and relevant.

Everyone in CiCS has a potential role and corresponding responsibility with regards to Change Management.

End-Users/Functional Teams:

  1. Submitting enhancement requests through the appropriate systems
  2. Participating in testing, pre-deployment testing and post deployment testing
  3. Timely sign off for the change
  4. Verifying that change requests are valid

CiCS Staff as End-Users, Functional Users or Functional User Management:
Responsibility for following the policy.

CiCS Staff Technical Role:
Responsibility to follow prescribed change management processes and procedures.

CiCS Executive:
Overall responsibility for the change management policy and processes contained within it and to ensure that all staff follow it.

Type of Changes

This section defines the different type of changes. Rather than use the confusing ITIL classification of change, CiCS will adopt more meaningful titles to the various types of changes:<.p>

  • Minor/Routine Change: These are changes that may be done at any time as these have been categorised as low risk to the University and the procedures are known and well documented.
  • Examples of this type of are:
    • Application-based security or business needs patches
    • Regularly scheduled maintenance
    • Operating system patches (critical, hot-fixes, and service packs) *
  • Major/Significant Change: These are classified as needing approval changes and these must be planned in advance and submitted for approval from the Change Advisory Board (CAB). The change request should also suggest a time for this change to take place via the change form before being carried out. The CAB will have ultimate say if the change goes ahead at the suggested time or not. Detailed in the change request should be the documentation about what work is going to happen and the perceived benefit and impact to the users. These types of changes should always have a back out plan or mitigating action plan attached.
  • Examples of this type of are:
    • Change that results in an interruption to a service, or has a significant risk of an interruption to service
    • Change that results in a business or operational practice change
    • Changes in any system that affect disaster recovery or business continuity
    • Introduction or discontinuance of a service
    • Operating system patches (critical, hot-fixes, and service packs) *
  • Emergency/Unscheduled Change: Unscheduled outages (server crashes, etc.) may require immediate attention whenever they happen. The Change logging form should still be filled in, but this could be done retrospectively. Please see the sections on Emergency Change Advisory Board and Emergency/Unscheduled Changes for more information.
  • Examples of this type of are:
    • Department or Building is without service
    • A severe degradation of service requiring immediate action
    • A system/application/component failure causing a negative impact on business operations
    • A response to a natural disaster
    • A response to an emergency business need
  • New Development: This type of change is specifically for the deployment of new features/functionality, services or applications and is not a fix to a problem.

* This appears in both categories as the impact can vary depending on the content of the patch. The CAB will be able to provide guidance on which category a particular patch fits into and whether it needs approval before applying.

Slide1.jpg

Submitting a Change

  1. Go to the change form - https://cics.dept.shef.ac.uk/change/
  2. Enter your LDAP username and password. This is so we can record who filled in the change form.
  3. Select the service you are making the change on. If your change affects multiple services then expand as many categories as necessary and select multiple services. Either find it in the service area category or start typing its name in the search box and select it.
  4. Fill in the type of change, there are four choices available:
    • Routine – Select this if your change if your change is well known and documented.
    • Fixing a minor fault - Select this if your change is a minor fix i.e. Spelling error
    • New Development – Select this if your changes adds new functionality or features
    • Fixing an urgent / severe problem – Select this if your change is to fix an immediate problem i.e. stopped server.
  5. Fill in a brief description of the change, avoid technical jargon and try to keep it plain and easy to understand.
  6. Use the pull-down menu to estimate how long the change will take to be made.
  7. Fill in the risk to the service category. There are two options:
    • Minimal - Changes that may be done at any time as they have a little or no risk of going wrong and the procedures are well known and documented
    • Significant - Changes that must be planned in advance and need approval. There could be a significant risk to the service.
  8. Use the pull-down menus to identify the date and time that the change will be made.
  9. Submit the change
  10. Change request will be automatically logged within a Change Database. If your change was classified as ‘Minimal’ then you can carry out the change when you specified, if however, the change was classified, as ‘Significant’ then this change request will automatically generate an email to the Change Advisory Board who will review it. The CAB meets on Thursday afternoons. Please ensure that you have submitted your change request before Noon on Thursdays to be considered. It maybe required for you to attend a CAB meeting in order to provide more information or answer questions about the change request.
  11. If for some reason you need to cancel or reschedule a change or if it does not complete, then you will need to log back into the change form and under then heading labeled ‘Your Changes’ you will be able to update the status of the change. The statuses available are:
    • Uncompleted
    • Successful
    • Failed
    • Partial
    • Cancelled

This is not a replacement for cics-faults or any other communications channels. You should still inform the users of the change taking place and the affects it will have as usual.

Change Procedure

All change requests need to be documented and logged, this will be facilitated through the use of the online form. This documentation will be retained centrally within a change request database. For this reason verbal requests and authorisations are not acceptable.

If your change is urgent, then please see the section on Emergency/Unscheduled Changes.

Change Advisory Board (CAB)

The purpose of the change advisory board is to review all CAB-approved change requests and determine whether or not they should be made. In addition, it may determine that certain changes are altered before implementing in order for it to be accepted. The change advisory board membership is based upon the seven different sections of the service catalogue plus at least one member of the CiCS Executive. For the CAB to be quorate, then at least 7 members should be in attendance.

  1. Assistant Director Development & Operations - Dave Surtees (Chair)
  2. Assistant Director Frontline & Customer Services - Kath Winter
  3. Assistant Director Research & Infrastructure - Nathan Cunningham
  4. Solution Assurance - Martin Rapier
  5. Academic & Workplace Systems - Patrice Panella
  6. Corporate IT Systems - Anne Rodgers
  7. Frontline IT Services - Dan Courtney
  8. Business Support Services - Janine Barraclough
  9. Infrastructure - Stewart Harris
  10. Information Security - Chris Willis
  11. Communication - Jenny Allsop
  12. Helpdesk - John Ollerenshaw
  13. Change Manager - Ben Allsup

Emergency Change Advisory Board (ECAB)

We appreciate that due to the nature of these types of changes that it is not very practical to either wait for group of advisory board members to gather or to seek approval for a change to be made. This is made especially difficult for out of hour’s incidents that require immediate or quick changes to be made in order to restore a service. In these circumstances, an appropriate (preferably independent) service manager and member of the executive has the authority to approve a change. It is acknowledged that in some exceptional circumstances that this may not be possible and the authority will then fall on the person making the change. However, the change request form should still be filled in, even if it is retrospectively.

Emergency/Unscheduled Change

In some cases, events are critical enough that they must be rushed though, thereby creating an Emergency/Unscheduled Change. Each situation is different and as much consideration as possible should be given to the possible consequences of attempting this type of change. It is still necessary to obtain sufficient approval for the change, but this may be in the form of discussing the matter with a relevant service manager or section head and logging who it was discussed with and how it was approved.

Pre-Holiday Rule / Leaving Rule

For at least two days prior to annual leave or leaving the University, a CiCS member of staff should only be permitted to make Minor/Routine Changes. If there is an urgent requirement to make an Emergency/Unscheduled change during this time, please ensure that there is sufficient documentation provided and colleagues know where to find it and what the change involves.

Change Freeze Periods

At certain critical times of the year, it will be necessary to impose a non-essential change freeze period. During this time you should only make changes that are deemed essential to either the running of or fixing of a problem with a particular service. If you have the need to make a change during this time, then please follow the instructions sent out with the change freeze dates. If in doubt, contact the change manager. The dates of any change freeze will be communicated well in advance so that you are enable to plan your work around them.

Cancelling a change

If for any reason you have to cancel or postpone a CAB-approved change, then please do this via the mailing list for change approvers explaining why.
The mailing list is: cics-change@lists.shef.ac.uk. If you need to perform the change again, then please make a new request.

Post Change Checks

After any change has been implemented, the person who is responsible for implementing the change should perform a check to see if it has been successfully applied.