In an operational environment, the purpose of the Change Management process is to achieve the successful introduction of changes to an IT system or environment. Success is measured as a balance of the timeliness and completeness of change implementation, the cost of implementation, and the minimization of disruption caused in the target system or environment. The process also ensures that appropriate details of changes to IT resources (assets, CIs) are recorded. Basically, a change is anything that alters the status of a configuration item (CI). This typically includes anything that adds to, deletes from, or modifies the IT environment. The definition of a change is the addition, modification or removal of approved, supported or baselined hardware, network, software, application, environment, system, desktop build or associated documentation. Change management would typically be composed of the raising and recording of changes, assessing the impact, cost, benefit and risk of proposed changes, developing business justification and obtaining approval, managing and coordinating change implementation, monitoring and reporting on implementation, reviewing and closing change requests.

ITIL defines the change management process as:
The goal of the change management process is to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes, in order to minimize the impact of change-related incidents upon service quality, and consequently improve the day-to-day operations of the organization.

ISO 20000 defines the objective of change management as:
To ensure all changes are assessed, approved, implemented and reviewed in a controlled manner. However when an organization introduces a change with a project or initiative, that change needs to be effectively managed on both the technical side and the people side. A technical side focus ensures that the change is developed, designed and delivered effectively. The discipline of project management provides the structure, processes and tools to make this happen. A people side focus ensures that the change is embraced, adopted and utilized by the employees who have to do their jobs differently as a result of the project. The discipline of change management provides the structure, processes and tools to make this happen. Project management and change management both aim to increase the likelihood that projects or initiatives deliver the intended results and outcomes. While each discipline can function independently, the most effective approach is to integrate change management and project management to create a unified approach to implementing change on the technical front and people side front. This tutorial presents an overview of integrating change management and project management, including recent data on the effectiveness of integration.

In any project, change is inevitable whether it comes from within the project or from external sources, therefore it makes sense to have an agreed process in order to identify, assess and control any potential and approved changes to what was originally agreed for the project. What is needed is a systematic and common approach. Once the project plan and other key associated documents have been approved, these become the project "baselines" and can only be changed after approval by the appropriate authority, normally the Project Board (PRINCE2^® Project Management Methodology). Change control is not there to prevent changes, but to ensure that every change is agreed by the relevant authority before implementation.

An important and vital element is the projects use of configuration management (CM). Configuration management may be provided as a continuous organizational service or be provided by a Project Support Office (PSO) or a PMO (Program Management Office). Everything that the project produces is subject to configuration management; this includes management documentation as well as specialist products (Products delivered by the project) and deliverables. It is important therefore to integrate the use of change control procedures with the configuration management system used by the project. The system that is set-up to manage change should also include the management of the general issues. An Issue Register should be set up early in the project to capture and assist in the management of change and issues. A configuration management strategy document must be created as part of planning and this defines the way in which changes and issues are to be managed and handled throughout the project.

The difference between an issue and a risk is that the issue has already happened, whereas a risk is something that may or may not happen at some point in the future. Risk may be defined as a potential for loss or damage or destruction of an Asset as a result of one or more threats exploiting one or more vulnerabilities in the system. Whenever an issue is raised, it may be managed informally, usually by the project manager, however if it is to be managed formally then the project manager would enter it into the issue register before proceeding any further. The PRINCE2^® methodology states that an Issue Report is created in tandem and contains supplementary information regarding that particular issue.

Changes come in two flavors:
Request for Change (RFC) -This comes from the customer or user and is a request to change one of the project baselines in some way. If there are any extra costs involved in implementing the RFC, then the customer would normally pay for it. Since all RFC's are a change to what had been originally agreed, it is normally the Project Board alone will have the authority to agree to such changes.

Off Specification -These are normally raised from the supply side of the project, and detail some aspect that should be provided by the project, but currently is not, or is forecast not to be provided. This might include products or deliverables that are missing, or a product not meeting its specification or quality criteria.

At the beginning of a project it needs to be decided how changes and issues are to be prioritized, and it is usual that a ratings system might include terms such as Must Have, Should Have, Could Have, or Won't Have For Now (MoSCoW Technique). Such definitions need to be agreed. Another aspect that needs to be decided is whether or not the Project Board or senior management wanted to be involved in reviewing all project changes. If many changes are predicted then it may make sense for the Project Board to appoint a change authority who would make decisions on such changes on behalf of the Project Board. In such cases, the "rules of engagement" needs to be determined. For example, the change authority would only deal with low cost changes. Another aspect is setting up a change budget for the change authority to use to fund any approved changes and their implementation. Such additional budgets should be captured within the project plan before sign-off.

If the project is using 'Management By Exception' where tolerance boundaries have been set, then should any proposed implementation deviate beyond these tolerances, the Project Board must be involved in the decision whether to implement or not. During implementation, the project manager should ensure that its status is reported to the Project Board up to the point when the issue or change has been fully implemented.