|
Without a pretty good understanding of what a project or activity has to deliver cannot provide a good estimate, regardless of time spent. Also, if you don't know WHO will build it, and their capabilities, any accuracy is impossible. When people approach the limit of their abilities, time spent on tasks goes up exponentially. However, if someone has a very good understanding of what they're supposed to build, the team that will build it, reasonble estimates can often be produced quite quickly. Obviously, there can be risk factors, such as customers or managers with unreasonable expectations, but those can typically be managed by experienced teams. Anyway, raw estimates should never be seen as budgets. Budgets should be much larger, especially if they can be kept hidden from the developers, since budgets need to take all sorts of risks into account. But most team if they know what the budget is (and it's big enough), may tend to relax a bit too much early on in a project. Most software projects go a bit (or sometimes quite a lot) over estimates. Which is often fine. The estimate may still have been a useful exercise, in that it forced someone to think about most details of the deliverable early on, and also provided something to track progress against. |
This is an excellent observation.