Rework doesn’t show up as a line item, but it’s one of the most expensive things a delivery-intensive business does. Every piece of work done twice is time that didn’t go somewhere else — and that somewhere else usually had more value.
The direct cost is obvious enough: the hours to redo the work. But that’s not actually the expensive part. The expensive part is the disruption to everything else. Work that had to stop so this could be fixed. Commitments that moved because resource was pulled sideways. The decision that didn’t get made because the person who needed to make it was dealing with a problem that shouldn’t have existed. Rework generates a queue of secondary disruptions that teams rarely track and almost never attribute to the original cause.
There’s a trust cost too. Clients in delivery-intensive businesses aren’t just paying for the output — they’re paying for confidence that things will work as agreed. Rework, especially when it surfaces late, erodes that confidence in ways that don’t immediately appear on a project report. The client who stops pushing back on rework has usually stopped expecting it to go away.
Most teams I work with have normalised a level of rework they don’t realise they’ve normalised. It just becomes the rhythm — fix this before it goes out, rework that before the review, check it again before the handoff. The effort looks like thoroughness. It’s actually the cost of something upstream not working cleanly.
That upstream problem is almost always one of three things: a brief that wasn’t specific enough before the work started; a handoff that moved work to the next stage without the right quality check at the right point; or a decision that was made too late and required the work to be redone once more information arrived. These aren’t difficult to fix. They require someone to name them, and to build the practices that prevent them rather than the practices that catch them after the fact.
The distinction matters. Catching rework is a downstream response. Preventing it is an upstream discipline. Many operations are quite well organised around catching — review cycles, approval stages, QA steps. Fewer are well organised around the upstream conditions that generate rework in the first place. And so the downstream machinery keeps running, absorbing effort, normalising a cost that never appears clearly on any report.
A simple test is useful here: look at what your team reworked last week. Not what was corrected as a normal part of delivery — there’s a difference between iteration and rework. What had to be substantially redone because it didn’t meet a standard it should have met the first time? How much of that was genuinely unavoidable? And for the rest: what would have had to be different upstream to prevent it?
Most teams don’t do this accounting. When they do, the number is higher than expected, and the upstream causes are more specific — and more fixable — than the general sense that “things could always be tighter.”
Building the upstream practices that reduce rework is part of the operating discipline work in Create Momentum. So is making the current cost visible before it becomes something the business has simply learned to carry.