How to Cost a Job That Changed Mid-Stream

Why this matters

When scope changes mid-job, most shops quietly give up on costing that job. The estimate no longer describes the work, so the variance number is meaningless, so nobody computes it, so the job leaves no data behind. That is a problem, because changed jobs are not rare and they are not random. They cluster on the job types and property classes where your scoping is weakest, which makes them the highest-value records you own and the ones you are most likely to throw away.

The second cost is worse. A changed job costed carelessly does not just lose information, it injects bad information. Cost 39.5 actual hours against a 24.0-hour original estimate and the record says you were 65 percent over. That number goes into a rollup, drags a job type's median, and triggers a template correction on a template that was never wrong. Now you are overpricing your clean jobs to cover a change-pricing problem you have not identified.

The core rule: one estimate, one cost segment

Every estimate you issue creates its own cost segment. The original estimate owns the hours and materials for the original scope. Each change order owns the hours and materials for its own added scope. You cost each segment against its own baseline, separately, and you never let them blend.

This is the whole method. Everything below is mechanics for doing it without a fight.

Step 1: Set the cut point the moment the change is identified

The cut point is a timestamp, not a paperwork event. It is the moment work on the original scope stopped being what the crew was doing. Log it when the tech identifies the condition, not when the change order comes back signed, because the hours between those two moments are real and they belong to the change, not to the original scope.

If you wait for the signature to start segmenting, every hour of investigation, pricing, and waiting gets charged to the original scope. That inflates the original segment's variance by exactly the amount your change process is slow, and you will spend the next quarter trying to fix a template that measures your own paperwork lag.

Step 2: Classify the change before you price it

Four classes, and they cost differently and feed back differently.

The classification decides where the cost lands and which part of the business gets the feedback. Lumping a missed condition in with a discovered one is comfortable in the moment and destroys the one signal that would have improved your site walk. Be honest at the record level even when you are generous at the invoice level: you can absorb the cost commercially and still code it as a missed condition internally.

Step 3: Issue a written revised baseline, even for a small change

The revised estimate needs the same three fields the original had: hours by task, material quantity, and expected trips. A change priced as a single number with no hour breakdown cannot be costed later, which means every change order you write that way is a job you will not be able to learn from.

Include a stand-down and remobilization line on any change that pauses work. A default worth committing to: 1.0 hour per technician on site for each approval pause, plus real drive time if the crew has to leave and come back. Tune it after a few jobs, but do not leave it at zero, because it is never actually zero and the hours will otherwise land in the original scope's variance where they will be read as slow work.

Step 4: Code every hour and every part to a segment

The techs need exactly one extra field on the time entry: which segment. Original, or change 1, or change 2. Make it a dropdown, not a note field, or it will be filled in with prose and nobody will be able to sum it.

Materials follow the same rule, and materials are harder because a single supplier invoice often carries both segments. Split it at receipt, when someone still remembers what the parts were for. Splitting it at month end is guesswork wearing a decimal point.

Step 5: Cost each segment against its own baseline

Compute variance per segment, per bucket. Never compute a whole-job variance against the original estimate. The only legitimate whole-job number is actual total against revised total, and even that is a commercial figure rather than an estimating one.

Step 6: Decide what feeds the rollup

The original segment feeds the job type's template rollup. It is the only part of the record that describes the work the template was written for.

The change segments feed a different rollup: how accurate is your on-the-spot change pricing. That is its own skill with its own error rate, and it is almost always worse than your planned-estimate error rate because it is done under time pressure, on site, without the material list in front of you.

The disruption hours feed a third place: your change-order template's stand-down line.

Three rollups from one job. A shop that only keeps one is throwing away two thirds of what the job taught it.

Worked example: a 24-hour job that closed at 39.5 hours

The original. Estimate 24.0 labor hours, materials at 1.00x allowance, 1 trip.

The change. Midway through day two, the crew opens up an area and finds a condition the site walk could not have reached. Classified as a discovered condition. The customer approves a change order the same afternoon: 8.0 additional labor hours, additional materials.

Revised baseline: 24.0 + 8.0 = 32.0 hours.

Actual: 39.5 labor hours.

The wrong read. 39.5 against the original 24.0 is 15.5 hours over, 65 percent over the 24.0-hour original estimate. Recorded that way, this job alone would drag its job type's median hard and look like proof the template is badly light.

