Rework

Rework is repeated work caused by incomplete input, unclear criteria, late correction or a change discovered after the output has already moved forward. In SMEs it often looks like normal effort, but it is one of the clearest signals that a process interface is not well designed.

In brief

Rework consumes capacity the company has already paid for. It increases lead time, makes workload appear higher than demand, and hides the difference between productive work and correction work.

The key diagnostic point is that rework usually appears downstream from where it is created. The correction may happen in one team, while the cause sits in a previous handoff, a missing field, a weak definition of done or an unclear decision rule.

Reducing rework means finding the loop, tracing it upstream and changing the condition that allowed incomplete work to move forward.

Operational definition

A case is rework when three conditions are present: the work has moved forward, it returns or is corrected, and the return could reasonably have been avoided through clearer input, criteria, ownership or validation.

Not every revision is rework. Some iteration is legitimate. Some variation comes from new information. Rework is the avoidable part of repetition.

A useful measure is first pass yield: the share of cases that pass through the flow without returning to a previous step. Low first pass yield means the process is spending capacity on correction.

Why it matters for SMEs

SMEs often absorb rework through goodwill. People stay late, correct files, call again, enter data twice or rebuild missing information. The company sees commitment, while the system loses capacity.

This can produce a wrong staffing decision. A team asks for more people because it is overloaded, but part of the overload is repeated work generated earlier in the flow.

Rework also creates conflict. The team fixing the error blames the team that sent the input. The upstream team believes the downstream team is too rigid. Without a shared cause map, both views remain partial.

For external evaluation, hidden rework weakens the quality of earnings: margins depend on correction effort that is not visible in the standard numbers.

Observable signals

Look for repeated versions of the same file or request.

Look for work that moves back and forth between the same two roles.

Look for recurring missing information.

Look for side notes used to explain what the official form does not capture.

Look for phrases such as “send it back”, “fix this again”, “we always check that manually” or “it was not complete”.

Common mistakes

The first mistake is interpreting rework as carelessness before checking the process. Sometimes skill matters, but recurring rework usually has a structural cause.

The second mistake is adding a final check instead of improving the input. Final checks catch errors when they are already expensive.

The third mistake is measuring only where the correction happens. The useful question is where the need for correction was created.

The fourth mistake is mixing normal revision with avoidable rework. The categories must be separated.

Operational example

An administrative team appears overloaded and asks for more support. A sample of recent cases shows that many return at least once before completion. The main causes are incomplete intake information and different interpretations of what “ready” means between two roles.

The intervention is not additional headcount. The company agrees on a definition of done for the handoff, adds three required fields to the intake step and names one owner for input completeness.

After several weeks, first pass yield improves and the team recovers hours previously spent on correction. The workload problem was real, but part of it came from rework rather than demand.

Diagnostic questions

What percentage of cases pass through the flow without returning?

Where does correction happen?

Where was the cause created?

Which inputs are repeatedly missing or ambiguous?

Which definition of done is shared between the sending and receiving roles?

Which rule prevents incomplete work from moving forward?

Practical implications

Start with one flow and 20 to 30 recent completed cases. Count returns. Classify causes upstream. Separate normal revision from avoidable repetition. Then place a barrier at the source: clearer intake, required fields, a definition of done, or a named owner for input completeness.

Remeasure after six to eight weeks using the same method. Report the result in hours recovered, not only in percentages.

MARTRO reading

In MARTRO’s reading, rework is a signal of interface ambiguity. It shows where roles do not share the same standard for what must be handed over, in what form and with which completeness criteria.

The solution is rarely a generic appeal to attention. It is usually a small piece of operational governance: a clearer handoff, a quality gate, a definition of done, or an explicit owner.

When to go deeper

Go deeper when correction loops consume capacity, when teams blame each other for incomplete input, or when a staffing request appears before rework has been measured.

Natural next steps are the guide on reducing rework, process mapping, RACI and bottleneck analysis.

Frequently asked questions

Is every revision rework? No. Some revision is planned or legitimate. Rework is the avoidable repetition created by weak input, criteria or ownership.

How do we measure it quickly? Count how many recent cases returned to a previous step. First pass yield is the share that did not return.

Where should we intervene first? At the source of the cause, not at the place where the correction is performed.

Can rework explain overload? Yes. A team can be overloaded because demand is high, because capacity is low, or because too much work is being repeated.

What is the simplest useful output? A cause table, first pass yield before and after, and one changed handoff rule.