Estimating web development projects is hard. Very hard. It’s only once the development team start working on the project that they see all the complexities which will determine how long the work will take. But, clients still need estimates so how can projects be estimated with accuracy?
At Safra London, we take the approach to break down a large task into smaller tasks and then estimate a best case time and a worst case time estimate for that task.
Define 'best' case:
In the best case scenario, all assets are supplied to the development team on time and every attempt made by the team to solve a coding problem works first time - as opposed to multiple times as is often the case.
Define 'worst' case:
In the worst case scenario, the client is slow at delivering assets and/or copy, or feedback. Everything the development team tries at first fails to work and they have to spend time learning new techniques to fix a surprisingly complex problem.
Determining which tasks will run long
Short answer: you cannot correctly predetermine which tasks which will run longer and which will complete quicker than expected. You can guess based on past experience but… a task on one project may have taken 1 day whereas, a task that looks and feels similar on a new project can easily end up taking 5 days.
There are so many legitimate reasons for this:
- developer experience in specific task
- client or design team changing their mind(s)
- how tight or loose the brief is
- the specifics of the business requirements for the task
- the visual appearance of the design
- the detail of the interaction design
Why might task X be harder than or easier than expected?
If we take the task like prepping SVGs for web development this is a notoriously complex or relatively easy task. I think (some)Designers and/or clients feel this task merely involves right clicking on an icon in Sketch/Photoshop and saving the file, which is 5-10 minutes per icon, but it all depends how the icon has been created and how the icon is to be used on the site.
So, if we cannot tell which task will be tougher or easier than expected. What can we do?
An example project
This is an image of the Little Hotdog Watson homepage’s hero area. It contains a carousel, some large full screen images, various typography styles and spacings (which change based upon different screen widths), and it contains a header bar with a left-aligned logo and a right-aligned nav bar with links which may be added/removed in future.
If we break down the hero task into smaller ones and estimate timings for both scenarios for each task then we take the average… like so:
| Task | Best (hours) | Worst (hours) | Average (hours) |
|---|---|---|---|
| Header bar layout | 3.5 | 10.5 | 7 |
| Mobile nav | 7 | 21 | 14 |
| Build Hero | 2 | 3 | 2.5 |
| Build Carousel | 3.5 | 14 | 8.75 |
| Export/Prep SVGs for icons | 2 | 7 | 4.5 |
| Total: | 18 | 55.5 | 36.75 |
An optimistic web developer may quote 18 hours and most likely even less than this (and end up costing the agency a lot of money) whereas a battle-scarred web developer may quote 55.5 hours (and end up costing you the project, when the client sees the estimate and runs away).
Instinct says, 55.5 hours is too long to complete this task. We may have uncovered some odd tasks but we’ve completed too many similar projects, in much much shorter timeframes: in fact, with a 7 hour day, this hero area would take nearly 8 days. Which is mad.
However, the average figure of 36.75 hours feels much safer and will account for the fact that the toughest task ’Mobile nav’ has potential to be a much bigger piece of work than expected. It also accounts for the fact that ’Build Carousel’ may turn out to be much easier than expected - as we may be able to use a third party library that meets our requirements.
Generally, most projects don’t turn out to be 100% full of tasks from hell nor are they 100% full of tasks which are super easy either. They tend to be a mix. A mix which you cannot usually guess up front but this technique helps us average that out.