A change request form that stops scope from drifting quietly

Scope rarely drifts because of a big request. Big requests get noticed, argued about and priced. Scope drifts because of a sentence at the end of a call: while you are in there, could you also. Nobody writes it down, nobody prices it, and six of those sentences later the schedule is two weeks out with no visible reason why.

A change request form exists to interrupt that sentence. Not to block it, and not to punish the person saying it, but to make the cost visible at the moment of asking rather than at the moment of missing the date. Everything about the form follows from that single job, including the parts worth leaving out.

The word appears in searches as formular, which is the German and Scandinavian word for form. The artefact is the same in every language: a short structured record of what is being asked, what it costs, and who agreed.

What the form is actually for

Three purposes, and it is worth being clear about which one applies, because they suggest different forms.

Pricing the ask. Someone wants something that was not in the agreed scope. The form captures enough detail for somebody to work out the effect on time, cost and other work. Without it, the estimate gets made in a hallway by whoever was asked, with no reference to what else is in flight.

Creating a record. Six months later, when the invoice is questioned or the date is disputed, there is a dated document showing what was requested by whom and approved by whom. This is the purpose that matters most in client work and the one most often skipped in internal work.

Making the trade explicit. The form is the place where "yes, and it moves the launch by four days" gets said. Requests are usually reasonable in isolation. They stop being reasonable when six of them are accepted without anyone stating the accumulated cost.

A form that serves the first purpose can be three fields. A form that serves all three needs about nine. Most downloadable templates carry twenty, which is why they get abandoned.

The fields worth keeping

Field	Filled in by	Why it is there
Request ID and date	Whoever receives it	Referring to it later without retelling it
Requester	The requester	Who to go back to with questions
Description of the change	The requester	What is wanted, in their words
Reason for the change	The requester	Distinguishes a need from a preference
Priority as the requester sees it	The requester	Prevents everything arriving as urgent by default
Affected deliverables	The assessor	What has to be touched
Effect on schedule	The assessor	Days, stated as a number
Effect on cost	The assessor	Money or effort, stated as a number
Alternatives considered	The assessor	Often there is a cheaper way to get the same outcome
Decision and date	The approver	Approve, reject, defer, or approve with a revised baseline
Approver name	The approver	A person, not a committee

The split between who fills in which half is the most important line on the form. Requesters describe and justify. Assessors price. Approvers decide. When one person does all three, which happens constantly in small teams, the form still works, but the sections should be filled in that order and in separate sittings. Pricing a change while still in the mood that produced the idea reliably produces a low estimate.

Two fields commonly found on templates can be dropped. A risk section duplicates the risk register and gets filled in with generic text. A long classification taxonomy, sorting changes into corrective, preventive, enhancement and defect, adds a decision that changes nothing about the outcome.

The impact assessment is the whole document

Everything else on the form is administration. The assessment is where the form either earns its keep or becomes a rubber stamp.

A usable assessment answers three questions with numbers, not adjectives.

How many days of work does this add? Not how hard it feels. Days, including testing and the review cycle that the change will need. The most common underestimate is not the build, it is the second round of feedback on the changed thing.

What does it displace? This is the question templates almost never ask. A team with no spare capacity cannot absorb a change without dropping or delaying something else. Naming what gets delayed converts an abstract cost into a specific one, and it is the sentence that most often causes a requester to withdraw the request themselves.

What does it depend on that is already finished? Changes that reopen completed work cost far more than their size suggests, because the completed thing has already been tested and signed off. A change to a page that is live is a different animal from a change to a page still in draft, even when the edit is identical.

Who should produce the assessment

The person who will do the work, reviewed by whoever holds the schedule. Estimates produced by the person who holds the schedule alone are optimistic, because that person wants the date to hold. Estimates produced by the person doing the work alone miss the knock-on effects on other people's work. Both signatures on the number is a small amount of process that prevents a large amount of argument later.

Four outcomes, not two

Approve and reject are the obvious ones. Two more are needed, and their absence is why forms get treated as a formality.

Defer. The change is reasonable, it is not urgent, and the current phase is nearly done. It goes into a list for the next phase with a date for reconsideration. This outcome resolves a large share of requests without a fight, and it requires that the list actually exists and gets looked at. A deferral to a list nobody reads is a rejection delivered dishonestly.

Approve with a revised baseline. The change is accepted and the date or the budget formally moves. This is the outcome that most teams avoid, and avoiding it is what turns a series of approved changes into a missed deadline nobody can account for. Approving the work without approving the consequence is the single most expensive habit in change control.

A plain approve, without any change to the plan, should be reserved for changes small enough to fit in genuine slack. If every approval is that kind, the estimates are wrong.

Routing by size, so the form does not become a tax

A single process for all changes fails at both ends. Small changes go around the process because it is disproportionate. Large changes get waved through by whoever was nearest.

