Home > Policies > Policy & Procedure
Change Management Policy
Name of Policy
Change Management Policy
Policy Number
Information Technology
Original Policy Date
Last Revised Date
Other Related Regulatory Rules Laws & Policies Next Scheduled review Date
Associated Procedures & Forms (Attachments)
Cycle of Reviews


·       The goal of Change Management at Prince Mohammad University is to ensure that standardized ITIL (IT Infrastructure Library) methods and procedures are used for efficient and prompt handling of all Changes to the IT systems; thus minimizing any undue disruption to IT services delivered to the University.

Change Management also aims to provide the ITD the ability to rapidly adapt as University’s requirements change and increase their ability to ensure a customer focused operation is maintained. To ensure that a comprehensive business and technical risk assessment is made for all changes, allows for open communication between key stakeholder and coordination of resources required for successful implementation.


·       Prince Mohammad University relies upon IT services in order to perform its roles of teaching and administration. The inter-dependencies of these systems are complex and the results of change made to any system may have serious consequences. The uncontrolled implementation of changes to University’s IT systems, critical systems and underlying infrastructure utilized to perform its core roles presents a significant risk to the University.

Changing system requirements, resolution of known issues, implementation of new services and routine maintenance all require appropriate Change Management. Change management ensures the stability of systems by the identification and mitigation of associated implementation risks, minimization of disruption to Prince Mohammad University's operations caused by system outages, and improves service and service levels provided to the University.

The Change Management policy is based on the industry best-practice standards of ITIL – the IT Infrastructure Library.

ThisoutlinestheITD its roles and

Procedure :

·       Definitions

PMU: Prince Mohammad University

ITD:Information Technology Department

ITIS:IT Infrastructure Services

Changeis the process of developing a planned and documented approach to change in an organization. In the ITIL framework, Change Management is responsible for controlling change to all configuration items within the live environment, test and training environments, and all environments under the control of ITD operations. It is not typically responsible for change within development projects where change requests are managed by the Project Manager.

CAB: The Change Advisory Board. As can be inferred from the name, this body has no governance role, but is tasked with advising the Change Manager and Service Owner of the perceived impact of a requested change. This body is made up of a core group with representation from all major systems and the core Services teams, and incorporates required stakeholders depending on the nature of the Request for Change being assessed.

ITIL:The IT Infrastructure Library is a collection of internationally recognized best-practices for delivering IT Services, covering all aspects of service provision, quality assurance, and providing a framework which allows customization of internal processes. It was developed within the British Public sector and has since been revised with commercial input to become the world standard for IT Service Management.

RFC: Request for Change – an electronic form which initiates the Change Management process.

CM a board

Meeting and will be responsible to select the Change advisory board members per the nature of the RFC. CM is also responsible for scheduling and publishing approved changes.

Service Owner: is a person or department responsible to provide the service for the business.


Change Management Process Development

Guidance from ITIL

The Change Process at the Prince Mohammad University has been based extensively upon the guidance of the British Government "Information Technology Infrastructure Library" textbooks (ITIL). Wherever possible, this guidance has been followed closely, most notably in the use of the ITIL terminology.


The ITIL texts provide comprehensive guidance as to industry best-practice in this area, and have been widely adopted as standards to ensure IT infrastructure stability and resilience.

ITIL forms the basis of the British Standard BS15000 and International Organization for Standardization ISO20000.


Process Development

The Change Management Process was developed within the ITD and implementation will be staged. The benefit of this approach is to work on the process iteratively, allowing various approached to be trialed before formal adoption


Process Improvement


The Change Management Process will undergo continuous improvement. The primary source of improvements will be the review phase of the process, wherein

the Change Advisory Board members analyze and identify process improvements which will enhance success or increase the efficiency of the process.

Constructive feedback is welcomed, and suggestions for improvement will be incorporated wherever value is added.

Change Management Process Notes

Change Process Scope

Currently the scope of this process is limited to ensure a successful staged implementation. All changes to centrally manage IT infrastructure and Systems must follow the PMU Change Management Process.


This scope is further limited to changes for which an outage or noticeable change is visible for clients. This ensures the process is not swamped by minor operational changes, and reduces the bureaucratic overhead of the process.


