Improve your project estimation accuracy by empowering your development team with these 4 techniques and associated tools.
As we discussed in our previous article “How To Create More Accurate Web Project Estimations?“, you first need to have the project documentation and designs to make an accurate estimate. The project estimation accuracy improves with the completeness of project documentation and designs.
#1 Analogous Estimating
In the early stages of the project where only limited documentation is available a good technique to employ is analogous (also known as top-down) estimating.
Analogous estimating uses historical data (similar past project) to estimate the duration of your current project. As with any other technique, it’s best used by the developer(s) who actually worked on the past project and can make the best expert judgment on how the current project compares to the past one.
You need to develop a small eCommerce website similar in scale to the one you did two months ago. Except, this one also has Facebook and Twitter sharing feature. The previous website took 40 hours to develop and you estimate (also based on prior experience) it would take about 4 more hours to implement and test the sharing feature. Your estimate using the analogous estimating technique is 44 hours.
- Can be used with only limited documentation provided there is enough historic data
- Can be used in the early stages of the project to refine your initial ballpark estimate
- Relatively fast to calculate
- Accuracy is lower than other techniques and further
- Accuracy drops in case of insufficient or missing historic data
If you don’t have sufficient internal historic data you can consult an external expert. In this case, keep in mind that external developer might be on a different skill level than your development team and adjust the estimate accordingly.
Always account for the missing documentation and add contingency to your estimate accordingly. Your initial estimate of 44 hours would need to go up by 10-50% depending on the expected complexity and scope.
#2 Parametric Estimating
Parametric estimating technique is similar in nature to the analogous estimating, but adds an additional layer of accuracy by dividing the work into measurable units.
You know you will be developing a five page website with a basic admin panel. You can use the information you have and compare it to the average time it takes to develop a new page template for a similar website and bind it to the admin panel. If that takes an average of 12 hours per page, your estimate using the parametric estimating technique would be 60 hours.
- The same points as analogous estimating
- More accurate than analogous estimating
- The same points as analogous estimating but still more accurate
Since this technique is very similar to analogous estimating the same suggestions apply. Due to increased accuracy you can reduce the contingency percentage if you’re confident in your historic data.
#3 Three-point estimation
The project manager or the development team first decompose the project into a list of estimable tasks. This requires the documentation and designs to be available. The tasks can vary in scope, with more detailed tasks providing the best levels of certainty but also taking the longest to estimate. Typically, a reasonable number is 20-30 tasks per project. Three-point estimate requires three figures to be produced for each of the estimated tasks.
a – The best-case estimate for completing the task
m – The most-likely estimate for completing the task
b – The worst-likely estimate for completing the task
(All based on previous experience or educated best-guesses)
There are three formulas you can use to calculate the estimates for each task.
The simplest one is:
ET = (a + m + b) / 3
A more accurate weighted formula places more weight on the most-likely estimate:
ET = (a + 4m + b) / 6
And the most complex one that also accounts for standard deviation:
E = (a + 4m + b) / 6
SD = (b – a) / 6
ET = E + 2 x SD
You only need to pick one ET formula to use. You may want to try all of them and see which one best fits you.
The final project estimate is calculated as a sum of all individual task estimates. Usually there’s no need to add contingency to this estimate. You can compare the actual time taken to complete each task to the estimated time and add contingency based on what you find.
The three-point estimate works best when estimates are unbiased and based on previous experience on similar tasks. As such, some managers find it best to ask for a, m and b numbers for each task and calculate the ET themselves. In this way, the development team won’t be tempted to alter the initial a, m and b numbers after seeing the final estimate.
To save you some time we have prepared 3 XLS spreadsheets to help you calculate each of these formulas:
Weighted with SD: weighted-with-sd-formula.xlsx
You need to build an art gallery website which uses sliders to display works of art, and show artist biographies. You split the work into following tasks (numbers are a, m, b in that order):
Responsive Layout: 2h, 3h, 5h
Header: 2h, 4h, 7h
Slider: 2h, 5h, 10h
Biography section: 1h, 2h, 4h
(Simplified to four tasks; in reality you would have much more front end and back end tasks)
Using the weighted formula, we calculate the averages for each task:
Responsive Layout: (2 + 4 x 3 + 5) / 6 = 17 / 6 = 2.8h
Header: (2 + 4 x 4 + 7) / 6 = 25 / 6 = 4.2h
Slider: (2 + 4 x 5 + 10) / 6 = 32 / 6 = 5.3h
Biography section: (1 + 4 x 2 + 4) = 13 / 6 = 2.2
Estimated project time: 2.8h + 4.2h + 5.3h + 2.2h = 14.5h
- One of the most accurate estimation techniques
- Psychologically easier for developers to provide three numbers, less pressure of “getting it wrong”
- Identification of the worst case number leads to discovering otherwise hidden problem areas
- Reduces the risk of over-optimistic and over-inflated estimates
- Tools provided reduce the overall time of calculation
- Stays solid even with limited previous experience
- Requires full documentation to be able to decompose the project to tasks (which actually isn’t bad)
- Providing three estimates for each task requires more time than other methods
- Leaving the final calculated estimate visible might lead to development team adjusting their initial estimates
Use the provided tools to keep you from manually calculating estimates for each of the 20-30 tasks.
#4 Bottom-Up Estimating
This is my favorite technique and also the one the one I prefer to use because it’s the best fit for my level of experience. Bottom-up estimating starts in a similar way to three-point estimation – by decomposing the larger project parts into (very) small chunks. It’s also somewhat similar to parametric estimating since the estimates for each chunk require knowledge of time required to complete a similar chunk.
Since this is the technique that proved most-accurate it deserves an article of it’s own to cover it in detail and provide real-life examples.
- The most accurate estimation techniques
- By decomposing the project down to smallest chunks there’s almost no chance of missing important details which will take long to complete but would likely get unnoticed with other techniques
- Helps identify holes in documentation so these can be filled early
- Requires more time to complete compared to other techniques, though it gets better rapidly as you use continue to use this technique
- Requires full documentation otherwise the accuracy can suffer.
- Most useful if you have at least somewhat experienced development team since it relies heavily on previous experience
You can use this technique even for less experienced teams but make sure to add contingency to make up for lack of historic data.
This technique can be combined with three-point estimation to add even more accuracy. Note that this will also require more time to complete an estimate. More on that in our bottom-up estimating article coming soon.
A few more words on contingency budget
It should always be very clear that an estimate is just that – an estimate. Do not expect it to be 100% accurate. Even if it proves accurate in four projects, in the fifth one it may be off by 10-20%. The accuracy of any type of estimate can be low in cases of little to no previous experience. In such cases you can manage the uncertainty with a contingency budget. You should also account for missing documentation so it’s reasonable to assume that if roughly 30% of documentation is missing, you’ll need to add 30% to the estimate.
Do you know of any other estimation techniques or tools? Let us know in the comments.
If you’d like to further improve your project estimation skill, we’ve prepared an extensive Ebook “The Ultimate Guide to Successful Project Estimation” that will teach you ins and outs of project estimation tools and techniques.