Pricing a change request on a fixed-price project
Two identical $7,200 changes: one barely moves the date, the other cuts on-time odds from 84% to 25%. A flowchart and the numbers for pricing a change.
Short answer Price a change as the rise in your project’s P80 cost, divided by (1 − margin), then check what it does to the date. The change’s own likely hours underprice it, its own P80 overprices it, and absorbing it free quietly removes your margin: in the example below the chance of earning a 25% margin falls from 80% to 24%.
- P80 rise, sign-on
- $7,513audit logging $7,531
- Price of the change
- $10,000at a 25% margin
- On time, same date
- 80% / 25%slack / critical path
- Margin if absorbed
- 24%chance of 25%, from 80%
Start with the decision tree
Most change-request arguments are really three separate questions asked at once: is it a change at all, what does it cost, and what does it do to the date. Answer them in order. The figure is the whole routine; the sections below put numbers on each step.
Figure 1. How to handle a request that may be a change, step by step.
- If it is inside the written scope, deliver it.
- Otherwise write it down in one sentence with an acceptance test.
- Estimate it as a range, including the testing and integration it drags in.
- Add it to the schedule and re-run the simulation.
- If it is on the critical path, quote the new P80 finish too.
- Price it as the rise in project P80 cost ÷ (1 − margin).
- Send price and date; get written approval before starting.
The baseline: a six-task build
A fixed-price build with six tasks and dependencies, quoted the way a P80 quote is: price = P80 cost ÷ 0.75, rounded to $500, and a promised date at the P80 finish.
| Task | Days (low / likely / high) | Cost a day | Starts after |
|---|---|---|---|
| Requirements & design | 6 / 8 / 14 | $850 | – |
| Back end & API | 12 / 16 / 28 | $900 | Requirements |
| Front end | 10 / 14 / 24 | $800 | Requirements |
| Integrations | 5 / 8 / 18 | $900 | Back end |
| Testing & fixes | 6 / 9 / 18 | $750 | Front end, integrations |
| Deploy & handover | 2 / 3 / 6 | $800 | Testing |
Inputs. Project fixed costs $2,500 and overhead $6,000. Beta-PERT (λ = 4), 100,000 runs, fixed seed, durations in calendar days. Illustrative figures. Figures are rounded for display, so recomputing from the rounded values can differ by a dollar or two.
The simulated P80 cost is $65,598, so the quote is $87,500. The P80 finish is day 52.3, so the promised date is day 53. At that price and date the baseline has an 80.2% chance of earning the 25% margin, an 83.7% chance of finishing on time, and a median margin of 29.4%.
Two changes of identical size, in different places
Now the client asks for one of two things. Both are estimated at 4 / 7 / 16 days at $900 a day, so on paper they are the same piece of work. Single sign-on starts after the back end and runs in parallel with integrations, so it sits on slack. Audit logging has to happen between the back end and integrations, so it sits in series on the critical path.
| Single sign-on (slack) | Audit logging (critical path) | |
|---|---|---|
| Likely cost of the change | $6,300 | $6,300 |
| Average cost added to the project | $7,199 | $7,205 |
| Rise in the project’s P80 cost | $7,513 | $7,531 |
| P80 finish moves by | +0.6 days | +8.4 days |
| On time at the original date | 80.3% | 25.1% |
Figure 2. Chance of finishing by day 53 after adding each change. The dashed line is the 80% a P80 promise implies.
The cost is the same. The date is not: a change on slack barely moves it, while the same work in series takes the promise from 84% to 25% unless the date moves to day 61.
That is why a price per hour, or a price per change size, is not enough on its own: where a task sits in the network decides its effect on the date, and only a re-run of the schedule shows it.
What absorbing a “small” change does to the margin
Absorbing either change at the original price does not make the job lose money. The chance of a loss only rises from about 0% to 0.02%, which is why absorbing feels harmless. The margin is what pays: the chance of earning the 25% target falls from 80.2% to 24.1% (24.3% for audit logging), and the median margin drops from 29.4% to 21.2%. Repeat that a few times and you have the spiral without ever having had a visibly bad job.
Four ways to price the change; one holds up
Take the single sign-on change and add a price for it using each natural method, each grossed up for the 25% margin. Then check the whole project at the new total price.
| Priced at | Cost basis | Price of change | Chance of 25% margin |
|---|---|---|---|
| Its likely hours | $6,300 | $8,400 | 72.7% |
| Its average cost | $7,200 | $9,600 | 78.4% |
| Its own P80 cost | $8,894 | $11,900 | 87.1% |
| Rise in the project’s P80 | $7,513 | $10,000 | 80.1% |
Figure 3. Chance of earning the 25% target margin for the whole project under each way of handling the single sign-on change. The dashed line is the 80% the original quote was built to.
Rust is short of the target; blue is more than the policy needs; teal is on it. Only the last method puts the project back where it started, 80%.
The likely-hours price is the common one, and it leaves the project at 73%, because the average cost of a change is above its likely cost. The change’s own P80 overshoots, because adding a task to a project that already has spread usually raises the project’s P80 by less than the task’s P80 on its own ($7,513 against $8,894); the reason is the same one as in why task P80s do not add. The rise in the project’s P80 is the figure that holds the original risk policy constant.
Do not price the date separately from the cost
For the audit-logging change the price is the same $10,000, but promising the old date leaves a 25% chance of keeping it. The new P80 finish is day 61. Quote both: $10,000 and day 61, and the project is back to 81.4% on time with an 80.0% chance of the 25% margin. A client who hears the price but not the date will assume the old date, and the argument arrives later, in worse form.
A routine that holds up with clients
- Write the request in one sentence, with the acceptance test that would show it is done.
- Estimate it as a range, including the testing and integration it drags in; most change estimates leave these out.
- Add it to the network with its real dependencies and run both versions with the same seed.
- Quote the price and the date together.
- Get written approval before work starts.
- Log the estimate and the outcome, so the next change is estimated from evidence; calibrating from completed jobs shows how.
For frequent small changes, derive a rate card once with this method (a price for a small, medium or large change in each part of the system) and re-derive it when your estimates are recalibrated. Whether a request is a change at all depends on your written scope and agreement; this note covers the arithmetic, not contract interpretation or legal advice.
Doing it in BidVariance
Add the change as a task with the dependencies it really has, then run the baseline and the changed project with the same seed (runs are deterministic, so the comparison is clean). Read the P80 cost and the deadline confidence for each. The Business and Consultant licenses add scenario comparison, which shows two saved runs side by side; see pricing. The free minimum bid price calculator and deadline confidence calculator cover the single-task version of the same arithmetic.
Frequently asked questions
How do I price a change request on a fixed-price project?
Estimate the change as a range, add it to the schedule and re-run the simulation, then price it as the rise in the project’s P80 cost divided by one minus your target margin. In the worked example that was $7,513 ÷ 0.75, about $10,000, and it kept the chance of earning the margin at 80%.
Should I price change requests hourly?
Hourly is simple, but it reopens the pricing model mid-project and hides schedule effects. A fixed price per change keeps the logic of the original quote. If the client needs transparency, show them the range behind the price.
Does every change request need a new deadline?
No. A change that sits on slack barely moves the date (a 0.6-day shift in the example), while the same work in series on the critical path moved it 8.4 days. Re-run the schedule to see which one you have.
What does absorbing a small change do to my margin?
The job usually still makes money, so it feels harmless, but the chance of earning your target margin drops sharply. In the example it fell from 80% to 24%, and the median margin from 29.4% to 21.2%.
What if the client says the change is already in scope?
That is a question about your written scope and agreement, not about arithmetic. Write the request as one sentence with an acceptance test, and price each reading of it if the scope is genuinely ambiguous. Have a lawyer review the contract language.