Change control in projects: a plain-English checklist

Almost every project meets a request to change something after the plan has been agreed. A new feature, an earlier date, a different supplier. Change control is how a team deals with those requests without the project drifting. This checklist draws on guidance from the Association for Project Management (APM).

What is change control?

APM describes change control as the process in which all requests to change the approved baseline of a project, programme or portfolio are captured, evaluated and then approved, rejected or deferred. It is a subset of overall change management. In short, it gives everyone a clear route for asking for a change and a clear way of deciding what happens next.

Why does it matter?

An approved baseline is the agreed starting point for scope, time and cost. APM's guidance says changes to the baseline, or to success criteria, are progressed through change control. One APM article warns that uncontrolled changes to the project plan can cause chaos and confusion, and that unrestrained changes put the success of the project in jeopardy. In a programme or portfolio, APM adds, unmanaged change may be far-reaching.

The usual steps

APM's material sets out a similar sequence in each version. In the 8th edition list, the steps are:

1. Log the request in a change register.
2. Initial evaluation: is the request worth investigating further? The outcome is to reject or proceed.
3. Detailed evaluation: assess the impact on scope, quality, time, resources, costs, risks, benefits and stakeholders.
4. Recommendation: put a recommendation to the sponsor and/or wider governance board.
5. Update the plan if the change is approved.
6. Implement and monitor the change.

Who decides?

APM says the recommendation goes to the sponsor and/or the wider governance board, who approve, reject or defer it. An APM article from 2024 says that, at a minimum, the process includes a discussion between the project manager and the sponsor. Your own governance may name a particular board, but APM's pages do not require a specific one.

A checklist you can use

• Log every change request with a description, the date requested and who asked for it.
• Treat each request separately, so each change has a single, clear problem to solve.
• Prepare a short assessment covering advantages and disadvantages, the effect on budget and timeline, and the benefits or risks.
• Record the decision and the reasons, whether it is approved, rejected or deferred.
• If a request is rejected, explain why to the person who asked. If it is deferred, set a review date.
• Communicate approved changes to everyone involved and update the plans.
• Keep the change log up to date, so there is one place to see what changed and why.

When is formal change control needed?

APM says formal change control is required when tolerances are breached. Small adjustments within agreed limits may be handled by the project manager under the project's own rules, so it helps to agree early what counts as a formal change.

Try this on your next project

Before the project starts, agree three things: where change requests are logged, who evaluates them, and who decides. Write them on one page and share it with the team. When the first request arrives, you will already know the route.

Sources: APM, "What is change control?" (Body of Knowledge, 8th edition), "The basics of change control and its importance" (3 April 2024) and "How to control change in a project" (23 March 2015). Read on 12 November 2026.