Thresholds fix this, and they can be crude.

Below a couple of hours of work, no form. The person doing the work decides and mentions it. Trying to formalise below this level is how teams end up with a process that everybody agrees to ignore.

Between a couple of hours and a few days, the short form and one named approver. Most changes live here. The approver should be a single person with authority, and the turnaround should be stated, because a form that sits for a week trains everyone to bypass it.

Above a few days, or anything touching the delivery date, the full assessment and whoever owns the contract or the budget. This is where a revised baseline usually belongs.

Setting the thresholds in actual numbers for the specific project, and writing them where the team can see them, does more for scope control than any template. The numbers matter less than the fact that they exist.

Log the rejections too

There is a temptation to only record what was approved, since that is what has to be built. Recording rejections and deferrals costs one line each and pays back twice.

The first payback is the repeat request. Things that were declined come back, sometimes from a different person, sometimes from the same person who has forgotten. A dated record of the reason turns a second argument into a thirty second answer.

The second is the pattern. Twenty rejections over a project, read together, usually say something specific about where the original scope was wrong. If the same category of request keeps arriving, the requirement was misunderstood at the start, and that is worth knowing before the next project is scoped rather than after. Forms that exist only as approved paperwork throw that information away.

Where the form should live

A form is a document, and documents drift away from the work. Three arrangements, in ascending order of how well they hold up.

A file, filled in and emailed. Works for the record keeping purpose and fails for everything else, because the request and the resulting task never meet. Approved changes get forgotten because the approval is in an inbox.

A web form feeding a spreadsheet. Better, in that requests are collected in one place and can be counted. Still leaves a manual step to turn an approved request into work, and that step is where things get lost.

The request as a card on the board the team already uses, moving through columns for received, assessed, decided and done. The assessment lives in the card. The approval is a comment with a date. When the change is approved, the card becomes work or spawns the tasks that deliver it, with the history attached. Nothing has to be copied anywhere, which is the only reliable way to keep a record complete. Tools that carry board, timeline and discussion in one place make this a single lane rather than a separate system, which is worth confirming on the Features page before adding another product.

The board arrangement has a side effect worth having. A column of requests, visible to everyone including the client, is itself an argument. Nobody needs to be told that scope is drifting when eleven cards are sitting in the assessed column. Comparing how candidate tools handle this, on pages such as All comparisons, is more useful than comparing their form builders.

Internal changes need the form more, not less

Client change requests usually get some process because money is involved. Changes requested by the team itself, or by another department, routinely get none. That asymmetry is backwards.

Internal changes have no invoice to make them visible, so their cost shows up only as a missed date. The founder who asks for one more field on the signup form, the designer who wants to redo a screen that is already built, the developer who wants to refactor before shipping: all reasonable, all uncosted, and collectively responsible for more slip than client requests in most small teams.

The same short form works. What changes is the approver, who needs to be someone able to say no to a colleague or a manager, and the reason field, which for internal changes should state what the change is expected to improve. A request that cannot articulate that is a preference, and preferences belong in the deferred list.

What to change first

Pick the threshold below which no form is needed, write it as a number of hours, and tell the team. Then add one lane to whatever board the work already sits on, for requests waiting on an assessment, so that pending changes are visible without anyone having to ask. Doing that on the board the team already opens daily, whether that is Pinateca or the current tool, matters more than which template the form is based on.

Q1. What should a change request form contain as a minimum?

Request ID and date, requester, what is being asked for, why, the effect on schedule and cost as numbers, the decision, and the name of whoever decided. Nine fields is enough for most projects. Longer templates add classification taxonomies and risk sections that duplicate documents kept elsewhere.

Q2. Who is supposed to approve a change request?

One named person with authority over the budget or the delivery date, not a committee, unless the change is large enough to affect the contract. Committees are appropriate above a threshold set in advance. Below that threshold, routing to a group means nobody answers and the requester eventually proceeds without an answer.

Q3. Do small internal changes need a form at all?

Not below a threshold the team sets in advance, commonly a couple of hours of work. Above it, yes, and internal changes benefit more than client ones because they carry no invoice to make their cost visible. The form for internal changes should require a statement of what the change is expected to improve.

Q4. How is a change request different from a defect or a bug report?

A defect is work that was already in scope and was not delivered correctly, so fixing it is not a change. A change request asks for something that was not agreed. Mixing the two lets genuine changes be booked as defects and delivered unpaid, and it lets real defects be deferred as though they were optional.

Q5. What is the best way to stop change requests from being ignored?

State a turnaround time for decisions and meet it. A form that sits unanswered for a week teaches everyone to bypass it, and once bypassing becomes normal no template will bring the process back. Keeping requests as visible cards on the board the team already checks, rather than in a separate document, is what makes the turnaround observable.