Change management

Change release calendar

To register a release with ITD change and release management, follow the steps below.

  • Complete the ITD release registration form.
  • Raise a new incident in remedy detailing the release requirements. Select functionality (how to?) as the query to classify the record as a service request.

Image of remedy incident page

  • Attached the completed ITD release registration form to the remedy incident.
  • Assign the request to the SMO process owners group located under ITD-C&S and you will receive confirmation from the IT change management team

If the requested release is urgent/aimed to proceed within 4 weeks of the current date, please ensure you email the completed form to for expedited consideration.

You will receive an email from the SMO process owners, confirming receipt of your request. All further actions will be logged in remedy against the raised Incident.

To request a release, please complete release registration form v3 (XLSX 36KB).

Change management


This policy does not contain process or procedural information, the intended and target audience and applicability is:

  • regional information technology managers
  • service management forum
  • community of practice
  • service delivery management
  • service desk senior management
  • SAP support centre management
  • teaching and learning systems management
  • learning and business support management.

The change management process is owned by the executive director, customer experience and service delivery IT director, service management, the custodian is the IT director, service management and it is managed and implemented (on a day-to-day basis) by the service management process owner change, release and configuration process owner.

The responsibility for setting of policies, processes and procedures sits with the executive director customer experience and service delivery change, release and configuration process owner.

The responsibility for reviewing and approving current and amended policies and procedural/process documentation relating to change management of IT infrastructure, systems software, applications software and data, sits with the:

  • CIO (for the policy only)
  • executive director customer experience and service delivery
  • IT director, service management
  • service management process owner
  • ITD director’s group
  • business and administrative units representatives.

The policy and process documents will be subject to review/revision on at least an annual basis.

1.1. Document purpose

This document describes the processes, which must be followed when initiating change to environments detailed in the change management scope, in particular to production environments.

Because the change management process deals with the management of changes in all environments, it is imperative that both customers and the company's change organisation understand the events that are considered within the scope of the process.

In this section, the scope is described and includes areas which are both within and outside of the change management process scope.

In scope

IT change management is responsible for managing changes involving the below. 

All infrastructure changes in all environments including:

  • LAN-WAN hardware/software.
  • mainframe hardware/software.
  • midrange hardware/software.
  • network hardware/software.
  • infrastructure-production fixes including Microsoft patches.
  • infrastructure-application software.
  • TCC (total contact centre).
  • reboots as a result of change.
  • state office desktop changes.

All application changes in the UAT/training and production environments including:

  • software
  • releases
  • maintenance and enhancements
  • production fixes.
  • emergency changes are classified as a break fix refer to emergency policy
  • facilities management changes impacting the provision of IT services.

Out of scope

  • Move/add/changes equal to or less than 50.
  • Single desktop upgrades.
  • Web content changes through a console.
  • Business change management.
  • Application changes to Development and Test environments (legacy environments).
  • Infrastructure 'crash and burn' environments and test rigs.

Modifications may be made to the scope periodically to include additional items and this must be circulated to the director's for sign off.

IT change management (excluding business change management) is the function of planning, scheduling, communicating, and executing changes successfully. The goal of IT change management is to establish a clear set of policies and procedures that ensures the successful introduction of change, while maintaining a stable production environment.

3.1. IT change management function

The IT change management function begins at project conception or identified need for change.

The function is complete once the change has been implemented, measured and reported with results i.e. closed successful, failed, deferred or cancelled.

3.2. Benefits

IT change management function provides business and customers with many benefits and services. These include the following:

  • Better alignment of IT services to business requirements.
  • Increased visibility and communication of changes to both business and service-support staff.
  • Improved risk assessment.
  • Increased availability of users – through less disruption and, higher-quality services.
  • Greater ability to absorb a large volume of changes.
  • An enhanced business perception of IT through an improved quality of service and a professional approach.
  • A managed risk approach through standardisation, planning and risk mitigation to provide an integrated view of the ITD production environment.

3.3. Process overview

The change management procedure is designed to:

  • Provide those wishing to make changes within the scope of the change controlled environments, a process which is both timely and successful: meets defined objectives.
  • Provides clients and partners a framework for communication and consultation so that business priorities may be considered in the planning of changes to operational services.
  • Ensures that standardised methods and procedures are used for efficient and prompt handling of all changes;

Process workflow overview, refer to appendix A.

3.4. Process details

