Software developers have a tendency to underestimate the time required to complete Change Request tasks. Most developers only estimate the time it might take to make the code change itself. For more reliable estimates, the following items should also be taken into consideration:
- Estimate for Requirements gathering, elaborations, and documentation (requirements elaborations included back-and-forth emails and meetings that at times took a significant time)
- Estimate for Updating Design and Software Architecture documents
- Estimate for database changes, if any
- Estimate for data migration changes, if any
- Estimate for Coding
- Estimate for Testing, incl. integration testing
- Estimate for Re-work, addressing defects, and re-testing (add 10% to estimate)
- Estimate for Updating Help content
- Estimate for Updating Training manuals, guides, etc.
- Estimate for deployment
- Add reserve for the unknowns (add 10-40% to estimate)
Comments
Your claim is absolutely correct, Chanath, and your reason is absolutely correct, too: most software developers think about their code, not all the things that go into making a project a success. But it's not just change requests that developers frequently underestimate -- it's all work, even the work they are estimating up front before the work begins. That's where good project management is key to success.
Another reason for underestimation comes to mind as well: many software developers are averse to measurement of their work, and the little measurement they do is done grudgingly. As such, they often have little idea how much actual effort and cost it takes to complete a certain amount of work and have to estimate from the gut.
Post new comment