Mid-Project Requirement Changes: How Outsourcing Charges for Them

Change is normal, not an exception

Almost no outsourcing project finishes exactly as the original requirements document described it. Stakeholders see the first prototype and only then understand what interaction they actually wanted. A third-party payment or hardware integration turns out to be more complex than the plan assumed. Nobody is being unprofessional; software requirements become visible only as work progresses.

The problem is not change. It is how change gets priced. A significant share of the disputes we have handled started with a contract clause saying only that "requirement changes will be negotiated separately" — no method, no approver, no time limit. Every small adjustment then becomes a negotiation, the schedule slips repeatedly, and neither side is happy.

First, separate defects from clarifications from changes

This is where arguments start. Three lines belong in a contract annex:

• Not a change. Anything already specified in the requirements but implemented incorrectly is a defect and is the vendor's cost. Copy edits and colour adjustments that do not touch logic count as normal polish.
• A clarification. Where the specification was vague and the two sides read it differently, filling in the detail usually costs no development fee but consumes schedule, and needs written confirmation.
• A change. New modules, altered business processes, a different third-party provider or interface, or restructuring screens already accepted. These affect code structure and test cases, and must be priced.

Once the boundaries are explicit, the conversation shifts from "you want money for that too?" to "which category is this?" — which is far less emotional.

Three ways to price a change

Person-day conversion. Estimate how many people and how many days the adjustment needs, and settle at the contract rate. Transparent and easy to check, well suited to small and medium changes. The estimator must state its basis: which screens, which interfaces, whether regression testing is needed.

Function-point conversion. Agree in advance what a standard item costs — a list screen, an approval flow — and add or subtract points per change. Good for standardized scope; weak at pricing complex interaction accurately.

Rebudget by phase. Do not settle individual changes at all. Fold them into the next phase's scope and quote, and reschedule. Suited to long-running product work, provided each phase's scope is locked in writing.

In practice the most common arrangement is the first method plus a change allowance: reserve 10% to 15% of the contract value for changes, run those inside the allowance through a light process, and require separate approval beyond it. That range is not arbitrary — it roughly matches how much requirements normally grow on a healthy project.

Six items every change order needs

What is changing, ideally with a screen or flow sketch. What it touches: modules, interfaces, data tables. Effort estimate: how many people, how many days, on what basis. Schedule impact: days added, and whether any milestone moves. Cost impact: the amount added or removed. Effective condition: signature or online confirmation with a date.

With all six present, "I thought that was a quick tweak on the side" stops happening. The form does not need to be formal — one page or a shared table will do — but it must be numbered and on record. Numbering has a second use: reviewing at month end shows where changes cluster, and whether the gap was in requirements or in execution.

What a change typically costs

Cost scales with three factors: whether the work touches interface or underlying logic, whether the database schema has to move, and whether live data must be migrated. Interface and copy edits usually run from half a person-day to a bit over one. A single business-process adjustment commonly runs from a few person-days to a dozen-plus difference. Once schema change and data cleanup are involved, add regression testing and data verification on top.

So do not estimate by asking what one button costs. Estimate by asking how many layers this change touches. A vendor who cannot describe the impact scope is telling you something.

Three ways to keep change under control

A freeze window: no new requirements in the one to two weeks before each milestone acceptance, so the current scope can actually close. Tiered approval: the project manager decides small items, while anything above an agreed threshold or touching core flows requires the business owner. A change register: one shared log, reviewed weekly, showing exactly where scope keeps growing.

None of this is complicated, but together they turn "the project keeps expanding and the budget keeps climbing" into a predictable, explainable process. Requirement-change management in outsourcing is not about blocking changes. It is about making every change carry a clear price and a clear slot in the schedule.