Last article (Simple Tips in Writing Software Requirements), I was given advices in writing software requirements document or software requirement specifications (SRS) and that advice came from my very short experience in the field. I got a request from to give examples of these effects of how costly mistakes comes can be from inaccurate requirement document.
A software requirement is the foundation of a project. It is the blueprint of a building. It is the base of the architecture of a building. If your blueprint is not correct, the building will fall at some point. So to have a successful project, the project managers and owners must make sure the requirement documents are solid. 70% of projects failure comes from poor requirements documents.
The main factors in estimating the cost is the delivery time, and human resources working on a project. In estimating the project budget, the two main factors are development time and manpower. Once your requirements are rock solid, next major thing is, your time and manpower estimate. If you do estimate them wrong, your project will fail. Other estimates are cost of goods such as software, tools, technologies, indirect expenses, overtime, and so on.
But again, two key factors are the delivery (from start to finish) time duration, and the manpower. You need to make sure the team you build has right experience with right tools and technologies and they suit for their roles. You can't hire 10 sales guys to do coding. You also can't hire a water boy to cook. So you need to make sure, your team is experienced in tools and technology you're going to use in your project or have considerations for the training and learning time.
When we have a requirements document with ambiguous meanings in it, each of the stakeholders of the document could understand the meaning by his/her own way (since it holds several meanings), therefore you are giving the client the right to make changes in the deliverable, and you will not be able to negotiate with him. Therefore this will cost you more time, and of course, you will pay more for the human resources; in addition, this could affect any future work with your client. Not to mention that this could affect the human resources by feeling bored and not satisfied with the project, this will lead them not being able to give a good output for the project.
As Mahesh Chand writes in his 10 Tips Why Software Projects Fail, not having clear and detailed requirements is one of the key reasons why software projects fail or take longer than expected delivery time. Longer delivery time increases total cost of development and also leads to unhappy business stakeholders and customers. That could eventually end up shutting down the project. Less than 20% of new software projects go live. Rest 80% died due to various reasons and one of them being the requirements.
Please feel free to open any discussion.