The Rework Spiral: Why Redoing Work Costs Far More Than Doing It Once

Somewhere in your portfolio is a piece of work that has been finished more than once.

It was done in March, when the team demoed it and everyone agreed it was complete. It was done again in May, after the integration test found that it had been built against the wrong version of an interface. And it was done a third time in July, once a stakeholder finally saw it working end to end and said, gently, that this was not quite what they had meant. Each time, the status went to green. Each time, someone moved on. And each time, the same constrained people were pulled back to do again what they had already been paid to do once.

We have a soft, forgiving vocabulary for this. We call it iteration, refinement, a revision, another pass, incorporating feedback. The words are chosen, half-consciously, to make the thing sound like progress. And some of it genuinely is: discovering that you were wrong and correcting course is how good work gets made. But a large part of what hides under those words is not learning. It is rework: effort spent redoing something that was already supposedly done, to fix a defect, a misunderstanding or a false assumption that could have been caught earlier and was not.

This piece is about what rework actually costs in a portfolio of projects competing for shared constrained resources. The answer is much more than the hours to do the work again, and the excess is almost entirely invisible, because rework is charged to the future while it is recorded, if it is recorded at all, as ordinary progress in the present. I am going to call the mechanism the rework spiral: the compounding, systematically underpriced cost of redoing work in a system where the doing was never the expensive part.

Why rework does not look like it costs anything

Watch what happens on the instruments when a project reworks something. The team is busy, so utilisation stays high. Activity continues, so the plan keeps moving. The work eventually passes, so the status returns to green. On every meter a manager routinely watches, redoing the work reads exactly like doing it: people are occupied, tasks are closing, the project is advancing towards done.

This is the same trap that runs underneath most of flow economics, the one at the heart of The Utilisation Trap and The Dependency Tax: the cost that is easy to see gets managed, and the cost that is structural and invisible gets ignored, precisely because it is invisible. The hours spent reworking are visible, and they look like productive hours, because they are indistinguishable from any other busy hour on a timesheet. The value those hours were supposed to be earning, and are not, is invisible, and so is the fact that they are the second time the organisation has paid for the same outcome.

Because that is what rework is, underneath the gentle vocabulary. It is the constraint doing a piece of work it has already done, instead of doing the next piece it has not. And in a system governed by a constraint, that is close to the most expensive thing you can ask of it. Take the reasons one at a time.

Mechanism one: rework spends your scarcest hour twice

Start with the mechanism that is easiest to state and hardest to feel.

Everything in flow economics turns on the constraint: the one resource whose pace sets the delivery speed of the whole portfolio. An hour of the constraint's time is not just an hour. It is the scarcest, most valuable hour in the system, because it is the hour that governs how fast everything moves. When work is reworked, and the rework lands on the constraint, as it very often does, because the hard, defect-prone, judgement-heavy work is exactly what your best people do, that hour is spent twice on a single unit of value.

The first time bought the value. The second time buys nothing new. It merely restores the ground you thought you already held. So every hour of constraint time consumed by rework is an hour of the system's throughput, permanently gone, exchanged for no additional output. And by The Utilisation Trap, a constraint that is already loaded near its limit does not absorb that extra demand gracefully. Every hour of rework you push onto it lengthens the queue for everything behind it, non-linearly, so the true cost of the redone work is not the redone hours. It is the redone hours plus the delay they inflict on every other project waiting on the same person.

This is why rework is so much more expensive in a portfolio than it is in a single project seen alone. On one project, redoing a task looks like a local slip. Across the portfolio, it is a withdrawal from the one account every project is drawing on.

Mechanism two: the cost of being wrong escalates with how late you find out

The second mechanism is the one that turns a manageable error into an expensive one, and it has nothing to do with how big the original mistake was.

A defect, a wrong assumption, a misread requirement, costs almost nothing at the moment it is made. It costs a little more the moment it is discovered. And it costs dramatically more for every layer of work that gets built on top of it before anyone notices. This is the old quality-engineering observation that the cost of a defect rises by roughly an order of magnitude at each stage it survives undetected: cheap to fix at the point of thought, ten times more once it is built, a hundred times more once other things depend on it and it has shipped. The number is not the point. The shape is: the price of being wrong is set not by the error but by the delay in catching it.

In a portfolio, that delay is usually long, and it is long for structural reasons. A wrong assumption made at the start of a project is not tested until the work reaches the point where reality pushes back, and in a system full of dependencies and handoffs, that point is often an integration, a review, or a first real use, which by their nature come late. By the time the merge point reveals that a foundational choice was wrong, several streams have already been built against it. Fixing it now is not one team's rework. It is that team's rework plus everyone downstream who trusted the thing being fixed. The single wrong assumption has propagated unseen, and the correction has to chase it through every place it went.

