Change Order Identification for General Contracting

Read the contract sections dealing with changes, change directives, allowances, and notice requirements. Highlight key points such as how changes must be authorized, time limits for notice, and what documentation is needed.

List common triggers such as owner-directed scope changes, design revisions, unforeseen conditions, differing site conditions, and delays caused by others. Write these in plain language and keep the list short and practical.

Draft a short explanation of “entitlement” (why the contract allows an adjustment) and “notice” (when and how to inform the client). Use simple examples tied to your project type.

Gather the project manager, superintendent, project engineer, and key coordinators for a brief session. Walk through the cheat sheet and key contract points, using real or hypothetical examples to make it concrete.

Share the change triggers cheat sheet electronically and post it in the job trailer. Make sure field staff know who to call when they see a potential change.

After a handful of changes have been processed, hold a quick follow-up conversation to reinforce lessons and clarify any confusion that came up in actual use.

Participate in daily site meetings or at least review the superintendent’s notes to listen for phrases like “owner wants different,” “drawing doesn’t match existing,” or “we had to work around.” Treat these as possible change triggers.

Scan daily reports, photos, and logs for unexpected work, extra manpower, or delays. Look for tasks described as “extra,” “temporary,” or “rework,” and flag them for follow-up.

When the client or end users make informal requests during walkthroughs or calls (for example, “Can we move this wall?”), write them down immediately with date, person, and a short description.

Ask the superintendent and foremen to call or email you whenever they see work that seems outside the original plan. Reinforce that it is better to over-report than miss a true change.

Check email threads and meeting minutes for any language suggesting change, such as “please revise,” “additional,” “delete,” or “alternative.” Highlight these items for further scope review.

Maintain a simple running list or inbox for potential changes, capturing who raised them, when, and a brief description. This list feeds into more formal evaluation and logging.

Identify which drawings and specifications make up the current contract basis. Save them as a clearly labeled set (for example, “Contract Set – Issued for Construction”) in your document system.

Whenever new design documents arrive (bulletins, revisions, updated details), log them with date, description, and who issued them. Link them to any related RFIs or meeting notes.

For each change document, compare affected sheets or details against the current contract set. Look for added elements, reconfigured layouts, changed materials, or additional performance requirements.

For each difference you spot, write a short note like “Added insulation at roof deck,” “Relocated door and enlarged opening,” or “Additional fire dampers at corridor.” Avoid vague labels like “revised plan.”

Review allowances, alternates, and clarifications in the contract to see if the new requirements might already be covered. If not clearly covered, treat as a potential change.

Add each suspected impact to your potential change list with a reference to the specific bulletin, RFI, or sheet. This prepares them for formal logging and further entitlement review.

When a subcontractor sends a change request or extra work ticket, record it with date, vendor, description, and any related field ticket numbers. Store documents in a dedicated “Sub Change Requests” folder.

Read the subcontract scope of work and relevant drawings/specs to see whether the requested work is clearly included, clearly excluded, or ambiguous. Highlight any scope language that supports or contradicts the request.

Talk to the superintendent and review daily reports to confirm whether the work was performed and what directions were given on site. Check whether the subcontractor was told to proceed and by whom.

If the work appears to be beyond the original subcontract scope or driven by client/design direction, mark it as a potential change. If it appears to be a production or estimating issue, mark it as a cost issue needing a different discussion.

If multiple tickets or requests relate to the same underlying change (for example, several trades impacted by a layout shift), group them mentally as one potential change event for future logging.

For requests that appear to be valid changes, add them to the potential change list with notes on which subcontractors are affected and how.

Create or use a standard register with columns such as Change Event ID, description, source (RFI, bulletin, directive, field), impacted trades, date identified, status, and notes.

When you decide an item is a potential change, create a new line in the register and give it a unique ID (for example, CE-001, CE-002). Use this ID consistently in emails and file names.

Describe the potential change in one or two sentences, focusing on what is different from the original contract (for example, “Add sprinkler heads in storage area per AHJ request”). Avoid cryptic abbreviations.

Note the source type (owner request, bulletin, RFI, unforeseen condition, subcontractor request) and reference any specific document numbers or field tickets.

List the trades you expect to be impacted (for example, electrical, drywall, mechanical). This does not have to be perfect at this stage but helps plan pricing later.