This section details the key activities performed in a generic change control process. The first section describes the ownership of the process and key partners second section describes the planning, raising and review of change requests third section describes the implementation process of the change, and the last section describes the closure process of the change request.

Each procedure is described with enough detail to complete the implementation of a change through the IT change management process.

3.5. Who owns 'IT change management'

The process of IT change management is owned and governed by the executive director customer experience and service delivery and is implemented by the ITD service delivery and support team.

Other key players will be stakeholders, managers or team leaders from application, desktop, service desk and Infrastructure support teams.

The IT change process owner is considered the point of reference on any question or issue relating to the change process.

Whilst it is acknowledged that each team operates and is governed by this process, it is understood that some teams are structured differently. In some instances, technical resources will represent their changes, in some teams however there are structures and internal processes in place which cater for governance and representation over changes for that group. For example, the infrastructure continuity team in Infrastructure Services acts as the change facilitator on behalf of the entire group. Therefore, change for infrastructure services is internally managed by their continuity team who then comply with the overarching change management process.

In instances where there is a change facilitator function within a team, area or region the engagement model for change will be through that facilitator. That is, that if any team member from one of those areas has a question they should initially contact their respective facilitator. Likewise, if the change manager or change process owner has a question they too will initially go through the facilitator.

3.6. Changes to the change management process

It is the change process owners responsibility to continually improve the service. Changes or enhancements to the change management process must be suggested to the change process owner who will then submit valid suggestions to the service management forum and communicate to the change community of practice for prioritisation.

3.7. Planning, raising and review of change requests

3.7.1. Planning to implement a change

A change request is required for the infrastructure and application changes to all environments detailed in the change management scope section.

Change data should be entered into the IT change management tool as soon as it is available.

It is advisable to raise a provisional change to allow early risk mitigation by all areas of ITD.

3.7.2. Raising a change request

A change request must be raised in remedy smarts in only 1 category: Draft. All change requests in draft status need to be submitted for approval prior to implementation.

ITD requires all change requests to be raised in specified lead times dependant on classification of change.  This will aid in risk mitigation and stakeholder endorsement.

  • Draft: A change request creation in progress and not yet submitted. All changes in draft format will not be captured on change calendars for risk mitigation.
  • Request for authorisation: Change has been submitted for Stakeholder endorsement.
  • Planning in progress: A change request in a 'planning in progress' stage with a confirmed start date and implementation plan, back out plan and named PVT testers. If the change is to proceed all evidence and approvers to be added to the change at this point. The change is locked beyond this point and no changes can be made to change evidence including dates, times, plans.
  • Scheduled for review: This is the equivalent of technical review stage – requires appropriate stakeholder endorsement.
  • Scheduled for approval: This is the equivalent of business review stage – requires stakeholder endorsement and Change Advisory Board (CAB) approval to proceed.
  • Scheduled: Change request may be implemented and is now classified as a change record.
  • Implementation in Progress: change is currently in progress.
  • Completed: Change owner inputs result of change.
  • Closed: Change tool automatically closes all completed change records.

Additional change categories:

  • Re-submitted: change request has been re-worked and is waiting on stakeholder endorsement.
  • Rejected: Change request has been rejected by a stakeholder and requires additional work prior to resubmission.
  • Cancelled: Change request is no longer required.
3.7.3. Identify change requirements

Defining the scope of a change includes identifying the objective of the change, systems impacted, duration of any outage requirements, business units affected, testing including UAT sign off (where relevant including) (date and person responsible), location of UAT documentation and an assessment of risk.  This data is used at many decision points within the process and will be verified at the CAB where significant and major changes are discussed. This information is also required for ensuring communications are sent to the correct impacted areas for engagement and auditing purposes both internally and externally.

A preliminary review of the provisional and scheduled changes will determine if the proposed implementation timeframe is appropriate. By reviewing schedules early, conflicts can be negotiated and resolved prior to the CAB. All changes are assessed by appropriate estimation of the risk introduced by the change, the visibility of the change to the user community and the impact of a change failure.

3.7.4. Creating a change request

Once the scope of the change is defined, the data is entered into a uniquely identifiable change record that is used throughout the change process for evaluating, tracking, scheduling and measuring a change.

