process change management

Audience & applicability As this policy 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.

Document Approval List Version Approver name Role How approved Date

V3.0 IT Executive Team Governance authority Endorsed at Ops Meeting 22/06/2017

Document Change Control Version Date Authors Description of changes

V2.1 23/5/2016 Louise Griffin Yearly review to incorporate Audit requirements and

Improvements

V3.1 30/5/2018 Louise Griffin Yearly review to incorporate Audit requirements and

Improvements

v3.2 19/05/2019 Louise Griffin Minor content and formatting changes

Document Information Details Name Email

Process Owner Louise Griffin [email protected] [email protected]

Location SMO Standards and Processes Intranet Page

Change management service

Procedure

mailto:[email protected]

mailto:[email protected]

https://education.nsw.gov.au/technology/guides-and-forms/service-management-guides

NSW DoE | IT Commercial & Services | Procedure - Change Management 1 | P a g e

Table of content 1. Executive summary ........................................................................................................ 2

1.1. Document purpose .................................................................................................. 2

2. Change management scope .......................................................................................... 2

3. Introduction to the IT Change Management Process ..................................................... 3

3.1. IT Change Management Function ........................................................................... 4

3.2. Benefits ................................................................................................................... 4

3.3. Process Overview ................................................................................................... 4

3.4. Process Details ....................................................................................................... 5

3.5. Who Owns “IT Change Management” ..................................................................... 5

3.6. Changes to the Change Management Process. ...................................................... 5

3.7. Planning, Raising and Review of Change Requests ............................................... 5

3.8. Exemption Process for Change Requests ............................................................. 11

4. Risk assessment matrix ............................................................................................... 15

4.1. Risk Assessment Definitions ................................................................................. 15

4.2. Risk Assessment Matrix ........................................................................................ 15

4.3. Risk Assessment Questions.................................................................................. 16

4.4. Change Lead Times & Endorsement Times .......................................................... 17

5. Roles & responsibilities ................................................................................................ 18

5.1. Change Management Roles & Responsibilities ..................................................... 18

6. Reporting & Metrics ..................................................................................................... 21

6.1. Critical Success Factors (CSF’s) ........................................................................... 21

6.2. Key Performance Reporting .................................................................................. 21

Appendix A ........................................................................................................................... 1

7. Glossary ........................................................................................................................ 1


1. Executive summary The Change Management process is owned by the Director IT Commercial and Services, the

custodian is the IT Director, Service Management and is managed/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 & 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 & 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.

2. Change management scope 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.


Scope Description

In Scope IT Change Management is responsible for managing changes involving:

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 (MAC) 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 Directors for sign off.

3. Introduction to the IT Change Management Process

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 – page 21


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 & Service Delivery and is implemented by the ITD Service Management

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.

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

(SMF) 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(RFA): 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, backout 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 (SFR): This is the equivalent of technical review stage – requires

appropriate stakeholder endorsement.

• Scheduled for Approval (SFA): This is the equivalent of business review stage –

