Most companies develop their software in-house using a team of engineers. Your company should probably subcontract more of its development work.

Many managers like it that way; they can see whether the team members are working and they like the fact that their colleagues can see that the manager is responsible for a large team.

However, it’s often not an efficient way to work. The teams are often made to work in an open plan office (or cubicles in America) where everyone bothers everyone else, with conversations, telephone calls, meetings, etc.

It doesn’t have to be this way. Some of the work can be sub-contracted to engineers such as myself, working at their own premises. The contract engineer can then get on with the work each day, with no travelling time to work and few disturbances. Of course, this means that the work is judged by results, not by the amount of time, like a team member in the office.

The two major problems with software development projects are that they are often over budget and are delivered late. Large companies often accept this situation – but there are alternatives. If some of the work is sub-contracted, it’s possible to specify a fixed delivery date for each work package. The company also has more control over the costs.

There are a few preconditions for successful subcontracting:

• has to be a certain level of trust between the contractor and the company
• it has to be the sort of work which can be performed externally
• it can’t be classified (secret) development
• the manager has to be prepared to write a statement of work
• the contractor has to do the work
• the company has to pay on time

Visit my site at: www.garthwaite.info

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