Need advice on how to give accurate estimations on project completion

Question

I work as a developer in a small digitial marketing company. I am actually the only developer there, so despite being junior (graduated in July 2007, did some freelancing), I am actually senior by definition/nature.

Anyway, whilst my technical knowledge is ok (well I'm happy with it), one thing which I always wanted to and must master is estimating the completion time of a project. As my degree was a mix of Business Management and Computing, we did learn a bit about development time estimation (Function Point Analysis, COCOMOII, etc) but sometimes I don't have the time to use these approaches. For example, I have a meeting, get told of an upcoming project there and then, and must give an on the spot estimation of the time it would take to complete the project, so I can only rely on experience (and some projects I have not attempted in my professional or personal experience).

Are there any tips to help me give an instant estimation of the time required for completing projects?

Thanks

Answer 1

I highly recommend Steve McConnell's Software Estimation. It not only discusses how to estimate but how to present your findings, which is always important but especially in your on-the-spot estimates.

Answer 2

If someone springs a new project on you and asks for an estimate on the spot do not give them an estimate. Explain to them why any on the spot estimates will always be wrong, and that you will not be able to give any accurate estimates until you fully understand the scope of the project. Do not allow people to bully you into this, whatever you tell them they will expect you to meet, that's not good business.

The best advice I've read for making good schedules was written by Joel in his Evidence Based Scheduling. Give that a shot if you really want to get good at estimating.

Answer 3

The real question is not how to make accurate estimates in the spot, but how to make accurate estimates of your estimation ability on the spot.

You never say,

"It should be done in 104 man hours"

You say,

"Given what I understand of your requirements, it should take between 84 and 304 man hours. If you need a better estimate, then I can analyze your requirements more carefully and give that to you in two days."

So your estimation ability needs to focus on how to know how good you can estimate something given the requirements. If you do know off the top of your head, you can give a much smaller range with much higher confidence, but if you don't know then its a WAG and you must give a very large range to express your level of uncertainty.

Keep in mind that most sane people understand you can't give a 95% confidence estimate on the spot - what they really want is a ballpark figure they can use to play with in their head to determine whether they really want to move forward with a given project or not. The large range should be enough to give them this information without tying you down to a specific number.

Answer 4

Here's a blog entry i found to be a little useful Has a few good tips that you may find to help:

Jeff Atwood - On Our Project, We're Always 90% Done

Answer 5

Estimated times always include a certainty factor derived from risk, whether it's explicit or implicit. The same project could have two perfectly valid, but different, estimates from the same developer depending on this. For example, there may be a project that has a 25% chance of being done in 4 weeks and a 75% chance of being done in 8. The experience that you're referring to is actually your implicit understanding of this need to be able to understand risk.

The problem is that when you're johnny-on-the-spot in a meeting, you don't have time to analyze risks and gut estimates are notoriously bad throughout the entire industry. In light of this, I strongly suggest reading Steve McConnell's literature. Software Estimation and Rapid Development are good starting points.

For a brief answer now, I suggest two core considerations:

1. Understand the software development story, and sell and explain it to your manager(s). It isn't theoretically possible to be accurate within a factor of 2 for a project that hasn't been defined more concretely than a quick meeting. Resultantly, on-the-spot estimates have to be a range, and typically a wide range. This is difficult to sell to management because they need to make schedules and budgets, and we understand that, but the simple fact is that you aren't psychic and you can't tell them "this will take 2 weeks" for anything that might actually take two weeks. If a project will take more than two days, the initial estimate should be a range.
2. Don't confuse estimates with targets. This is an easy mistake to make, especially when you're new in the industry. An estimate is a guess at the amount of work a task will take that entails risk analysis and a certainty factor. A target is a commitment. Distinguish between these carefully as it's very common for an organization to use the word "estimate" when they're talking about a target commitment.

Answer 6

always factor in testing, although you might think you can do something in 2 days testing it could throw up some issues that could take days to fix

Answer 7

I always give a very conservative estimate. If I think I can do it in 2 weeks, I will tell them 4. If they demand it sooner I will tell them I will try but I can't promise anything. Nobody ever complains when you're done ahead of schedule, but they will almost always complain if you're late. Obviously this can only carry so far; you can't tell them 4 years if it will be done in 2, but in a large project like that you'll have to sit down and thoroughly break the project down into parts to come up with anything approaching a realistic time frame.

Answer 8

Given your (lack of) experience I don't think you are going to be able to give an accurate measurement for anything greater than a small two day bit of work. Reading about all the estimation methods available is great. Just don't put much faith in them.

Be firm about not being able to estimate anything without some understanding of what you are supposed to accomplish. The estimate also has a probability and a range in it.

Good luck.