Change Order Identification for General Contracting
Change Order Identification defines how potential changes to scope, cost, or schedule are spotted early and captured in a consistent way. It covers watching field work, documents, and client requests for change triggers, then separating valid changes from noise. The process logs each potential change, checks it against the contract and current scope, and prepares it for pricing and approval. When followed, true changes are rarely missed, notices are timely, and the team has a clear list of pending change events instead of surprises at the end of the job.
Train project team on change triggers and contract basics
Step 1: Review contract change provisions
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.
Step 2: Create a simple “change triggers” cheat sheet
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.
Step 3: Summarize entitlement and notice concepts
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.
Step 4: Hold a short training session with project staff
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.
Step 5: Distribute cheat sheet to field and office
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.
Step 6: Revisit training after first few changes
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.
Monitor field work and client requests for potential changes
Step 1: Attend or review daily field huddles
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.
Step 2: Review daily reports and site photos
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.
Step 3: Track informal client and user requests
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.
Step 4: Encourage field staff to flag potential changes
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.
Step 5: Review new owner or consultant correspondence daily
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.
Step 6: Compile a list of potential change events
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.
Compare new drawings, bulletins, and RFIs to current scope
Step 1: Maintain a “current contract documents” set
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.
Step 2: Log new bulletins, addenda, and revised drawings
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.
Step 3: Perform side-by-side comparison for impacted areas
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.
Step 4: Note potential scope impacts in plain language
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.”
Step 5: Check if changes align with existing allowances or alternates
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.
Step 6: Add potential design-driven changes to your list
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.
Screen subcontractor and vendor change requests for validity
Step 1: Log each subcontractor change request
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.
Step 2: Compare requested work to subcontract scope
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.
Step 3: Confirm field events and direction
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.
Step 4: Categorize request as potential change or cost issue
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.
Step 5: Group similar requests where appropriate
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.
Step 6: Add valid potential changes to your list
For requests that appear to be valid changes, add them to the potential change list with notes on which subcontractors are affected and how.
Log potential change events in a central register
Step 1: Set up a change event register template
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.
Step 2: Assign a unique ID to each new potential change
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.
Step 3: Write a clear, brief description
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.
Step 4: Record the source and reference documents
Note the source type (owner request, bulletin, RFI, unforeseen condition, subcontractor request) and reference any specific document numbers or field tickets.
Step 5: Note initial affected trades and systems
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.
Step 6: Update status and next step
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.
Classify change events and perform initial impact scan
Step 1: Define change categories for the project
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.
Step 2: Assign a category to each change event
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.
Step 3: Estimate rough magnitude of cost impact
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.
Step 4: Estimate rough schedule or operational impact
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).
Step 5: Highlight urgent and high-impact events
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.
Step 6: Update status to reflect classification
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.
Review entitlement and notice requirements for each change event
Step 1: Revisit contract change and notice clauses
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.
Step 2: For each event, compare facts to contract language
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.
Step 3: Determine whether notice is required and by when
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.
Step 4: Decide preliminary entitlement status
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.
Step 5: Document entitlement notes in the register
Add short notes to each event describing why you believe there is or is not entitlement, referencing contract sections where possible.
Step 6: Flag events with urgent notice deadlines
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.
Group related items into coherent change events
Step 1: Review register for similar or connected items
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.
Step 2: Decide grouping logic for the project
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.
Step 3: Merge closely related low-value items
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.
Step 4: Keep distinct events separate when needed
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.
Step 5: Update IDs and references consistently
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.
Step 6: Communicate grouping decisions to team
Let the project team and relevant subcontractors know how you are grouping change events so they can align their pricing, documentation, and communication accordingly.
Issue timely notice of potential changes to client
Step 1: Identify events requiring notice this cycle
Filter the change event register for items marked “Likely entitled” or “Unclear” that have notice deadlines approaching. Prioritize high-impact events.
Step 2: Use a standard notice template
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.
Step 3: Draft notices with clear, factual descriptions
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.
Step 4: Route draft notices for internal review
Have the project manager review notices before sending to ensure accuracy and appropriate tone. Adjust language if needed to match company and client expectations.
Step 5: Send notices to required client contacts
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.
Step 6: Update register with notice status
Mark each event as “Notice sent” in the register and record the date sent. Note any immediate client responses or questions in the comments.
Handoff qualified change events to pricing and approval workflow
Step 1: Define “ready for pricing” criteria
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).
Step 2: Review change register for events meeting criteria
Filter the register for events that meet your “ready for pricing” conditions. Confirm their descriptions and classifications are clear enough for pricing to start.
Step 3: Assemble supporting documents for each event
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.
Step 4: Create a brief pricing request summary
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.
Step 5: Notify responsible person for pricing
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.
Step 6: Update status in register to reflect handoff
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.
👈 Use this SOP template inside Subtrak
Edit with AI. Customize in seconds. Store and share all your SOPs and checklists in one place.