Process Change Management
Transcript of 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
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
NSW DoE | IT Commercial & Services | Procedure - Change Management 2 | P a g e
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.
NSW DoE | IT Commercial & Services | Procedure - Change Management 3 | P a g e
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.
NSW DoE | IT Commercial & Services | Procedure - Change Management 4 | P a g e
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
NSW DoE | IT Commercial & Services | Procedure - Change Management 5 | P a g e
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.
NSW DoE | IT Commercial & Services | Procedure - Change Management 6 | P a g e
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
NSW DoE | IT Commercial & Services | Procedure - Change Management 7 | P a g e
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.
NSW DoE | IT Commercial & Services | Procedure - Change Management 8 | P a g e
• 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
NSW DoE | IT Commercial & Services | Procedure - Change Management 9 | P a g e
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.
NSW DoE | IT Commercial & Services | Procedure - Change Management 10 | P a g e
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.
NSW DoE | IT Commercial & Services | Procedure - Change Management 11 | P a g e
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
NSW DoE | IT Commercial & Services | Procedure - Change Management 12 | P a g e
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.
NSW DoE | IT Commercial & Services | Procedure - Change Management 13 | P a g e
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.
NSW DoE | IT Commercial & Services | Procedure - Change Management 14 | P a g e
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.
NSW DoE | IT Commercial & Services | Procedure - Change Management 15 | P a g e
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
NSW DoE | IT Commercial & Services | Procedure - Change Management 16 | P a g e
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
NSW DoE | IT Commercial & Services | Procedure - Change Management 17 | P a g e
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.
NSW DoE | IT Commercial & Services | Procedure - Change Management 18 | P a g e
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.
NSW DoE | IT Commercial & Services | Procedure - Change Management 19 | P a g e
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
NSW DoE | IT Commercial & Services | Procedure - Change Management 20 | P a g e
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.
NSW DoE | IT Commercial & Services | Procedure - Change Management 21 | P a g e
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
NSW DoE | IT Commercial & Services | Procedure - Change Management 1 | P a g e
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
NSW DoE | IT Commercial & Services | Procedure - Change Management 2 | P a g e
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
NSW DoE | IT Commercial & Services | Procedure - Change Management 1 | P a g e
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