Change order management: integrated change control on a construction project

Why changes go wrong

Changes rarely go wrong because of the work itself. They go wrong in the paperwork around it: an extra done on a verbal instruction and never priced, a change approved for its cost but not for its delay, an approved change added to the contract but not to the budget, so the cost report shows an overrun that is not one. Each of these breaks the link between scope, cost and time that integrated change control is meant to protect.

The vocabulary, kept simple

Change request

Anyone's request to modify the work: the owner, the architect, the engineer, or the contractor after a site condition or an RFI answer. Nothing is approved yet.

Pricing (or quotation)

The contractor's price for the change and its impact on the schedule, with the subcontractors' quotes.

Change order

The signed agreement on the change: scope, price and time. It amends the contract.

Change directive

An instruction to proceed before the price is agreed, when the work cannot wait. The price is settled afterwards, often on time and materials.

Credit change

A change that reduces the scope and the contract price.

Standard contract forms use their own terms and procedures; read the change clauses of your contract, including notice deadlines. Missing a notice period can cost you the right to be paid for a change, whatever its merits.

The process, step by step

1. Log every request the day it arrives, with a number that never changes and never gets reused, the source document (RFI answer, site instruction, revised drawing) and the activities it affects.
2. Notify the owner in writing within the contract's deadline when a request will cost money or time, even if you cannot price it yet.
3. Price it: direct costs from subcontractors and suppliers, your own labour and equipment, general conditions if the job gets longer, then the markup set by the contract.
4. Assess the schedule impact on the critical path, not in isolation: three days of work on an activity with ten days of float is not a three-day extension. See critical path and baseline.
5. Get a written decision: approved, rejected, or proceed under directive. Record who decided and when; the decision should not be edited afterwards.
6. Apply it everywhere at once: contract value, the budget of the affected cost codes, the schedule and the baseline if the contract dates change, and the next progress billing.
7. Track the actual cost of the change against its budget, so you know whether it made or lost money.

Worked example: a canopy at the main entrance

Halfway through the envelope, the owner asks for a steel canopy at the main entrance. The steel fabricator quotes $7,400, the roofer $1,600 for the flashing, and the general contractor's own labour for coordination and blocking comes to $800. The markups allowed by the contract (overhead and profit on its own work, a lower rate on subcontracted work, plus the subcontractors' own markups already in their quotes) bring the price to $13,500. The work takes three days on an activity with six days of float: no extension is due.

Once CH-3 is approved, the contract goes up by $13,500, the budget of the steel and roofing cost codes goes up by $9,800, and the expected margin on the change is $3,700. If the budget were not updated, the cost report would show a $9,800 overrun on the envelope that is not an overrun at all, and earned value would understate the CPI.

Records that hold up later

• Never delete a change. A rejected or cancelled change stays in the log with its status; deleting it erases the history you will need in a claim.
• Keep numbers sequential and permanent, even for cancelled changes.
• Attach the source: the RFI, the instruction, the revised drawing, the quotes. A change without its trigger is hard to defend.
• Correct a billed change with a credit change, not by editing it: the billings already issued must stay consistent.
• Keep pending changes visible in the forecast as a risk, but out of the contract value and out of the billing until they are approved.

Where the PMP method meets the job site

The PMBOK Guide asks that every change go through one controlled path, with its impact on scope, schedule, cost, quality and risk assessed before the decision, and the baselines updated after it. On a construction project, that translates into the steps above. The value of the discipline is not the paperwork: it is that at any moment you can answer the owner's question “what has this project cost me in changes, and what is still pending?” in one line.

Applying it in Teyvor

In Teyvor, a change request is logged against the task it affects, priced (it can also be priced after the fact, or on time and materials at actual cost plus a markup), then decided, and the decision is final. An approved change is added to the contract and to the budget of its cost codes, with its margin; its schedule impact is applied only after you confirm it. A change is cancelled rather than deleted and stays in the register, a billed change is corrected with a credit change, and numbers never go back. The pending changes also show in the look-ahead on the tasks waiting for them.