Estimates are the benchmark against which project success is measured. At the end of the project, the project success will be judged by how well it met estimates made at the beginning of the project.
If you estimate well, you will win more business with more competitive bids, and avoid unprofitable projects.
With rewards so great, and most estimates so wrong, what can we do to improve our estimates?
Estimates are based on assumptions. When creating your estimates, document your assumptions and provide them along with the estimates.
The main benefit of writing down your assumptions is that when stakeholders or clients review your estimates, they can point out any assumptions that are wrong. This can be fed back in to the estimation process to produce more accurate estimates.
As the project proceeds and more and more assumptions can be resolved, your estimates can become more accurate. This is called the cone of uncertainty.
Another important benefit of documenting assumptions with the estimates is that it gives you justification to change the estimates if one of the assumptions later changes. It is much easier to get a change in the project schedule approved if the stakeholders and clients were forewarned about the assumption.
When estimating a large block of work there is a natural tendency to focus on the main part of the work and forget ancillary tasks such as documentation and testing. This will lead to highly optimistic estimates.
By breaking project tasks into smaller and smaller tasks, it is easier to estimate the effort involved in each task. Combining the smaller estimates again into a whole project estimate is a simple task that can be performed for you by project management software such as TaskTrakz.
When you break down tasks into smaller tasks you are more likely to find tasks similar to tasks that you have done before. This is ideal because the time that these tasks have taken in the past can be used as a fairly accurate estimate of how long these tasks will take on this project.
Also, by breaking down tasks you can isolate and highlight individual tasks that are risky and thus are difficult to estimate. By making these risky tasks as small as possible you can improve the accuracy of the overall project estimate, because other parts of the project do not have the similar risk, and can be estimated more accurately.
When estimating a project, a single person is limited to their own knowledge and understanding of the project. By having multiple people estimate the project, more accurate estimates can be created as different people will consider different problems that may occur in the project, and discussion can reach a consensus taking into account all relevant problems.
Group estimation works best if the estimators form an individual opinion, and then discuss to reach a consensus. This can be done with each estimator estimating all the project tasks individually, and then meeting once everyone has completed their estimates (as in wideband delphi estimating), or by each participant in an estimation meeting writing down an individual estimate for a task before sharing it immediately afterwards with the group (as in agile planning poker).
The consensus not only makes people consider additional potential problems that might impact the estimate, but also makes people less likely to pad their estimates with extra time. This is because they know that they may be challenged on any of their estimates during discussion and have to defend it.
There is uncertainty in every one of your estimates. You should communicate this to the people receiving your estimates. The simplest way to do this is to estimate using ranges.
A simple two point range is often good enough. For example, adding a table to the database and model code will take between one and four hours. If the client or stakeholder queries any ranges as being too large you can explain the reason.
Sometimes a three point range is preferred. In a three point range you specify the best case, the most likely case and the worst case. You can use the PERT formula to turn this into a single weighted average estimate if desired.
In either case the presentation of an estimate range will clearly convey the level of uncertainty in your estimates. It is likely that estimates provided early in the project may have a lot of variability, prompting stakeholders and clients to authorize further requirements gathering and design to obtain better estimates.
TaskTrakz lets you mix and match one, two and three point estimates for any of your tasks so you can accurately represent the uncertainty in your estimates directly in your task tracking system.
Lastly, the most accurate estimates are those based on the measured time performing similar tasks in the past. For instance if it took you 1 hour to paint a wall in the past, it will likely take 1 hour to paint a similar sized wall in this project.
I hear all the software developers say "Hey, what about us? Every project is completely new and different to what we have done before". However, if you break down your project appropriately you will find a lot of tasks similar to those from previous projects. For example setting up and configuring a web server is likely to take a very similar amount of time from project to project. Those tasks that really are new can have an appropriately wide range assigned to them to reflect the uncertainty, but large parts of many projects can be estimated accurately using past measurement data.
So, make sure you track your time against the estimates you prepared for your project. This will give you an excellent basis for estimating tasks in future projects.