The 5 Common Pitfalls of Software Projects
There is no silver bullet answer for how a business should construct or engage a team to successfully deliver a software development project. Options can include using in-house developers, a local on-shore software services supplier, an off-shore development company, on-shore developers from off-shore companies, freelancers, near shore developers and probably a few more.
Regardless of the above choices and where you sit within the business, there are a few common pitfalls that should be understood by everyone involved!
1. Resourcing a project based on developer rates alone
This statement is not just about a comparison of rates between off-shore and on-shore development staff but also about the make-up of development teams themselves. It’s important to have a balanced team. Good senior developers can be worth their weight in gold. There is, however, definitely a place for more junior developers as in anything but the simplest project there is usually a requirement for a variety of skill levels. The seniors often define or refine the architecture and structure and the juniors repeat a format laid down by the seniors or work on simpler isolated functionality. In any situation on-shore or off-shore the juniors must have a level of skill to follow the methods and system architecture. I’ve seen a number of situations where senior developers have spent most of their time correcting junior developers work – this is where the project really grinds to a halt!
2. Poor communication
Successful software development relies on good communication. This is not just relevant to communication of user requirements but also communication between the development team itself. As a guide, the more people in a team the more channels of communication and the higher probability of misinformation and misunderstanding. Agile development, which is a popular method of organising a development team and its workload recommends around 6 people plus or minus a few. Larger projects should be split into multiple smaller teams. Sometimes you can find senior developers who can build a system from the database to the user interface by themselves. If they are skilled in the required technologies then why not! You not only have less people to pay but you have also minimised the channels of communication. If you are going off-shore then the use of video conferencing is a must and the odd site visit can also really help. One of the best ways of communicating progress is for the development team to deliver new functionality. This is a key principle of Agile but regardless of Agile, get your team to demonstrate progress by delivering actual working software.
3. Wrong choice of technology or too much technology
Software developers by their very nature have what is called a high Growth Needs Strength. GNS is the strength of a person's need for personal accomplishment, learning, and development. Therefore if you ask a developer which technology should be used to deliver a project there is a fair chance he or she will pick the latest wiz technology (of which there are many!) They may also unnecessarily pick more technologies than is necessary. We also call this CV or Resume driven development!
4. Unable to verify quality
Many organisations have had their fingers burned by going for a low cost off-shore development team and having a non-technical in house project manager. When the project pressure invariably mounts the development team will start taking shortcuts possibly in failing to write meaningful tests but also in following the defined design and method of construction – by the way this is not just the domain of off-shore teams! A project manager may be able to ensure a project passes user acceptance testing, but that’s just the start of the story. If you are not lucky enough to have a highly proficient in-house team who work well together then get an in house or independent consultant who is on your side or use a outsource company who verify code quality independently of their development team.
5. Not considering the budget after delivery
The true cost of software is absolutely not just the cost of getting it over the User Acceptance Test delivery finish line. The true cost is calculated over the entire life of the software including its ongoing maintenance. It’s always tickled me that many large organisations outsource projects with a focus purely on the delivery cost. They often end up with low quality resources from outsource companies delivering a low quality product. The irony is these same outsource companies are actually incentivised to deliver a low quality product. Once the often woefully short guarantee period has expired they can charge higher rates for their higher skilled resources who are the only people who can work with the spaghetti code that’s been delivered. In other words, software that is delivered at a low cost often has a much higher cost in ongoing bug fixes and general enhancements that occur through its life. Oh and by the way low quality software usually has a short life span! Try to ensure delivered software continues to be thoroughly tested within any guarantee period and consider all the above points to improve its overall quality.
