Giving an accurate estimation

Estimating is something that is never easy, regardless of how many years of experience you have, because the circumstances between each project are always different.

The best advice I can give for estimating is:

  • Take the technical aspect out of specifying something. If you look at a problem purely from "what code/tool will fix this" you'll inevitably make a mistake and realise that your five hour estimate is actually several days
  • Requirements change, all the time. I've had clients tell me that some data hasn't changed in twenty years, and (surprise, surprise!) the data was completely different when it came to UAT.
  • Break a project into tiny parts, as small as possible. Add time for bug fixing, and general urgent fixes for when that code is finished, with the idea that you won't write new code until one bit of code is signed off as working.
  • The general rule is to double your estimates. Don't do this "just because" you're told to because someone will call you out on it, and you'll struggle to say why you're quoting eight hours to do something a client has seen you do in four hours.
  • People change their minds all the time. Get everything in writing. That way, if someone says that the payment process you spent ages creating is wrong, you can point towards where they've signed it off in the way you've built.
  • Most importantly, if you're behind on something, SAY SOMETHING AS EARLY AS POSSIBLE! People don't mind bad news if it comes to them early enough for them to react to it.
  • Sometimes, you just have to accept that some people are being dicks and don't value your time. You could do everything right, and someone will bitch that it's not good enough. We've all had moments where our work or experience has been insulted because something has gone wrong. If you're to blame, admit it. If you're not to blame, fight your corner. If you act like a doormat, people will walk all over you. In the same vein, if you fail to admit mistakes, your ability is called into question. If someone says something takes two hours and you believe it takes ten, don't give in without a legitimate reason.
/r/webdev Thread