# A change request process for fixed price implementation projects
Source: https://korrel.ai/blog/change-request-process-fixed-price-projects
Published: 2026-08-07
Updated: 2026-08-04
Topic: change request process for a fixed price implementation project
Tags: change-control, project-costs
---
## Key points

- On fixed price work a change request is a repricing event, not a risk assessment or a safety review.
- The generic five-step change control model carries no pricing step, which is exactly where the margin leaks.
- Name one approver on each side and give them two working days to answer in writing.
- Price the change from the estimate that produced the fee, never from the fee itself.
- Book every approved change as a revised budget line so the variance report stays honest.

A change request process for a fixed price implementation project is a repricing loop, not a risk review. Someone writes down what the client asked for outside the signed scope. Someone sizes it against the original estimate. The client agrees the new number before anyone builds anything. That is the whole mechanism, and it fits on one page.

Search for how to run one and you get something else entirely. Change advisory boards. Risk categorisation. Emergency protocols for production systems. All of it is written for a team that operates software rather than a team that delivers it.

## Why does every change control guide look like ITIL?

Because it was written for the people who run the system, not the people who build it. Atlassian's guide to [change types in IT service management](https://www.atlassian.com/itsm/change-management/types) sets out standard, normal and emergency changes, with risk assessment and change advisory board approval for the higher-risk ones. That is proportionate when an unreviewed release can stop payroll for a whole company.

Your position is different. You have a signed statement of work, a fixed fee, and a client who has just asked for a second integration in week five. The risk is not downtime. It is that you build the integration, absorb it, and find out what it cost at closeout.

So the framework answers a question you never asked. Not "is this change safe to release?" but "what does it cost, and who has agreed to pay?"

## What the generic five-step model leaves out

A price.

Asana's [five-step change control process](https://asana.com/resources/change-control-process) is the version most results converge on: propose the change, summarise its impact, decide, implement, close it out. As a sequence, it is sound. Read it as a commercial mechanism and the hole is obvious. Impact assessment counts the people and the days a request will take. The decision it produces is approve or deny, never a new number.

That is where a fixed price job quietly stops paying. Work gets added. The number does not move. Nobody makes a decision to give the work away, which is why it keeps happening.

## The change request process on a fixed price implementation project

Five steps, three of them under an hour each.

| Step | Who does it | Output | Time |
|---|---|---|---|
| Raise | Anyone on delivery | A note naming the request and the scope clause it falls outside | Same day |
| Size | Whoever built the original estimate | Hours by grade, licences, retest effort | One day |
| Price | The commercial owner | A fee and a revised date | One day |
| Approve | One named person at the client | A written yes | Two working days |
| Book | The project lead | A revised budget line and end date | Same day |

Raising is deliberately cheap. A developer who has to open a template and fill in eight fields will not bother. You hear about the request three weeks later, from somebody else, after it has been built. Two sentences in an email to a shared address is enough to start the clock.

The step people bolt on afterwards is sizing. It belongs to whoever produced the original estimate. They are the only person who can say whether the request was already half covered by an assumption nobody wrote down.

## Who approves a change, and how fast?

One person on your side, one on the client's, inside two working days. Name both before delivery starts, in the statement of work, next to the scope they are guarding.

No board. No weekly meeting. A change advisory board exists because a production release can hurt people who were not in the room, and that reasoning does not transfer. A change to your scope affects two parties, and both of them are already on the email.

The two-day window matters more than the approver's seniority. Leave a request hanging for a fortnight and watch what a live job does with it. The team keeps moving, because momentum is easier than chasing a client for a decision, and the work tends to get built anyway. Nobody decided that. That silence is one of [the leading indicators that a fixed-price job is losing money](/blog/job-losing-money-before-it-finishes) long before the cost report shows anything at all.

## How do you price a change against the original estimate?

From the estimate that produced the fee, not from the fee itself.

Open the estimate. Use the same rates and the same grades, then add what the request needs. The items teams forget are the same ones every time:

