5 major mistakes in software projects and how to avoid them

1. Feature Creep
As any software project manager knows, customers cannot stop asking for more. At the same time, most customers don't think of software as "concrete" so they think that all changes are possible, unlike houses or machinery. Therefore, they don't think that the deadline needs to change when adding scope so it is imperative to communicate the cost of extra features, either in time or manpower. Of course, it is important not to confuse clarification of features (very useful) with new features.

2. Buzz in the trenches
It is human nature to be optimistic. People dwell on the positive more than on the negative. When facing a roadblock, it is common for leaders and managers to hope that everything would work out quickly and hence project only the rosiest of scenarios. It is fairly common for managers to assign a fixed number of hours to solving a roadblock when the source of the error hasn't been ascertained! But for the overall manager, this is usually a prelude to disaster. The overall manager must keep an eye and an ear on the people in the trenches to make sure that deep-seated problems are not being sugarcoated till it is too late.

3. Tools
Vendors will happily sell you tools that you never use. On the other hand, really good tools can dramatically improve the return on effort. Therefore, a good manager pays attention to the tools being used and helps in the adoption of tools that make a positive difference. Go for tools that you can play with and test out not with some toy scenarios but with the actual problems that you are facing. The best tools are those that get worked to death. Shelfware is your enemy, eating up your budget and your people's time.

4. Consultants
Consultants can be godsent in a lot of projects. Unfortunately, they are rarely used well. That is why consultants and contractors have such a bad reputation. Remember, the onus is on the client to make the best use of a consultant. There should be a clear start condition, a clear end condition and what exactly the consultant is expected to do. Measuring progress via daily updates, preferably in writing, helps clients ensure that the consultants are worth the money being spent on them. I have often seen contractors working for the same client for years and getting paid a lot more than the employees. Such environments can breed resentments of epic proportions. Also, often the client is left in a lurch when the contractor moves on to some other project. Therefore, knowledge transfer should not be an afterthought, it should be an ongoing process.

5. Stability
A successful software project ends with the customer getting what (s)he needed and wanted. Usually, this requires frequent feedback from the customer, thus risking feature creep. However, it also means that the customer's expectations are grounded in reality. The single most important mechanism for eliciting feedback is to show the customer the software built so far. This is only possible if there is a stable and usable build from the recent past. But the collaborative nature of software development goes beyond just the customer. Developers, quality assurance people, technical writers and other such members of the team are also needed to provide feedback. If every build is usable, it is easier to provide feedback and improve the software. Thus, in my opinion, a daily stable build is necessary for project success.

I have been in software all my professional life so I don't know how much these pointers would help non-software people but you are welcome to it...