(Other than blaming the developers)
Rule number 1. The estimate is never wrong. If you even think the estimate is wrong, re-read this rule and get enlightenment.
Rule number 2. The developers who will actually do the work are NEVER the right people to make the estimate. Estimates must always be done by the same person to make sure that they are consistent. Consistency is the key to ensuing that the estimate is right.
Rule number 3. Analysts should NEVER be allowed to estimate their own projects. The analysts have too much self-interest involved in the project gong ahead so will always produce over-optimistic estimates.
Rule number 4. Estimates must be made well in advance of assigning staff to a project. After all it is impossible to assign staff to a project until it has a budget, and a budget cannot be assigned until there is a good estimate.
Rule number 5. Senior project managers are the best people to create the estimates because they can easily create an estimate that is within 25%. The very best project mangers can create even better estimates given only a vague description of what is needed.
Rule number 6. Developers and analysts who complain about inaccurate estimates just do not understand the process and need to be told about rules 1 through 5.
Some Questions about Estimating
Q: What bozo came up with those rules?
A: I’m not sure, but that bozo sure works for a lot of companies. He (invariably a male) even manages to get promoted to even higher levels of incompetence based on the promised land created by these fairy tale estimates.
Q: But what happens when the inevitable happens and the project misses the due date?
A: Not much. There is usually someone else to blame. The best tricks to shift the blame are to talk about “scope creep”, new requirements, being let down by vendors, incompetent developers, bad luck, unforeseen circumstances, other projects impacting delivery, etc. It is amazing how far projects can overrun and still nobody is held accountable. The record I have seen so far is over 6 years late, but even more amusingly I have seen lots of “that should only take them 2 weeks” projects take more than a year to complete (assuming they they ever delivered anything useful).
Q: But surely something happens.
A: Sure does, the project team gets stressed out delivering crappy software, and then get stuck trying to support an unmaintainable heap of garbage. But that is not a problem for the person who made the estimate, it just means that the project was staffed by a bunch of worthless losers.
A Blinding Flash of the Obvious
Estimates are ALWAYS wrong. All they are is a prediction based on uncertain information, and early on they can easily be off by a factor of 4 or more.
Developers have to estimate their own work. Unfortunately they cannot produce early estimates, because in order to do a good estimate a developer needs to have a good understanding of the requirements.
Analysts with good domain understanding can often produce a reasonable order of magnitude estimate after a few days of talking to the various project stakeholders about what they really need.
“Zero information” estimates produced for budget purposes are useless and misleading. Accountants understand this but are willing to go along with the game unless the software development manager decides not to play.
Read the literature, NOBODY comes within 25% of their “zero information” estimates without cooking the books, rewriting history or spin control.
Whenever the developers and analysts predictions do not match the project managers predictions, start looking for a new project manager. Reward the project managers who can produce good predictions, let the rest find an alternate career outside software development.
When the process is broken, change the process
The traditional way of estimateing and running projects is broken. I support the Agile Software Development approach because it allows projects to be successful without imposing undue stress on the team members.
Software development is meant to be fun, if it isn’t the process is wrong.
Pete McBreen, 17-Feb-2003, pete@mcbreen.ab.ca
- Republished from my main site with minor changes.