57. The cost of rework

The cost of rework often remains hidden and is generally attributed to external factors:

• The user doesn’t understand the product, so we need to make changes.
• The sponsor changed the requirements, so we need to add functionality.
• It wasn’t what was expected, so we have to do it again.
• The client misunderstood, or the user doesn’t know what they want, or the sponsor wasn’t involved enough, etc.

At its core, these are signs of a deficient process not only in capturing the requirements but also in defining the underlying problems:

• What do the users need?
• What does the business need?
• When is it needed?
• What is the budget?

In software development, there are some rules that are usually advisable to follow:

• Do everything possible to avoid writing code.
• Fully understand the problem before writing code.

How can we then send requirements to software development teams without being 100% sure of what the user really needs, what benefits the business, and what is appropriate for the time and resources available?

Each percentage point we subtract from the level of certainty adds to the complexity transferred to other teams.

That is, if we are 90% sure of the requirements sent for development, the remaining 10% is a hidden cost that will return in the form of rework, sooner or later.

In this scenario, rework is not the worst evil. There is a worse scenario where rework is not required, not because we adequately satisfy the needs, but because our users decided to abandon the product and not let us know.

Thus, you can consider rework as an indicator that anticipates a possible abandonment of your product by users.

Take advantage of it.