The change request must contain:

  • objective of change
  • clearly identify what is changing (scope of change)
  • identify capacity requirements (where relevant)
  • UAT signoff (include date of signoff and who endorsed the signoff), UAT documentation or identify location/contact for UAT documentation: (where relevant)
  • clear implementation steps including timings and the final version of code attached or linked to but must ensure version control
  • testing plan and signoff points (all areas of the lifecycle need to be signed off by the appropriate owner/subject matter expert and attached to the change)
  • go/no-go decision points
  • production verification signoff (who is responsible to verify change has worked and production environment is stable)(where relevant).
  • identification of impacted areas and applications (inclusion of impacted/related configuration items, refer to appendix B (PDF 16KB)
  • communications to impacted service owners and/or Business Units as applicable
  • disaster Recovery Impact.
  • back out steps.
  • If the back-out impacts the entire system (i.e. IPL or server reboot)
  • business and service impact
  • technology/business risk
  • security implications.

Entering accurate and up-to-date information with appropriate detail is a requirement for a change to be approved. In addition, any impact to off-site contingency plans, operational documentation, or any other documentation or procedures must be indicated in the change record.

3.7.5. Submit request

All change requests in draft status are required to be submitted for endorsement prior to implementation through the change tool.

Once a change request has been submitted, all stakeholders identified are automatically notified and are able to review the change. It is the responsibility of all stakeholders to manage the endorsement of a change within an appropriate timeframe. If the stakeholder is unable to review the change request within the suggested timeframe, please advise the IT change management.

It is the requestor’s/implementer’s responsibility to ensure that all endorsements are received prior to implementation.  If a particular stakeholder is not contactable, IT change management is able to assist the requestor in gaining the stakeholder endorsement. Please refer section lead times section 3.12.

3.7.6. Review, verify and approval of change request by stakeholder

The role of a stakeholder is to determine whether the proposed change, implementation plan, back out plan, and accompanying information is correct and conforms to IT change management process. A stakeholder assesses the information provided for all technical aspects of the change. Additional approval groups may work with the IT change manager or requestor to mitigate or avoid impacting the represented functional areas. Any change request that is not accurate and complete will be rejected.

A stakeholder is responsible for reviewing all changes affecting their group that are scheduled for implementation. The stakeholder will assess the impact on their work area and confirm with their clients if necessary. If the information in the change request is sufficient to warrant approval, the request is approved.

Approval of a change

Upon approval, the stakeholder accepts the risk and responsibility of the change request. Change requests that are approved by all stakeholders are scheduled for implementation

If a stakeholder rejects a change, the stakeholder is required to identify the reason why the change has not been accepted. The request requires to be either reworked and/or resubmitted for approval or cancelled as no longer required by the requestor.

3.7.7. Review change request by change owner

A co-ordinator/implementer should perform a query of the IT change management system to determine if another change has been submitted that may have an impact on the scheduling of this change. The concern at this time is to determine if another change is scheduled at the same time or affecting the same application area, hardware, etc.

The query may be performed on either the IT change tool or on the IT change calendar available on the intranet.

If a conflict is detected, the requester has several options available. First, determine if the requester’s change can be scheduled at another date and/or time. If the requester’s change is critical, then contact with the other requester(s) should be made to determine if their changes could be rescheduled. Determining the priority of a change should help to resolve conflicts between required changes.

3.7.8. How to review a change with issues and conflicts

If a stakeholder has concerns or questions about a change, and the information provided in the change request is not sufficient, the stakeholder can either request further information, request an amendment to the request, or reject the request.  It is recommended that stakeholders make every attempt to resolve any issues or conflicts before rejecting a change. Once a change is rejected the process will have to revert back to the beginning requiring all stakeholder endorsement.

If the change is deemed business critical the change requestor can seek director approval and follow the emergency change request process.

3.7.9. Rescheduling a change

If issues arise that cannot be resolved, a determination should be made by the change co-ordinator to either cancel the change or re-plan the work involved. To reschedule the change should be taken back to draft or planning in progress status and the reason for rescheduling addressed, reason/resolution documented in the change and the resubmitted for approval. If the action is to cancel the change request entirely, then a reason for the cancellation is required to be documented in the change record.

3.7.10. Change advisory board

The objective of the CAB is for a ‘core’ group of individuals, to review, discuss and assess each submitted change on its worthiness to proceed to implementation. Each change will be reviewed in terms of risk and other factors.

All high and medium (major/significant) risk changes are required to be represented at CAB for endorsement to proceed.

The CAB meeting will be held weekly Wednesday from 11 AM until approximately 12:00. All changes to be reviewed must be submitted within the change tool by Friday COB. It is the responsibility of the requestor to ascertain the status of their change following the meeting.

Assemble finalised schedule

The final schedule of all changes will appear on the IT change calendar. The calendar provides a brief description of each change record as well as a high-level schedule depicting final schedule time frames.

3.7.11. Implement change

The Implementer should follow the implementation steps as stated in the change request. The service delivery manager or his delegate must approve any deviation from the original implementation plan.

Once a change request is in scheduled status the implementer is required to follow the implementation plan as stated in the change record. A request may not be implemented unless it has received all endorsements. Any variation in the implementation plan from that, which was authorised, must be escalated for approval during the implementation and recorded in the request for later review.  All escalation details are to be identified in the implementation plan prior to implementation.

3.7.12. Post verification testing

Immediately following the conclusion of the change implementation, the Implementer is required to work with the team who is conducting the post verification testing (PVT) to ensure that no problems have risen as a result of the change. The PVT team is required to test existing functionality as well as new functionality as a result of the change. IT/ business sign-off is required accepting the change as successful. If sign-off is not received, the change to be backed out as unsuccessful.

3.7.13. Completing change request

The requestor/implementer updates the change record with the appropriate status, successful, cancelled, failed within 3 working days of the change being implemented.

In the event a change is denoted as ‘failed’ or ‘cancelled’, the Requestor/Implementer will be required to document the failure as a CPIR in the change record.

3.7.14. Back-out change

If a change fails and is backed out, the request must be closed as failed. All failed changed must be represented at CAB the following week.

Back-outs are performed in accordance with the back-out instructions defined in the change request and after consultation with the appropriate service delivery manager and/or infrastructure/application manager.

3.7.15. Change window exceeded

If a change window is exceeded confirmation from a service delivery manager and/or infrastructure/application manager is required before the extension can be granted. This change to the plan and timings must be recorded in the change when closing.

3.7.16. Closure of a change

All change records require to be closed within 5 days of implementation.  Where this timeframe is unable to be met, the IT Change Manager is required to be advised.

When a change record is closed the data is used for reporting, to track system availability, and to begin/validate other dependent change requests.

Key success criteria

  • The change was implemented in accordance with the implementation plan
  • The change was implemented within the planned implementation timeframe
  • The change caused no unplanned customer impact
  • The change met anticipated objectives defined in the Change request justification
  • The change did not result in a system/application outage due to the execution of the back-out plan.

3.8. Exemption process for change requests

In line with ITD change policy section 2.8 exemption policy IT change methodology has built-in flexibility to manage changes outside of ITD change process or during change freeze periods. This allows directors/managers to assume responsibility for the risk of the change proceeding outside of the change process.

For further information, please refer to change management exemption process for change requests.

This section outlines the method for determining the risk of a change.

4.1. Risk assessment definitions

High (Risk level 4 and 5) (Major)

Where the business impact and/ or technical risk is high resulting in a definite service outage of critical services with possible revenue loss, affecting single or multiple clients/platforms impacted. The implementation is moderate to complex or requires an extended window. i.e. call centre, Customer, Web.

Medium (Risk level 3) (Significant)

Where the business impact or technical risk is medium resulting in possible service outage affecting single or multiple clients/sites/platforms with a moderate number of users affected. The change is easy to moderate to implement.

Low (Risk level 1 and 2) (Minor)

Where the business impact/ or technical risk is low resulting in no service outage or outage of non-critical components, system useable by users during implementation or affecting a single client/site with a low number of users impacted.

4.2. Risk assessment matrix

The following matrix will be used to determine risk assessment.

The risk of a change is automatically calculated depending on the answers chosen by the change co-ordinator. The responses are weighted from 1 to 5 (1 = lowest weight: 5 = highest weight) The average is then taken and is then converted to a number between 1 and 5 as per above.

For further information, please refer to the risk assessment matrix.

4.3. Risk assessment questions

Risk assessment question table (DOCX, 15KB).  

4.4. Change lead time and endorsement times

The lead-time of a change refers to the minimum number of days a change request is raised prior to the scheduled date of implementation.

The definition has taken into consideration the time required by stakeholders to assess/review prior to approval, client notification, number of platforms impacted, outage time and dependent changes.

Lead-Times for changes are auto calculated based upon various risk, impact, and back-out responses when raising a change record. 

For more information, please refer to the change lead time matrix.

The business and technical decisions that drive change, are conducted by processes external to IT change management (e.g. request management system) and are made prior to any change request.

This section identifies the various participants involved in the IT change management process.

5.1. Change management roles & responsibilities table (DOCX 17KB)

5.1.1. Change management RACI matrix (DOCX 17KB).

6.1. Critical success factors 

The critical success factors (CSF's) for change management will be to:

  • successfully implement changes
  • maintain IT production stability
  • improve IT and business productivity
  • adhere to policy and satisfy audit requirements.

6.2. Key performance reporting

In order to measure the efficiency and performance of the IT change management process, a number of statistical factors have been established. The following factors have been identified as providing a means to measure the IT change management process on a weekly/basis:

  • total number of changes per month
  • % successful changes
  • % expedited changes
  • % emergency changes
  • % failed changes
  • % latent changes
  • % closed within 5 days of implementation
  • number of changes backed-out
  • number of changes that exceeded the approved window.

Print version for change management Process (PDF 430KB)


This purpose of this document is to provide a formal standard for the implementation and management of a service management process within the service management organisation.

This document will be supported by detailed process, procedural, work instruction and guideline documents as required.

As this standard does not contain process or procedural information, the intended and target audience and applicability is specific to:

  • regional information technology managers
  • service management forum
  • community of practice
  • service delivery management
  • service desk senior management
  • SAP support centre management
  • teaching and learning systems management
  • learning and business support management.

The standard document has been created to provide a standard and framework to support and underpin a service management process within the service management organisation. It is not intended to be a process or procedural document and subsequently will be supported by these documents.

Change management is a significant component of ITIL’s service operation. Service operation is the phase of the ITIL service management lifecycle that is responsible for 'business-as-usual' activities. The ITIL model diagram shows service operation in relationship to other lifecycle components: Service strategy, service design, service transition and continual service improvement

Within the service transition stage of the service lifecycle, change management is one of a number of lifecycle processes that impact all lifecycle stages.

These processes are:

  • change management
  • service asset and configuration management
  • knowledge management.

Processes focused on service transition, but not exclusive to the stage, are:

  • transition planning and support
  • release and deployment management
  • service validation and testing.

The scope of change management across the key stakeholders diagram shows the scope from the business consumer to service providers and suppliers.

1.1. Purpose

The purpose of change management within IT is to ensure that:

  • Standardised methods and procedures are used for efficient and prompt handling of all changes.
  • Minimising the number of service interruptions resulting from implementation, enhancement and maintenance activities.
  • All changes to service assets and configuration items are recorded in the configuration management system (as it develops).
  • Understand the risk to the business.

Change management aims to achieve these outcomes through the following means:

  • Being a central point of contact for all change management activities affecting service management customers.
  • Assisting in the resolution of scheduling conflicts.
  • Setting appropriate lead times to ensure all changes are adequately planned and reviewed.
  • Increasing visibility within the support community to allow impact assessment across the range of IT services.
  • Increasing visibility within the customer base to promote a secure and stable environment.
  • Providing an efficient review and approval process through the CAB.

The service management change management standard document provides clear and comprehensive guidelines for the management of change across the ITD and business units. These policies underpin and guide the functions and activities employed to deliver a quality change management service to the DEC business.

1.2. Change definition

A change is the addition, modification or removal of an authorised, planned or supported service or service component and its associated documentation.

Change management ensures that changes are recorded, evaluated, authorised, prioritised, planned, tested, implemented, documented and reviewed in a controlled manner.

1.3. Change process overview

Please refer to the change process overview.  

1.4. Emergency change process overview

Please refer to the emergency change process overview.

This standard applies to the management of any change that occurs in relation to a product or service delivered to the service management office.

Service management office are accountable for ensuring that their respective teams follow the guidelines within this Standard statement and the procedures derived from it.

The reason for this standard is to:

  • Ensure consistent and efficient handling of changes such that the customer experience is predictable.
  • Ensure all changes are recorded in the change management tool, tracked, fully approved and managed to completion within agreed timeframes.
  • Enable quality assurance and the continuous improvement of the change process.
  • Assist in providing quality data from a single source for reporting and review of changes.

For further information, please refer to the change process standard statements.

Return to top of page Back to top