Keep construction change requests organized before approval

A construction change request needs an intelligible record before anyone can make an informed decision about it. A site photograph, a verbal instruction, an estimate, and a revised drawing can all describe parts of the same issue without establishing the same authority. Confusing those records can leave the team unsure what was requested, what was priced, and what was actually approved.

This guide focuses on organizing the administrative record from first observation to an authorized decision and downstream update. It does not replace the project contract, professional design responsibility, safety procedures, or jurisdiction-specific requirements. The examples are hypothetical and use generic document records that a small contractor can maintain without a particular project platform.

Start with the project’s actual change procedure

Identify the documents and roles that govern changes on the project. Check the required route for notices, requests, instructions, quotations, approvals, and records of completed work. Ask the responsible contract administrator or qualified adviser to resolve uncertainty before building a generic workflow around assumptions.

Record the applicable process reference in the project setup. Staff need to know where to find it and whom to ask when a report falls outside ordinary administration. Do not invent a universal notice period, signature rule, or right to payment based on a template.

Procore’s change order overview discusses changes to scope, cost, and schedule within the contract context. Its change order request guide distinguishes the request and review process. The document structure below is original operational analysis rather than a legal interpretation of either source.

Distinguish an observation from an instruction

An observation records a condition someone has seen. A clarification request asks for information. A proposed change describes an alteration under consideration. An authorized instruction or approved change has the authority established by the project’s governing arrangements. Those states should not share one ambiguous “change” label.

Give the initial record a neutral description. For example, “existing service location differs from drawing reference” reports an observed discrepancy without deciding the technical response, cost responsibility, or contractual entitlement.

Preserve who reported the issue and when. If a verbal conversation occurred, record its factual context and route it for confirmation through the appropriate procedure. Do not transform an informal remark into approval by writing “agreed” in the log. The authorized person must determine the effect of the communication within the project arrangements.

Give each request a stable identifier

Assign a unique reference that stays with the issue through revisions and decisions. Link it to the project, relevant location, work package, drawings, specification references, and any related information requests. Avoid relying only on an email subject that changes as the conversation grows.

Keep the request identifier separate from revision numbers and final change order references. One request can produce several priced options, and several related requests may later form one approved change. The record should preserve those relationships rather than overwriting the original identity.

Use the business audit trail guide to design the broader event history. For construction changes, the important addition is the connection between a specific request, the version reviewed, and the authority of the resulting decision.

Assemble evidence without losing its context

Collect the relevant photographs, marked-up drawings, site notes, measurements supplied by qualified people, and correspondence. Identify where and when each item was created and what it is intended to show. A photograph of a detail without a location may be difficult to interpret later.

Retain original evidence according to the project’s recordkeeping arrangements. If an annotated copy helps explain the issue, label it as a working annotation and keep the original linked. Avoid removing context that could change the meaning, such as cropping out a nearby reference point without retaining the full image.

Do not ask administrative staff to certify technical conclusions they are not qualified to make. They can organize the evidence and identify missing information. The appropriate design, safety, commercial, or site professional must assess the issue within their role and authority.

Describe the proposed scope in plain, bounded terms

State what is proposed to change and what remains outside the request. Refer to the relevant baseline drawing or specification version. If the proposal is still awaiting technical clarification, label it accordingly rather than presenting a complete instruction.

Separate alternatives. Option A and option B should have their own scope and assumptions so the reviewer can compare them. A combined paragraph that mixes several possible responses can make a price appear to cover more work than it does.

Include the location, affected quantity or extent where established, dependencies, exclusions, and the information still needed. The purpose is not to write an exhaustive contract in a log entry. It is to give the reviewer a coherent proposal and clear references to supporting records before a decision is made.

Keep cost and schedule assessments connected to their assumptions

Ask the responsible people to provide cost and schedule effects in the format required by the project. Identify the estimate version, basis, inclusions, exclusions, and validity or review conditions where applicable. A preliminary allowance should not be mistaken for an approved final amount.

For schedule effects, state the dependency being assessed and the information used. Administrative staff should not infer a project’s completion impact by simply adding the proposed work duration to the current finish date. The qualified planning or project team needs to assess the actual sequence and constraints.

Record uncertainty honestly. A cost can remain under review while a technical option is being developed. Show that state and the next decision needed. Avoid entering zero merely because an impact is unknown; a zero can be read as a deliberate conclusion that there is no effect.

Use a review-ready request checklist

Before routing a request, check that the reviewer can identify the issue, understand the proposed response, and see the evidence and assumptions. The checklist should improve completeness without delaying required notices or urgent procedures established for the project.

If an element is missing, distinguish “not applicable,” “not yet known,” and “required before decision.” These labels prevent a blank field from carrying several incompatible meanings.

Route the request without implying approval

Use a small set of clear states, such as draft, submitted for review, clarification requested, decision recorded, and downstream updates pending. Include the responsible person and next review date for any waiting state.

An acknowledgement means the request was received. It does not by itself authorize additional work or establish agreement on cost or schedule. The wording of automatic messages should preserve that distinction. Do not let a dashboard icon carry more meaning than the underlying project procedure permits.

