During my experience as an IT professional, I have learned to pay a lot of attention to project estimates. That is because if a project is estimated inaccurately, it will be on a straight path for disaster, regardless of how extraordinary the effort of the project team would be. These are some tips that I personally use when providing estimates for future projects:
- Estimate page components rather than entire pages. Companies nowadays put a great deal of efforts into designing single page applications or continuous scrolling websites. Guessing a number of working days for these kind of website is a super bad decision. Try instead to provide estimates for each block of functionalities that you see in the pages.
- Try not to estimate blocks of tasks bigger than 3 or 4 days. If a task is bigger than 4 days, then most probably it can be split further into smaller tasks.
- Do not estimate optimistically. Make room as well for disaster. Unforeseen events will happen during project so make sure you take them as well into consideration.
- Include in your estimate overheads like communication and code review. One common mistake is to consider in a task only the development work. But a developer’s work needs code review, unit testing and they might need as well to participate in clarification meetings on the task.
- Quantify project phases like UAT and Discovery phase. Don’t assume that an UAT or Discovery phase should take 2 weeks or 4 weeks just because it is a good average to consider. It is best to calculate the number of days for these phases directly correlated with the development number of days.
- Don’t include unjustifiable buffer in the estimates. Try to justify each and every task from the estimate. Don’t put 20 days in the estimate just because you have a feeling that the project is complex. If you don’t have solid facts for that number then most probably it is wrong or it could remove your company from the negotiations table because of a higher price.
- Document each assumption or risk that you identify during estimate activities. This will be very useful when justifying the numbers with the client or when the contract is drafted.
- Include when possible a second pair of eyes in the estimate process. During requirements analysis you could oversee bits of functionality which combined could bring the project over budget.
I hope you find this list useful! In case you think I am missing another important tip, please let me know in the comments section.
And please remember: there is no such thing as 100% accurate estimates.