scott.hodson.blog

Here’s my hard and fast version of how to do estimates if someone needs a quick estimate and that is looking for a ballpark figure.

1. Estimate what you think it’ll take to develop it
2. Triple it.
   1. R&D of new or unproven technologies
   2. Proof of concept
   3. Debugging
   4. Project management
      1. meetings
      2. conference calls
      3. email
      4. conflict resolution, law suits
      5. travel
   5. QA
   6. User acceptance
   7. Requirements ambiguity
   8. Complicated migrations of legacy data
   9. Uncooperative partners
   10. 3rd world offshore programmer electricity and internet outages, natural disasters
   11. Company politics
   12. User and/or developer documentation, training
   13. Unforseen regulatory compliance requirements
   14. Recalcitrant status-quo team members
   15. Undocumented or incomplete APIs/web services that you’re required to integrate with
   16. All the other stuff that can derail a project
3. Then say the estimate has a degree of accuracy of +/- x% (usually 30-50%) and it’s not binding, a more precise estimate can be given with more details later.

If they don’t like it or think it’s too high then tell them they have to give you more details but with what little you have it’s too risky to shave an estimate with so little details and that you value an ongoing collaborative relationship more than a line drawn in the sand based on too little information. After all, you signed the Agile Manifesto, right?

“Customer collaboration over contract negotiation”