Blog Post
Software Development Projects - How to Get Better Estimates
Estimating software development jobs isn’t always easy.
Software development costs are almost entirely people and on a fixed price project it can be hard to unpick every small job and sensibly estimate how long they will take.
Even small projects - one or two months of effort - can have plenty of hidden costs.
Software developers are also optimistic and they can underestimate by quite a margin. And there is always a temptation for managers to underestimate to keep costs down.
Here’s an approach to estimating that is structured and not too complicated:
- Break every job down into smaller jobs until you are confident that no job is bigger than 10 days.
- Get two estimates for each task - a low, best case estimate and a bigger, worst case scenario number that could be more likely if things go wrong.
- Sum up all the low estimates.
- Find the difference between each low and high estimate, sum up the squares of those numbers and find the square root of the total. That’s your contingency.
- Your development estimate is the answer to #3 added to the answer to #4.
- Look at the numbers again - I’m not always convinced when worst case estimate isn’t at least double the best case number. I’m always tempted to push the worst case numbers up, particularly if I think the contingency is low - 2 or 3 days of contingency on a 30 day job feels low to me.
- Add in time for project management, analysis/design conversations with the client and testing. I usually make each of those a percentage of the development estimate - 10% for project management, 25% for analysis and 25% for testing.
Agile development methodologies such as SCRUM get you to review progress at the end of each ‘sprint’ and then adjust your estimate of what’s possible in the next sprint. That works better in a product development world, but in a fixed-price project world clients want to know upfront what their software is going to cost - instead a simple, structured approach to breaking bigger jobs into smaller tasks and then thinking about what could really happen is required.