requires stakeholder endorsement and 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 Change Advisory Board (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 Change Advisory Board (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/SME 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).

• 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 (CAB)

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

3.8.1. Complete remedy change request in line with normal change Management process

Purpose Provides a mechanism for Change Coordinators to raise Change requests.

Trigger Change request submitted by a Change Coordinator.

Inputs Details of the request.

Description The change coordinator completes a Change Management request as per Normal Change

Management process.

Outputs Change Request status - Planning in Progress.

3.8.2. Seek exemption

Inputs Change Request status – Planning in Progress.

Description The Change Coordinator in consultation with the Change Manager determines to proceed with the implementation of the change within the exemption period.

Outputs If Yes, then go to 3.8.3 Change Management exemption request.

If No, then go 3.8.7 Normal Change Management process.

Inputs Change Request status – Planning in Progress.

Description The Change Coordinator in consultation with the Change Manager determines to proceed

with the implementation of the change within the exemption period.

3.8.3. Change management exemption request

Purpose To validate if the exemption request to be undertaken within the Change Freeze period, is viable from a business and technical perspective.

Trigger A change coordinator has raised a Change Management exemption request.

Inputs A request record.

Description The change coordinator completes a Change Management exemption request, seeking exemption for the implementation of their change within the change freeze period.

Outputs Change Management exemption request.


3.8.4. Review Change Management Exemption Request

Purpose To review the request and confirm validity in proceeding.

Trigger Approvers have assessed a request.

Inputs Reviewed request.

Description The approvers of the exemption request must assess if the request is viable to be

undertaken within the Change Freeze period.

Outputs • Reject request record.

• Approve request record.

3.8.5. Approved?

Purpose To determine if the change will proceed within the exemption period.

Trigger Change exemption request has been approved by all approvers.

Inputs Approved exemption request.

Description The exemption request has been technically and practically accessed in proceeding within

the exemption period.

Outputs

If Approved, then go to Create a ‘Resolved’ Service Request in Incident Management tool

(Automatic).

If No, then go to 3.8.7 Normal Change Management process.

3.8.6. Relate service request

Purpose To relate approved Service Request.

Trigger Approved service request.

Inputs • Approved service request record.

Description The Change Coordinator of the approved service request will relate the service request to

the Change Request with a status of ‘Planning in Progress’.

Outputs Approved service request related to Change Request.


3.8.7. Normal change management process

Purpose To follow Normal Change Management practice.

Trigger Change record status ‘Scheduled for Review’.

Inputs Approved service request related to Change Request.

Description

The change request will be reviewed by the Change Manager to determine that the change

is fit for purpose technically, and that the implementation plan, back-out plan and test plan

is correct and conforms to ITD Change Management practices.

Outputs Approved or Rejected change request.

3.8.8. “Rejected” and advice change coordinator

Purpose To advise the Change Coordinator of all non-viable or unapproved exemption requests and

set the record status to “Rejected” in preparation for closure.

Trigger A exemption request is deemed to be not viable or is not approved.

Inputs • A non-viable request.

• An unapproved request.

Description

The Change Coordinator will be advised that the request shall not be proceeding and given

the reason(s) why. Via email.

The status of the request will be set to “Rejected” and the request will remain in that status

for an agreed timeframe. During the agreed timeframe the request will be deemed to be in a warranty period. The

Change Coordinator can raise questions about the rejection during the warranty period.

Outputs • Change Coordinator notification email.

• Non-standard request record with a status of “Rejected”.

3.8.9. Close request

Purpose To ensure that all requests are closed once completed or declined.

Trigger A completed or declined request record that has come to the end of its warranty.

Inputs • A completed request record.

• A rejected non-standard request record.

Description The request record will be closed automatically (within 5 days) in the Remedy SRM system

if no objection has been received from the Customer within the agreed warranty period.

Outputs A closed request record.


4. Risk Assessment Matrix

This section outlines the method for determining the Risk of a Change.

4.1. Risk Assessment Definitions

High (Risk Level 4 & 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 & 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.

Risk Level Risk Average

Low Risk Level <2.5 Risk Average

Medium Risk Level >2.5 <= 3.5 Risk Average

High Risk Level >3.5 Risk Average


4.3. Risk Assessment Questions

Question 1 2 3 4 5

When are you planning to implement the change?

Standard

Maintenance Window

TAFE and School

Holidays

Negotiated Non

business hours Window

Core Service Hours

Peak

Processing Times

Is there a service outage involved?

No outage Outage Single service but has

failover

Outage Single

service no failover

Outage to Multiple

service/s

Core Business

service outage

What business service is the change being applied to?

Dev / Test Pre Prod DR Prod - single system

Shared or

Critical Prod

system

Has this change been performed before?

Documented

Routine or Standard

procedure/

Process

Not applicable

Non-Standard/Non

documented

procedure several times

Non-Standard/Non

documented

procedure done once

Never done

What level of pre-change Testing has been performed / planned? UAT and/or Technical

Full testing

cycle

(Integration Testing, UAT)

Minimal / Basic Testing (Partial

testing cycle)

3rd party tested

(tested outside

Client environments)

Technical testing

completed only

Untested / Cannot be

tested

What is the back-out/roll-back strategy?

Immediate Failover or DR

Uninstall /

Configuration

change

Restore/Reinstall to prior state

Requires rebuild/reconfigure

Unable to be

backed out / requires

forward fix

How will Post-implementation Verification Testing (PVT) be performed?

PVT

Immediately post change by

application team

PVT deferred to

non -business hours by

application team

PVT deferred to

during Business Hours by

application team

No PVT testing , IT health checks only

PVT will

not/cannot be

performed

Will Business Continuity / DR be affected?

No DR capability exists or not

applicable

DR solution

update/change is

required and

planned

Not applicable

DR solution

update/change is

required but is not

planned

DR solution

exists but will

not be

updated


4.4. Change Lead Times & 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. The 3 categories of risk with minimum lead-times

are:

The following table provides the maximum turnaround times (in days) in conjunction with the

change record lead-times for approval to be sought.

Risk

Lead time (from SFR) Stakeholder endorsement time Total lead time required

High 10 10 20

Medium 5 5 10

Low 2 3 5

Pre-approved Predefined when approved by the CAB and senior Management.

Emergency Implemented at a time that will not cause further depredation of service that is currently identified.


5. Roles & responsibilities 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

Role Responsibility

Change Requestor

(Requested For in Remedy tool)

Individual who requests the change or person who identifies the need for

a change. A requestor will engage the change process through the service request process.

Change Co-ordinator

(Change Co-ordinator in Remedy

tool)

The individual who has developed the change. Ensures that the change

request has all appropriate information and IT Change Methodology has

been followed and all endorsements received prior to implementation.

The Change Co-ordinator is responsible for the end to end coordination of this change including communications.

Within ITD this role will lie in the team initiating the change. This may not in all cases be the team implementing the change.

Change Facilitator

Where business units have a central change facilitator it is their

responsibility to also ensure that all changes for their respective teams adhere to the change process and are approved by them before

representation at CAB or implementation.

Implementer

Identifies the individual who will be actioning or implementing the

change. The implementer is responsible to ensure all endorsements have been received prior to implementing change.

Stakeholder

(Change Manager in Remedy in

tool) (Including: Application and Infrastructure Team Change

Managers, Service Delivery

Managers and Configuration Item Approvers)

This person/s is required to accept the risk of the change proceeding

including impacts and risk to system stability and accept all system

downtime as an agreed downtime if implemented outside of change

windows or during a change freeze. They are to ensure the Change Co-ordinators adherence to the change process and that all change

evidence has been included in the change including pre-implementation

testing has met business objectives and that PVT meets all business critical requirements. Implementation and back out plans are correct and

correct CI’s and stakeholder approvals have been included.

Any concerns regarding changes are addressed with the IT Change

Manager during approval turnaround times.


Role Responsibility

The Change Manager will approve the change and cannot be the change co-ordinator this will cause a conflict of interest.

IT Change Process Owner

This person owns and governs the IT Change Management Process.

The change process owner is responsible for education of stakeholders in change practices. The IT Change tool, improvements to and

governance of the change process and reporting on all change activity.

CAB Chairperson

The CAB Chairpersons role is to chair the CAB. The CAB Chairperson

can withhold CAB approval pending further action or they can defer their

approval to a member of the ITD executive team to accept responsibility

for proceeding. This person will be the change process owner or delegate. The role is responsible for reviewing all significant/major

changes (both scheduled and emergency) prior to the CAB,

implementing and managing governance of change across ITD, representing change activities and outcomes in the Daily Operations

Review (DOR).

Change Advisory Board Members

‘Core’ group of individuals who meet weekly to review, discuss and

assess each submitted change on its worthiness to proceed to

implementation. The change will be reviewed in terms of risk and other factors.

eCAB Advisory Board Members Service Delivery Manager, Change Process Owner and Senior

Management approval.

5.1.1. Change Management RACI Matrix

Activity / Role Change

Requester

Change

Co-ordinator Implementer

Stakeholder/Approver

CAB Chairperson

Process Owner

Gather

Requirements I RA C C I I


Activity / Role Change

Requester

Change

Co-ordinator Implementer

Stakeholder/Approver

CAB Chairperson

Process Owner

Request for

Change I RA C C I I

Plan (Planning In

Progress) I RA C C I I

Build I A R C I I

Test and UAT C RA C C I I

Technical Approve I R C RA I I

Business Approve C R I A R I

Deploy to Prod

(Implementation in

Progress)

I A R C I I

PVT Test A R C C I I

Monitor and Close I RA C C I I

Deploy to DR I A R C I I

Measurement and

Reporting I C C C C AR

Legend

• R = Responsible: executes the task.

• A = Accountable: accountable for final result.

• C = Contribution/Consulted: contributes/Consults to the task.

• I = Informed: needs to be kept up-to-date on activities/tasks.


6. Reporting & Metrics 6.1. Critical Success Factors (CSF’s) The critical success factors for Change Management will be:

• To successfully implement changes

• To maintain IT production stability

• To improve IT and business productivity

• To 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


Appendix A Remedy 7.6 Change Flow Diagram – normal / urgent

Initiate RFC RFC Review & Approval Change ImplementationSchedule RFC Measurement & ReportingBUILD & Test Change

Your Change here by Friday COB to

make CAB

LeadTime

DRAFTDRAFT Request for AuthorisationRequest for

Authorisation

Rejected

CM Qualityapproval

Planning inProgress

Planning inProgress

ScheduledFor ReviewScheduledFor Review

ScheduledFor Approval

ScheduledFor Approval ScheduledScheduled

Implementation in

Progress

Implementation in

Progress

CM Technicalapproval

Stakeholderapproval

SDM/ BusinessApproval

ChangeManager

ClosedClosedCompletedCompleted

CI Health Check

CM Quality ApprovalChange Manager Rejected Rejected

LeadTime

Meets lead time

Change proposed dates

Set timing to Expedited and timing reason

NoAnswer

Expedited smartform

Reschedule? No

End

End


Initiate RFC Build & test change RFC review & approval Schedule RFC Change implementation Measurement & reporting

• Summary – Description (Mandatory)

• Change Co-ordinator

• Change Location (Mandatory)

• Classification

• Change model – Timing

• Operational Categorization

• Risk Level (Mandatory)

• Work Info

• Business Justification (Mandatory)

• Assignment - Manager Group and

Change Manger

• Dates

• Scheduled Start & End

• Relationships

• CIs Change

• CIs Impacted

• Other Relationships

• Advanced Bar

• Impacted Areas

Work Info

• Pre-Implementation Test Plan

• Pre-Implementation Test

Results

• Implementation Plan

• Implementation Test Plan

• Back-out Plan

• Back-out Test Plan

Dates (Mandatory)

• Scheduled Start

• Scheduled end Time

Relationships

• Confirm CI’s

Advanced Bar

• Impacted Area – Confirm

• View Risk Report - Confirm

Technical Approval

• Change manager

• By impacted

• Change Manager

• CI Supported by

• CI Approved by

CM Quality Approval

• Change Manager

Changes are locked from here

Business Approval

• SDM

Change Manager

• Approval

Work Info

• Implementation Test Results

OR

• Back-out Test Results

• Post Implementation Review

(if required)

Classification

• Implementation Success

Code

Dates

• Actual Start and End Dates

External reporting


7. Glossary Term Definition

DEC The New South Wales Department of Education and Communities

ICT Information and Communications Technologies

IM Incident Management

IT Information Technology

ITD NSW DEC Information Technology Directorate

ITIL Information Technology Infrastructure Library

ITM Information Technology Manager

CAB Change Advisory Board

SDM Service Delivery Manager

CI Configuration Item

DOR Daily Operational Review Meeting

DEC The New South Wales Department of Education and Communities

ICT Information and Communications Technologies

process change management

Documents