- Retesting whatever the change touches, including things that already passed
- Data and integration work sitting underneath the visible feature
- Project management time across a longer schedule
- Licence tiers that shift when user counts or modules change
- A disruption uplift when the work lands mid-delivery. Add 10 to 25%, because interrupted work costs more than sequenced work

Then compare the total to the original line for that deliverable. If a request adds 40% to a component you priced at ten days, it is one of two things. An estimating error, or a requirement nobody had thought of. The client deserves to know which, and both conversations are easier on day three than at final invoice.

None of this is exceptional. PMI's [Pulse of the Profession 2018](https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2018.pdf) found that 52% of projects completed in the previous twelve months experienced scope creep or uncontrolled change to scope, up from 43% five years earlier. Half your jobs will need this loop. Build it once.

## Where does an approved change get tracked?

On the budget, not just in the contract.

An approved change that lives only in an email thread is filing, not control. It has to land in three places. The revised fee, so invoicing is right. The revised date, so the schedule is honest. The internal budget, so the variance report compares actuals against the number you are now working to.

Teams skip the third one. The budget line still holds the original estimate, so every approved change makes delivery look like it is overrunning when it is performing exactly as agreed. Two months of that and nobody trusts the report, which is worse than not having one.

Kept consistently, the record turns into a pricing input. It shows which requests recur across clients, and which deliverables always attract them. That is the raw material for working out [which implementation projects are actually profitable](/blog/which-implementation-projects-are-actually-profitable) once licences and rework are counted. More on the mechanics sits under [change control on fixed price work](/blog/topics/change-control).

## What if the client will not pay for it?

Then it does not get built, and you say that on the day rather than at the end.

There are three honest answers to a rejected price, and each of them is a decision somebody made on purpose:

- **Swap it.** Something of similar size comes out of scope, and both sides sign the trade.
- **Defer it.** The request becomes a second phase, quoted separately, with its own start date.
- **Absorb it.** The change is priced, logged at zero, and visible to whoever reviews the job.

The third is legitimate. Goodwill is a real commercial instrument, and spending some of it to protect a relationship worth six figures is a trade a commercial owner should be free to make with their eyes open.

Absorbing a change and leaking one differ in three ways. You know the figure. You chose to spend it. It sits somewhere a manager can see.

## Start with the next request that arrives

Do not write the policy document first. Take the next thing a client asks for outside scope and push it through the five steps by hand. Email, and a spreadsheet for the sizing. Forty minutes, most of it the sizing conversation you were going to have anyway.

Korrel keeps change requests on the project itself, alongside the costs and milestones they alter. The revised budget line stops being a separate file somebody forgets to update. That helps once the loop exists. It will not create one.

One request, run properly, on a live job. That argues the case better than any process document.

## Common questions

### How is a vendor change request different from ITIL change control?

ITIL change control protects a running system from a risky release. A vendor change request protects a fee from unpriced work. The inputs differ accordingly: one needs a risk category and board approval, the other needs hours, rates and a revised date. Running the heavyweight version on a twelve-week delivery costs more in process than it saves.

### Do you need a change request for a small addition?

Yes, and it should take ten minutes. Size is a poor filter, because a small request still moves the fee, and the small ones are the easiest to leave unpriced. A one-paragraph note naming the request, the hours and the fee is enough. Reserve the full sizing exercise for anything that changes a milestone date.

### Who should approve a change request on a fixed price project?

One named person at the client, agreed before delivery starts and written into the statement of work. A committee is slower without being safer, and an unnamed approver means requests sit unanswered while the team builds the work anyway. Your side needs one name too, usually whoever owns the commercial relationship.

### What happens if the client refuses to pay for a change?

The change does not get built, and you say so the same day. There are three honest routes: swap something of similar size out of the scope, defer the request to a separately quoted phase, or absorb it deliberately with the price logged at zero. Silence is not a fourth option.