An engineering project never comes out the way it went in. The client's requirements change, the area changes, a discipline is added, a study that was finished gets reopened. That is normal and expected on almost every project.
What isn't normal is executing the change without pricing it. And that — not the fee schedule — is where the profit of most engineering offices leaks away.
What Is a Change Order, and When Is One Due?
A change order is a document that records an amendment to the agreed scope of work, states its effect on both the contract value and the contract duration, and is approved by both parties before execution.
The practical question isn't "is this a big change?" but: was this work inside the scope written in the contract? If it wasn't, it deserves a change order — however small it looks.
Size is not the criterion. Ten undocumented "small" amendments cost more than one large priced one.
Five Places Profit Leaks
| Leak point | What it looks like in your office |
|---|---|
| Executing before approval | "Let's start now and document it later" — later never comes |
| The verbal request | A change agreed in a call or a site visit, with no written trace |
| The recurring "small tweak" | Each one not worth raising; together they are worth an invoice |
| Pricing value but not time | You priced the extra work and forgot it delayed the project by a month |
| Not updating contract value | Approved orders never reflected in certificates and invoices |
Notice that none of these five is an engineering error. They are all documentation errors — and yet they are what actually eats the margin.
The first is the most dangerous. Once work is executed before approval, you lose your entire negotiating position: a client who already received the work has no incentive to sign for its cost.
One Rule: No Work Before Written Approval
The rule sounds rigid, and the objection is ready: "the client is in a hurry, the relationship is good, we'll lose them if we get formal."
Experience says the opposite. Clients are not annoyed by documentation — they are annoyed by surprises. A client who approves a change order before execution pays without discussion. A client hit with an invoice for work they assumed was included feels manoeuvred, even when the amount is entirely fair.
Applying it takes three steps: log the request the moment it arrives, estimate its effect on value and duration, and send it for approval before anyone starts work. The whole cycle can close within a day if you have a clear path for it.
How to Price a Change Order
Start from the same basis as the original project: estimate the additional hours per discipline, multiply by your hourly cost, and add your margin.
Three items are routinely missed and deserve to be counted:
- Rework of completed work. A change doesn't only add new work — it invalidates work already done. A drawing that was redrawn counts twice because it was drawn twice.
- The knock-on effect across disciplines. One architectural amendment can trigger structural, electrical, and mechanical review. Price the chain, not the first link.
- The cost of standstill. When the team stops while waiting for the client's decision, time is consumed and salaries are still paid.
Time Extension Is Part of the Change Order, Not an Attachment to It
Many offices price the extra work and forget the time. The result is a project delayed by the client's own changes, with the office held accountable for the delay.
Every change order should carry two numbers, not one: its effect on value, and its effect on duration in days. The second may well be zero — but stating it explicitly is what protects you, because silence is later read as an admission that there was no impact.
Effective Contract Value: The Number That Should Always Be in Front of You
After three approved change orders, the contract value is no longer the figure written on its first page. It is the original value plus approvals minus reductions.
When that number isn't updated and visible, three consequences follow in order: you issue a certificate with progress calculated against an outdated value, a difference appears at final settlement, and the difference turns into an argument from memory instead of a review of records.
That is why updating the contract value should be an automatic consequence of approving a change order, not a manual step somebody has to remember.
What Changes When Change Orders Live Inside a System
Inside an engineering consultancy management system, four things change:
- Every order is linked to its contract and project, with a clear status: proposed, pending, approved, rejected
- The effective contract value updates automatically on approval, so certificates are built on the right figure
- Rejected orders stay recorded rather than deleted — they are your evidence when the discussion returns
- Project profitability is calculated against actual value and actual cost, not the original contract figure
The third point matters more than it looks: rejected change orders document what the client asked for and declined to pay for. That record is what settles the argument when the same request comes back at a later stage.
Frequently Asked Questions
What is the difference between a change order and an ordinary amendment?
The criterion is the scope of work written in the contract. Anything inside it is an included amendment; anything outside it is a change that deserves a change order, however small. The size of the work is not the test — its position relative to the scope is.
Should I stop work until the change order is approved?
Yes, for the additional work specifically, while the rest of the project continues. Executing before approval costs you your ability to negotiate, because a client who already received the work has no remaining incentive to sign for its cost.
How do I handle a verbal change request?
Document it yourself the same day with a message summarising the request and its preliminary effect on value and duration, and ask for written confirmation. Don't refuse a verbal request — convert it into a written one. That difference is the difference between a documented claim and an argument from memory.
What if the client refuses to pay for the change?
Then the change isn't executed, work continues under the original scope, and the order is recorded as rejected. Recording the rejection isn't a formality — it protects you when the same request returns later, or when someone asks why it was never done.
Does a change order include a time extension?
It always should. Every order carries two effects: on value and on duration in days. Even when the time impact is zero, state it explicitly — silence is later interpreted as an admission that no delay occurred.
How many change orders are too many on one project?
The count alone isn't the problem, and a long project may naturally carry many. The real signal is the same type of change recurring across different projects — that means the scope of work in your proposals is written incompletely, and the fix belongs in the proposal, not the project.
Conclusion
An engineering office loses less in its fee schedule than in the distance between what it executed and what it documented. Every undocumented change is work you gave away without thanks, because nobody ever knew it was extra.
Review one project currently in progress: how many changes were executed on it without an approved change order? That single answer tells you where your profit goes.
Read next: Running an Engineering Consultancy — The Complete Guide From Proposal to Handover.