How do you deal with time slippage in your smaller programming deliverables?

Question

I'm asking this about smaller jobs: I think that with larger jobs you have all kinds of contractual issues to deal with. With larger jobs, if you haven't contemplated schedule slippage, you're basically hosed.

With smaller deliverables (10 hours or less): If you're doing something you've done before, it's very easy to estimate the time the job will take (and it may take less, since you've already learned how to do it "best"). But with something new, how do you deal with possible time slippage in your initial estimates? Arbitrarily add 20% to the time, just in case? Give a range and then give more precision as you move ahead? Do some HelloWorlds billing a few hours and try to figure out the unknowns?

I'm assuming, for this question, that you work for a flexible client who needs to have the best information possible to do their job, and needs everything sooner than later.

Answer 1

At the beginning of anything new and different, any estimate that's precise to better than +/- 50% is either padded, or a guess, or has a nice flexible scope.

That said, the priorities - and timescales - are often flexible, and dependent on plenty of things other than the development team or the client.

The important thing is that there's visible progress, responsiveness to client needs (as opposed to requests - a flexible client will see the difference), and an iterative approach that lets you go live early with less than 100% of the features if necessary (it won't all be needed on day 1) providing that fix- and feature- releases are frequent and give tangible additional benefit.

Getting the client out of the mindset of "complete, ready on date X" and into the mindset of "sufficient, and improving all the time" is key to this.

Otherwise, you have to go back to time honoured tradition... you ask four trusted, experienced, reliable colleagues for their estimate...

... and you add them together.

Answer 2

Learning requires feedback, so I suggest tracking your own accuracy.

Keep a log with a brief description of each estimated task, the original estimate, and the actual time required. So, for example, if you find that your estimates are 25% short, start making a corresponding adjustment upward. If you find that there is no pattern of over or short, look at the characteristics of the tasks themselves to see if there are certain kinds of tasks you consistently over- or under-estimate.

Answer 3

This is a somewhat open question so the answer might be as well.

Try to deliver something as close as possible to what was asked, try your best to make it run without blatant errors (e.g., crashes). Never try to second guess the requirements, if it was not asked for, don't do it even though you know it will be necessary - that will give you leverage when you need more time to get it "right" - which is not necessarily what was asked, but what your customer will actually want after you deliver. If you can be early, do so but not for more than 10% - otherwise you will be thought as someone that can't estimate.