Speed and the High Cost of Rework

increased quality - speed - efficiencyOne of my best clients initially contacted me because they simply wanted to get faster at what they do. They needed to deliver more value to their customers more often, and at lower cost. However, they just couldn’t seem to improve. When I paid them a visit, I looked at their product development lifecycle as a whole. Their product roadmap was solid, their requirements specifications and test plans were clear, the team had all the right skills, and their quality was high. So what could be improved?

This company thought they were doing all the right things. Then I interviewed the software team, and the truth came out.

Rework was killing them

Unbeknownst to senior management, product managers were frequently changing requirements after the original specifications were implemented and tested. I discovered that it was common for a couple of their product managers to ask their buddies on the development team to just go ahead and add this one little thing as a favor. No big deal, right? They would add them, then these little changes would break 5 other things. Then 5 new bugs were opened, 5 fixes, 5 retests, and everything works again. At the end of the day, everything was working fine and someone got their pet feature added. Senior management was none the wiser.

Here’s the problem: all that rework has a cost. You may think that because everyone is on salary that these off-book changes were “free.” You’d be wrong.

Consider opportunity cost

All that time spent on sneaking in changes and fixing the fixes adds up. Time that could have been better spent on higher value features. I calculated that my client was losing around $340,000/year to this unplanned rework! This obviously had to stop. What more could you do with that kind of savings?

Here’s what we changed…

We introduced agile practices to the software development processes. This approach enables the incremental delivery of products, instead of one “big bang” at the end. Incremental delivery allows us to inspect and adapt to changing requirements – with complete transparency.

In order to deliver a product incrementally, we break down requirements into user stories, prioritize them in a backlog, and continuously implement, test, and release.

Working in this manner minimizes rework, isolating it to either small bug fixes, or refining the user stories in the current iteration. We can now inspect and adapt, consistently creating value instead of creating waste.

The Result

My client’s organization is still adjusting to working iteratively – the agile way. This is normal. But the payoff is immediate – rework is negligible, and customers get to enjoy new features sooner. That translates to not only cost savings, but a much shorter path to new revenue.

My Challenge for You

Consider the following questions:

  1. How much productivity in your organization is lost to rework? How would you know?
  2. Can you deliver a product incrementally? How frequently?
  3. What can you do right now to go faster, with higher quality, and at lower cost?

Need help answering these questions? Give me a call.

© 2015 Mark Richman. All Rights Reserved.


comments powered by Disqus