Change control


Change control is the process through which all requests to change the baseline scope of a project, programme or portfolio are captured, evaluated and then approved, rejected or deferred.


In traditional development models where scope is well defined early in the life cycle, it is essential for success that changes to baselined scope are controlled. A rigorous change control process must be established and maintained on all projects, programmes and portfolios.

The process must allow all stakeholders to submit their suggestions for changes to scope and typically comprises five steps:

Request: The stakeholder who requests a change must provide relevant information on the nature of the change. The request is entered into a change register which records all requests and their status (e.g. pending, approved, rejected or deferred).

Review: The change request is reviewed to determine its high-level impact on outputs and benefits. If necessary, further clarification may be sought before deciding if it is worthwhile performing a detailed assessment. The proposed change may be rejected without further evaluation, in which case the reasons for rejection will be recorded and the stakeholder informed.

Assessment: All options relating to the change are captured and evaluated. The detailed impact on plans and schedules is estimated and a recommendation to approve, reject, defer, or request more information is made. Thresholds are set to determine whether the decision can be made by the P3 manager, sponsor or other members of the management team.

Decision: The decision is communicated to the team and stakeholders as outlined in the communication management plan and the configuration management plan.

Implementation: Relevant plans and schedules are updated if a change is approved and before the changes are made to existing products, or specifications for future products.

If an unauthorised or emergency change is identified, it should be retrospectively put through the change control process.

Change control is intrinsically linked to configuration management. Any changes need to be fed back into the configuration management system. In certain circumstances, it may be appropriate to have a change freeze where no further changes to scope will be considered. Where this has been agreed by the sponsor, it should be included as a key decision point in the configuration management plan.


Most change control happens at project level as this is where tangible products are delivered.

If the project has an agreed change budget, it may be in the control of the project manager who will make decisions about accepting or refusing change requests. If changes are major or cumulatively exceed the budget, then they may have to be escalated to the project sponsor for funding from the management reserve.

Change requests often take on a contractual significance where a project is being delivered by a contractor for a client. Contract terms will dictate a change control process that governs how the contractor will be paid for changes to the specification on which the original price was agreed.

In some industries, schedules of rates form the basis of pricing changes in advance of implementation. This eliminates the need to negotiate a price between contractor and client. Uncontrolled change in a contractual environment often leads to claims that may have to be settled in court.

Agile projects make change control an integral part of the development process. Each development iteration starts with a planning meeting that clarifies and prioritises the function addressed in the iteration. Some of these features may be changes to existing features but are considered alongside all the others.


Programmes are primarily concerned with changes that relate to benefits, either directly or indirectly through a change to a project’s output. The change control process at programme level will initially assess the impact of a change request on benefits and then assess the impact on the component projects. Significant change to a project may require a redistribution of resources or funds and may have a knock-on effect on other projects.

The programme management team may also be involved in project change requests that have an effect on other projects. The interrelationships between projects must be well mapped so that the impact of change requests that affect multiple projects can be assessed properly.


Major changes are escalated to the portfolio management team from projects and programmes. They will need to consider how any portfolio-level management reserve will be used to fund major changes.

The scale of a portfolio means that it is subject to changes in organisational strategy. This, in turn, might result from changes to the portfolio’s environment. Any changes at this level will need to be communicated down to the individual projects and programmes, together with an analysis to determine their impact.

Join APM

Sign up to the APM Newsletter.