Introduction
Folks in software development often discuss reasons for project failures, why it didn't finish by the deadline, why the quality of the deliverables wasn't great, so on and so forth. In this article, I will be sharing some thoughts which may or may not be part of any fancy software development methodology. It is just pure experience. And also, please bear with my English :-).
7 Secrets to Successful Software Project Delivery
Software development is fun as long as the ship is sailing smoothly. The moment a major problem comes up, the ship starts to sink. There are many reasons, both technical and non-technical, that can be attributed to failures. There are some best practices which can help us avoid the trouble in the first place.
- Having experts in the team
- Good communication
- Team bonding
- Understanding the target market
- Blitzkrieg Programming
- Testing your own stuff
- Reject change requests
Having Experts in the Team
This is simple. A mediocre team will produce a mediocre product. Having experts in a team delivers results faster and with good quality. Even if you have excellent entry level developers, you need experts to guide them. Academic excellence needs professional guidance. Along with the experts in the team, always include mediocre people with great attitude. Give them tasks which require them to interact with the experts on a regular basis. They will learn a lot from the experts. Who knows they may get motivated when they get to know how the expert himself/herself became an expert. After all, nobody is a born expert. This way, you can build your army of future experts.
Good Communication
In a good team, even a minor change (e.g. in requirements, design or implementation) is communicated in advance to everyone in the team. This warns and prepares everyone for a probable calamity. This avoids the "Tsunami effect" (A minor change at one place can cause a big issue somewhere else). Otherwise, a minor change can later cause major rework elsewhere, which surely brings a project closer to its dreaded end.
Great communication definitely doesn't mean long meetings or using complicated software tools. It has to be done in a way that practically requires no schedule changes. Unnecessary activities kill productivity.
Team Bonding
On a more personal note, it's very important for team members to enjoy each others company and always be comfortable in the group. Personal understanding among team members surely helps the project.
Understanding the Target Market
It's extremely important for the development team to understand the market for which the product is being developed. Questions like, why to develop this product, who is the end user, how they work, what the end user might be looking for in the product, other than what is mentioned in the requirements specification. Marketing people will get the requirements specs but development team must feel those requirements when developing the product. This applies to all the people on the project. The team should also understand the risks the users might get into while using the product being developed. E.g. a team working on a banking application has to be careful about the security of data being handled and manipulated by the application. A lot can be at stake. On the other hand, a team developing a game won't have such issues.
Rapid Prototype Programming
This is my favorite. It essentially means to complete a prototype in the shortest time possible. Prototype is something which proves whether the suggested design or implementation approach is feasible and/or worthwhile. Since it may or may not get included in the final product, time spent developing it must be minimized. Use open source code (you won't ship it, right!). Rewrite it if the prototype is accepted. Use third party software. If possible, use their trial versions. Simulate everything you can and reduce the total prototype development time.
Testing Your Own Stuff
Developers can't imagine the presence of bugs in their code, unless the product goes to Test and Validation and truck loads of bugs are sent back. Well, statistics show that if bugs can be identified early in the development cycle, costs (in time and money) can be reduced. The key to testing your own code is to be "brutal" about it. Make it a game, as if for every bug you find, you are going to reward yourself with something. This will make your life easier during the last phases of the project. You can't be lenient when testing your own stuff. How you do the testing is up to you. You can write your own test plan document, use existing ones, automate the test procedures, etc.
Rejecting Frequent Change Requests
Having a brave manager with good negotiation skills always helps. The person should have the courage to say "No" to frequent change requests. As a general rule, a new change request should be rejected by all means and pushed back with evidences on why it should not be done. This puts the customer (or marketing people) into a situation where he/she needs to think over the change again. Let them convince you why it's important rather than just accepting it easily. Key to this is not to show any arrogance and be prepared to defend your point. Of course, don't fight if you think that the requested change is a valid one.
Summary
As I said earlier, these are just my learnings from experience. Do let me know what you think.