Set the initial status (for example, “Identified – pending review”) and note the next step (such as “review entitlement” or “issue notice to owner”). Save and back up the register regularly.

Agree on simple categories such as “Owner-requested enhancement,” “Design coordination,” “Unforeseen condition,” “Regulatory/AHJ,” and “Contractor-driven.” Document these in the change event register template.

For each logged event, assign the category that best fits the primary driver. Use your notes from design and field reviews to guide this choice.

Using judgment and input from the superintendent or estimator, assign a rough magnitude tag such as “Low,” “Medium,” or “High” based on how much cost you expect may be involved.

Note whether the change is likely to affect schedule and if so, whether the impact is minor (no milestone impact), moderate (local resequencing), or major (potential milestone or completion shift).

Filter or color-code the register to highlight change events that are high-cost or high-schedule impact. These should be prioritized for quick notice and pricing.

Change the status of each event to show that it has been classified (for example, “Screened – pending entitlement review”) so you and others can see where each item stands.

Open the contract again and focus on clauses covering changes, differing conditions, delays by others, and notice requirements (deadlines, format, who to notify). Keep this open while you review events.

Look at the description and category of the change event and ask whether it fits conditions described in the contract that allow an adjustment. Note specific contract sections that support entitlement, if any.

For events that may be compensable, identify whether formal notice to the client is required and what the time limit is from when you became aware of the issue. Calculate the notice deadline for each event.

Assign each event a preliminary status such as “Likely entitled,” “Unclear – needs discussion,” or “Not entitled (cost-only or internal).” Be conservative but honest in your assessment.

Add short notes to each event describing why you believe there is or is not entitlement, referencing contract sections where possible.

Highlight events where notice deadlines are imminent or already passed. Prioritize these for immediate action or escalation so the team can decide whether to send late notices or accept the risk.

Scan the change event register for items that share the same source (for example, one bulletin), affect the same area, or result from the same underlying issue.

Agree with the project manager on how you will group changes (for example, by bulletin, by room/area, by system). Choose a method that makes sense to the client and reflects how the work is actually impacted.

For small items clearly tied to one underlying change, merge them into a single event. Update descriptions to reflect the combined scope and adjust impacted trades accordingly.

If two items are technically related but clearly different in cause or entitlement (for example, one owner enhancement and one corrective change), keep them as separate events to avoid confusion.

When you group or split events, update IDs, descriptions, and references so there is no ambiguity. Note prior IDs in the comments so you can trace back to original entries if needed.

Let the project team and relevant subcontractors know how you are grouping change events so they can align their pricing, documentation, and communication accordingly.

Filter the change event register for items marked “Likely entitled” or “Unclear” that have notice deadlines approaching. Prioritize high-impact events.

Prepare a simple notice template that includes project name, event ID, description of the issue, date discovered, and a statement that the contractor reserves rights to time/cost adjustments pending full evaluation.

For each event, draft a notice that describes what changed, when you became aware, and how it may impact cost or schedule. Avoid blaming language; stick to facts and contract references where relevant.

Have the project manager review notices before sending to ensure accuracy and appropriate tone. Adjust language if needed to match company and client expectations.

Issue notices via the contract-specified method (for example, email, portal, or letter) to the designated client representatives. Keep proof of sending, such as sent emails or portal receipts.

Mark each event as “Notice sent” in the register and record the date sent. Note any immediate client responses or questions in the comments.

Agree on what needs to be true before a change event is handed off (for example, scope clearly described, impacted trades identified, entitlement preliminarily confirmed, notice sent if required).

Filter the register for events that meet your “ready for pricing” conditions. Confirm their descriptions and classifications are clear enough for pricing to start.

Gather all related RFIs, bulletins, sketches, field photos, subcontractor requests, and internal notes for each event. Save them in a dedicated folder named by the change event ID.

For each event, prepare a short summary that describes scope, assumptions, affected trades, and any schedule concerns. This helps estimators or project engineers understand the context quickly.

Send the pricing request and supporting documents to whoever owns change pricing in your organization (estimator, project engineer, or project manager), referencing the change event ID and desired turnaround time.

Change the status of each event from “Identified” or “Screened” to “Sent to Pricing.” Note the date and who it was sent to so you can track progress and follow up in later change order processes.