Frequently Asked Questions

Below are some frequently asked questions and answers relating to the Change Management Process.

If you're still unable to find the answer you're looking for, get in contact with the Service Delivery team.

    Expand
  • What is change management and why do we need it?

    Change management is a controlled process for introducing changes into the IT production environment in order to minimise disruption. When the approved change management process is used, many benefits are realised:

    • Changes occur at times both convenient and appropriate to the University
    • Affected users receive appropriate and timely communication
    • There are no conflicts with changes being made by other TS teams
    • If a change does not go according to plan, the reasons for the problem are investigated and actions are taken to prevent the issue occurring in the future.
  • What does the Change Management team do?

    The Change Manager:

    • Chairs the weekly ITDS Change Advisory Board meeting
    • Reviews RFCs for completeness and accuracy prior to passing to the CAB
    • Provides/updates/creates documentation and advice on the change process
    • Prevents potential conflict by maintaining the Forward Schedule of Change
    • Is an escalation point for problems with changes
    • Controls the processes for both normal and emergency changes
  • What is the Change Advisory Board and what does it do?

    The CAB is comprised of representative(s) from each Information Technology and Digital Services team and includes the Service Delivery team as the convenor. The CAB meets once a week (Wednesday) to review and assess any requests for change prior to implementation.

    The CAB is responsible for the co-ordination of all changes to IT production systems including:

    • Reviewing and authorising/rejecting RFCs not already approved at the CAB level
    • Generating action items for ITDS staff
    • Discussing procedures and improvements to the change process
    • Approving procedures to allow a change to be standard (pre-approved)
  • What are the RFC submission deadlines?

    RFCs must be submitted and set as "approval" status before 2pm on each Monday for review on Wednesday.

  • What if I need to make a change to a service immediately?

    Follow the Emergency Change Procedure and notify the Change Manager to request an Emergency CAB (ECAB).

    If a Priority 1 or Major Incident is declared by the Service Desk, Emergency Changes can be actioned immediately and logged retrospectively once the Major Incident is resolved.

  • What RFCs can be approved outside of the CAB meetings?

    • Any standard change with an approved process.
    • An Emergency Change that follows the Emergency Change Procedure and involves an Emergency CAB (ECAB).
  • Which changes should follow the change management process?

    Any change made to a production IT system that is managed by ITDS will require a Request for Change (RFC). An RFC is logged via the RFC web form.

    Some typical changes that require a Request for Change are as follows
    Service Action requiring an RFC
    Application Services PeopleSoft Student Admin/Finance/HR update to a form
    Application Services MyUni upgrade
    Customer Services Deployment of new applications (change to SOE)
    IT Risk Management Upgrade to the security management sofware
    Network Services Upgrades to the wireless network
    Unix Services Moving a server from one rack to another
    Unix Services SAN firmware upgrade
    Windows Services Release of Microsoft patches on a monthly cycle
    Windows Services NAS firmware upgrades

    Other changes, while not changes to the way our production systems work, require TS approval. These buildings may have communications or server infrastructure in them.

  • What needs to go into an RFC to ensure my change is approved?

    • All text boxes must be completed with appropriate information
    • A good title: a short (A clear brief description of the changeA reason why the change must happen
    • A proposed time for implementation
    • Any risks that you foresee during implementation (and any mitigations you have made to reduce those risks)
    • Identify what Configuration Item(s) will be changed and ensure they are linked to the RFC correctly
    • Record what service(s) are affected by this change
    • What happens if this change is not implemented
    • A back-out plan and resources required (if applicable)
    • Communication text (aimed at appropriate audience)
    • Correct team, urgency, impact and type of change selected

    Most importantly, ensure that you have submitted your RFC and a technical CAB representative has assessed/progressed the request to the approval status prior to the CAB deadline.

  • Who is responsible for coordinating RFCs that affect multiple teams?

    Unless otherwise arranged, the requestor logging an RFC assumes responsibility for co-ordinating an RFC. This co-ordination includes the following tasks:

    • Asking other teams for any required staff (with sufficient notice)
    • Preparing any communications to be sent by the Service Desk
    • Making sure communication gets sent with appropriate notice (ten business days for changes happening outside of maintenance windows, two business days for changing happening during maintenance windows).
  • CAB has raised issues/action item(s) with my RFC. What happens next?

    The CAB will create Action Item(s) for each issue it has with your RFC in the Notes section of the record and will advise the requestor via email or in person.

    Before a change can proceed, the action items must be completed or addressed to the satisfaction of either the AI requester or the TS CAB. Action Item updates should be added to the notes section of the RFC for tracking purposes.

  • What is the Forward Schedule of Change?

    The Forward Schedule of Change is a visual representation of all changes that are approved or pending approval and can be viewed in the Cherwell "Change Calendar". The Forward Schedule of Change enables the CAB and key University staff to schedule future changes, identify any upcoming RFCs that may impact a service and quickly view any conflicts between RFC timings.
  • What happens if my RFC fails?

    A manager or the ITDS CAB can request a formal PIR (Post Implementation Review). This is a process run by the Change Manager and involves calling a meeting with;

    • The implementer(s)
    • Any CAB representatives who would like to have input
    • Any necessary technical expert(s)
    • Any representatives from a customer group that may have been adversely affected

    The aim of the process is to:

    • Identify the cause of failure
    • Identify any processes/procedures that can be improved to stop this from occurring again
    • Create Action Items (AI) against Team Leaders/Managers to reduce the likelihood of this occurring in the future

    The Change Manager will provide a copy of the PIR report to all attendees of the meeting to gain feedback and/or comments. The report will then be made available to the TS Managers mailing list and/or manager meeting.

 


Contact the Change Management team

For any questions about the change management process please contact the IT Service Desk on 33000 or email the Service Delivery team.

Please don't hesitate to contact us with any business critical events you wish to add to the forward schedule of change and will we attempt to coordinate technology changes to not impact the event.