Guidelines: Information Technology Change Management

Overview

All change requests must be managed according to the principles illustrated in this flowchart diagram. In the illustration below, the IT Change Management process is broken up into 3 phases namely:

• Request Phase
• Classification, Review and Approval Phase
• Implementation Phase.

 

In the subsequent sections of the guidelines, each phase mentioned above is broken down in smaller groups of work.

 

Phase 1: Request for a Change to an IT System

Step 1: Identification of the need for a formal change request

A new change request can be initiated by any user. The need for an IT change can be the result of an IT incident or problem, a new system release, or a specific request, including, for example:

• Commissioning or decommissioning an IT system or service.
• Modifying a system configuration that requires IT involvement.
• Developing, coding, scripting, or programming a system or application.
• Patching and updating system firmware, operating system or software.
• Making bulk changes to systems and data in production, outside of standard business operations or application functionality processes.
• Modifying security group, roles and privileges. Modifying the security configuration of IT systems, applications and networks.

IT change requests must be first processed by the Help Desk, a representative from IT or the Global Director, Communications & Partnerships, who will confirm the need to submit a formal request or identify alternative options where appropriate.

 

Step 2: Change Documentation

The change request must be documented in the request tracking system, and the change management fields must be filled in. The requested change must:

• Identify the change requestor, change reviewers, change resources, change manager, and change approvers.
• Contain sufficient details to facilitate a clear assessment of the risk and demonstrate sufficient planning.
• Be communicated to the appropriate stakeholders for validation and assessment and be approved through the tracking system before implementation.

The change manager is responsible for ensuring that:

• The initial classification of the change request is accurate.
• All required documentation is recorded (Refer to Phase 2, step 1.).
• All required approvals are in place (Refer to Phase 2, Step 3) before starting or implementing the change.
• Status updates, such as approval and completion status, are maintained throughout the life cycle of the change (from creation to completion, or cancellation).

 

Phase 2: Classification, Review and Approval of a new Change Request

Step 1: Classify the type of change.

There are 4 types of Change Request. They are described in detail in the table below. For each Change Type, there are associated documentations that needs to be compiled and submitted. This process enables proper tracking of changes and facilitates the implementation of a back-out plan should a Change Request result in further issues or complications.

Change Type	Criteria	Supporting Document
Emergency Change	A change that requires immediate implementation to correct an important issue, such as a disruption or outage of service. Examples of emergency changes include (but not limited to) repairing an IT service issue that severely impacts the business, or a situation that requires immediate action to either restore a service or prevent an outage. An emergency change requires: Sufficient review and discussion with all impacted and involved parties, including business users, the IT Manager of the team performing the change, and members of the ECAB. Approval by the ECAB prior to implementation. Testing may be reduced, or not performed altogether if necessary, and may be performed after implementation. Submission of a formally documented change request within one business day after the issue has been resolved. Post-implementation review. Presentation and discussion at the next CAB meeting.	Documentation can be provided after the change has been implemented.   Documentation must include: Completed Change Request form ECAB approval Post-implementation review report.
Major Change	A change that is high risk and complex, with a significant potential impact to production services, and limited backup/recovery in the event of an issue.   A major change requires: Formal review and discussion with all impacted and involved parties, including business users, the IT Manager of the team performing the change. Formal testing. Formal review and approval by the CAB prior to implementation. Formal post-implementation review.	Change Request Risk assessment Design/Solution documentation Implementation plan Test plan Test results Back-out plan Outage notification CAB approval Post-implementation review
Minor Change	A change that is low risk and well understood, with a limited potential impact to production services, is sufficiently tested prior to implementation and is easy to back-out in the event of an issue. A minor change requires review and approval by the manager of the team performing the change.	Change Request Risk assessment Back-out plan Remediation plan or approach Approval by manager
Normal Change	A change that is low risk and relatively common, where the implementation follows a simple documented procedure or work instruction. For example, password reset or provision of standard equipment to users. A standard change follows a formal procedure or work instruction that has been authorised in advance.	Standard Change Procedure Authorisation

 

Step 2: Change Review & Analysis of Risk(s)

Business value(s), business risk(s), technical risk(s), and cost risk(s) must be assessed as part of a formal review of new change requests, by stakeholders from the WSB and IT. Examples of business value & risks, technical risks and cost risks is provided below.

Business value and risk includes the following:

• Value to WSB’s operations and alignment with business objectives and requirements.
• Potential impact and risk to WSB’s operations if the change is implemented.
• Potential impact and risk to WSB’s operations if the change is not implemented.
• Timing of the change to minimise impact to operations.
• Acceptance and adaptation by affected parties and users.
• Potential security risks introduced by the change.

Technical risk includes the following:

• Complexity of the change.
• Complexity of the system or infrastructure affected by the change.
• Interdependencies between different system components and IT services.
• Impact on normal IT operations, including: system usage, disaster recovery plans, back-up and storage, hardware and software, and change to operational procedures.
• Technical feasibility of the change and level of effort for IT and the Institution.
• Availability of resources with required technical expertise.

Cost elements include the following:

• Costs associated with not implementing the change, such as penalties due to non-compliance or loss following a disruption of the current systems or services. If possible, potential return on investment (ROI) should be estimated.
• Total Cost of Ownership (TCO), including one-time purchases (software, hardware and professional services) and ongoing maintenance costs.
• People costs (hourly rate, overtime, travel expenses, etc.)
• External costs (consulting services, third party outsourced services)
• Training costs.
• Communication costs

Information Technology must ensure that that major changes are communicated to the appropriate stakeholders to review the criteria listed above. This includes, at minimum the:

• Change Requestor’s manager.
• Impacted IT team, where applicable.
• IT Manager of the team that will implement the change.
• Global Director, Communications or its representative.