Integration with the (Purchase Department) Approval Process



Where Purchase Department approval is required for IT equipment or software purchases, an assessment of the impact of the purchase should be sought through the PMU Change Management process. The appropriate place for this integration is prior to distribution of Request for Proposal made by Director of IT


In some instances, assessment may be requested to provide information for inclusion as part of the development of the business case.


Change Type

The type of the changes which follow the Change Process varies. The following categories have defined:


●     Pre-approved

●     Minor

●     Medium

●     Major

●     Urgent

●     Emergency

●     Installation

●     Evaluation

The type of the Request for Change (RFC) affects the timeline of the request, determines the notifications which must be sent, and the review and closure process to follow.


Pre-Approved Changes

Many changes do not require authorization, and do not need to pass through the formal process. Those changes should still be logged in the normal manner; however they will proceed to the scheduling phase immediately.


This is essential to ensure appropriate change scheduling, and the minimization of impact arising from change conflicts. It also provides and audit trail of improvement made to systems and services. In Change advisory board review phases the minor or medium changes done frequently can be categorized as Pre-Approved Change.


Minor or Medium Changes



Minor or medium changes follow the standard change process and may affect relatively few clients or cause minimal impact; however they do require proper notification of selected groups of staff or students.


Major Changes

Major changes are designated as such because the affect, or have the potential to affect, large numbers of clients, or will involve lengthy outages of critical systems.


Major changes will typically involve notification of all staff or students and may require authorization by Senior University Management (IT supervisory committee, Communication meeting)


Urgent Changes

Urgent changes are designated as those which are not able to follow the standard change implementation timeline. These may occur due to external factor such as consultant availability or external project critical timelines, possible

hardware failure, or simply due to scheduling issue necessitating implementation in conjunction with other previously scheduled changes.


As these changes fall outside the normal change window, a special meeting of the Change advisory board may be held, or consultation prior to approval may be made by email.


All urgent changes will be reviewed by the Change advisory board post- implementation. This will ensure that appropriate measures are taken to reduce or eliminate the requirement for such urgency.


Emergency Changes

Changes may be designated at the time of recording as 'Emergency' changes. These changes will not be required to follow the standard Change Management Process, but instead are automatically approved and proceed directly to implementation. Emergency changes naturally take schedule precedence from all other changes.


All emergency changes are reviewed by the Change advisory board, following implementation.



All new systems to be commissioned within the IT managed server facilities must be submitted as an RFC. This allows the Change advisory board to assess the request for business and technical risk and ensure appropriate resources are allocated. It also automates the creation of appropriate work requests to ensure all standard tasks for preparation take place.



The process for the evaluation of a new item of equipment or software prior to its sale or support is important in order to ensure support criteria are met. The inclusion of a change type for the evaluation of new equipment etc reflects this importance, although it constitutes a variation on the standard process.


Request for evaluation are circulated to a number of key areas of ITD, to ensure appropriate checks take place prior to introduction.

The Change Advisory Board



The Change Advisory Board (CAB) is the body responsible for the assessment of changes to determine their risks and impact, and authorization of RFC implementation or otherwise.


Given the complexity of computing environment a Change advisory board has to be developed which has the depth to ensure accurate assessment and identification of risk and impact, both from a business view point, and technical and support issues. The method chosen in this instance has been to establish a "core" Change advisory board of relevant staff from the IT infrastructure services and mission critical MIS system, which will almost always be involved in change assessment, and then bring other appropriate stakeholders into the assessment when required.


The members of the core Change advisory board:

●     Change Manager

●     Manager - Infrastructure Core Technologies

●     Manager – Management of Information Systems

●     Manager – Academic Computing Services

●     Business Representative


In essence the Change Advisory Board has a dynamic membership so we do not waste the time of those that particular changes do not impact upon. This follows the industry best-practice guidance provided by ITIL.


Additional Change Advisory Board members relevant to each change are added to the group based on the services affected by a particular RFC. In particular this includes the service owners of all affected services. A further list of stakeholder for inclusion in the assessment includes representation from all service units and academic colleges and is built in consultation with those units. It may include a technical support of management staff with vested interest in the service


This stakeholder will be given the opportunity to submit an assessment of relevant changes, however they will not be required to attend the regular Change Advisory Board meetings, although they are welcome to do so.


