Successful Software Development: It's Not Rocket Science

Sometimes I wonder after years of software development whether the way we work has changed very much. Sure, technology has moved on at pace, but has our approach to running software development projects.

Users remain baffled by techno speak, developers prefer to invent rather than reuse and know what is best for you before you tell them what you want, while projects often miss deadlines and exceed budgets.

Just look at the Ministry of Defence who wasted nearly £30m on two IT projects alone. The first project, a communications system for the RAF, was abandoned because of problems integrating it with other systems and £21m was written off. The second, a pay system for the Navy, was closed when it became clear the project would cost three times the expected amount of £18.9m. £8.7m had already been spent, this too was written off.¹

Avoiding the common pitfalls of software development is not rocket science; it's simply a case of taking some sensible measures. Identified here are five killer mistakes of software development.

1. Getting the Requirements

The Mistake

One of the cardinal sins in software development is rushing into a project in a peak of enthusiasm without taking enough time to understand what the customer wants. This is one of the most common mistakes and is responsible for more failed software development projects and unnecessary rework than anything else.

The Solution

Get the customer requirements first and then fit the solution to the requirements. Avoid the "we know what you need" syndrome that still exists among some developers.

It's a good idea to use a business analyst to gather the requirements as they take a non-technical, objective view of what the customer wants.

It's all to easy to get railroaded into 'coding' before the requirements are fully understood, but time spent up front with the customer will prevent much pain and rework later.

2. Understanding the Lingo

The Mistake

Have you ever stood next to a group of software developers and wondered what on earth they were talking about. It's like a new language and to non-IT people it often is. The pitfall comes when the customer and IT think they are talking the same language when in fact they are not. This leads to a problem when the IT department delivers what they understood the customer wanted and it turns out to be something different.

The Solution

Communication problems are the hardest to resolve, as often it is only looking back the problem is identified. Regular communication and a close working relationship with the customer will help. What you need is a person with a foot in both camps. Someone who understands the business and IT equally well. If you can identify this person make sure you keep hold of them, they are hugely valuable. If you are unable to find this person, the next-best alternative is to have two people, one from the business and one from IT. By working closely together and sharing information, they can reduce any communication problems.

3. Managing Expectations

The Mistake

Often there is an expectation that IT is like a magic wand you wave and suddenly a miracle occurs. During a software project, expectations can inflate to a ridiculous degree. It is the role of the project manager to manage expectations to a sensible level.

The Solution

One-way to avoid inflated expectations is to break a project into smaller pieces or phases. I equate this to a sausage machine, where you feed in the raw material at one end and out it comes as small, perfectly formed, packages or sausages at the other end. The same can happen with software projects where you take small packages of requirements and push them through the machine, producing several deliverables over the life of a project. This way you manage expectations by making frequent deliveries to show what the technology can deliver. This approach ensures the project delivers to the customers' expectations by giving them early visibility of what you are building.

4. Prototyping

The Mistake

Customers often find it hard to articulate their requirements, with many people only able to say what they want when they see it. Building a system when you are not clear what the requirements are is a serious mistake. If the developer has not understood the requirements, it is likely that this will not show until late in the development life cycle.

The Solution

When there is a lack of clarity about the requirements, an effective technique is prototyping. A non-functional prototype can be produced quickly and cheaply to help you draw out detailed requirements from the customer. This way the developer tests his understanding of the requirements and avoids waste and rework later.

5. Testing Comes First

The Mistake

If the customer tests the software and finds a high number of bugs, however minor, you will lose their confidence. It is always harder to get customer confidence back once they have had a bad experience. It is easier and more cost-effective to test the software thoroughly for bugs before giving it to the customer.

The Solution

Use professional testers to test the software; they look at it from an user's perspective. Never ask the person who developed the software to do the testing, they will not be objective and already know how the software is intended to work. You need someone that comes to it fresh and asks, is this logical, is it intuitive, does it work and does it meet the customer requirements.

You can show the software to the customer before it is tested, but do not let them have access without being in control yourself.

Finally

Research in April 2003 for Unilog, the independent pan-European IT consultancy and services company, found that 100 per cent of IT managers had experience of a project that had failed to meet all of its objectives. Three of the reasons given for these failures were:

1. Lack of proper ties between IT and the business.
2. Expectations not properly set.
3. Inadequate project scoping.

Concentrating on these three aspects alone will give you a good chance of success.

Don't become the victim of a failed software project, put measures in place that will ensure your success. After all, it's not rocket science!

References

¹ MoD Wastes £30m on Failed IT Projects, Jane Wakefield, ZDNet UK.