Stephen Larrison posted an article in his blog, Survive Outsourcing, about how to compete with offshore-outsourced projects by fixing the requirements mess up front. His background in manufacturing, as well as software development has lead him to a similar perspective as the one I touched briefly on in my post about where bugs come from.
Stephen points out that “You have to eliminate scrap and rework†in order to compete with teams that have lower cost implementation resources. He points out that this is the key to improving productivity in software development, just as it is in the manufacturing world.
I read a book a little over 10 years ago, The Machine that Changed the World, by Womack, Jones, and Roos. They first introduced me to the concept of the value of investments made upstream in the process. They specifically showed the payback of a dollar invested during the design of a new product (their focus was automotive) yielding the same results as ten dollars spent after a product enters manufacturing. It had the same effect as $100 spent fixing problems after they’ve been released to the field. IIRC, their point, in 1991, was that Japanese manufacturers were investing more at the design stage than U.S. Automakers. Seems almost prescient now with Toyota set to overtake GM as the largest car manufacturer in 2006.
There’s an analogous rule of thumb in software development that requirements bugs cost ten times as much to fix after they reach development, and 100 times as much to fix once they’ve been released to the field. A requirements bug caught in development seems cheap (you only have some wasted effort and minor delays associated with re-working the software to meet the corrected requirement), when you compare it to cost of releasing buggy software – which can result in lost sales and added costs (if the cost of “repair†is accounted for). But truly, the savings comes from fixing the bug before anyone starts building part of the solution based upon the incorrect requirement.
In Stephen’s article, he references CIO magazine, and an eye-opening statistic: “71 percent of software projects that fail do so because of poor requirements managementâ€. It is seriously worth a read. Here are some more statistics on software project failures.
Scott
