It is important for software development companies to accurately gather requirements in order to develop the correct application. Poor requirements gathering, however, this leads to poor project estimation, bad budget planning and cost and time overruns. 9/10 major projects experience cost overrun. Moreover, a study by McKinsey showed the average software projects overran by an average of 66% over budget and some projects have run over by 200% or even 400%. These high level of overruns would suggest that there are potentially some issues with project estimation or delivery. Given that a project will often take as long as it takes to deliver then a poor estimate can be seen as not foreseeing the work involved in the project with a good level of accuracy. Studies have shown that many projects fail or overrun because of poor requirements gathering. It is an area that is often overlooked and undertaught. Learn more about ‘Why Requirements Gathering Challenges Can Lead to Overruns’ in our other blog post.
So how can poor requirements capture lead to poor estimation.
Poor detail in requirements capture
Almost more dangerous to good estimation is poorly detailed requirements. This is often where the requirement does not contain the necessary level of detail and the analyst, writing the requirements, and the developers, implementing the application, are making different assumptions about what the system should do. An example of this might be a requirement for a user to login to an application. The user should supply a username (email) and a password. The analyst may feel that they have specified what is required and the developer, who we will assume is new to the organisation and inexperienced, implements this requirement. However the analyst has failed to mention that the password must follow a particular format (e.g. minimum 8 characters, at least one number, at least one letter and at least non-alphanumeric symbol).
Poor detail in requirements can lead to estimations made against simpler requirements. In many of these instances the lack of detailed may not be noticed until implementation or even testing. This can lead to a task taking longer than was estimated and even some rework to reimplement a features due to an incorrect assumption.
Inexperienced team, poor requirements and estimates
We have covered missing requirements and poorly defined requirements above. One area which can affect estimation for a project is the experience of the team providing the estimates. In order to get accurate estimates there must be accurate requirements. However there must also be staff who are experienced enough to estimate accurately and, importantly, to recognise when a set of requirements are not sufficiently detailed to be estimated.
An inexperienced team can simply accept a poor set of requirements and provide some estimates. A more experienced team may look at a set of requirements and determine that the requirements are not detailed enough to provide an accurate estimate.
Organisational pressure to estimate against incomplete requirements
A common scenario where poor or incomplete requirements can cause poor estimation is pressure to estimate against requirements which are too high level or not yet finished. Organisations want to budget for developing an application so they want to get an indication of cost without spending much time and money doing this.
This is commonly seen in tender situations where an organisation will send high level requirements to various suppliers to get an estimate. There is rarely enough detail to give an accurate estimate so suppliers are sometimes force to make assumptions. When the project is underway some suppliers can then use the lack of detail to move their original price upwards when requirements are finally fleshed out.
For internal IT departments, there can be pressure to provide an early estimate for the development of a system ‘just to give an indication of what it might cost’. However these early estimates can then become fixed in the minds of management as the actual final cost. Care should be taken against providing fixed estimates against very high level, early or incomplete requirements as these estimates are rarely accurate and are a common cause of project overruns.
It is clear that poor requirements gathering leads to poor project estimation. To avoid these problems, it is important to invest time and effort in the requirements gathering process. This may involve conducting stakeholder interviews, creating user personas, and developing detailed user stories and acceptance criteria. By thoroughly gathering and documenting the requirements, project teams can develop more accurate project estimates and improve the chances of project success.
Our new product Requiment, guides you through prepared questions to determine a full and detailed requirement specification and project scope based on outcomes . This application acts as a virtual business analyst, guiding users through the requirements process, whilst providing insight and recommendations to the user based on the type of application being designed as well as trends from other users. Ultimately, our mission with Requiment is to make the process of software requirements capture more accurate, agile and efficient leading to more successful projects.
Find out more in our other blog ‘Why You Should Use Software for the Requirements Gathering Process’ and sign up now!