This is the strongest argument for Full Kit that no one frames as a rework argument. Starting work before its assumptions are validated does not just risk a stall. It plants a defect at the foundation and postpones its discovery to the most expensive possible moment, when the most has been built on top of it. And it is why the routinely single-digit flow efficiency most portfolios run at is not only a story about waiting. Some of that lengthy calendar time is work being done, discovered wrong, and done again, with the redo hidden inside a busy-looking timeline.

Mechanism three: rework re-enters the queue at the back and slows everything

The third mechanism is where rework stops being one project's problem and becomes the portfolio's.

Redone work is not a fast-forward. When a piece of work bounces back to be corrected, it does not resume from where it left off with the rest of the system politely holding its place. It rejoins the queue as fresh demand, competing for the constraint against everything else in flight, and often it rejoins at the back. So a rework loop does not simply add its own hours to its own project. It adds a new unit of work in progress to the whole portfolio, and by Little's Law, lead time rises with work in progress: more open work means a longer queue for everyone. This is the entire argument of Start Less to Finish More, arriving from a new direction. Rework is WIP you created by accident, and it lengthens the queue exactly as if you had started another project, except this one produces nothing.

So a single rework loop can carry all three costs at once. It spends the constraint on value already bought, it arrived late and therefore large because of everything built on the original error, and it re-enters the system as new WIP that slows every other delivery. The busy hours on the timesheet show none of this. They just look like work.

Why it is a spiral and not simply a tax

Everything so far describes the cost of a single rework loop. What makes rework genuinely dangerous, and what earns it the word spiral rather than tax, is that the conditions which cause rework are the very conditions that rework makes worse.

Run your constraint near a hundred percent and there is no slack to do things carefully: work gets rushed, reviews get skipped, the second pair of eyes is always busy, and corners get cut, which manufactures the defects that come back as rework, which adds load, which pushes utilisation higher still. Put your best people on several things at once and context gets lost across every switch, so mistakes get made that would not have been made with continuous attention, and each mistake returns later as a correction, which adds more work to juggle. Let projects run on green status reports that measure activity rather than risk, and the emerging defects stay hidden until they are structural, so the discovery lands at the most expensive moment, and the rework is maximal. Start work before it is ready and you build on unvalidated ground, which guarantees a later correction.

Each of these is a driver of rework. And rework, once it lands, tightens every one of them: it raises utilisation, adds to the multitasking pile, and consumes the very slack that would have let the next piece of work be done right. That is the spiral. A portfolio under pressure cuts the corners that create rework, and the rework it creates increases the pressure. Left alone, it winds inward: more load, less care, more defects, more load. Organisations that feel permanently busy and permanently behind are often not short of capacity. They are spending a large and unmeasured fraction of it doing the same work twice, and the busier they get, the larger that fraction grows.

A worked example

Numbers make the spiral concrete. Treat them as illustrative, not precise; the shape is what matters.

Take a data platform project whose value, once live, is equivalent to a cost of delay of about £15,000 per week. Early on, a foundational choice gets settled quickly and wrongly: the exact definition of a core metric, agreed in a meeting, written down by no one, and subtly not what the business actually needs. Catching it then would have cost a half-day of validation, the kind of readiness check Full Kit asks for and busy teams skip because the project is approved and everyone wants to look like they have started.

Nobody catches it. The lead data engineer, who happens to be the portfolio's constraint, builds on it. A reporting stream is built on top of that. A partner feed is built on top of the reporting stream. Ten weeks in, at the integration point, the error finally surfaces, because that is where reality first pushes back.

Now the bill. The lead engineer spends about three weeks reworking the foundation: three weeks of constraint time, spent a second time, buying no new value. The reporting team redoes roughly two weeks of work built on the bad definition; the partner-feed team redoes about two weeks more. The corrected work does not slot back in where it was, it rejoins the queue behind other portfolio commitments, so the effective slip to delivery is not three weeks but closer to five. At £15,000 per week, that is about £75,000 of destroyed value on this project alone, plus three weeks of your constraint that could have been advancing the next initiative and instead advanced nothing.

Compare the two numbers honestly. Caught at the point of thought: half a day. Caught at integration: five weeks of delay, four-plus weeks of redone effort across three teams, three weeks of irreplaceable constraint time, and £75,000 of drag. Same error. The entire difference in cost is the delay in catching it. None of it appears as a line called "rework" on the project's report. It appears as a busy, hard-working ten weeks followed by a diligent five-week push to the finish, which is precisely why nobody counts it, and precisely why the bill was allowed to run.

Why single-project management is structurally blind to this

If rework is this expensive, why does almost no organisation measure it?

