How Much Rework Do You Have?

As a requirements solution vendor we talk with people every day about their requirements issues, assist them to understand the root causes, and help them articulate a business case for investing in a solution. For most companies, the biggest single inefficiency in their software development efforts is the amount of rework that’s done due to inadequate requirements.  (The reasons as to why the requirements are inadequate are many and beyond this post but stay tuned for a new paper on the topic that goes into more depth).

When we ask people how much rework they have done on their software projects, the answer varies consistently between 5% and 25%.  I find this fascinating since industry statistics show the average rework rate to be considerably higher (Forrester: 30%; voke: 40%).  Why do people regularly report lower rework rates?  Here are some reasons based on these conversations:

Vocabulary

On many projects, rework is simply known by a different name.  In many cases it appears as contingency or padding in other line items within the budgeting process.  In others a large amount of rework is pushed in to maintenance, and in extreme cases a new project may even be positioned.

Awareness

We have had countless conversations where people were simply unaware that rework happened. One reason is related to the vocabulary mentioned above where the rework may be disguised and dispersed under different budget items hiding the true nature of this expenditure as rework.

Scope

It seems that most people only consider the rework that takes place in the development aspect of a project. The total cost of rework depends on many factors including your development process and where you may be in the development cycle, but should  include all impacted areas as well, such as: planning & estimating; all forms of testing (unit test, integration testing, regression testing, etc.); product documentation; user support; services and training; etc.  When all these are factored in, the true magnitude of rework becomes much clearer.

Denial

Rework implies that something was done wrong, requiring work to be repeated.  Nobody likes to be associated with this and for many it is difficult to come to terms with the amount of rework that actually takes place on the average software project.  While initial discussion may start with the claim of minimal rework, after a little inquiry the rate tends to creep up.  I recall one time in particular where the initial rate of 7% rework ended up being 35% after our conversation.

Combinations of the above

Various combinations of the above may be at work, each contributing to the low rework numbers that people report, and may actually believe, on a regular basis.

I wouldn’t be surprised if there are more reasons and would love to hear any you’re aware of. As people realize the true magnitude of rework on software projects, it quickly becomes a prime target for improvement initiatives.

Don’t forget to leave your comments below.

---

Tony Higgins is Vice-Presidentof Product Marketing for Blueprint, the leading provider of requirements definition solutions for the business analyst. Named a “Cool Vendor” in Application Development by leading analyst firm Gartner, and the winner of the Jolt Excellence Award in Design and Modeling, Blueprint aligns business and IT teams by delivering the industry’s leading requirements suite designed specifically for the business analyst.