Change request process: six steps and a one-page form

Every agency contract I have seen says something like “changes must be agreed in writing”. Very few agencies have a routine for doing that on a Tuesday afternoon when the client asks for one more field on the form. The clause exists. The process does not. So the developer adds the field.

A change request process is the routine. It needs to be quick enough that using it is easier than skipping it, and consistent enough that the client learns what to expect. The form below is the whole toolkit. The six steps after it are how to use it. For background on why unpriced changes do so much damage, see the scope creep pillar.

When a request needs the form

Three tests. A request is a change if it:

1. adds, removes, or alters a deliverable listed in the scope, or exceeds a stated limit (a ninth page template when the scope says eight)
2. falls under a listed exclusion
3. arises because an assumption in the scope turned out to be false

Everything else is ordinary project work: clarifying a requirement, fixing a defect, or choosing between two approaches that cost the same.

When you are unsure, raise it. A change request that concludes “this is in scope, no impact” takes five minutes and builds the habit. The reverse error is the expensive one.

The six steps

Step 1: log the request

The moment a request appears, in a meeting, a chat message, or a comment on a design file, write it down and give it a number. A spreadsheet with six columns is enough:

Then reply to the requester with a sentence that commits you to nothing except a response:

Noted. That is outside what we scoped, so I will send you a short change request by Thursday with the cost and any effect on the launch date.

Everyone on your team should be able to say that sentence. It is the only part of the process that needs to happen in real time.

Step 2: check it against the scope

Open the signed scope and find the line. This takes two minutes and has three possible results.

The request is in scope: do it and say so. The request is clearly outside: note the deliverable, exclusion, or assumption it conflicts with. Or the scope is ambiguous: in that case the ambiguity is usually yours to absorb, since you wrote the document. Do the work, and fix the wording in your master copy so the next project is clear.

This step only works if the scope has limits and exclusions to check against. If yours does not, the scope of work template shows how to write them.

Step 3: estimate the impact

Estimate the full cost of the change, including the parts that get forgotten:

• the work itself
• testing and review
• rework on anything already built or approved that the change touches
• project management time
• documentation and training updates

A worked example. The client wants a second payment provider added to a checkout.

At $150 an hour, 40 hours is $6,000. The team can fit 20 hours of change work a week alongside the planned scope, so the launch moves by two weeks, or ten business days. The build alone, at 16 hours, would have suggested $2,400. Quoting only the obvious part of a change is the most common pricing mistake in this process.

Also note any ongoing cost. A second provider means a second set of fees and a second integration to maintain. The form has a row for that.

Step 4: present options

Fill in the form and give the client a choice. For the example above:

Then recommend one. “We suggest C. Launching on time with one provider gets you revenue sooner, and you will know from real orders whether the second one is needed.”

Options change the tone of the whole exchange. One price reads as a demand. Four options read as advice, and the client stays in control of their budget. The swap is especially useful on a fixed budget, and I would offer it on every change request where something of comparable size is still unbuilt.

Step 5: get written approval

Send the form to the named project contact. Approval can be a signature or an email reply:

Approved, CR-03, option C.

Work starts when that arrives. Before that, the answer to “can you just get started while I get sign-off” is a friendly no:

We will have the team ready to start the morning the approval comes through.

The clause in your contract that backs this up should read something like:

We do not start work on a change until your project contact has approved the change request in writing. If a change request is declined or not answered, the original scope, fee, and timeline stand.

If an approval comes from someone other than the project contact, forward it to the contact and ask them to confirm. This catches the enthusiastic department head with no budget authority.

Put a validity date on every form. An estimate assumes the change is made at the project’s current stage. The same change approved three weeks later may land on work that has already been tested, and cost more.

Step 6: update the plan and the log

Record the decision in the log. Then update everything downstream: the task list, the timeline, the invoice schedule, and the team. A change that was approved and never added to the invoice schedule is a surprisingly common way to do the process perfectly and still not get paid.

Declined and deferred requests stay in the log. Deferred items become the first draft of your phase 2 proposal, which makes the log a sales document as well as a control.

Rules that keep the process alive

Use it for free changes. When you decide to absorb a small change, raise the form anyway, show the real value, and apply a 100% discount. The client sees the gift. The precedent that changes go through the form survives.

Turn requests around in two business days. A slow process gets bypassed. If the client waits a week for a price on a two-hour change, they will go straight to your developer next time.

Fill in the form yourself. The client describes what they want in a sentence. You do the paperwork. Asking a client to complete a form before you will consider their request makes the process feel like an obstacle.

Introduce it before you need it. Walk through a made-up change at the project kickoff, while there is nothing at stake. A process the client first meets when they are being told something costs extra will feel like a penalty.

Charge for heavy estimates. If pricing a change needs more than a couple of hours of investigation, say so and agree a fee for the investigation.

How the process differs by pricing model

On fixed fee work, the process protects your margin, and every step above applies as written.

On time and materials, the client pays for the hours either way, so the form protects their budget and your relationship. Use a lighter version: log the change, state the estimated hours and the effect on the forecast total, and get an acknowledgment. The comparison of fixed price and time and materials covers which model suits which kind of project.

On a retainer, a change request is the tool for work that exceeds the monthly allocation. State how many hours the request needs, how many remain this month, and whether the excess is billed as overage or moved to next month.

If changes are already out of hand

A change process introduced on day one is easy. Introducing one in week nine, after a dozen unpriced additions, takes a reset conversation first. The scripts for that are in how to handle scope creep. The rest of the documents that make this process enforceable are covered on the Scope hub.