Change Advisory Board Responsibilities


●     The responsibilities of the Change Advisory Board members are:

●     Identification of business , technical and support risks associated with the implementation of the RFC

●     Identification of the direct or indirect costs and resource requirements

●     Identification of impact on any other University services

●     Identification of impact on PMU operations not directly associated with the change

●     Circulation of assessment and collation of responses from team members

●     Timely response to requests for assessments

●     Assisting the Change Manager with authorization of RFCs


Change Advisory Board Meetings


The Change Advisory Board will meet weekly to perform authorization, review and closure of RFCs. The Change Manager is responsible for scheduling and rescheduling the meeting.


Time frame

As the Change Advisory Board meets weekly, impact on timeframe for implementation should be minimal, given appropriate planning prior to RFC initiation.



The Change Advisory Board meeting will be chaired by the Change Manager, and will follow a standard agenda.



Discuss RFCs in assessment phase Approve or Reject RFCs



Schedule changes

Ensure ITS Change Calendar is updated



Ensure all RFCs include proper notification Emergency and Urgent RFC Review



Close all outstanding completed RFCs



Review failed changes

Improve the IT Change Management Process


The agenda of RFCs for assessment will be circulated to Change Advisory Board members and notified via email prior to each meeting.


Urgent Meetings

An ad-hoc urgent Change Advisory Board meeting may be called as and when required for urgent changes. This may be conducted via email if required.



For IT infrastructure changes, a quorum of four Change Advisory Board members must be present in order to authorize any RFC. In the absence of sufficient Change Advisory Board members, all changes may be deferred until a time a quorum can be obtained or referred to Service Owner and Director of IT to authorize.



For an RFC to be authorized, it must be approved unanimously by the Change Advisory Board, having taken into account the assessments submitted. Should a unanimous decision be unachievable, the RFC will be referred to Service Owner, IT Director for a final decision.



An essential element of the Change Management Process is the requirement to ensure the IT supervisory Committee and Senior Management are well informed about all Changes relating to mission critical systems, especially those for which they have delegated accountability.

The Department heads and Service Owner identified for each MIS system are to be included in automated reporting. The Forward Schedule of Changes will also be circulated to ITD Management and Senior Administrators monthly.


Process Overview

Initiation / Recording

Due to the variety of the changes that may be required, specific Request for Change forms is designed to suit the type of change. They are as follows (see Appendix A for templates):


The proper recording of changes is essential to this process. All changes must be submitted either electronically or by tools approved by PMU.


RFCs must be filled out in full and include the following information:


The person requesting the change should fill in their user id. All communication with the initiator will then be made by email

Service Affected

To identify the Owner and stakeholders of the service which are to be consulted and given the opportunity to take part in the RFC assessment.

Requested Date

This indicates the data and time on which the initiator wishes to implement the change. Both date and time are required to assess the impact of outages.

Critical Date

In most cases the requested date will become the implementation date. The exception to this is when the request conflict with higher priority change already in the system, or when another critical date is indicated by the assessment. The critical date should be the date by which this change must be implemented. It will be used to resolve scheduling conflicts only

Change Description

Describe the requested change in detail, providing as much information as required for other staff to understand and make an appropriate assessment. This change description should include details of the implementation plan, if appropriate.

Reason for Change

Why is this change being requested? Is It to fix a known problem?


       If so provide the provide the problem number.



Who will this Change effect?

The RFC initiator should provide their assessment of the impact of this change.

Which clients will be affected? Will other services be affected?

Which staff will be required for the implementation?

The Change Advisory Board will ensure appropriate representatives from this list provided are advised of the change and allowed an opportunity to provide their assessment.

Length of an outage

If there is to be an outage associated with this Change, please indicate the length. Approximation should be accompanied with some explanation.

Back out plan

If the change implementation fails, what plans have been made to reverse the change? These plans should be comprehensive, as in the case of a failed change, they will be reviewed by the Change Advisory Board to identify area for improvement.

Change Type

Indication of the type of RFC:

Pre-Approved , Minor , Medium , Major , Urgent or Emergency

Notification Text

What message should be sent to the clients?




