1

I'm a junior web developer and I've been working on an ongoing website for the last 6 months.

Last Friday I went and spoke to the client and he asked me to give time scales for my next section of work to which I quoted two weeks. Two working days later and I've almost finished the section (I really go into the zone and worked through breaks and lunches).

So my question would be how can I give more accurate timescales whilst still giving myself some breathing room?

closed as off-topic by Jan Doggen, gnat, Rory Alsop, JasonJ, Masked Man Dec 19 '16 at 13:46

  • This question does not appear to be about the workplace within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 5
    You need more experience to give more accurate estimates. – WorkerDrone Dec 13 '16 at 16:44
  • 2
    I'm voting to close this question as off-topic because it is about performing a job function not navigating the workplace. – IDrinkandIKnowThings Dec 13 '16 at 17:51
  • 3
  • 1
    Maybe even better: Remove the question here and put it on [productivity.se]. It is very broad, though; I suggest you add what you have tried, what seems to (not) work, etc. – Jan Doggen Dec 14 '16 at 7:18
  • 1
    I'm voting to close this question as off-topic - it would be welcome (after a bit of neatening up) on Productivity, as Jan commented. – Rory Alsop Dec 19 '16 at 10:25
6

As pointed out in the comment, experience is the best way to improve at this.

My typical rule of thumb is:

  1. Make sure I know the requirements ( maybe even prepare a brief requirement document to review with the client ),
  2. Walk through a pseudo implementation ( review the code ) so I have an idea what files I need to edit or create
  3. Based on the above steps, come up with an estimate.

Then I would add 20% to cover discovered work.

I would also suggest that you attempt to be more iterative in that if you discover something is going to take less time, report that. Nothing wrong with saying "This will take less time to accomplish than I originally thought" or visa versa. Communication is key.

  • 2
    As the duration gets larger, you may find you need to add a larger percentage -' you start having to allow for vacations and other nterruptions. Also, that "20%" depends on how good you are at your first guess -' I generally find I have to start at 2x and scale up from there, when testing and such are figured in. – keshlam Dec 14 '16 at 2:30
2

Experience will make you a better estimator over time. However, it is important to understand what you are being asked for and what you are answering. Your client probably isn't asking for an estimate, they want a commitment for when it will be done.

An estimate is really an educated guess/answer with some statistical probability of being accurate. Your client isn't interested in the most likely amount of time it will take to do the work, they want to know when you will commit to having it done. So your answer to them needs to take your estimate, and given a likelihood of success in that time window, provide an date/timeline that you feel you can meet with 90%+ certainty (or whatever percent you are comfortable with).

0

My approach is to:

  1. Work out what needs doing. Never underestimate the time spent testing, debugging, integrating, documenting and all the other stuff that isn't actually designing or writing code.
  2. Break the work down into sensible size chunks. Less than half a day is too small. More than a week needs breaking down further.
  3. Decide a realistic timescale for each of the chunks.
  4. Add the whole lot up to produce the estimate.

I once had a manager who admitted to me that he doubled every estimate I gave - that's when I realised I needed to do step 1 properly. Designing and writing was only half the job.

-2

Estimating/forecasting has been the bane of my life. Just to give one example: I can get a complex node.js app within three weeks. But once I work out the kinks, I can write a similar one in three days simply from acquired experience and reuse of generic code. Obviously, clients would like nothing less than me billing them for three days' work while eating the three weeks' worth of labor costs for writing and deploying a first-time app.

I am no longer freelancing - it's simply too much aggravation for me. The clients simply take advantage of me and I end up starving. If I am charging, I'll be charging a fixed price, say 80% of three weeks' worth of labor costs.

You simply have to do a lot more work, cook up more estimates and at some point, there will be a passing relationship between your estimates and the actual work.

  • 3
    Sorry, this does not answer the question How can I – Jan Doggen Dec 14 '16 at 7:16
  • @JanDoggen - it does answer the question "how can I" : "You simply have to do a lot more work, cook up more estimates and at some point, there will be a passing relationship between your estimates and the actual work." I am saying the OP has to accumulate a lot more experience than they currently have, – Vietnhi Phuvan Dec 14 '16 at 7:31

Not the answer you're looking for? Browse other questions tagged or ask your own question.