Work Estimation

It is a black art trying to get the costs right on a development estimate. Too much money and the client will go elsewhere, even if your quote is realistic and reasonable. Too little and you become one of the suppliers the client goes to when the realistic estimate sounds too high.

If you're one of the second estimate types, the sort who say it will cost less than it actually will, then you run the risk of not completing the work on time and within budget, you will have stressed out staff and may end up costing your company money instead of making money.

So what to do about this? Personally I aim for realistic where possible and include a contingency amount as well just in case of blowouts. I also do a very detailed breakdown in the estimate so the client knows why this project of theirs will take 2000 man hours.

So a client has approached you and asks "how much to build this? Just give me a rough estimate of dollar amount and time". You have very little detail, perhaps four or five paragraphs and they want the estimate based on this information. How do you go about this? You don't do it in a slap dash, "oh that'll only take us 3-4 weeks, how does $100k sound?", that's just asking for trouble. What steps would I take:

1. Spend a day or two researching what it is the client wants.
2. Create a list of questions and ask the client to clarify anything you're not sure of.
3. Make sure you fully understand what it is that they want before you commit to anything in writing.
4. Get a basic idea of what you think would be the best way to develop the solution, this will help you to estimate development hours.
5. Create the estimate and remember to allow for some or all of the following items (plus any others you think of that are applicable to your particular solution):

• Initial project planning
• Architecture design
• Solution design
• UI design
• Environment setup - development, test and live
• Business analysis
• Development - all the various parts, the code, the database changes, links between them etc...
• Unit testing
• Code rework - after unit testing, code reviews or system and UAT testing
• Code reviews
• Compiling/Deployment/Build Smoke Tests
• Team meetings
• Documentation - user guides, online help etc...
• Version control
• Issue management
• Testing - creating documents, strategy, test plans, testing activity, re-testing etc...
• Test management tasks - reports, document QA
• Dev lead tasks
• Project management tasks
• Post implementation support
• Contingency

Each of those estimatation areas are headings and may contain many sub-tasks, you need to review each item to decide how many hours you think needs spending on each sub-task. Also, if you have never worked as a tester then I would highly recommend asking a test manager or senior test analyst to help you with that section of the estimate. Testing is generally very badly estimated by developers not understanding what it is that testers actually do.

6. Get a sub-total of the number of project hours and multiply it by your hourly rate.

It's very detailed producing an estimate this way and it'll take you a day, maybe two days to pull this together, but you will have a much more realistic cost to present to the client and it will also give you a good basis for creating the full estimate when you have more information on what the project will entail.

By specifying what the estimate is comprised of, you are also allowing the client the opportunity to add or remove items they either think are missing or uneccessary.

If you're in the sort of position whereby you create the estimate and hand it over to a sales guy to pretty up and present to a client, then doing the estimate this way will give you a back up if the sales team decide your estimate is too high and present the client with a much lower amount. That way when the project is overtime and overbudget and they're looking for heads to roll, you should have some protection.