It is essential that indicated fields are filled in, and the system/CM will not save the requests without identification of the initiator, change description, requested date and back-out plan.


The above filtering can be done at form level or by using tools approved by PMU. policy Filtering of RFC also takes place to ensure changes are not submitted to the process which are erroneous and frivolous or requested by unauthorized staff.


Initial errors in the completion of the RFC form must be quickly identified, as must any missing information. RFC record may be updated by the Change Manager, Change Advisory Board members, or the RFC initiator. All changes made will be logged to ensure proper audit trail.


Completed RFC form




Filtered and corrected RFC


Roles and responsibilities

Responsibility for filtering the RFC form and ensuring accurate information has been recorded lies with the Change Manager. In the absence of the Change Manager this responsibility lies with the members of the core Change Advisory Board.


Assessment is one of the key phases of the process. Request for change will be forwarded via email to the Change Advisory Board members for their assessment. The Change Advisory Board is responsible for assessing the RFC and providing their assessment of:


○        Business and technical risks associated wit the RFC

○        Impact on any other PMU Services

○        Impact on PMU operations not directly associated with the change

○        Direct or indirect Costs and resource requirement


Email notification will be sent to all core Change Advisory Board members , the Service Owner , and identified service stakeholders following successful RFC and collation of responses from other affected colleagues (where necessary). The notification of assessment can be forwarded to other staff members if required.

Change Advisory Board members have a responsibility to ensure they respond to requests for assessment in a timely manner. Should no response be submitted, it will be assumed that no impact is foreseen in their area and therefore they approve the RFC.

Requests for further Information

Change Advisory Board members may also use email to request more information from the initiator. The initiator may respond by email. Following response, the Change Advisory Board will be informed of both the question and the answer provided to assist with their assessment.

This will highlight areas of the RFC where clarification is required and may also result in revisions to components of the process itself.







Change Advisory Board assessment Assessed change for authorization


Roles and Responsibilities

The change Advisory Board members have a responsibility to assess all RFCs to the best of their ability and knowledge.


Assessment should be provided within two working days of notification


Taking place in parallel with the assessment phase the RFC is categorized on a number of aspects.


The source of the change is categorized in order to identify whether the RFC is the result of a fix to a known problem, a new service, an installation, a patch or upgrade, or a client requested enhancement.


It is important that the service to be changed is identified, as this allows the identification of relevant stakeholders who would then be requested to take part in the assessment.


The impact of the change is the extent to which it affects PMU's operations, based roughly on the number of clients affected by the change, or the business critical nature of the services affected.


Urgency provides an indication of the extent to which delay of implementation can be tolerated


The combination of Impact and Urgency allows us to priorities RFCs appropriately; ensuring resources are targeted where they are most needed and eliminating scheduling conflicts.


The scale of the change gives the Change Advisory Board an indication as to the level of authorization required.

These categorizations are important to monitor the nature of changes, and to ensure efficiency of the process. They also contribute to the approval and scheduling phases of the process.


Following assessment by the Change Advisory Board, the RFC will proceed to authorization. All RFCs are authorized by the Change Advisory Board during the weekly meeting or by special arrangement if the RFC is designated urgent.

Authorization will be based upon the collected assessment made by the Change Advisory Board members , and will balance the expected benefits of

implementation with the business and technical risks identified, the urgency of the change and the predicted impact on clients or PMU operations.


All changes to centrally manage IT infrastructure will be authorized by the Change Advisory Board itself. In the case of RFCs which are for MIS systems, a recommendation for approval or rejection, and the Change Advisory Board assessments will be forwarded to the Service Owner or appropriate authority for formal sign-off. Those changes which will impact on several critical MIS systems will be referred to higher authorities depending on the scale of the change.


For an RFC to be authorized, it must be approved unanimously be the Change Advisory Board, having taken into account the assessments submitted. Should a unanimous decision be unachievable, the RFC will be referred to the Service Owner and Director of IT for a final decision.


Following the Change Advisory Board meeting the appropriate RFC will be updated, setting its status to Approved or Rejected, and specifying any points noted by the Change Advisory Board during the discussion.


Approval of the RFC will result in the notification of the Change Advisory Board members, the Service Owner, the Initiator, Director of IT


Rejection of the RFC will result in notification of the initiator with the reason for rejection.

