What Is a Change Request and How Extra Work Is Paid
Basics4 minInnovialabs editorial team
In short
A change request is a formal request to modify the agreed scope: it is described, estimated in time and money, approved in writing, and only then delivered and billed separately.
The short answer
A change request (CR) is a formal request to change something that has already been agreed: add a feature, alter logic, redo a screen. Anything outside the approved specification or backlog is handled as a CR.
Every CR follows the same path: description → estimate → approval → delivery → payment. This protects both sides: the client knows the price and the impact on timelines upfront, and the contractor does not work for free.
Change or bug: what is the difference
The main point of dispute is who pays. The answer depends on what was written in the requirements.
| Situation | What it is | Who pays |
|---|---|---|
| A feature does not work as described in the spec | Bug | Contractor (under warranty) |
| A feature works as specified, but you want it different | Change request | Client |
| You need a new feature that was not in the spec | Change request | Client |
| The requirement in the spec was ambiguous | To be discussed | Depends on the contract and correspondence |
| Something broke after a change in an external service | Usually support or a CR | Per the support agreement |
Hence the rule: the more precise the spec and acceptance criteria, the fewer disputes.
How a change request works
1. Request
The client describes what they want to change and why. A good request answers:
- what works now and how;
- what should be different;
- why the business needs it;
- how urgent it is.
2. Estimate
The contractor analyzes the impact:
- effort — hours per role (development, design, testing);
- timeline — whether the release or other tasks shift;
- risks — what else the change may affect;
- cost — by the hourly rate or as a fixed price.
3. Approval
The client accepts, rejects or postpones the CR. The decision is recorded in writing: a signature, a contract amendment or a confirmation in the task tracker, depending on the contract.
4. Delivery and acceptance
The change is built, tested and accepted under the same rules as the main work.
5. Payment
One of these models is usually used:
- Time and material — you pay for the hours actually spent.
- Fixed price per CR — an agreed amount for a specific change.
- Hour bank — a prepaid block of hours for extra work, from which CRs are deducted.
- Budget reserve — part of the project budget is set aside for changes upfront.
How to keep a clean paper trail
- One CR, one document or task. Do not bundle several changes into one request.
- Numbering and statuses. For example, CR-012: "new", "estimated", "approved", "done", "rejected".
- A change log. A table of all CRs with their estimates, decisions and dates.
- Links to original requirements. State which spec item is being changed.
- Decisions in writing only. Confirm anything agreed on a call with a message or in the task tracker.
| Log field | Example content |
|---|---|
| Number | CR-012 |
| Description | Add a date filter to the orders report |
| Related requirement | Spec section "Reports" |
| Estimate | Hours per role and timeline impact |
| Decision | Approved / rejected, date, approved by |
| Status | Done, accepted |
Common mistakes
- Verbal "favor" changes. Later it is hard to explain why the budget grew and deadlines slipped.
- Starting work before the estimate is approved. This leads to payment disputes.
- Treating every change as a bug. It damages the relationship with the contractor and drags the project out.
- Ignoring the timeline impact. Even a small CR can shift a release if it touches related modules.