more of an aspiration than a claim

Software Project Common Mistakes

From my project history and observations, here are some common problems I commonly see/hear about software development projects.

  • Not keeping the requirements up to date.

On some projects people get lax and it all becomes too hard to keep all the requirements up to date. This will cause even more problems further down the track when nobody can agree on what is meant to be delivered. It also makes it very hard to test a system if you don’t know what the systems functionality is.

  • Letting clients change the requirements at will.

I feel it is better to enforce scope changes and get the client to pay for them. This encourages them to take an interest in getting it right the first time. This is where a good project manager can really show why they get paid all that money.

  • Aiming too high for a first release.

Often clients and developers can fall into the trap of trying to add too many features in the first release. Sometimes features are added that are not required at all. Getting a first version with a minimum set of requirements requires good analysis and a ruthless eye. Bells and whistles and nice to have functionality can be added in subsequent phases. Get the core up and running first. Many projects will never make their first release due to excessive requirements.

  • Team Members not working together

This is often the fault of the management team. Good leaders will enforce people to follow good practices and work together as a team. Processes should be put in place and reviews should be performed to make sure the processes are being carried out correctly. People going off and going there own things will create multiple versions of the same thing and limit opportunities of reuse.

  • Not taking advantage of existing works

It’s amazing how many people still feel the need to re-invent the wheel. Some time invested up front on existing technology and processes can save so much time down the track. Don’t discount commercial offerings either. Often the time to produce these products yourself will be far more than the cost of buying an existing solutions. Sometimes spending a little money can save you far more and the product you are buying should be well thought out, generalised and top quality code.

  • Lack of tools

Not forking out money for licences on productive tools/decent machines etc can waste a lot of money. A programmer who is waiting for something to compile is not only not doing anything, but also losing the thought processes they are currently working on. Getting back into the zone can take 15-30 minutes once your train of thought is gone. Tools like code generators/IDEs can save many minutes that all add up over the life of a project.

  • Not giving people proper inductions when they join the project

Getting someone up to speed with a project should be a smooth process. If a resource has to wait for a login for 2 days before commencing useful work, this is wasted time. If a project is set up correctly from the beginning, it makes it so much easier to get new people productive.