The Change Requestor must provide sufficient information to analyse the change request prior to submitting the change request for approval. When the Change Approver reviews a change request, they either:

• Approve or deny the proposed change (standard / minor changes).
• Bring change request forward to the CAB (major changes)
• Convene the ECAB to review the change request (emergency changes).
• Request additional information by sending the change request back to the Change Manager for further investigation and analysis.

 

Step 3: Change Request Approval

Major and Emergency change requests must be formally approved by the CAB or the ECAB, respectively. Change Advisory Board makes decision about Major Changes and meets regularly, as required. Emergency Change Advisory Board makes decisions about high-impact Emergency Changes and meets upon request by the Global Director, Communications.

 

Phase 3: Implementing the Change Request

In the implementation phase of a Change Request, there are 4 steps beginning with testing. This sections details the 4 steps in a concise manner.

Step 1: Testing

All changes must be tested, when possible, prior to implementation in production. Tests of changes must be performed in a non-production environment, where possible. A test plan must be formally documented, where possible, and approved by IT and the relevant WSB stakeholders:

• The test plan must identify the specific test scenarios or scripts that are to be executed, what types of testing are required (unit testing, integration testing, user acceptance testing, etc.) and the way in which success or failure will be determined for each test.
• At a minimum, the test plan must include testing activities to verify that the change has the desired impact and that there has been no adverse impact to service stability. Additional testing may be appropriate for complex or risky changes.
• Test results must be documented in the tracking system.

 

Step 2: Change Request Implementation

Changes must only be released in production only when test results are accepted by the WSB, IT and the stakeholders. All tests points have sufficiently passed. Any failed tests must have a clearly established remediation plan or represent an acceptable level of risk that has been accepted by the Change Approver.

 

Step 3: Post Implementation Review

A post-implementation review must be performed by stakeholders to confirm the change is complete or to identify remaining issues. The status of the change must be updated based on the results of the post-implementation review.

 

Step 4: Regular Review of Change Request Status

The status of incomplete change requests must be regularly reviewed in CAB meetings, until the change is either dismissed or fully implemented. An annual review of open change requests must be performed by the IT Change Manager to identify and follow-up on old RFCs that have not been closed.

 

Roles & Responsibilities

In this section, a table is provided highlighting the key responsibilities for the different roles in a Change Request process.

Stakeholder	Responsibilities
Change Advisory Board (CAB)	Review change requests, including their potential impacts and level of risk. Provide formal approval to implement change requests. Review change progress with respect to the approved schedule and participate in Post Implementation Reviews. Provide recommendations regarding the implementation of changes into production, prioritize change requests, and make decision if any conflict occurs. Provide recommendations to improve or update this Policy.
Emergency Change Advisory Board (ECAB)	Meet upon the request of the Global Director, C&P. Review urgent change requests and: Confirm the level of urgency. Evaluate the potential impacts and risks. Formally authorise the implementation of emergency changes where appropriate. Ask for additional information where needed. Make any other decisions to address issues and concerns.
Change Approver	Review new IT change requests when they are submitted. Review the status of existing change requests. Chair the CAB meetings, including presentation of the status of all change requests (new, pending, issues, completed) and formal documentation of CAB meeting minutes or decisions. Ensure change requests are; Following the present Policy Fully documented with all necessary details; Communicated to the appropriate stakeholders for comment, before presented to the CAB for approval; Presented to the CAB for approval (or the emergency CAB where applicable); Addressed in a timely manner by the Change Implementer after CAB approval. Communicate with the Change Requestor and the Business to confirm specific aspects of the requests, as well as scheduling. Participate in the remediation of any problem, issue, incident and conflict resulting from a change by escalating to the right stakeholder or CAB meeting. Provide recommendations regarding the implementation of changes into production, prioritize change requests, and make decision if any conflict occurs. Provide recommendations to improve or update this Policy.
Global Director, Communications	Chair the CAB meetings, including presentation of the status of all change requests (new, pending, issues, completed) and formal documentation of CAB meeting minutes or decisions. Provide recommendations to improve or update this Policy
Change Manager	Verify the appropriate classification of the change and evaluation of the risks. Prepare the implementation of the change request, including some elements of analysis, work scheduling, design, build, test, and roll-back / back-out activities. Test changes and report any issue or negative impact. Implement successfully tested and approved changes into production. Update system documentation. Report to the Change Approver on the status of all changes assigned to her/him. Communicate with the Change Approver, the Change Requestor and any related key stakeholders to better understand the request for change, report errors, issues, or delay in testing or implementing the change. Escalate problems and incidents resulting from deploying changes. Participate in post-implementation reviews as required by the Change Manager
Change Requestor	Initiates a Request for Change (RFC) with the required details. Answer all additional information required by the Change Reviewer, the Change Manager, IT stakeholders, or the CAB. Communicate with business stakeholders to ensure business requirements are met. Participate in acceptance testing and post implementation reviews as required.
Change Reviewer	Assist the Change Manager by performing an initial review of the proposed change requests as required, based on the technical aspects of the change before the change is submitted for Approval.
IT Helpdesk	Respond to any user requesting an IT Change Verify the nature of the request and confirm if a formal change request is necessary. Identify the change classification and immediately inform the Change Manager or Incident Manager where necessary. Enter detailed information in the tracking system, including the name of the Change Requestor and description of the change. Update the status of the change as required.
Line Managers / Supervisors / Department Heads	Review any problem, issue or need from users that would require a new change request. Approve new change requests initiated from users. Communicate with the IT group to submit a new change request.
Users	Contact the Help Desk for any questions or concerns related to the technology. When a question or concern cannot be addressed by the Help Desk, contact their supervisor or representative. Contact their supervisor or manager for any request to change the existing technology.