No unauthorized RFCs will be implemented. The decision of the Change Advisory Board or Service Owner will be final. The RFC may be re-submitted provided that all the issues resulting in the rejection have been mitigated.



•  Change Advisory Board assessments

•  RFC



•  Recommendations for approval or rejection to the Service Owner.

•  Approval or rejection notification to the Initiator,

•  Notification to ITD Management

•  Notification to Service Owner

•  Notification to Change Advisory Board members




Proper scheduling is important to ensure change implementations do not conflict and cause undue impact on the PMU operations.


The IT change calendar should be published on the Intranet. This should be the definitive source of change schedule information, and is updated automatically directly from the Change process.


Changes requested for implementation within the same time period are rescheduled based on the impact and urgency of each change



Approved Changes Existing Change Schedule


Updated Change Schedule


Roles and responsibilities

Scheduling is the joint responsibility of the Initiator, the Service Owner and the Change Manager.


All notification to Clients should be broadcasted. This ensures consistency and reliability in notification process and content. This is especially important where outages may affect client operations, or where an outage to normal service is involved.


All notification will include reference to the appropriate RFC and links to the ITS change Calendar.


Notifications will only be sent following proper change authorization. No change notification to be sent by any other party.

All RFCs which are rescheduled must be notified to clients, firstly to inform them of the cancellation of the original change or outage window, and then to provide details for the updated schedule.




Scheduled Change Notification text via RFC



Notification to appropriate client groups


Roles and responsibility

Responsibility for notification lies with the IT help Desk / or the Change Manager. Implementation

●     From a change management point of view, the implementation of the change should follow the plans provided as part of the RFC.

●     Success or failure of the implementation must be promptly reported to the IT

●     Helpdesk, as must any known issues created by the implementation.

●     Following the scheduled date of implementation, an email message will be sent to the initiator requesting a status update.

●     On the requested implementation date, a problem record will be created and all incidents attributed to this implementation will be recorded efficiently which will provides raw data for change review phase.


Authorized and Scheduled RFC



Successful or failed change

Problem record with associated incident

Roles and responsibilities

The Initiator has responsibility for ensuring the implementation follows the suggested plan, and that back out plans are implemented if required. They are also responsible for ensuring appropriate staffs are available to assist with implementation, when and if required.



All changes which fall into the following categories are reviewed:


●     Failed Changes

●     Changes which exceeded the specified outage window

●     Emergency or urgent changes

●     Changes causing unexpected or unreasonable incident volumes


Changes falling into these categories will be passed to the Change Manager, who will ensure appropriate investigation take place, circulate a written report, and facilitate discussion to ensure any improvement to the process, or to the implementation can be identified and actions are taken to resolve.


All stakeholders and relevant Service Owners will be requested for information pertaining to the impact of RFC upon their operations, and will also receive a formal review report at the end of the process.


Implemented Changes



Review document to Change Advisory Board m Stakeholders and Service Owners

Process Improvements


Roles and responsibility

The Change Advisory Board members are responsible for appropriate review of changes and identification of improvements or additional safeguards to ensure future successful change implementation.


The formal process of RFC closure is the final step of the change Management process

The Change Advisory Board members will close all RFCs formally at the normal Change Advisory Board meeting, following any review or discussion required.



Completed RFCs


Closed RFCs



Roles and responsibilities

The Change Manager has the formal responsibility for RFC record closure.



The PMU change management process incorporates several key communication opportunities.


Change Calendar


The Change Calendar will be published via the web as publicly available information. It is updated dynamically upon each visit. This allows all interested parties to see those changes which have been authorized, are still to be assessed etc.


Forward Schedule of Changes

The Forward Schedule of Changes is circulated to the Director of IT and IT Supervisory Committee where appropriate. This keeps those bodies informed of all upcoming changes.

Management Reporting

An essential element of the Change Management Process is the requirement to ensure Service Heads are well informed about all Changes relating to mission critical systems, especially those for which they have delegated accountability.


Change Process Metrics

Each step of the process should have associated metrics which allow the process quality to be monitored, and improvements to be identified.

Example metrics include:

●     Time to assess

●     % failed changes

●     Number of assessments per RFC

●     Impact as per incidents recorded