There's no getting around it; developing software is an expensive business, and projects are often delivered late, over-budget, and with reduced features compared with original plans. In this introduction to his book, Steve Tockey explains how software projects can be better planned and executed to minimize waste without sacrificing output.

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.