Pricing a change request without a fight

A client disputes a change price for one of two reasons. Either they think the thing should have been included, which is a scope document problem and is dealt with elsewhere, or they cannot see where the number came from, which is a pricing method problem and is dealt with here.

It is worth being clear how ordinary this situation is. Atlassian, citing the Project Management Institute, reports that 52 percent of projects experience scope creep. An agency that has never priced a change is not an agency whose scope never moved. It is one that absorbed the movement.

The second is far more common and much easier to fix. A figure produced by the same visible arithmetic as the original quote is arguable on its merits. A figure produced by judgement is arguable on principle, and principle arguments have no ending.

So the rule is simple: quote a change in the same unit and by the same method as the original commitment. A client sold a decomposed sixty-hour estimate and then told a change is three story points has been handed a translation problem, and translation problems get resolved in the client's favour.

This is the pricing half of change control. The process half, which is when to raise a change record and what it contains, sits inside scoping a fixed-fee statement of work. This piece assumes the process exists and asks what number goes in it.

The first method is the strongest and it is only available if the original estimate was decomposed. If the payment integration was quoted at 38 hours as its own line, and the change adds a second payment provider, you re-estimate that line, get a new figure, and quote the difference. The client can see the before, the after and the delta.

That is why decomposition pays twice. It produces a better original estimate, and it produces a defensible change price for the rest of the project. An original quote that was one number cannot be re-estimated in part, so every change becomes a fresh negotiation.

The swap is the method agencies use least and clients like most. It presumes a fixed envelope and asks what comes out. Its failure mode is asymmetry: if the incoming item is larger than the outgoing one and nobody sizes both, the swap is a discount you agreed to without noticing. Size both, in writing, before agreeing.

Absorbing is often correct commercially and is only correct if it is recorded. An absorbed change that never appears in writing is a discount the client never knew they received, and worse, it trains them that scope is free. Price it, then mark it as absorbed. The goodwill only exists if it is visible, and the general point about invisible discounts is made in what discounting actually costs you.

The commonest underpricing error is quoting only the hours to make the change. A change lands in a system that already exists and a schedule that is already running, and both of those absorb effort.

Price four components, separately, in the record. The build itself. The re-test of everything the change touches, which on integrated work is often larger than the build. The re-integration and redeployment. And the schedule effect, which is a date rather than a fee.

Worked through: a change that takes six hours to build might carry four hours of regression across the flows it touches, an hour of deployment, and a two-day slip because it lands mid-sprint and displaces something already committed. Quoting six hours is not generous, it is inaccurate, and the missing five hours come out of your margin on work you did not price.

The schedule component deserves to be stated even when the fee is small, because it is the one clients react to and it is the one that gets forgotten. A cheap change that moves a launch by a week is not a cheap change, and the client would frequently rather pay more to avoid the slip. Give them that choice explicitly.

Atlassian's account of how this compounds is worth keeping in mind while pricing: scope creep expands in three parts, with scope growing, the schedule stretching and the budget rising as more time, resources or vendors are needed. Pricing only the first part is how the other two end up being yours.

Show the before and after of a line rather than a total. "Payment integration was estimated at 38 hours for one provider. With a second provider and a shared reconciliation step it estimates at 62. The change is 24 hours." Nothing in that sentence requires the client to trust you.

Where the original used a range, quote the change as a range by the same method. Narrowing to a single number for the change while the base was a band is inconsistent, and inconsistency is what people notice even when they cannot name it.

Where the change is new work with no line to re-estimate, decompose it the way you decomposed the original, and show the lines. A rate-card figure with no decomposition behind it is an invoice, not a quote, and the general argument for publishing rates rather than inventing them per request is in designing an hourly rate card.

Atlassian's estimation guidance recommends using more than one technique on the same question, on the grounds that combining approaches produces a more robust estimate than relying on any single one. For a change of any size, doing both the re-estimate and a quick comparison against a similar past change takes minutes and catches the case where the re-estimate anchored too close to the original.

Send it the same day. A change record that arrives a week later has to overcome the client's belief that work has already started, and by then it usually has.

Some changes should not be priced at all, and offering a number implies they are available. A change that would break an acceptance criterion already agreed, or that lands inside a cutover window, or that requires a decision the client has not made yet, needs a different response.

The useful framing is timing rather than refusal. "This is a 24-hour change and we can do it, in the phase after cutover. Doing it now costs 24 hours plus a re-baselining of the cutover plan, which I would not recommend." That is a price on both options and a recommendation, which is what the client actually wants.

Where the change reveals that the original scope was wrong rather than incomplete, say so and re-baseline properly instead of accumulating change records. Six change orders against a plan that no longer describes the work is a worse position than one honest re-plan.

On a phased migration this is not optional. The transit programme that moved 154 data sources with zero unplanned production outages worked because each phase had a defined validation test and closed before the next began. A change accepted mid-phase without re-testing the phase is not a change, it is an unmeasured risk added to a cutover.

And where the changes keep arriving because nobody on the client side is deciding, the problem is governance rather than pricing. That is one of the specific gaps a fractional technical project manager is brought in to close.

Most agencies have a change control clause and have never issued a change order. The clause is not the problem. The moment of use is: changes arrive verbally, on friendly calls, and re-pricing feels petty in the moment.

The consequence is second-order and expensive. A client who has never received a change record has been trained, by you, that scope is free. By month four they are not being unreasonable when they ask for more; they are behaving exactly as your process taught them to.

Which is why the first record is uncomfortable precisely because it is late. Issue one on the first change, however small, even if the price is zero and it is marked absorbed. Used routinely it stops reading as escalation and starts reading as competence.

Keep the format small enough that issuing one is not a decision. Three lines: what changed, the effort and schedule delta, and the options. Anything longer will not get sent on the day, and a change record sent late has lost most of its value.

Then feed the records back into estimating. The changes you keep receiving are the things your scope documents keep failing to bound, and a quarter of change records read together will tell you which exclusions are missing from your template. Building that template is what statement of work scoping is for.