1

Change Management

Contents
Introduction ..................................................................................................................................................................2
Request for Change .......................................................................................................................................................2
Change Classification ....................................................................................................................................................2
Change Prioritization ....................................................................................................................................................3
Change Approval Process .............................................................................................................................................3
Change Authorities .......................................................................................................................................................4
1T Africa Steercom ................................................................................................................................................4
1T Solutions Board .................................................................................................................................................4
1T Change Advisory Board .....................................................................................................................................4
Local Authorization ................................................................................................................................................4
Change Advisory Board .................................................................................................................................................5

PIETER KRUGER / JUSTIN GROBLER 1

2

Introduction
The purpose of this document is to introduce, on a high level, the concepts behind Change Management within the
OneTechnology department at PwC SMA. This document does not contain the policies and procedures associated with the
Change Management process. The policies and procedures for Change Management can be found in the 1T Policies and
Procedures database.

Change Management has two purposes: To limit change-related incidents by ensuring the integrity of the production
environment, and to improve the efficiency and effectiveness of day-to-day- operations. Change involve all four P’s of IT Service
Management, namely people, process, products and partners as seen in figure 1.

People

Partners Process

Products

Figure 1

Request for Change

A request for change is any formal communication seeking an alteration to one or more configuration items. This could take
several forms, such as a RFC document, a Service Desk call or even Project Initiation Document.

The interaction and interfaces between Service Requests and the Change Process must be clearly defined and team members
need to understand these differences. Consider the following:

 Typically, service requests pass through the Service Desk and are submitted by an end user.
 End-users do not log Change Records. A Service Request received from an end user may lead to the creation of a
Change Record in order to fulfill the Service Request
 A change must be recorded if that change could have a risk or an impact on the delivery of services to the business, or
if an audit trail is required.
 Certain types of Configuration Items can be specified to always follow a change process.
 Standard Changes are pre-authorized and may be triggered by the Request Fulfillment process, and directly recorded
and passed for action by the Service Desk.

In order to ensure that the correct process is followed at all times, an approved classification model and authorization model
for all types of Changes will be defined and followed.

Change Classification
PwC SMA 1T follows the practice of classifying three (3) types of changes. Each change will have a defined process and
associated change workflow. The 3 types of changes will cover IT Services and associated documentation, as well as
Infrastructure and related configuration items. The changes types are:

1. Standard Change: This is a change to a service or infrastructure for which the approach is pre-authorized by Change
Management, and has an accepted and established procedure with a known outcome. Typically these changes are
used for low-risk, pre-tested change operations. Critical elements of a standard change are:
a. There must be a defined trigger that will initiate the Request for Change (such as an SR)
b. Activities to effect the change are well known, proven and documented
c. Authority is provided in advance by Change Management, but final acceptance still needed by the Change
Manager.

PIETER KRUGER / JUSTIN GROBLER 2

3

d. The risk is low, and always understood

2. Normal Change: Refers to changes that must follow the complete change management process. It will proceed
through all steps of the change management process and will eventually be reviewed by the Change Advisory Board
(CAB). The CAB will provide advice and approval to the person deemed responsible for the change (Change Owner)
and the Change Manager. There are two types of normal changes:
a. Minor Change: These can be approved by a functional unit manager, service owner or budget holder, with
the Change Manager as final approver and does not need CAB approval. It is used for low risk, low impact
changes which are not classified as Standard Changes. Minor Changes may be tabled to the CAB for pre-
authorization to be classified as Standard Changes.
b. Major Change: These changes will be screened by the Change Manager and presented to the appropriate
Change Authority for approval. It is used for high risk and/or high impact changes, and has a mandatory
post-implementation review as the last step of the process.
3. Emergency Change: These changes are reserved for changes intended to repair an error in an IT service or related CI
that is negatively impacting the business to a high degree. Emergency Changes must be designed carefully and tested
where possible in order to understand the impact it may have on IT services. As a final step in the process, a
mandatory post-implementation review must be conducted. The number of emergency changes must be kept to a
minimum, and procedures must be devised to deal with them quickly without sacrificing management controls.

Change Prioritization
All Change Requests will be assigned an appropriate level of urgency that will have an effect on the implementation time for
the requested change. Regardless of the level of urgency, the change approval process will still be followed as prescribed in the
Change Management policy and the Change Advisory Board Standard Operating Procedures. This information can be found on
the 1T Policies and Procedures database.

The prioritization of changes cannot be used to implement changes immediately, but will instead be used to schedule the
changes accordingly in the Forward Schedule of Change (FSC), once approval is obtained from the appropriate authority. For
immediate changes to the environment in order to repair incidents that affects the delivery of services, the Emergency Change
process must be followed.

The levels of prioritization for change requests are:

a) High – The change must be scheduled for the first available timeslot in the Forward Schedule of Change (FSC) and
takes priority over Medium and Low changes for scheduling.
b) Medium – The change takes priority for scheduling in the FSC over Low priority changes, but is only scheduled after
all High priority changes are scheduled.
c) Low – The change will only be scheduled once all High and Medium priority changes have been scheduled in the
Forward Schedule of Change (FSC).