The business handoff checklist provides a general way to define the recipient, required input, and next action. Apply it here so a request does not disappear between site, design, commercial review, and the person authorized to decide.

Record decisions against the exact version

Capture the decision, date, authorized decision maker, applicable reference, and the request or option version being decided. Include conditions, qualifications, or required further action in the record. “Approved” without a version can become ambiguous after another estimate or drawing is uploaded.

Keep superseded versions accessible to those who need the history, while making the current decision obvious. Do not replace an earlier attachment in a way that makes it appear to have been the document originally reviewed.

The document version control guide develops this discipline in more detail. For construction changes, version control has to connect documents to authority as well as to content. A technically current drawing and a commercially approved change may be related without being the same record or completing the same approval step.

Walk through a hypothetical fit-out request

Imagine a small contractor on an office fit-out discovers that the recorded position of an existing service differs from the observed location. The site team follows the project’s applicable safety and reporting arrangements and creates a factual record with a location reference and photographs.

The issue is routed for qualified assessment. Two proposed responses are documented separately, each with its own scope and open assumptions. The commercial and planning teams assess the relevant effects without treating the initial observation as an instruction to choose either option.

The authorized decision later references option B, revision two, with a condition requiring a further design detail. The log records that condition and keeps downstream updates open. It does not show the entire change as ready for execution merely because one stage received approval. This example illustrates record relationships, not a technical solution or contractual conclusion.

Connect the decision to downstream records

Once the appropriate authority is established, identify which records must change: work instructions, drawing registers, procurement requirements, subcontract records, cost forecasts, schedule information, or billing evidence. Assign those updates rather than assuming every team will find the decision in the log.

Keep the affected version references visible in the handoff. A procurement update based on the wrong option can create a new discrepancy even when the decision itself was clear. Ask the recipient to confirm the update or identify the remaining question.

The purchase request process helps with the commercial handoff when additional materials or services are needed. Do not let a draft change request automatically generate a purchase or payment. The downstream action needs its own applicable authority and evidence.

Handle revisions, withdrawals, and overlapping requests

When a request changes materially, create a new revision and explain what changed. Keep the previous version associated with any earlier review. If the proposal is withdrawn, record the reason and confirm what happens to pending actions, quotations, and related notices under the project process.

Check for overlapping scope before combining requests. Two descriptions may refer to the same physical work, or one may assume that another has already been approved. Link the relationship and ask the responsible reviewers to resolve the boundary rather than silently deleting one record.

Preserve rejected or unselected options where the reviewed recordkeeping arrangements require them. Their existence can explain later decisions or prevent the same proposal being submitted again without new evidence. Keep the current state obvious so historic options are not accidentally used as live instructions.

Review the log for stalled decisions and missing evidence

Useful review questions include: which requests lack an owner, which await clarification, which have a decision deadline, and which decisions still need downstream updates? Look at the age and significance of unresolved items rather than only the total count.

Track why requests return for clarification. Missing location details, unclear scope boundaries, and mismatched versions may indicate that the intake standard needs improvement. Avoid using a fast closure target that encourages staff to mark unresolved commercial or technical questions as complete.

Keep access appropriate to the record. Commercial assessments, private contact details, and confidential project material may not belong in the same audience as a general site update. A useful change log gives each participant the information and authority relevant to their work without distributing every attachment indiscriminately.

Pilot the record structure before automating routing

Select several historical requests and reconstruct their identity, evidence, versions, decisions, and downstream effects. Use fictional or appropriately sanitized copies for training. Ask a colleague to explain the current authority and next action from the record alone.

Then apply the structure to a manageable set of live administrative records within the project’s approved procedure. Correct unclear fields and handoffs before adding reminders or automatic distribution. Automation should move a well-defined record, not decide technical scope or interpret contractual authority.

The useful outcome is a request history that another person can follow without relying on memory. It should show what was observed, what was proposed, which evidence informed the review, what was decided, and which authorized action remains. That clarity supports the people responsible for the project while preserving their actual decision roles.

Keep the record usable when the usual coordinator is absent

Create a cover view that shows current requests, upcoming decision points, outstanding notices or procedural questions, and downstream actions already authorized. The backup coordinator should be able to find the applicable project procedure and the person with authority to decide each issue.

Test the cover using one request with several revisions. Ask the backup to identify the current proposal, the version previously reviewed, the decision that has actually been recorded, and any condition still outstanding. If those answers require a private explanation from the usual coordinator, improve the references and state descriptions.

Keep the backup’s permissions and authority separate. They may be able to organize evidence and route a question without being permitted to issue an instruction, agree a price, or authorize work. The record should help them continue administration safely within the role, rather than treating access to a folder as decision authority.

When coordination returns to the usual owner, review material updates through the shared history. This avoids a second narrative developing in private messages. A dependable change record supports continuity because the facts, versions, and decisions remain accessible to the people responsible for them.

Sources and editorial method

Sources checked October 15, 2026: Procore: how construction change orders work and request for change orders. These official references provide general terminology and contract-context background. The register, hypothetical fit-out case, review table, and pilot method are original administrative analysis. No universal notice period, legal entitlement, engineering judgment, safety instruction, or tested software workflow is asserted.