For the same structural reason the rest of this series keeps returning to: the frame that governs the work cannot see the cost the work creates. Project management, as practised, tracks each project against its own baseline, in units of tasks completed and percent done. Within that frame, redoing a task and doing a task are the same event: a unit of effort, an increment of progress. Better still, rework is usually absorbed invisibly. A slipped date gets re-baselined and the variance disappears. A correction gets logged as a new task, indistinguishable from original work. A round of fixes gets called a sprint of iteration and booked as healthy agility. The single-project frame has no field for "this is the second time we paid for this," so the second payment is recorded as ordinary spend.

But the cost of rework does not live inside the reworked task's plan. It lives in the portfolio around it: in the constraint hours withdrawn from every other project, in the WIP the loop added to everyone's queue, in the drag accruing on a delivery date pushed out by an error caught late. This is the Project Illusion in one of its most costly disguises, the belief that if every project is individually busy and advancing, the portfolio must be healthy. A portfolio can be full of hard-working, green, advancing projects and be spending a third of its constrained capacity doing work it has already done. Rework is not the absence of progress. It is progress you are paying for twice, and it should be counted as one thing, not hidden inside the other.

What to do instead

You cannot drive rework to zero, and you should not try; some of what looks like rework is genuine learning, and learning is the point. The goal is narrower: to stop treating rework as free ordinary work, to make it visible, and to move the discovery of error to where it is cheap. A few disciplines do most of that.

1. Measure rework as a first-class number. You almost certainly track utilisation and percent complete. You almost certainly do not track what fraction of your constrained capacity goes to redoing work rather than doing it. That fraction, the rework rate, is one of the most revealing numbers in the portfolio, and most organisations have never once looked at it. You cannot manage a cost you refuse to name. Name it, and watch it on the constraint above all.

2. Move discovery left, because that is the whole ballgame. Mechanism two says the cost of an error is set by how late you catch it, so the single highest-return investment in flow is anything that surfaces error earlier: validating the risky assumption before building on it, integrating the scary seam first instead of last, putting a rough version in front of a real user in week one rather than week ten. This is the rework case for Full Kit and for retiring the frightening dependency first. Pull the moment of discovery as far towards the start as you can, and the same defect costs a fraction of what it would have.

3. Protect quality by protecting slack. The corner-cutting that manufactures rework is what a fully loaded constraint does to survive. If you run your scarcest people at a hundred percent, you are not buying more output, you are buying the rushed, unreviewed, context-starved work that comes back as corrections. Deliberately leaving slack on the constraint is not waste. It is the capacity to do things once. This is The Utilisation Trap read through quality: the last few points of utilisation are paid for in rework.

4. Stop rewarding green-then-rework. A status system that goes green on activity and only reveals defects at the end is a rework machine, because it hides the error through exactly the window where catching it is cheap. Manage by the signals that show emerging risk while there is still time to act, buffer burn rather than percent complete, as argued in The Watermelon Report. A project that is accumulating latent rework should not be allowed to report green.

5. When work bounces back, re-price the project, do not just redo the work. A rework loop is new information: the remaining investment to capture the value has gone up. Feed that into the investment view rather than absorbing it silently. A project that has reworked its foundation twice may no longer be worth finishing, and the honest place to see that is a return-on-remaining-investment number that rises every time the work comes back, not a re-baselined plan that forgives it.

The objection you are already forming

"So you want everything right first time? That is waterfall. Iteration, feedback, changing our minds when we learn something, that is how good work gets made. Are you telling me to stop learning?"

No, and the distinction is the whole point. Not all redoing is equal. There is deliberate, early, cheap learning, the prototype you built precisely to discover you were wrong before it was expensive to be wrong, and that is an asset; it is discovery working exactly as it should. And there is involuntary, late, expensive rework, the correction forced on you because an error you could have caught early was allowed to survive and propagate until reality exposed it. The first kind you should do more of, on purpose, as early as possible. The second kind is the tax. They look similar on a timesheet and they could not be more different in the ledger, and confusing them is how organisations end up defending their most expensive rework as healthy agility.

Flow economics does not ask you to stop iterating. It asks you to move the iteration to where it is cheap, and to stop pretending that a correction forced on you at the integration point is the same thing as a lesson you went looking for at the start. Every mature delivery discipline has, in its own language, reached the same conclusion. Lean calls avoidable rework a form of waste and hunts it. Modern engineering shifts testing left for exactly this reason. Critical chain protects the work from the disturbances that cause it. They are all paying down the same spiral.

Stop reading a busy team as a productive one. Some of that motion is the system doing, for the second and third time, work it has already been paid to finish. The doing was never where your capacity went. The redoing was, and until you measure it, it will keep winding inward, one green status at a time.

This is a foundations piece in the Flow Economics series. If it changed how you read the busy, hard-working projects on your own board, the natural next questions are how to stop planting the errors in the first place, taken up in Full Kit: Why the Best Time to Start a Project Is When It Can Actually Run, and why loading your scarcest people to the limit is what forces the corner-cutting, which begins with The Utilisation Trap.