Blog
7 min read
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.
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 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?"
A price.
Asana's five-step 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.
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.
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 long before the cost report shows anything at all.
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:
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 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.
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 once licences and rework are counted. More on the mechanics sits under change control on fixed price work.
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:
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.
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:
RELATED READING:
A fixed price SOW gives you one number and no invoice line to check yourself against. Convert it into a cost ledger, then reconcile actuals every week.
Separate the refused submission from the new response. Map each refusal reason to tasks, hours, costs and supporting evidence before you issue a priced change.
Unscoped integration work is any interface the signed scope never named. Here is how to count them all before signature, and what to do the day an undocumented one appears.
Korrel turns briefs into structured proposals, then tracks what each job actually costs.
START FREE TRIAL