Software change control: decide every change before anyone builds it

Contents

• Why do unmanaged changes break budgets?
• What goes in a change log?
• Which decision rules keep changes moving?
• Worked scenario: four requests in one milestone
• What does the Netbase record show about phase boundaries?
• Which questions should you ask a supplier about change?
• How does change control break down?
• How this guide is sourced and where it stops
• Common questions
• Bring your change rules

Why do unmanaged changes break budgets?

Change is normal in software. Users see a working screen and realise what they actually need; a regulation shifts; a competitor launches something. The damage comes not from change but from change that is agreed in a chat message, built without an estimate and discovered at invoice time. Each small request looks free on its own. Twenty of them move a launch date by a month, and nobody can say which decision caused it.

Change control does not exist to say no. It exists so that each yes has a known effect on money, time and risk, and so that the buyer, who owns the budget, makes the call rather than whichever developer happened to read the message. The project delivery page names change control as one stage of a Netbase project; this guide gives the working tools behind it.

What goes in a change log?

OutsourcingVN is operated by Netbase JSC, which runs change control on its own projects, so read the log as a supplier's tool that works equally well for buyers managing any supplier. Every request, however small, gets one row.

The classification column does most of the work. A defect fails an agreed acceptance criterion and is fixed inside the current scope. A clarification confirms what an existing criterion meant and changes nothing. A swap replaces one in-scope item with another of similar size. An addition is new scope and always needs sizing and approval.

Worked scenario: four requests in one milestone

A training company is three weeks into a milestone that delivers course booking and payment. Four requests arrive:

• CR-011, "The booking confirmation shows the wrong time zone." The supplier checks criterion AC-05, which says times appear in the learner's local zone. It is a defect, fixed inside the milestone scope.
• CR-012, "Does 'group booking' mean up to ten or up to twenty?" The criterion says ten. It is a clarification, recorded and closed.
• CR-013, "Replace the PDF invoice with an emailed receipt." Both are similar in size, and the finance lead prefers the receipt. It is a swap, approved by the product owner.
• CR-014, "Add a waiting list when a course is full." New scope. The supplier sizes it at one extra week and offers two options: add it to this milestone and move the date, or schedule it in the next milestone. The budget owner chooses the next milestone.

Four requests, four different outcomes, and the milestone date moves by zero days because only one request was new scope and it was deferred deliberately.

What does the Netbase record show about phase boundaries?

Since 2020 Netbase has worked as offshore development and managing partner on a multi-tenant cloud ERP SaaS for a US client who is not named. Phase 1, from 2020 to 2023 and aimed at agency SMEs, covers CRM, real-time messaging, HR, knowledge base, custom fields and workflows, work and project management and API integrations. A retail phase 2 was planned work when the profile was written and is not presented as delivered. The cloud ERP record shows a long engagement where new ambitions become a named later phase rather than silent growth inside the current one.

Commercially, most Netbase projects are agreed as fixed-scope contracts after discovery; milestone-based arrangements are also available. Under a fixed scope, a change log is what keeps the fixed part meaningful. Netbase delivery runs with weekly reviews and a named project manager, and its lifecycle includes agile execution with outcome-based milestones, which gives the log a regular review point. The total software delivery cost guide covers how approved changes fit into the full cost picture.

Which questions should you ask a supplier about change?

• How do you classify a request, and how fast? Ask for the categories and the turnaround in writing.
• Who on my side can approve what? Agree the product owner and budget owner roles, and the size above which the budget owner must decide.
• Will you show me the running total of approved changes? It should appear at every weekly review.
• What happens to acceptance criteria when a change is approved? They should be updated the same day; the acceptance criteria guide explains how.
• Can a change be deferred to a later phase without penalty? A good answer describes how deferred items are carried forward.
• How do you handle urgent production changes? Emergency fixes need a faster path, logged after the fact.

How does change control break down?

• Verbal approvals. A "yes" on a call is logged by nobody. Confirm every decision in writing the same day.
• Every request treated as a change. Billing defects as new scope destroys trust; classify honestly.
• Every request treated as a defect. Absorbing additions silently destroys the schedule.
• No budget owner in the loop. The product owner approves additions nobody funded.
• The scope map left stale. After a few approved changes, nobody knows what the contract covers; update the scope boundaries with each decision.
• Changes that carry new risk go unrecorded. A late integration or data change belongs in the project risk register as well as the log.

How this guide is sourced and where it stops

This guide combines NIST SP 800-128 on configuration change control with Netbase records approved in the OutsourcingVN claim register: the delivery lifecycle, weekly reviews, the contracting model and the cloud ERP engagement with its planned phase 2. The methodology explains how records are sourced. The cloud ERP record describes scope and phases; it does not publish a change log, a number of change requests or any schedule or cost figure, and this page claims none. The training-company scenario is illustrative, not a client project. Contract terms for changes are set in each project agreement.

Bring your change rules

Agreeing the log fields and decision rules before a contract takes an hour and saves weeks later. Custom Product Engineering projects run with change control from the first milestone.

OutsourcingVN is Netbase's own outsourcing-services platform. Submit a project with your brief and how you expect to approve changes, and a person will reply with a proposed change process for it.

Related services and solutions