IT Organisations frequently make changes that are highly visible to their business Customers. The sources of changes are many and varied.

Responsibility for controlling changes often falls to developers or project teams who need to record what is changed for project management and audit purposes. In such cases, the services and operations areas of IT are expected to react to changes whenever necessary. The IT Organisation is usually driven by the business it supports, so the focus on changes is to implement them as quickly as possible.

This document outlines a process for managing the implementation of IT changes from a service management rather than a project perspective. The approach deliberately separates the management and control of the individual components of a change from the implementation scheduling and approval aspects. The scheduling and implementation approval of a change must be under full control of the Services Organisation who is ultimately accountable for meeting Service Level Agreements. The risks of making each change must be balanced by the business urgency and supported by verification and contingency plans.

The management and control of components of systems management, such as software and fix release levels, asset registration, updating configuration databases, maintenance of production schedules and procedures, is outside the scope of this process and remains the responsibility of developers, project teams, support and technical teams and various production control and operational teams.

Change control assumes that personnel in the various groups carry out their jobs in a professional manner, using appropriate skills, experience, guides and checklists as necessary.

Change control is the process of reviewing plans to ensure that changes are implemented as fault free as possible and with minimum disruption to production. It will ensure that adequate backout and contingency plans exist and that relevant communication and training is delivered to impacted parties.