The right read, segmented. The time entries carry segment codes, so they sum cleanly:

• Original scope: 25.0 hours logged.
• Change scope: 11.0 hours logged.
• Stand-down and remobilization while the change was investigated, priced, and approved: 3.5 hours logged.

25.0 + 11.0 + 3.5 = 39.5 hours, which reconciles to the total.

Original segment variance. 25.0 actual against 24.0 estimated is 1.0 hour over, about 4 percent over the 24.0-hour original estimate. That is inside any reasonable flag threshold. The template for this job type is fine, and it is only visible as fine because the record was segmented.

Change segment variance. 11.0 actual against 8.0 estimated is 3.0 hours over, 38 percent over the 8.0-hour change estimate. That is a real miss and it is the actual finding of this job. On-the-spot change pricing at this shop is running well light.

Disruption. 3.5 hours against a change-order template that carried no stand-down line at all. Two techs on site, one approval pause, so the 1.0-hour-per-tech default would have carried 2.0 hours. The remaining 1.5 hours came from the crew waiting on a material run for the change, which is a separate lesson: change-order materials need their own staging step, not an assumption that the truck covers it.

What actually changes. Nothing happens to the job type's labor template, because the original segment says it is accurate to within about 4 percent. Two other things change instead. First, on-the-spot change estimates get a contingency until the change-pricing rollup shows the error rate coming down - if changes are running consistently in the high 30s percent over, a starting correction near 1.3x on the hour count is defensible, then re-measured after 5 more changes. Second, the change-order template gains a stand-down line and a material-staging line.

What the unsegmented version would have produced. A 65 percent labor overrun on the job type, a template correction pushing 24.0 hours toward 30 or more, higher prices on every clean instance of this job type, and no correction at all to the change pricing that was the real defect. The shop would be less competitive and no more accurate.

Costing a change you never billed

The uncomfortable case: work was added, the crew did it, and nobody wrote a change order. The temptation is to leave those hours in the original segment because there is no revised baseline to cost them against.

Do not. Create a zero-revenue change segment and code the hours to it. The job's margin takes the hit either way, and it should, but the original segment stays clean and your template stays honest. The count of zero-revenue change segments then becomes its own metric, and it is one of the most useful numbers a shop can watch: it measures how much work you are giving away without deciding to.

Read it as a share of jobs rather than a share of hours. A shop where more than about 1 job in 5 carries a zero-revenue change segment does not have a costing problem, it has a change-order conversation problem, and no amount of template correction will touch it.

What changes the answer

Time and materials. Segmentation still matters for learning, but the commercial urgency drops because the customer carries the hours. Keep coding segments so your change-pricing accuracy stays measurable, since you will bid fixed-price work on the same job types.

A change so large it becomes a different job. When the change scope exceeds the original scope, stop treating it as a change. Close the original job at its actual, open a new job with its own estimate, and let both cost cleanly. Attempting to run a 24.0-hour job with a 60.0-hour change bolted on produces a record nobody can read.

Multiple small changes. Below a certain size, per-change segments create more coding overhead than they return. A workable default: segment any change of 2.0 hours or more individually, and pool everything smaller into a single "minor changes" segment on the job. Tune the threshold up if your crews are pushing back on coding, because a threshold that gets ignored is worse than one set too high.

A customer-caused delay that is not a scope change. Site not ready, access not provided, another trade not finished. That is not a change segment, it is a delay, and it belongs in its own bucket. Mixing delay hours into change scope makes your change pricing look worse than it is and hides a pattern that may be concentrated in one customer or one property class.

How to verify you got this right

• The three segment totals sum to the job's total logged hours, with no unassigned remainder. An unassigned remainder means the coding is not being done at entry.
• The original segment's variance is computed against the original estimate only, and nowhere in the record does the total actual sit next to the original estimate as if they were comparable.
• Every change segment has an hour breakdown behind it, not just a price.
• Your change-pricing error rate is tracked separately from your estimating error rate, and you can state both. If you can only state one, the segmentation is not reaching the rollup.

References

• U.S. Small Business Administration (SBA), contract change management for small contractors
• Standard construction practice, change order documentation and cost segregation
• See related: The Job Costing SOP; Change Order Documentation Discipline; Documenting a Mid-Job Discovery to Protect the Re-Quote