What to Carry Forward From a Job That Went Wrong

Why this matters

Most shops review the jobs that go badly. Very few change anything as a result, and a smaller number still change the wrong thing. A lesson that lives in a story dies with the person who tells it, and a lesson bolted onto the quote template because one job hurt makes every future quote worse. The useful question after a bad job is narrow: which instrument, if any, changes. If you cannot name the instrument, you did not learn anything, you had a bad week. And if the honest answer is that nothing changes, that is a real answer and it needs recording too.

Siblings own the review meeting itself and the durability of knowledge. See related: The After-Action Review That Turns a Bad Job Into a Lesson, and Capturing a Lesson So It Outlives the Person Who Learned It. This card is about what the review is allowed to do to your paperwork.

The gate

One question, asked about the cause rather than the outcome:

Is this cause a property of the job type, or a property of that day?

A property of the job type recurs whenever you run that type of work: an access assumption that is wrong on a class of property, a step that always takes longer than the template says, a condition common to a building era. A property of that day does not: a supplier error, a customer who changed their mind, an unusual weather window, a tech working their first job of that kind.

The gate is about the cause, not the size of the loss. A large loss from a one-off is still a one-off, and a small loss from a structural cause is still structural. Confusing the two is how shops end up with a quote template shaped by their worst memories rather than by their actual distribution of work.

Where a lesson can land

A carry-forward is a change to a specific instrument. There are not many, and naming them makes the review concrete.

If the review ends without one of these being edited, nothing was carried forward, whatever was said in the room.

When one instance is enough, and when it is not

Set the trigger explicitly, because the failure runs both ways: shops that change nothing until it hurts three times, and shops that change everything on the first sting.

Change an instrument when there are three recorded instances of the same cause on the same job type, OR on a single instance whose cause is a safety event or near-miss, whichever comes first. That is an OR, deliberately: the count arm and the safety arm are independent and either one alone is sufficient. The unit of analysis is the cause on a job type, not the job. Three bad jobs with three different causes is not three instances of anything.

The safety arm carries no counting because a near-miss is a free instance of the event you are trying to avoid, and waiting for the second one is waiting for the injury.

When the instrument being changed is a number, move it half the observed gap, not all of it. A template that jumps to the full actual on every bad job oscillates for a year and never settles, because a single job's actual contains that job's noise as well as its signal.

Outcome one: it lands

A shop finishes a job at 31.0 hours against a 20.0-hour estimate, which is 55% over. The debrief traces the cause to access: on this class of property the route to the work is longer and more restricted than the template assumes, and the crew lost hours moving material and re-staging.

Run the gate. Access as a function of property class is a property of the job type, not of the day.

Now count. The shop pulls eighteen months of that job type and finds nine jobs on that property class. If you cannot run that query, the manual version is a wall of index cards, one per bad job, sorted by cause; it is worse and it works. What does not work is doing it from memory, because memory sorts by how much the job hurt. Four of the nine carry the same overrun signature. Four instances clears the three-instance arm, and the cause is the same one in all four, so the trigger is met.

The tempting change is to add hours to the template for that job type. Resist it, and the reason is in the numbers: five of the nine jobs did not have the problem. Adding staging hours across the board, whether the full 11.0-hour gap or half of it, would price the shop out of those five to protect the four, which is paying a certain cost for an uncertain event. That is the shape of problem a sibling handles properly. See related: How to Price Risk You Can Name but Cannot Size.

So the lesson lands in two instruments instead, both cheap:

• A survey trigger. When the property matches the class, the surveyor spends about 0.75 hours walking and photographing the material route before the quote goes out. That converts the unknown into a known on the jobs where it matters and costs almost nothing on the jobs where it does not.
• A conditional line in the estimating template. When the survey confirms the restricted route, the template adds staging hours. The first version of that figure is set at half the observed gap rather than the full 11.0 hours, so roughly 5.5 hours, and it gets re-checked after the next three jobs of that class.

Read the second bullet against the first case's own numbers before accepting it: the 11.0-hour gap came from one job, and the other three affected jobs may not have run as long. Half the gap is a starting figure, not a finding. The re-check after three more jobs is what turns it into one.

Outcome two: it does not land, and that is the correct answer

Different job, same shop, same quarter. A supplier ships the wrong item, the correct part takes five working days, and the shop absorbs two extra mobilizations plus the schedule damage to two other customers. It was an expensive week and everyone is annoyed.

Run the gate. The cause is a supplier picking error. It is not a property of this job type; it would have happened on any job with that item on it. Now count: the shop searches three years of records and finds one prior instance with that supplier, on unrelated work. That prior one does not count here, because the unit is the cause on a job type and it was a different job type. So this is instance one.

One instance, no safety event. Neither arm of the trigger is met, so no instrument changes. The estimating template is not touched, no new exclusion goes into the quote, and no allowance is created.

That is the discipline, and it is harder than it sounds because the loss was real and recent. What does happen is a single line in the carry-forward register: cause observed, no change made, date, and the count so far. That line is doing genuine work. It converts a one-off into the first entry of a countable series, so that if it happens twice more the trigger fires on evidence rather than on whoever remembers being angry about it.

A shop that only logs the changes it made cannot ever reach three instances of anything, because instances one and two were never written down.

What a false carry-forward costs

The reason for the gate is that unnecessary changes are not free, and their cost is invisible in a way the original loss was not.

An exclusion added after a one-off makes every future quote slightly harder to read and slightly more defensive, which is the surprise problem in a different form. See related: The Exclusion That Was in the Quote and Still Cost the Job. Hours added to a template after a one-off make every future quote of that type less competitive, and you never see the jobs you did not win. A checklist step added after a one-off gets performed by every crew on every job forever, and steps that exist for reasons nobody remembers are the ones that get skipped first, taking the credibility of the whole checklist with them.

The accumulation is what kills a template. Three years of one-off reactions produces a quote nobody can read, a checklist nobody completes, and hours nobody can justify, and none of it maps to the shop's actual distribution of work.

The register, and the prune

Keep one register, not one per department. Five fields per entry: the cause in one sentence, the job type, the instrument changed (or "none"), the date, and the running count of instances. Nothing else - a register with a narrative field becomes a story archive and stops being countable.

Then prune it annually, and treat the prune as seriously as the additions. For each instrument change made more than a year ago, ask whether the cause has occurred since the change and whether the change is still doing work. A template uplift that was right when it was set and has not been tested against the last twelve jobs is a guess with seniority. Removing a change is a legitimate carry-forward and it should appear in the register as its own entry.

Verifying a carry-forward is real

• Can you name the instrument that changed and point at the edited document?
• Does the register entry name a cause, or does it name an outcome? "Job ran over" is an outcome and it cannot be counted against anything.
• If the trigger fired on the count arm, do three recorded instances actually exist, on the same cause and the same job type, or does the count include jobs that went wrong for different reasons?
• If a number moved, did it move half the gap, and is there a date for the re-check?
• Does the register contain any "no change made" entries? If it does not, the shop is only recording the times it reacted, and its counts are unusable.
• On the safety arm, was the change made on the first instance rather than deferred to a pattern?

References

• 29 CFR Part 1904, recording and reporting occupational injuries and illnesses, which applies to your own employees and is separate from any commercial job review
• See related: The After-Action Review That Turns a Bad Job Into a Lesson; Capturing a Lesson So It Outlives the Person Who Learned It; How to Price Risk You Can Name but Cannot Size; The Exclusion That Was in the Quote and Still Cost the Job