What is a change control process? Steps and a change request template

Key terms

• Baseline: the approved scope, schedule and budget. Change control only makes sense once a baseline exists; before that, you are still planning.
• Change request: a formal proposal to alter the baseline. Anyone can raise one: the client, the team, a supplier or the sponsor.
• Impact assessment: the analysis of what the change does to cost, schedule, risk, quality and other work.
• Change authority: the person or board allowed to approve a change. Many projects set thresholds, for example the project manager approves changes under a set amount and the sponsor or a change control board approves anything larger.
• Change log: the register of every request and its outcome.
• Scope creep: changes that slip in without going through this process. Change control exists mainly to prevent it.

The change control process in seven steps

1. Raise. The requester fills in a change request: what, why, and what happens if the change is not made.
2. Log. The project manager gives it a number and adds it to the change log with status "Submitted". Nothing is lost in an email thread.
3. Screen. A quick check: is it really a change to the baseline, or a defect, a clarification or work already in scope? Reject or redirect early.
4. Assess impact. Estimate the effect on cost, schedule (including whether it touches the critical path), risk, quality and other projects. Offer options if there are any.
5. Decide. The right change authority approves, rejects or defers. The decision and its reason are recorded.
6. Update the plan. If approved, update the schedule, budget, scope documents and risk register, and save a new baseline if the change is significant.
7. Implement and close. Do the work, verify it, communicate it, and mark the request closed.

Change request template

Worked example: assessing one change

A warehouse fit-out has a baseline budget of $1,200,000 and $60,000 of unused contingency. The client asks for a second loading bay (CR-014).

• Cost. The estimate is $45,000. If it is funded from contingency, the remaining contingency is $60,000 − $45,000 = $15,000. If the client pays for it as extra scope, the budget becomes $1,200,000 + $45,000 = $1,245,000 and contingency stays at $60,000.
• Schedule. The new work adds 15 working days to the "external works" activity. That activity has 10 days of total float. The first 10 days are absorbed by float; the remaining 15 − 10 = 5 working days push the project finish date out.
• Risk. The extra excavation is near an existing drain, so a new risk goes into the register with an owner.

The decision is no longer "do we want a second bay?" but "do we want a second bay for $45,000 and a 5-day later finish?" That is the question change control exists to put on the table. If the 5-day slip is not acceptable, an option is to resequence the work so the bay is built in parallel, which the team assesses as a second option on the same request.

Setting approval levels

Approval levels decide who can say yes, so small changes move quickly and large ones get proper scrutiny. Set them in the project charter or management plan before the first request arrives. An example for a project of the size above:

Under these rules CR-014 ($45,000 and a 5-day slip) goes to the sponsor or board, even though it is a modest share of the budget. The amounts are illustrative: pick thresholds that match your budget and risk appetite.

Common mistakes

• Approving verbally. A "yes" in a corridor becomes a dispute later. If it is not in the change log, it did not happen.
• Assessing cost but not time. Many changes are cheap but sit on the critical path. Always check float.
• Ignoring small changes. Ten "small" changes add up. Log them all, even if the project manager approves them alone.
• One threshold for everything. Set approval levels by size so small changes move fast and large ones get proper scrutiny.
• Not updating the plan. An approved change that never reaches the schedule and budget makes every later report wrong.
• Using change control to say no. A process that rejects everything pushes people to work around it.

How to do this in Critova

Critova has change requests built in: anyone on the project can submit one, an approver approves or rejects it, and each request carries its budget and date impact, so the change log builds itself. Because the schedule uses the critical path method, you can test a change in the activity grid and see at once whether it eats float or moves the finish date, then save a new baseline once it is approved. The cost features show the effect on the budget and earned value, and the critical path guide explains how float decides whether a delay matters. You can export the change register to Excel for a board pack.