Progress that goes backwards.

What happens when a curve can't fall

In practice, it doesn't go down. That is the failure.

The progress figure for that activity stays where it was. The rework happens, consuming hours and material, and those are recorded against something — often the same activity, occasionally a general code. The activity now shows the same percentage as before while having consumed the resources twice.

Two consequences follow. Productivity for that activity is wrong, and it is wrong in the flattering direction, because the output stayed constant while the input grew and only the input was recorded. And the completion date is wrong, because the work everybody believes is finished is not.

It surfaces at handover, which is the worst possible time and the reason the last ten percent so often takes thirty.

The mechanism that is missing

What is needed is not complicated: a way for reported progress to be reduced, with a reason attached, and a rule about when it applies.

The rule matters more than the mechanism. Not every non-conformance reverses progress. Some are documentation issues. Some are accepted as-is. Some require a repair that is genuinely additional work rather than a redo. Only the last category should move the percentage backwards

, and somebody has to decide which category each one is in.

Without that rule the choice falls to whoever is updating the sheet, and they will reasonably leave the number alone rather than explain a reversal to a meeting.

Rework has to go somewhere

The second half is where the hours land.

If rework is booked against the original activity, the activity looks unproductive and nobody can tell whether the crew was slow or the work was done twice. If it is booked to a general code, the activity looks fine and the general code becomes an unexplained lump that grows all year.

Neither is satisfactory, and the workable answer is a rework flag rather than a separate account

: same activity, marked. It keeps the cost where the work happened and makes the second attempt visible, which is the only way anybody learns anything from it.

The one that never closes

The second failure is quieter than reversed progress and it accumulates in the same place.

A non-conformance is raised, a disposition is agreed, and the physical work is done. Nobody goes back and closes the record. Six months later the register holds a hundred open items, most of which were resolved long ago, and the ones that genuinely matter are indistinguishable from them.

By handover this becomes concrete: an open NCR against a system can block a completion certificate, and somebody has to go through them one by one under time pressure to work out which are real. That exercise is always more expensive than closing them as they went.

Which is the same closure problem as Week 9 and Week 23, in a third register. Nothing closes by itself.

On a project that is already running

If you are setting this up, decide the categories of non-conformance, decide which reverses progress, and add a flag rather than a code.

Inherited: the odds are that nothing reverses and rework is invisible. The first useful step is not to fix it. It is to find out how large it is — take the NCRs from the last quarter, find the ones that required physical rework, and ask what happened to the reported percentage of each. If the answer is nothing in every case, you now know the direction of the error in your curve, which is worth more than a corrected number.

System design

Two decisions, taken before the first non-conformance rather than during it: which categories reverse progress, and where rework hours land.

Record	Produced by	Required quality	Verified against	Feeds
NCR	QA/QC	Linked to the activity, not only to the system	Inspection record	Quality, progress
Category	QA/QC lead	Decided before the event: does it reverse progress	The disposition	Progress adjustment
Rework hours and quantities	Site engineer	Flagged against the original activity	Timesheet	Productivity, cost
Progress adjustment	Project controls	Applied with a reason, not silently	The NCR	Report, schedule

The category is the field that does the work. Without it the choice falls to whoever is updating the sheet, and they will leave the number alone.

Practical insight

Take the last ten NCRs that required work to be redone. For each, look at the progress reported for that activity before and after.

If none of them moved, your curve has never gone down, and the difference between it and the site has been accumulating quietly. Then look at where the rework hours went. If you can't find them, they are inside the original activity, making a crew look slower than it was.

Key takeaways

• Quality is the only input that subtracts, and most systems have no mechanism for it.
• When progress can't go down, the activity keeps its percentage while consuming resources twice.
• Productivity is then wrong in the flattering direction: input grew, recorded output didn't.
• Not every non-conformance reverses progress. The categories have to be decided before the event.
• Without a rule, the person updating the sheet leaves the number alone, and they are being sensible.
• Flag rework against the original activity rather than hiding it in a general code.
• On an inherited system, measure the size of the error before trying to correct it.

Records born here. NCR register · rework-flagged hours and quantities · the progress adjustment record.

What is coming next

Two more sources and the inputs are complete. The next one produces no quantities at all — it produces stoppages.

Next week: permits, holds and stand-downs, and lost time as a delay event with a record behind it.