REWORK: Stopping Software Development Overruns

For any project, there are two budget numbers: what the project should cost and, a bigger number, what it ends up costing. For many managers, budget or schedule overruns seem like a permanent attribute of software development. The usual solution is to reduce the scope of deliverables or cut corners on requirements analysis, testing or some other work phase in the project.

Of course, correction and revision is part of any developmental process. But did you realize that 50% or more of most software project costs go to repair and rework, not to original development work? Rework represents a huge avoidable cost. Unfortunately, most of the need for rework does not become apparent until testing the actual software, well after specs are frozen and code written. This is the most expensive rework cycle. If you can avoid these costs then suddenly the original estimates for developing software don't look so bad after all.

REWORK: A MANAGEMENT METRIC

QA and testing processes, to a large extent, drive rework. Strong QA procedures will find problems quickly, before the cost to repair skyrockets. When project quality assurance does not measure up, then too many problems go undiscovered until late in the testing effort, or worse, post deployment. At this point, fixing the problem becomes expensive and time consuming.

An effective management metric for assessing rework is the following: measure the time or cost associated with getting the project from inception to the first round of system tests (post-unit test) compared to the time and cost to go from system test to a stable production release. If the latter is more than 50% of the former, investing in better QA and test processes should be seriously considered.

REMOVING REWORK COSTS

There are reliable ways to reduce or eliminate rework. Unfortunately, most organizations do not take the time to implement them, believing that rework is an inevitable part of the software development process. The following are proven approaches to reducing rework:

1. Integrate test design into the requirements process. Ambiguity in defining requirements is the major cause of rework. Deriving test cases from the functional specification is an activity that quickly surfaces these ambiguities. If writing and validation of a specification includes writing of a complete suite of test cases, then the development team is much more likely to get it right the first time.
2. Apply model-based technology to functional specifications and testing. These technologies provide comprehensive descriptions of functionality and thus reduce misunderstandings between the business and the development teams as to expected application behavior. Some modeling techniques automatically design complete test suites. This means that most defects are caught in the early phases of testing when they are still relatively cheap to fix.
3. Invest in test-driven development processes such as agile or incremental development. A major advantage of these approaches is that they focus on reducing functional ambiguities and discovering defects quickly, making rework less expensive.

As in any engineering process, some rework is inevitable. However, too many software projects experience excessive rework-driven cost and schedule overruns. When better QA and test processes are integrated into the development effort, rework drops dramatically.

Experience the difference of getting it right from the start. Visit critical-logic.com or email info@critical-logic.com for more information.