Change Approval Process

Formal authorization is obtained for each change from a change authority that may be a role (Change Manager), person (Line
Manager) or a group of people (CAB) and the levels of authorization should be judged by the type, size, or risk of the change.

The approval process to follow will be based on a voting system for changes that are not deemed high risk or has a high cost
associated with it. The voting system will add flexibility but maintain accountability and a clear audit trail within a defined rule
set for change implementation:

 Majority Voting: The change approval process is based on a voting system, where only the majority of change
approvers (for instance 75%) need to approve a change for this change to be implemented.
 Mandatory Voters: Certain voters can be marked mandatory for certain changes, and the approval will not be signed
off until the mandatory voter has cast his vote.
 Over-riding change approver: It will be possible for top-level approvers to override the lower level approvers in the
approval chain. However, this shifts the risk and responsibility to said approver and should only be considered in
extreme cases where executive decisions are required.

PIETER KRUGER / JUSTIN GROBLER 3

4

The culture of the organization will dictate to a large extend the manner in which changes are authorized. Hierarchical
structures will however impose many levels of change authorization, while flatter structures may allow a more streamlined
approach. In the current PwC 1T environment, a hierarchical structure exists and will be followed for change authorization.

The structure for change authority at PwC SMA 1T will be based on the following model:

Fig.1 PwC SMA 1T change authorization model

Change Authorities
Four types of change authorities exist within PwC SMA. These are:

1T Africa Steercom
Executives and / or Line of Service Leaders with authority to approve or reject proposed projects or other initiatives with
significant cost and/or risk and approved by the 1T Solution Board. The 1T Africa Steercom can veto a RFC approved by the 1T
Solutions Board.

1T Solutions Board
A group of Leaders from 1T management teams (IT Exco) within OneTechnology and represented by business through the
Business Relationship Managers. The purpose of the Solutions Board is to give initial approval and prioritization for new
projects and service implementations driven by Business Units across PwC SMA.

1T Change Advisory Board

Change Manager, 1T Exec and 1T Functional Unit Managers. All projects or other initiatives authorized by the other change
authorities are presented to the 1T CAB for final assessment and prioritization for release into the production environment. The
1T CAB will provide approval for pre-authorized changes, or Standard Changes, and will support the other change authorities by
scheduling approved requests. The 1T CAB does have the authority to request further review for RFCs should there be valid
concern on disruption to services or business users, if the integrity of the production environment is in question, or if deemed
further testing is required. The CAB may not veto changes approved by the 1T Solutions Board or 1T Africa Steercom.

Local Authorization
Local authorization can take place in the event where a Standard Change was logged for approval, or where Minor Changes are
requested. Standard Changes are pre-authorized by the CAB and requires approval from the Change Manager. Minor Changes
are low-risk, low impact changes that requires approval from Change Manager and a Line Manager, Service Owner or Budget
Holder. Minor Changes do not require CAB approval.

PIETER KRUGER / JUSTIN GROBLER 4

5

Change Advisory Board

The CAB is a body that exists to support the authorization of changes and to assist Change Management in the assessment and
prioritization of changes. As and when a CAB is convened, members should be chosen who are capable of ensuring that all
changes within scope of the CAB are adequately assessed from both a business and a technical viewpoint. To achieve this, the
CAB needs to include people with a clear understanding across the whole range of stakeholders needs.

The change manager will normally chair the CAB, and members may (by invitation) include:

 Customers (the business or business representation)

 IT Management (Functional Unit Managers, Line Managers, Department Managers)
 Application Developers
 Technical experts
 Services and Operations Staff (Service Desk, ITSC, Security)
 Contractors or third parties

It is important to emphasize the following:

 The CAB meeting will be composed according to changes being considered

 It may vary considerable in make-up, even during the course of a single meeting
 Must reflect both user’s and IT service provider’s views
 It may include the problem manager, as well as the service level manager

When the need for an emergency change arises, there may not be time to convene the full CAB in which instance it will be
necessary to identify a smaller organization with authority to make emergency decisions. This body is known as the Emergency
CAB. Change procedures should specify the composition of both the CAB and the ECAB determined in each instance, based on
the criteria listed above.

CAB meetings will be held regularly as determined by the requirement for the introduction of changes into the environment.
Where CAB meetings are held, a standard agenda will be used and should include the following discussion points:

 Failed Changes, Unauthorized Change, Backed-out changes

 RFC’s to be assessed by the CAB
 Scheduling of changes and the update of the Forward Schedule of Changes as well as the Planned System Outage
documents
 Change implementation reviews
 Change Management process review, including any amendments made or proposed amendments
 Change Management wins and accomplishments
 Outstanding Changes and Changes in progress

Note that the CAB is an advisory board only. If the CAB cannot agree on a recommendation, the final decision on whether to
authorize changes is the responsibility of management (IT management, IT Steercom, Directors etc.).

PIETER KRUGER / JUSTIN GROBLER 5