How to Review a Losing Job Without Assigning Blame

Why this matters

A job that lost money is the most useful data your shop will generate all month, and it is the one you are least likely to look at. The reason is social, not technical. Everybody in the room knows whose hours are on the sheet, so the review turns into a defense, the crew learns that a bad number means a bad conversation, and the next set of time cards quietly gets rounded toward the estimate. Once that happens you have destroyed your own measurement instrument, and every estimate you write after that is built on numbers people massaged to stay out of trouble.

The goal of a losing-job review is a corrected estimate, not a corrected person. Run it so the crew has no reason to shade the data, and you keep the feedback loop alive. Run it as an inquest and you get one honest cycle followed by years of clean-looking, useless numbers.

Step 1: Commit to the review before you know whose job it is

Set the trigger by number, in advance, and apply it to every job that crosses it. A workable default, and note it sits above the flag threshold rather than replacing it: a bucket variance past about 15 percent puts a job in the weekly costing queue for a quick look, while a job whose labor hours land more than 25 percent over the normalized estimate, or that finishes below zero margin, earns the full blameless review below inside seven days. Two tiers, two different amounts of everyone's time. Write that rule down and post it.

The reason this comes first is that a discretionary review is always read as an accusation. If you only call a review when a particular crew runs long, the review IS the accusation, whatever words you use. A threshold that fires on the owner's own quoted jobs as readily as on a second-year tech's is the only version that survives contact with real people.

Seven days matters too. Past about two weeks nobody remembers which day the access problem showed up, and the review degrades into speculation dressed as recall.

Step 2: Normalize the scope out loud, before anything else

Pull the approved change orders and add their hours to the estimate. Say the corrected number aloud so the room is working from the same baseline. A job that ran 58 percent over the original estimate but only 36 percent over the scope-corrected estimate is a different job, and the difference is not a technicality: the first number blames the crew for work the customer added.

Skipping this is the most common way a review goes wrong in the first three minutes. The crew knows about the added work, sees you quoting the raw number, and concludes you are not arguing in good faith. Everything after that is theater. If a scope change was done but never approved in writing, normalize it anyway for the review, then handle the paperwork gap separately with the office. Do not use the review to punish a missing signature.

Step 3: Read all three buckets before anyone speaks to cause

Put labor hours, material quantity, and travel hours on the board as three separate variances, each with its own sign and size. Do not let the conversation start on the biggest one.

The reason is that the biggest variance is almost always labor, labor is the bucket with a person's name on it, and starting there sets the frame for the whole meeting. Reading all three first does two things: it shows the room that you are looking at a system, and it frequently reveals that two buckets moved together, which is a much better clue than either alone. Material 12 percent over and labor 36 percent over on the same job is a scope or condition story. Labor 36 percent over with material dead on estimate is a method or access story.

State each variance with its base in the same clause: "10 hours over a 28 hour corrected estimate, so 36 percent over." A percentage floating free of its base is how a review ends up arguing about two different numbers.

Step 4: Run the counterfactual on the estimate first

Ask the estimating question before the execution question: given what we now know was true on that site, what would a correct estimate have been? Answer it in hours.

This single reordering is what makes the review blameless without making it soft. It puts the estimate on trial first, and the estimate belongs to the shop. It also produces the number you actually need, because the output of the review is a better estimate, not a verdict.

The answer splits the variance into a part the estimate should have caught and a part it could not have. The part it should have caught is a template correction. The part it could not have is either genuine site randomness or an execution issue, and only now is it worth separating those two.

Step 5: Ask what the job told them, not why they were slow

The question that gets honest answers is "walk me through where the day went sideways," asked once, then silence. The question that gets defensive answers is "why did this take 38 hours."

Two more phrasings that work, because they ask for information rather than justification:

• "If you ran this same job again next week, what would you set up differently on the first morning?"
• "What did you find on site that was not in the write-up?"

The second one is the highest-yield question in the whole review, because a recurring answer to it is a template defect. Log the answer verbatim on the job record. Three jobs later, the same sentence appearing three times is your correction.

Ban a small set of words from the meeting for everyone including yourself: "should have," "obviously," and any sentence beginning with a person's name followed by a verb. Not because feelings are fragile, but because those constructions reliably stop the flow of information you came to collect.

Step 6: When the cause genuinely is a person, take it out of this room

Sometimes the honest answer is that one tech worked at half the pace of the others on a job the estimate had right. Blameless does not mean causeless. It means the group review is not the venue.

Close the group review on the estimating finding, then hold a separate one-on-one about performance, on a different day, framed as coaching with a specific observable: hours on a named task against the crew median for that task, not a general impression. Two separate meetings, because a performance conversation held in front of peers will not just damage that tech, it will teach every other person in the room to stop volunteering information.

