Improving Productivity By Reducing Rework
Bob Longhorn of CAI gave a masterful talk describing how the cost of rework can be killing software projects and how reducing rework could be the quickest way to improved productivity. Bob defined rework not as I normally do (redesign, reimplementation, retest of existing software to add functionality) but as the amount of churn, the rework of fixing things that were not done properly the first time in a development project. I believe Bob said many organizations have 30% of this rework and he say at least 1 organization with 70% rework.
That says that improved processes and reviews could improve productivity by 30% just about all by themselves.
Even at Galorath I see rework at times that could have been avoided by reviews and verification that review changes were made. We all know it is many times less expensive to fix a problem up front than when the software is in test. Yes, we have processes, but sometimes that extra review just doesn’t happen due to perceived time constraints.
It is a shame so many organizations think they don’t have time for reviews. They don’t have time not to have them.
Bob says (correctly) that experimentation and prototyping are NOT rework. and that every deliverable should be inspected before declaring it complete. Quoting Bob “”Nothing Will Provide A More Significant Improvement in productivity Than Improved Quality”
Socalizing An Estimate
We are sometimes asked how to “socialize an estimate”…. That is a great question. According to dictionary.com socializing is “to treat as a group activity.” What a great idea.. getting stakeholders involved in the estimate process as well as applying the estimate to project plans. Socializing the estimate means it is not just a one time event that is thrown in the corner but a cornerstone of project planning. An provides the groundrules and assumptions as well as the results and risks for the viewing (and sometimes changing) by those involved. Of course the changing needs to be controlled so we don’t have stakeholders attempting to drive down the schedule or cost by making arbitrary changes. That is why SEER for Software provides versioning and configuration management of estimates.
I still shutter when I recall some time ago, a program manager who stated that he had nothing to do with the estimate… that others produced them and he ignored them.. he generated a plan completely independent of the estimate. That is more than just a shame. Socializing estimates can mitigate that. And help ensure project managers and other take ownership.
Software Sizing, Estimation, Risk Management Book Available in Japanese
I received copies of the book Software Sizingl, Estimation, and Risk Management: When Performance is MEasured, Performance Improves, translated into Japanese. I dont know the link to purchase the Japanese version yet. The English version may be obtained via http://www.amazon.com/Software-Sizing-Estimation-Risk-Management/dp/0849335930/ref=sr_1_1?ie=UTF8&s=books&qid=1213648096&sr=8-1 I am honored that the Japanese publisher found this book valuable enough to translate and look forward to much dialog with Japanese speakers on this. I originally envisioned this book as the elements fo software sizing. The publisher thought it would be better to include estimation as well. Mike Evans, my coauthor, thought we should do this as a series of three books. We had another book planned “7 Characteristics of Dysfunctional Software Projects” when Mike became terminally ill. Mike thought that book should still be written but I haven’t been able to bring myself to write that book without Mike.
