As if Re-work Wasn’t Enough …
Studies show that somewhere between 25-50% of software project budgets are consumed by re-work. That means work that needs to be done again because, for some reason, the results were not correct. Significantly, 70-85% of this rework is directly related to poor requirements. Of course, we all know that there are many reasons requirements fall short and that there are many things that can be done to remedy this. But if the wasted budget wasn’t enough to think about, there’s more!
After the average project spins its wheels burning through scarce resources and eventually reaches the ‘goal-line’ with a finished product, we run head-first into another sobering industry statistic: for every software product delivered, 45% of the features, on average, are never used! [1] That’s right. NEVER used.
There could be many reasons why we spend lots of time and money building features that aren’t needed by the user community, but my money would be, once again, on poor requirements. Some probable sources:
- Requirements elicitation and analysis wasn’t thorough enough to truly understand the needs of the business and/or the user community
- Requirements validation with stakeholders was inadequate allowing unneeded features to remain undetected
- Requirements ambiguities that allow developers to “fill-in the blanks” with unnecessary functionality
- Insufficient user and other stakeholder involvement at key points during the development lifecycle prevented these issues from being detected
- Inadequate scope management allowed additional and unsanctioned features to be introduced at various points throughout the development cycle
It’s difficult to estimate how much of a project budget could be saved by not building those 45% unused features. It depends on how significant and ‘deep-rooted’ the features are. At one end of the scale, they could simply be superficial features and options whose exclusion would have little or no impact on the underlying layers of the application. At the other end, like an ice-berg, they could represent just the exposed parts of much larger underlying capability. I suspect most are of the former kind, but 45% is a big number. It’s likely that some unneeded features involve significant capabilities of the application.
Adding to the additional development costs for these unused features, there are also the testing costs. Tests have to be written and test data created; the tests have to be run and the results reported; and bugs have to be fixed and then retested with regression-all for a feature set that will never be used. Then, the support group needs to learn more than they’ll ever get support calls for. And add to that, the costs to create training materials, guides, tutorials, online help and other resources for unused features.
The maintenance cost of the application will also be larger than it needs to be. Not necessarily because bugs will be reported on these unused features, but because as long as they exist and are in service, any fixes and enhancements will need to be regression tested to ensure that they remain unaffected.
Those are the hard costs that are incurred when you create an application with 45% unused features. But the soft costs are also significant. New users are forced to learn much more than they will ever use in practice. Plus, the usability of any application with so many unused features has to be negatively impacted. At a minimum those who designed the user interface would have had to make compromises in terms of menu and ribbon designs, wizards, dialog boxes, and preference-option screens to accommodate these additional features. It’s likely that any designer would be able to create a better and more efficient user-experience by focusing on the exact 55% of features that were actually needed.
When looking to improve the economics of application development for business, efforts should be focused on those areas with the largest potential for gain. I would suggest that reducing the 25-50% of your budget wasted on rework, and preventing the creation of 45% unused features are good places to start. And that means improving your requirements.
Don’t forget to leave your comments below.
[1] Jim Johnson. The Standish Group International Inc. 2002.
Tony Higgins is Vice-President of 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. Tony can be reached at [email protected].