Rework measurement should show effort spent correcting or repeating work against an agreed need, with the reason attached. Separate customer scope changes, ambiguous criteria and production mistakes. Keep the original decision context visible so a total leads to a useful improvement rather than an unfair judgment of people or customers.
Agree what you are counting
Define rework for the workflow and explain the boundary. Correcting a report that uses the wrong period is different from adding a newly requested analysis. Both consume effort, but they call for different action. Planned iteration within a design process may be normal delivery rather than an avoidable error. Use the agreed scope and acceptance criteria to distinguish these cases instead of labelling every revision a failure.
Choose a unit that supports the decision, such as hours by delivery item or the number of returned items. Retain the related work identifier and the point where the need for repetition was discovered. If effort estimates are approximate, label them accordingly. Avoid comparing teams whose work complexity and recording practices differ. A detailed recorder can appear worse than a team that never captures corrective effort, even when the underlying process is healthier.
Record reasons without creating a blame code
Use a small reason set with examples: changed customer need, unclear agreement, missing input, production correction and unresolved cause. Allow a brief explanation and more than one contributing condition where necessary. Do not force staff to choose a person as the cause. The purpose is to reveal which condition should change, not to make people conceal work that might count against them.
Check classification with a few shared cases. Ask whether two colleagues can distinguish an approved scope change from a correction under the original agreement. Where the record is ambiguous, preserve that uncertainty and investigate proportionately. Connect relevant quality issues to their own customer-response process. Counting hours is not a substitute for correcting an affected output or informing the responsible customer owner. Keep sensitive project detail out of broadly shared summaries.
Turn the pattern into a targeted trial
Review totals by reason and by the point where the issue became visible. A large amount of repeated work caused by unclear approval criteria suggests a different improvement from recurring source-data mistakes. Examine several actual cases before proposing a change. A numerical category can conceal distinct situations, and a large one-time change may not justify redesigning a routine process.
Select an action with an owner and a review period. Clarifying acceptance, checking input readiness or improving a handover may be more useful than adding another final inspection. Compare subsequent work using the same definitions and note changes in scope or demand. Do not promise that a particular action will eliminate rework; some learning and customer change remain part of legitimate delivery.
Preserve both the operational and commercial view. An authorised customer change may need a new estimate or agreement even if it is not classified as quality failure. An internal correction may remain included in the existing commitment. Route those questions through the appropriate owners instead of allowing the reason label alone to determine what the customer is charged. The measurement should inform decisions rather than silently make them.
Fictional worked example
A fictional scenario to explain the method, not a customer result or a market benchmark.
In the fictional studio Reed Pattern, twenty revision hours appear in a monthly report. A case review assigns eight hours to an approved customer change, seven to ambiguous approval criteria and five to a production mistake. The categories sum to twenty, but the team does not describe all twenty hours as quality failure. It retains a short explanation for each group.
Reed Pattern chooses to trial a clearer approval brief for comparable work. The production mistake receives its own correction and review, while the authorised change follows the normal scope process. At the next cutoff, the team compares the same categories and notes any difference in project complexity. These invented figures illustrate classification and arithmetic, not a claim that the new brief will remove seven hours from every future month.
TAKE THIS INTO YOUR NEXT CONVERSATION
A practical next-step checklist.
- Define correction, change and planned iteration boundaries.
- Keep effort linked to the agreed work and criteria.
- Use reason categories with an uncertainty option.
- Trial an improvement matched to the observed cause.
Common questions.
Should planned design iteration count as rework?
Choose and explain a rule appropriate to the process. Separate expected iteration from correcting a failure to meet agreed criteria so the total remains useful.
Can rework hours determine customer charges automatically?
No. Commercial treatment depends on scope, agreements and authorised decisions. Use the record as evidence and involve the appropriate owner.
Further reading & source context.
These primary references provide background. They are not evidence for the fictional example above and do not endorse AccelerateLink.
Found an error or a missing qualification? Send an editorial correction.
Find my next move.
Use a practical tool to turn this idea into a clearer starting point.
Find my next move