Best practices for estimating a sofware project?

gicio

Hi!

what is your best practices for estimating a software project?
And did you show the customer your detail estimation sheet?

sneakyimp

I believe it's important to remind a customer that what you provide is an estimate and that there is always the possibility that one might run into unexpected problems. I would definitely show them an estimation document and this estimation document would explicitly describe what I am estimating. Anything not included in the estimation document would not be included in the estimate. Obviously it's in your best interest to list everything you expect to spend time on and to include everything that must be done.

A long list can be helpful for convincing a client to recognize the real scope of what they ask. It can also motivate them to point out things they expect to be done and in that capacity it can really help you come to an understanding with your client about what needs to be done. Typical things that fail to get discussed in the estimation phase are discovery [e.g., learning how the client's old system works], testing [think your software is going to be bug-free right out of the gate?], migration or go-live processes [e.g., moving DNS to a new server, updating a live database, etc.].

The downside of a detailed estimate is that it takes time to build it. Your time and their time. I would recommend wowing them with your expertise in an initial meeting where you listen to their problems, describe what they tell you in your own words to get it straight, and then offer a variety of solutions to their problem and explain the tradeoffs of each. If they seem suitably impressed, I would hit them up for a discovery/estimation phase where you design their solution and create estimates for project completion.

Weedpacket

sneakyimp wrote:
A long list can be helpful for convincing a client to recognize the real scope of what they ask. ....

A whole dependency diagram looks good ("we need to do this and this and this, then we'll be able to go on to do that and the other....")

A third thing it can do (once you and the client have decided just what should be in it) is provide a milestone checklist. That can provide the client with a measure of genuine progress (if they only go by what they can see they might think the job is finished with the UI) which may reassure them that progress is being made when you're working on something that as far as they can see has no effect at all - reassure them enough in fact to make a progress payment (should you agree to such a payment model).

Ashley_Sheridan

I would agree with breaking down the project into a list and maybe indicate dependencies like Weedpacket suggested. It gives you both something written down to confirm exactly what the deliverables were to avoid feature creep. Always plan a little extra time for things. Things will go wrong 9 times out of 10, so having a buffer is nice, and the client will be pleased if you deliver early, not so much if you deliver late.

barand

Use the 80:20 rule.

80% of the job takes 80% of the time. The last 20% takes the other 80% of the time.