Return on Software: Maximizing the Return on Your Software Investment
This chapter is from the book
This chapter is from the book
This chapter is from the book
Almost every software organization on the planet is in the unenviable position of having to do the best it can with limited resources. We could always do more, and we could probably do it better, if we just had more people, more time, or more money. How do we get the most out of the resources we do have? How do we maximize our "bang for the buck"? That's what this book is about—helping you, the practicing software professional (or, the software professional-in-training), make purposeful, appropriate, business-conscious technical decisions so that you and your employer can get the most out of the limited resources you do have. This chapter explains why software professionals need the concepts and techniques in this book and gives a survey of the rest of the book.
Software on Purpose
There are hundreds, if not thousands, of books on how to develop software. Books on C, C++, Java, CORBA, XML, databases, and the like abound. However, most software organizations don't have a very good track record with the software they develop. After studying thousands of software projects, the Standish Group observed that about 23% of software projects fail to deliver any working software at all [Standish01a]. Unfortunately, these projects aren't being cancelled until well after their original schedule and budget have been exceeded.
The Standish study also showed that for projects that do deliver software, the average one is 45% over budget, 63% over schedule, and delivers only 67% of the originally planned features and functions. Based on our industry's track record, a software project that's estimated to take 12 months and cost $1 million can be reasonably expected to take closer to 20 months and cost about $1.5 million, while meeting only two thirds of its requirements.
Tracy Kidder [Kidder81] reports that about 40% of the commercial applications of computers have proven uneconomical. These applications don't show a positive return on investment in the sense that the job being automated ended up costing more to do after the system was installed than it did before. Return on investment is defined in Chapter 8, but, simply, those organizations paid more to develop the software than the software ever earned back for them.
Assuming the Standish and Kidder data can be combined, the resulting statistics are rather grim. If 23% of all software projects are cancelled without delivering anything, and 40% of the projects that do deliver software are net money losers, then about 54% of all software projects are counterproductive in the business sense. Over half the time, the organizations that paid for software projects would actually have been better off financially had they never even started those projects.
The total amount of money spent on software development in the United States has been estimated to be more than $275 billion annually [Standish01b]. This means a sizeable amount of money is being wasted every year—around $63 billion in cancelled software projects alone. The money wasted annually could be as much as $149 billion if projects not showing a positive return on their investment are included. These numbers may even be conservative when you consider that larger projects are much more likely to fail than smaller projects [Standish01b], [DeMarco99]. Be aware that this cost data is for the United States only; there's a lot of software development going on outside the United States. There's not necessarily any reason to believe that software organizations outside the United States are any more—or any less—successful, so the worldwide annual results could be staggering.
There might be a million and one different reasons for the poor software project performance observed by the Standish Group. Maybe
The customer's requirements and specifications were incomplete, vague, or ambiguous.
Those requirements kept changing throughout the project.
Bad design decisions were made.
The staff didn't have enough expertise in new technologies used on the project.
The projects weren't given enough resources to be successful.
The projects weren't sufficiently planned and managed.
The project's externally imposed deadlines were unrealistic to begin with.
. . .
Underlying all of these reasons is the more fundamental reason of bad business decisions being made. Either consciously or unconsciously someone decided to
Not provide the project team with complete, precise requirements
Allow the requirements to change throughout the project without considering—or maybe even being aware of—the effect of requirements change on project success
Use an inappropriate design
Not properly address—or even consider—the risks and uncertainties new technologies impose on software projects
Not provide enough resources for the project to be successful
Not sufficiently plan or manage the project
Impose unrealistic deadlines on the project
. . .
In spite of there being so many books on how to develop software, there aren't many books on why that software is being developed in the first place. Knowing why the software is being developed will help decision makers make better business decisions. This book doesn't say anything about how to develop software. It's all about why, and why not.