Why software development projects go wrong

There are basically three types of software development projects:

• those which are a success
• those which struggle, but eventually come to a successful conclusion
• those which fail

This article considers some of the factors which determine where projects go wrong.

In my experience, projects often go wrong right from the very beginning. It’s rarely caused by lack of skills. Most software development teams contain highly qualified, intelligent people, but things still sometimes go drastically wrong. Let’s consider why this could be.

Poor requirements

This is probably the major reason why projects go wrong. If the top-level requirements are not correct, it’s almost impossible for a project to succeed. In some projects, it’s fairly easy to determine the requirements. In others, especially projects which are particularly innovative, in can be very difficult. There is a lot of skill required in writing good software requirements.

Some reasons why the requirements are sometimes poor are described below.

Not considering the needs of all stakeholders

The stakeholders are all the people who will have contact with the product in some way. It’s easy to completely forget some stakeholders. For example, the people who are going to maintain the product are stakeholders, so their needs should be considered from the very start. It’s necessary to get the stakeholders to state their needs themselves. It’s not sufficient that the project members or team leader attempts to guess the needs of the stakeholders, because they almost certainly don’t have the specific knowledge of each stakeholder.

Gold plating – over engineering – adding too many features

It’s a tendency of many engineers (perhaps including myself in the past) to add too many features to the product. Most engineers want he customer to be happy with the final product and it is often assumed that this means adding as many features as possible. This is often not the case – the customer would prefer something simpler, which is easier to use. Occasionally, the customer himself is to blame for requesting too many features. I’ve experienced this in cases where the customer is requesting technical bids from several companies – they keep asking the supplier to add new features, without increasing the price, with the threat that the competition will win the tender if the extra features are not added.

Other reasons are listed below

• Requirements which do not correspond to features the customer wants
• Making the requirements too detailed
• Mixing what should be separate requirements into one requirement
• Mixing requirement levels, e.g. mixing up high and low-level
• Missing requirements
• Requirements which are not implementable
• Requirements which are not testable
• Teams which are too large
• Giving programmers the task of writing requirements
• Adding more people to a project which is already late
• Not giving enough responsibility to individuals
• Performing “big bang” integration
• Not testing enough
• Unrealistic time scales
• Not taking the deadlines seriously