Three Common Causes of Small Software Project Failure

The statistics on software projects are dismal, with up to 75% of all projects ending in failure (thankfully, things are getting better).

With nearly 15 years running a company dedicated to rescuing struggling software projects, my team and I have seen many failed projects. Here are four of the most common types of failure we’ve seen in small software projects, where small is defined as a development budget less than $1 million:

1. Lack of involvement from product owners

We worked on a small (less than $50k) web app that was developed by a software team through an advertising company acting as a middleman:

The product the client received was only tangentially related to the actual needs of their business. It was beautiful, it was functional, but it failed to meet a single objective of the client.

All of the Software Team’s communication during development happened only with the Ad Agency. The ad agency did not keep the client involved.

Without connecting the development team to the client the project was built for the wrong purpose. A rescue mission was deemed not worth the effort and we were not able to assist.

For some companies, the belief is that work can be specified into a set of requirements, given to a team and the team can produce perfect working software. This is so very far from the truth.

A software product is akin to a new employee. It can perform amazing work but it requires oversight, training, and time to learn how to do the job.

Unless the product owners get and stays involved so that everyone understands how the final product will be utilized, small projects stand little chance of success.

2. Custom software at a fixed price

Fixed bid pricing is hard, because rarely does the software team and the client share a vision of what the finished project will look like. Even well specified projects eventually have areas where there are differences in interpretation.

A fixed-bid project almost always starts out great. The software team makes amazing initial progress, there are regular meetings and the application develops well along most of the requirements.

However, in reality it is a different story. At some point, mismanagement occurs. Too much time is spent polishing a feature. A feature is deferred until later. There is unexpected behavior in an external dependency. Or some part of the project needs to be reworked. And there’s no budget for any of these.

Projects like this are important to stop as early as the problems begin to appear. (I.E. As close to the “Standards dropped” point as possible.) It can be tempting to “force” the team to meet the obligations of the contract, but this can compromise the integrity of the project, which may have started with a solid foundation. In the long run, it’s cheaper to end the engagement with an incomplete project than to push to get a workable output.

Of all failure types, fixed bid is the most painful. There are no winners. Development teams, eager to please their clients, run too deep into the red before declaring the project a failure. Clients, eager to ignore the reality that their project is more expensive than budgeted, push development teams to meet impossible obligations.

In the end, both sides end up unhappy, each side believing the other is responsible. (The answer, of course, usually lies somewhere in the middle.)

A good team will come to you with bad news early and will be very hesitant to offer fixed-bid. Unless of course they’ve done the work before and if that’s the case, you’re better off renting the solution through a SaaS vendor than doing it yourself.

3. Things get complicated

Ask any reasonably talented developer what they could build in 2 weeks and you’ll get answers that have little basis in reality. Many technical problems appear simple at first but the true scope of implementation is revealed only after the project begins.

The world of software development is constantly moving. Everything is built on top of libraries and plugins, all of which are developing at their own pace. Relying on dependencies can provides shortcuts for commonly solved problems.

But at some point in every project, something new is required. It is at this junction when progress slows down and the true cost of every layered dependency becomes clear.

This dichotomy between nearly instant progress and slow-to-develop custom programming can lead to the failure of many small projects. How can a team progress so quickly and then in relative terms perform so poorly when new work is required?

The failure to anticipate and communicate that progress will slow down, perhaps dramatically has lead to many project failures. Rescuing these projects is possible, but only if the development team was disciplined enough to remain committed to their own solution to the new problems.