During my experience as a consultant and as a project manager, 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.
Below are some tips that I personally use when providing estimates for future projects:
Companies nowadays put a great deal of efforts into designing single page applications or fitting lots of content into single pages in order to improve SEO. Guessing a number of working days for these kind of website pages is a super bad decision. Try instead to provide estimates for each block of functionality from the page. For example, in a Homepage, you should provide estimates for Header, Navigation, Minicart, Slider, Footer, etc. This way you could have a clearer list of activities that can be further documented and as well you reduce the wild guessing of putting a number on a single big page.
This is a classic. If a task is bigger than 4 days, then most probably, if is analyzed further, it can be split further into smaller activities. The splitting exercise also helps uncover risks otherwise not visible when estimating big chunks.
Make room as well for disaster. Unforeseen events will happen during project execution so make sure you take them as well into consideration. During the estimate process, document any risks that could arise and then try to put some numbers on them. This way you can have a justifiable overhead that leaves room for disaster and maybe opens as well a communication channel with the customer in order to clarify these items and their costs.
One common mistake is to consider that during the implementation of a task you only spend time doing development. A developer's work needs code review, unit testing and they might need as well to participate in clarification meetings. All these activities are gathering important time, which if it is not considered, can significantly affect the overall effort for a task.
Do not assume that an User Acceptance Testing or Discovery phase should take 2 weeks or 4 weeks just because it is a good round number to mention to your customer. It is best to calculate the number of days for these phases in direct correlation with the execution time estimated on the project.
Try to justify each and every task from the estimate. Don't just put 20 days in the estimate just because you have a feeling that the project is complex. Do proper risk analysis and only based on the risks that you identify you can increase your estimate. Adding unjustified overhead to the estimates could risk removing the company from the negotiations table due to possible high price.
Documented assumptions, constraints and risks gathered during a project estimate are very useful information that could be used by the project manager to discuss project deliverables, milestones and most important budget. So please make sure you document each assumption or risk that you find during estimating activities.
Some work could look easy from one's eye perspective but complex from other developer point of view. Furthermore, one could overlook by mistake certain 'hidden' project sections that could remained un-estimated. Whenever possible, but especially when estimating complex projects, do include another pair of eyes to contribute to the project estimates.
I'm pretty sure you've heard this phrase before: "I don't know who did the estimate but it is not realistic at all. I cannot develop this component in that timeframe.". Well, estimates are subjective pieces of work. You cannot find two persons that will give you the same numbers for a project estimate. So, whenever possible, try to estimate projects with the team that has the highest possibility to work on that project afterwards. This would bring the benefit of team buy-in for the numbers in the estimate.
Analyzing historical data from previous project estimates and as well project execution might show you valuable patterns. For example you might notice that on previous 3 projects you have delivered, the Contact Us page took in average 2 additional days to develop. You can make use of that information for any future implementations that require Contact Us pages to be developed.
There could be situations when pressure from the project manager or sales representative could appear in order to reduce the estimate numbers so that the project could fit within the budget. This is not a good practice as it would lead to unrealistic execution costs or delayed project timeline. Budget matching should be achieved with other methods and this should usually be a sales representative or project manager's work.
Instead of writing something like: "Implement the Login functionality" or "Develop the Register page", it is better to use simple noun words like "Login page" or "Register page". This will provide simplicity, consistency and clarity when reading the estimate document. This is especially useful when estimating big and complex projects.
In order to have realistic timelines across project execution, the project needs to be constantly re-estimated and reviewed. Some risks should have been clarified and some new ones could appear. All of them needs to be reflected in the scope and in the timeline of the project.
I hope you find this list useful! In case you think I am missing another important tip, please feel free to share it! It would be great to create here a repository of tips that could help us estimate better.
Furthermore, please remember! No matter how much you try, there is no such thing as 100% accurate estimates. That is why they are called estimates.
We communicate via email about our progress on the Project KPIs project and what new features we add to our products. Each email will be sent at least one month apart and we promise we try to send only meaningful information to you.