The tell that you have merged them by accident: the review produced no change to any estimate or template, only a conversation about effort. That is a performance meeting wearing a costing meeting's clothes, and the crew will read it correctly.

Step 7: Close with one change, one owner, one date

End every review with exactly one written change: a template hour correction, an added scoping question, a materials allowance change, a sequencing rule. Name the person who owns it and the date it is done. One, because a review that produces six changes produces zero.

Then set the check: the next three jobs of that type get their variance read against the corrected number, and the result goes back to the same group. Closing the loop in front of the people who gave you the information is what makes them give it to you next time.

A worked review, carried through

A four-day job type. Estimate at quote: 24 labor hours, plus a material take-off, plus 1.5 hours travel. Actual on close: 38 labor hours, material 12 percent over the take-off quantity, travel 3.2 hours.

Normalize. One change order was approved mid-job, worth 4 labor hours. Corrected estimate: 28 labor hours. Actual 38 against corrected 28 is 10 hours over, which is 36 percent over the corrected estimate. The raw 58 percent over the original 24 is set aside and not used again.

Read all three. Labor 36 percent over corrected. Material 12 percent over take-off. Travel 3.2 hours against 1.5 estimated, so 1.7 hours over, a 113 percent overrun on the smallest bucket. Note that travel more than doubled while material moved only slightly. That pattern points at trips, not scope.

Counterfactual on the estimate. Walking the site conditions as now known: the existing work behind the access panel was in a condition the write-up did not mention, and dealing with it consumed 4 hours of the 10. A correct estimate, knowing that, would have been 32 hours, not 28. So 4 of the 10 hours belong to the estimate.

What the job told them. The crew's answer to "what did you find that was not in the write-up" was the access condition. Their answer to "what would you set up differently" was that they ran the sequence in the order the write-up implied, hit the condition at step three, and had to undo and redo two hours of completed work, then lost another 1.5 hours waiting on a second run for a fitting they had not carried. That is 3.5 hours: 2 hours rework and 1.5 hours of the travel overrun mirrored in labor.

Attribution. Of the 10 hours over: 4 hours estimating (40 percent of the overrun), 3.5 hours execution and sequencing (35 percent), and 2.5 hours unattributed spread across four days (25 percent). Unattributed hours at a quarter of a small overrun are normal noise and get no action.

Is it systematic? The shop pulled the last six jobs of this type. The access condition had been noted in the field notes on 4 of those 6. It was in the estimate template on zero of them. That is not a one-off site surprise, it is a template defect that had been visible in the notes for months.

The one change. The template for this job type gains a scoping question about that access condition, and a conditional 4 hour line that the estimator adds when the answer is yes. The estimator owns it, done by Friday. Not a blanket 4 hour increase on all jobs of the type: on the 2 of 6 jobs where the condition was absent, a blanket increase would have made the shop 4 hours high and cost them bids.

The check. The next three jobs of the type get read against the corrected template. On the two where the condition was present, the corrected estimate would have been 32 hours. Nobody's name appeared in the written output.

What changes the answer

A single-tech job. With one person on site there is no crew median to compare against, so the execution slice is much harder to isolate. Lean harder on the repeatability test: run the same job type with a different tech and see whether the overrun follows the person or the job type.

A job you bid competitively and won on price. The review should still ask the counterfactual, but the finding may be that the estimate was correct and the price was wrong. Those are different problems with different owners, and confusing them leads shops to inflate hours to fix a pricing decision.

A first-of-its-kind job. A 36 percent overrun on a job type you have never run before is not a defect, it is the cost of learning. Review it for what it teaches the template, set no expectation that the crew should have hit it, and do not count it in your bias statistics until you have two or three more.

How to verify you got this right

Three checks, all observable:

• The written output names a document, not a person. Read the closing item aloud. If it is a template, a question, an allowance, or a sequence, the review worked. If it is a name, it did not.
• Voluntary reporting goes up, not down. Count how many jobs in the following quarter had a field note describing an unexpected site condition. If reviews are landing as accusations, that count falls, because saying nothing is safer.
• Your variance spread narrows before your bias does. A shop that starts correcting templates from real reviews usually sees the extreme overruns thin out first, while the median stays roughly where it was. If instead your reported hours suddenly cluster tightly on the estimate across the board, be suspicious: that is what shaded time cards look like, and it is the specific failure this whole procedure exists to prevent.

References

• U.S. Small Business Administration (SBA), job costing and small business financial management guidance
• Trade-standard practice for post-project review and lessons-learned documentation
• See related: How to Separate Estimating Error From Execution Error, How to Compare Estimated Against Actual on Every Job, How to Adjust an Estimate Template From Real Data, The Job That Looked Profitable and Was Not