outsource
The client asked for something small on a Tuesday call. It was small. It was also the fourth small thing that month, and the third of them touched a part of the project that had already been signed off. The invoice at the end of the phase is going to be larger than the number in the contract, and the conversation about why will happen with no written record of any of those four requests.
A change order template is the artifact that prevents this, and downloading one changes nothing on its own. The form is the easy part. What makes it work is a rule about when it gets filled in, which is before the work starts rather than after, and a place to keep the filled in forms where both sides can see them.
A change order is a written record that the agreed work has changed, signed by both sides, stating what is different, what it now costs, and what it does to the schedule. It sits underneath the contract rather than replacing it.
The naming varies by industry and by country. Construction work in some markets calls the same thing a variation. Professional services often call it a scope change or a change request. Some contracts distinguish a directive, which instructs work to proceed before the price is agreed, from a change order, which is the agreed version signed by both parties. Two things follow from that variation: the words in a downloaded template may not match the words in the contract being amended, and a template used on real projects should be read once by a lawyer familiar with the relevant contract form. Nothing in a generic form survives that check automatically.
Three documents get confused with change orders and do different jobs.
An amendment changes the contract itself, including its terms, rather than a piece of the work under it. Changing a payment schedule or a liability cap is an amendment.
A change request is the ask, before anyone has priced it. It is useful to keep these separate, because most requests should be priced and then declined or deferred, and a template that treats every request as an approved change loses that filter.
A field instruction or directive tells work to start without the commercial terms settled. It exists because some changes cannot wait. It is also where most disputes begin, which is why a directive should carry a deadline for converting it into a signed change order.
Most downloadable templates carry too many fields, and half empty forms get distrusted quickly. These are the ones that earn their place.
| Field | Why it matters | Common mistake |
|---|---|---|
| Sequential number | So a missing one is visible | Numbering by date, so gaps cannot be spotted |
| The change, in plain description | So both sides agree what was asked | Written as a solution rather than as the change in requirement |
| Who requested it, and when | So the origin survives staff turnover | Left blank because it was a phone call |
| Reason for the change | So patterns show up in the log | Filled with a category code nobody reads |
| Price effect, and how it was derived | So the figure can be checked later | A single total with no basis shown |
| Schedule effect in days | So time is priced as well as money | Omitted, which is the most expensive omission of all |
| What it does to already approved work | So rework is visible before it is done | Ignored until the rework is discovered |
| Approval, both sides, dated | So the record means something | Countersigned after the work is finished |
Two fields are worth adding for anything longer than a few weeks. A revised contract total, carried forward on every change order, keeps the cumulative picture in front of both sides so the final invoice is never a surprise. And a status field with three values, open, approved and declined, makes it possible to see how much is in flight.
The declined value matters more than it looks. A log that only records approved changes cannot show how much work was requested and sensibly refused, which is exactly the evidence needed when a client later believes nothing was ever pushed back.
Money is easy to argue about because both sides understand it. Schedule effect is where change orders quietly fail, for three reasons.
The work itself takes time. This part usually gets estimated, sometimes accurately.
The decision takes time. Between the request and the signature, the affected work is often paused. If a change sits unsigned for a fortnight while three people are asked for approval, that fortnight is real and it belongs on the form. Putting a response by date on every change order turns the delay into a shared problem rather than a supplier's problem.
The interruption has a cost beyond its own hours. Pulling people off a sequence and putting them back is not free, and on work with dependencies the effect is not proportional to the size of the change. A two day change landing on the one task everything else waits for can move the delivery date by a week.
The practical response is to state the schedule effect as a number of days on the critical path rather than as hours of effort, and to name which delivery date moves. That sentence is short, and it prevents the most common dispute of all, which is a client who accepted a price and believed the date was unaffected.
Three pricing methods cover nearly everything, and picking the wrong one is what turns a change order into an argument.
| Method | Works when | Risk carried by |
|---|---|---|
| Fixed price addition | The change is well defined and can be scoped properly | Supplier, who absorbs any underestimate |
| Time and materials | The extent is genuinely unknown at the point of approval | Client, who cannot see the total in advance |
| Not to exceed ceiling | The extent is unclear but the client needs an upper bound | Shared, with the supplier capped |
The ceiling is the most useful of the three and the least used. It allows work to start on something imperfectly understood without asking the client to sign an open ended commitment, and it converts to a fixed figure once the extent is known.
Whichever method is chosen, show the basis rather than only the total. A rate, a quantity and a line for each component takes an extra two minutes and removes the entire category of objection where a client challenges a number they cannot see inside. It also makes the change order reusable as evidence when a similar request arrives later.
One rule is worth applying without exception: price the change before doing it, even when the work is obviously going ahead. A priced change that is approved retroactively is a request for goodwill, not a contractual position, and goodwill runs out.
Five failures account for most of the damage, and none of them are about the form.
Verbal approval. A yes on a call is not a change order, and the person who said it may not be the person who signs invoices. The fix is a standing rule that work outside the agreed scope starts when the change order is signed, applied consistently enough that nobody tests it.
Bundling. Combining six small changes into one document to save paperwork means one disputed item holds up the other five. Number them separately even when they are approved together.
Drip. Changes small enough to absorb, arriving steadily, are the most expensive pattern in client work because no single one justifies a form. The counter is a threshold agreed at the start, below which changes are absorbed up to a stated pool, and a log that records them anyway so the pool's depletion is visible.
No record of what was refused. Covered above, and worth repeating, because it is the field most often removed to simplify a template.
The log lives in email. A folder of signed PDFs attached to messages is not a log. Nobody can answer how many changes are open, what they total, or which delivery dates have moved.
A form with a signature line and no named signatory is a form that circulates for a fortnight. Two details settle this, and both belong in the original contract rather than in the change order.
The first is authority. Name the role on each side that can approve a change, and name a value above which a second approver is needed. Without this, every change order is sent to whoever answers fastest, and the one that matters is the one sent to somebody who later turns out not to have had the authority. Where a client's own procurement process requires a purchase order, the change order should reference it, because an approval that cannot be paid against is not an approval.
The second is time. A change order should carry a date by which a response is needed, together with what happens if the date passes: the price expires, the schedule effect increases, or the change is withdrawn. This is not a threat, it is the honest position, since a quote built on this month's availability genuinely stops being valid. Stating it converts an open ended wait into a decision.
Both details have the same purpose, which is to stop the supplier from carrying a delay it cannot control. When the approval route and the expiry are written down in advance, an unanswered change order becomes a visible open item in the log rather than a piece of work quietly held in limbo.
A change order register needs to answer four questions at a glance: what is open, what it totals, what has been approved, and which dates moved as a result. A spreadsheet does this adequately for a single project with one maintainer, and it stops working the moment two people update it or several projects run at once.
The stronger arrangement is a register that sits next to the plan it affects, because a change order's whole purpose is to move something in that plan. When an approved change adds four days to a task everything else waits on, that should be visible as a shifted date rather than as a paragraph in a document. Teams keeping the board, the timeline and the change log over one set of items stop maintaining a schedule and a change record that disagree with each other.
There is a client facing version of the same question. Change orders are the single most useful thing to show a client without showing them everything, because the register answers the question they actually have, which is why the number moved. A shared view limited to the register and the dates does that without opening the whole workspace, and how access is scoped is worth checking before deciding what to share.
Take the last finished project and count the changes that never got a form. That number, not the template, is the finding. If it is more than two, the problem is the rule about when work starts, and the fix is a single sentence added to the next proposal: work outside the agreed scope begins when a signed change order is in place.
Then put the register where the schedule already lives so an approved change moves a date instead of sitting in a folder. Teams running client work across several projects at once can see how Pinateca keeps the plan and the change log in one place before rebuilding anything.
It is an agreement to change the work, and its effect depends on the contract it sits under and on the law that applies. The dependable version is signed by authorised people on both sides, dated before the work starts, and consistent with the change procedure written into the original contract. Having a lawyer review the template once is worth more than any downloaded form.
A change request is the ask, before anyone has priced it or agreed to it. A change order is the priced, signed record that the agreed work has changed. Keeping them separate matters, because most requests should be priced and then declined or deferred, and merging the two removes that filter.
As days on the critical path, with the affected delivery date named, rather than as hours of effort. Effort hours understate the effect of a change that lands on a task everything else waits for, and a client who approves a price while assuming the date is unchanged is the most common dispute in change management.
Sometimes it has to, and that situation should be handled with a written directive rather than informally. The directive instructs the work, notes that the price is unsettled, and carries a deadline for conversion into a signed change order. Starting on a verbal yes leaves no position to fall back on.
Agree a threshold and a pool at the start of the project: changes under an agreed size are absorbed until the pool is used up, then they follow the normal process. Log them regardless of size. Small unlogged changes are the pattern that makes final invoices larger than expected, because no single one ever justified a form.