When estimating for a project that you’re not sure you’re going to be awarded, you don’t want to spend too much time analysing the minutiae in the spec. So what do you do when you’ve won it, you’re half way through building it, and you stumble across a small, but fundamental problem?
Software developers will always be asked to estimate for work, so that project costs, timescales and resource requirements can be planned. Much as you’d like to just get on and build a web application, this, unfortunately, is a fact of life.
If your estimates are wildly under actual times, there can be repercussions. If you work for yourself you’ll most likely take a hit on the profit you’ll make on a project. If you work for someone else, your boss might not be too happy as the company has taken that hit.
This post talks about how to estimate, types of estimate (with a section on ballparks) and how you can manage the use and interpretation of estimates you provide.
Answers to questions such as “What is a functional spec?”, “Why is it important?”, “How do you write a functional spec?”, “What does it contain?”, “What does it not contain?”