This term is one of the entries in the OutsourcingVN glossary of words buyers meet while a project is in delivery.
Why does a change request matter?
Change is routine on a software project: users see a working screen and ask for something different, or a rule changes outside the project entirely. OutsourcingVN is operated by Netbase JSC, and what separates a healthy project from a drifting one is not whether change requests arrive, but whether each one is written down, estimated and decided before any code moves, rather than agreed in a chat message and discovered at invoice time.
What is an example of a change request in practice?
A training company's booking project is three weeks into a milestone when the finance lead asks for the emailed invoice to be replaced with a receipt sent straight to the booking confirmation screen. The project manager logs it as change request CR-013, notes that the two formats are similar in size and effort, and the product owner approves it the same day as a swap, with no change to budget or schedule. Because it went through the log, nobody argues at acceptance about whether the receipt was already included.
What are the common misreadings of a change request?
A change request is not automatically a sign the project is going badly — a request raised, logged and decided in a day is change control working as intended, not a failure. It is also not the same thing as a defect report: a defect means the agreed criteria were not met and is fixed inside the existing scope, while a change request asks for something the agreed criteria never covered. And logging a request does not mean building it; many change requests are deferred to a later phase or declined, and the log exists precisely so that decision is visible and deliberate rather than silent.
What is a change request most often confused with?
| Commonly confused with | What's actually true | Watch out for |
|---|---|---|
| Sign the project is going badly | A request raised, logged and decided quickly is change control working, not a failure | Treating every logged request as a warning sign |
| Defect report | A defect fails agreed criteria and is fixed in scope; a change request asks for something scope never covered | Mixing bug fixes into the change-request log |
| Approved work | Logging a request doesn't mean building it; many are deferred or declined | Assuming a logged request becomes committed work |
Plan the next step for your project
Common questions
Either side. A developer who gets an informal ask from a stakeholder should log it as a request rather than building it on the strength of the conversation.
No. A request that turns out to be a clarification of existing scope, or a swap of similar size, often carries no extra cost; only new scope, classified as an addition, typically needs fresh budget.
Which decisions does a change request affect?
Classifying each request, logging its impact and applying agreed decision rules so a yes or no takes days, not weeks, is the subject of the software change control guide. A request that adds genuinely new scope usually needs its own acceptance criteria before it can be sized, and where an in-house team's own AI coding agents are drafting or reviewing the changed code, the AI-assisted software delivery guide covers what shifts in review and ownership, with AI engineering enablement as the service that puts those review gates in place for your own engineers, including where a human stays in the loop before a change ships. When a request has come in on a live project and you need it sized and decided, describe it and Netbase will respond through Netbase's own outsourcing-services platform; submit a project when you are ready.