Why software projects truly fail

We often hear the depressing statistics about the failure of software projects - a case of history repeating itself. In many cases, software development projects go over time and over budget. The clients are not happy because:

• The software took too long to product, deadlines were not met
• The solution cost too much, it went over budget
• The software didn't deliver the core functionality
• The software that was delivered was of poor quality

Software developers are not happy either - they had to deal with constant change requests, having to implement new features and do bug fixes close to the release dates. This then progresses into a “triangle of blame”:

• The clients are blamed because of incomplete, ambiguous and rapidly changing requirements requests
• The developers are blamed due to poor practices in software design and development
• The managers are blamed for setting unrealistic schedules and poor communication

Numerous attempts have been made to tackle this problem, with various methodologies and processes suggested, ranging from change request control to agile management. However, software project failure still persists.

Analyzing why software projects fail: the economics perspective

Software features fall under the following categories:

• High value, low cost: these are the features which bring a lot of business value, but they are relatively inexpensive to make
• High value, high cost: these are the features which bring a lot of business value, but they are also correspondingly costly to make
• Low value, low cost: these are the features that are both cheap and useless
• Low value, high cost: these are the features that cost a lot of development time, but yet bring little business value

Ideally, for software projects to be successful and have high payoff, we’d want to target our efforts at achieving the first two options. Unfortunately, most software projects end up in the bottom scenarios, where a high portion of the budget is spent on low-value functionality. That’s why we hear reports of software that cost too much but yet failed to deliver business functionality.

Solving project failure with an 80-20 outlook

The Standish Group research study has reported that only 20% of software features are used always or often, and that 80% of features are sometimes, rarely or never used!  A logical conclusion of this is that 80% of money spent on a software project has gone to waste because it did not provide value.  A central aspect of the 80-20 rule (Pareto principle) is focusing on the things that matter.

• Clients need to ensure to identify core business values first and then the software functionality, which helps to produce requirements which are of business value rather than 1001-item wishlist
• Managers need to ensure that the majority of development and test time is spent on features which matter to the client, the functionality that is of high value

Thus, if the 80-20 rule is recognized and applied, it would mean that a software project, rather than being an overbloated soup of all features would instead be more focused on the 20% of functionality which actually matters. The result would be that software could be delivered much faster, with lower cost and bring much higher business value.

But to achieve this goal, it takes a radical shift in attitude in clients’, managers’ and developers’ approach to software projects.