A construction change order is a formal project record used to document an approved or formally processed modification to the work, contract value, project time, or other contract requirements according to the project's applicable procedures.
A good change-order process preserves the full decision trail: what changed, why it changed, where the change originated, what it costs, whether it affects the schedule, who reviewed it, and how the approved change updates the project record.
Terminology and approval requirements vary by contract and organization.
Construction projects rarely finish with every assumption unchanged from the original contract documents. As design develops and construction progresses, teams encounter owner decisions, design revisions, coordination conditions, unforeseen field conditions, scope clarifications, substitutions, procurement issues, schedule decisions, RFI responses, and work that has to be added or deleted.
A formal change-management process creates a documented path from issue, to evaluation, to pricing and time review, to approval, to an executed change, to updated project records. The change order is the record at the end of that path.
A change order is not simply "extra work." Depending on the situation, it may add scope, delete scope, revise scope, change contract value, modify contract time, document a no-cost change, document a no-time change, or combine cost and time adjustments.
The key idea. A change order records the authorized change. The issue that created it may have started much earlier.
The practical reason is to preserve agreement and traceability. A structured change record helps the project answer a specific set of questions later, without relying on memory or an email thread:
The value is not paperwork for its own sake. It is keeping scope, cost, schedule, and authorization aligned as the project moves.
Most changes trace back to a small set of recurring project conditions. Recognizing the source early is what makes pricing, review, and approval move quickly later.
An owner changes scope, finish, functionality, sequencing, or another project requirement.
Architectural or engineering information is revised after the original work was priced or planned.
A clarification reveals work different from what the team previously understood.
Existing or concealed conditions differ from assumptions or available documents.
Two disciplines, trades, or assemblies require revised work to resolve a conflict.
A product, material, equipment item, or system changes.
The parties determine that work needs to be added, removed, or redefined.
A project decision changes timing, sequencing, access, phasing, or milestone requirements.
An approved alternative changes the planned scope or cost.
A project-specific allowance or other budget item is reconciled through the applicable process.
Not every event above automatically creates entitlement or requires a change order. Project-specific contract documents and procedures govern the actual treatment.
There is no single universal workflow. Project structure, contract type, and organizational governance all change who does what. On most projects the pattern looks like this:
Approval authority depends on the contract, the organization, project governance, approval limits, dollar thresholds, and the type of change involved.
At any point in the process, the team should be able to answer:
The specific procedure is set by the project's contract documents, but the sequence below reflects how a well-run change moves from identified issue to updated project record.
A project condition, decision, document revision, RFI response, or scope issue creates a potential change.
Link the drawings, specifications, RFI, submittal, owner direction, meeting decision, photos, or other records behind the change.
Clarify exactly what work is added, removed, or revised.
Send the potential change to the party responsible for estimating, reviewing, or deciding it.
Pricing, credits, allowances, subcontractor impacts, or other cost effects are documented according to project procedures.
Identify schedule activities, milestones, procurement items, or sequencing potentially affected.
The parties review scope, pricing, time, responsibility, backup, and required revisions.
The change reaches the formal approval stage required by the contract and project procedures.
Update budgets, contracts, commitments, forecasts, schedules, documents, and reporting as appropriate.
The exact sequence, terminology, required notices, and approval authority are project-specific.
The issue that creates a potential change often appears well before the final change order exists — frequently first surfacing in an RFI or during the construction submittal process. Many organizations use an intermediate record to evaluate the issue first. Depending on the organization, that record may be called a change event, potential change order, PCO, change request, change proposal, proposed change, or change notice. These terms are not universally interchangeable.
Evaluate whether something affects scope, price, time, responsibility, or downstream work.
Record the change once it reaches the formal approval or execution point required by the project.
The important control is preserving the connection from the original issue to the final approved record.
A practical construction change-order record usually needs enough information to answer what changed, why, what supports it, what it costs, and what it does to time. Start from our free construction change order template, which already includes the fields below.
This is a practical field list, not a legally required universal one. Contract documents and project procedures govern what a given project actually requires.
The fictional example below shows how the fields work together on a change that originated from an RFI response.
The amount shown does not represent a benchmark or typical project value. Project-specific contracts and procedures govern actual change-order requirements, including numbering, routing, pricing, time adjustments, and approval authority.
These records are often mentioned in the same conversation, but they sit at different points in the same chain and produce different outcomes.
| Document | Purpose | Typical trigger | Typical result |
|---|---|---|---|
| RFI | Clarify missing, conflicting, or ambiguous project information | A question discovered in drawings, specifications, scope, coordination, or field conditions | A documented response or clarification |
| Change event / potential change | Evaluate whether an issue affects scope, cost, time, responsibility, or downstream work | An RFI response, field condition, owner request, design revision, or other potential change | Scope, pricing, and time evaluation, plus a decision on how to proceed |
| Change order | Document a formally approved or processed modification according to project procedures | A potential change reaches the required approval or execution stage | A documented modification to the project and contract records |
An RFI may reveal the need for a change, but an RFI itself is not the change order. For the question side of that chain, see our guide to RFIs in construction. To document the resulting change, use the free construction change order template.
These terms are often used at different stages of the same broader change-management workflow, but their exact meaning varies by organization and contract. A practical way to think about the stages:
Something potentially affects the project.
The team defines, prices, evaluates, or negotiates the potential change.
The change reaches the formal approval or execution point required by the project.
Some organizations use entirely different terminology, or combine these stages into fewer records. What matters operationally is that the connection between the original issue and the final approved record survives.
Construction projects sometimes encounter conditions where the team needs direction before pricing or formal documentation is complete. Depending on the contract and organization, projects may use records such as a written directive, construction change directive, field directive, owner directive, change notice, time-and-material ticket, or another form of interim authorization. These are not universally equivalent.
Whatever the mechanism, the project should preserve:
The contract governs authorization, notice, compensation, time entitlement, and required documentation.
There is a meaningful difference between potential exposure and approved financial impact. A potential change may be unpriced, estimated, submitted, under review, negotiated, approved, rejected, withdrawn, or superseded. The financial record should distinguish those stages rather than treating every open item as a committed number.
Relevant financial effects may include:
A project can carry significant pending exposure before any approved change reaches the contract value. That is the gap most teams are trying to close when they move change tracking into construction cost management alongside construction financial management.
One approved change can move several different financial views of the same project. Teams should know where a change shows up in each of them.
What was planned or allocated for the work.
What is contracted or committed to vendors and trades.
What the owner-facing contract value reflects, where applicable.
What the team currently expects the final project cost to become.
Potential financial impact that has not reached final approval.
Financial impact that has completed the required approval process.
If change information is tracked separately from budgets and forecasts, leadership can be looking at an outdated financial picture even when the project team already knows the exposure exists.
A change can affect the schedule even when its cost impact is modest. The schedule effect usually shows up somewhere other than the change itself:
A cost change does not automatically create a time extension. Where time is at issue, the record should document:
That is also why teams increasingly review pending changes inside construction scheduling software rather than as a separate financial list.
A generic "open" status is not enough for complex change management. Teams commonly use stages such as the following — as examples, not universal requirements:
The important thing is that each status represents a real next action. At any moment, the team should be able to see what is waiting, who owns it, how long it has been waiting, what financial exposure exists, and what schedule exposure exists.
One change-order form documents one change. A change-order log gives the project-wide view — what is pending, what is priced, what is waiting on a decision, and how much exposure sits behind all of it. If you need a register to start from, use our free construction change-order log template. Useful fields include:
| Change | Subject | Source | Status | Cost exposure | Time |
|---|---|---|---|---|---|
| CE-014 | Loading dock drainage revision | RFI-041 | Approved | $12,500 | 0 days |
| CE-015 | Electrical gear substitution | Procurement | Under review | Pending | Equipment release at risk |
| CE-016 | Level 3 finish revision | Owner request | Pricing received | $8,400 | No identified impact |
| CE-017 | Existing utility conflict | Field condition | Pricing requested | Pending | Sitework sequence |
| CE-018 | Roof screen modification | Design revision | Withdrawn | $0 | None identified |
Values shown are illustrative only and carry no benchmark implication.
Useful change reporting is less about industry benchmarks and more about live exposure. The measures below tend to change how a project actually behaves:
The number of changes alone does not tell leadership the amount of exposure. Twenty small closed items and three unpriced changes against a milestone are very different situations.
The team cannot tell exactly what work is included, so reviewers price and approve different things.
The change is disconnected from the RFI, drawing, owner decision, field condition, or other trigger that created it.
Pricing is evaluated and approved without anyone checking what the change does to the schedule.
A request for time does not identify the work, procurement item, or milestone actually affected.
Reviewers cannot understand what the requested value represents, so the review turns into a negotiation about missing information.
Nobody knows whose action is next, and the change sits between two parties who each believe the other has it.
The change is executed, but budgets, commitments, forecasts, schedules, or reporting stay outdated.
The decision exists in threads rather than in the controlled project record, and it disappears when people move on.
Multiple unrelated issues in one record become difficult to evaluate, approve, and audit later.
Change registers are usually sorted by number or dollar value. Neither reflects operational urgency. Priority should reflect:
Illustrative example. A $100,000 change affecting work six months away may require less immediate operational attention than a $5,000 unresolved change blocking tomorrow's inspection or material release. The dollar values shown are examples only.
The change order is one document. Change control is the broader operating process around identifying potential changes, assigning responsibility, documenting source records, estimating cost, evaluating schedule impact, reviewing and negotiating, obtaining decisions, managing approvals, updating project financials and commitments, updating schedules, maintaining forecast visibility, reporting exposure, and preserving history.
A project can have strong change-order forms and weak change control. The form proves a decision happened. Change control is what keeps that decision connected to cost, schedule, and the work in the field.
On a small project, documents, a spreadsheet, and a weekly meeting may be enough. As volume grows, that breaks down — because the issue, the pricing, the approval, and the financial impact end up in four different places. Teams running structured change control are generally solving for:
None of this requires a specific vendor. It requires that potential changes, financial exposure, project records, and approvals do not live in disconnected places.
Jet.Build connects project changes to the information behind them — budgets, commitments, RFIs, documents, approvals, schedules, and reporting — so teams can see both the individual change and the project-wide exposure.
Potential, pending, approved, rejected, and executed changes stay visible in one project workflow.
RFIs, drawings, submittals, proposals, and attachments remain connected to the change they support.
Changes can be reviewed alongside budgets, commitments, contract values, and forecast information.
Each item shows status, responsibility, and the next action required.
Reviews and decisions follow the project's configured workflow and preserve history.
Teams can review active change exposure instead of reconstructing it from separate spreadsheets.
Teams can use Jenny, Jet.Build's built-in assistant, to surface underlying project records and summarize project information. Pricing, contractual decisions, and approvals remain the responsibility of the project team. Changes also stay connected to the wider construction project management record.
At the end of the process, the project should be able to answer every one of these questions without reopening an email thread:
The change order is the final record of one decision. The change-control process is how the project keeps hundreds of those decisions from becoming disconnected from cost, schedule, and execution.
Where change orders connect to project controls, financials, RFIs, schedules, and approvals.
Take about 30 minutes with our team to see how Jet.Build connects potential changes, RFIs, budgets, commitments, approvals, schedules, documents, and reporting across active projects.
Schedule a Demo