I have personally had good results with Wideband Delphi, however with a few tweaks. 1. Instead of iterating until there's complete consensus, take the min and

I have personally had good results with Wideband Delphi, however with a few tweaks. 1. Instead of iterating until there's complete consensus, take the min and max of each of the subtasks and use them as follows: The sum of all the min's is the absolute best case hours estimate. The sum of all the max's is the absolute worst case hours estimate. 2. To project a completion date from the raw hours, you need to estimate how many weddings, deaths, vacations, pregnancies etc. your team might have-- this is absolutely a guess. 3. Assume an engineer works no more than 80% a day-- he will take coffee breaks, answer e-mails, meetings, etc. 4. Know your engineers and apply individual efficiency metrics to their tasks. Some guys will work slowly but their first version works flawlessly. Some guys will race through things only to have their code not pass validation later. Most people are somewhere in the middle. 5. Don't forget time to automate test tools, builds, deploys etc. These are huge time savers. 6. If doing hardware+software projects, integration will take way more time than you possibly think it could. You will hit at least one dastardly bug in your OS, hardware or silicon. 7. Give estimates as probabilities of completion, not hard dates. NEVER give an off the cuff estimate for anything non-trivial. You will be held to any utterance you make. The correct answer to a request for an estimate is, "I don't know." If your management won't allow you to make detailed estimates, or won't provide detailed enough design documents, specs, they are not serious individuals and don't deserve a serious answer.