A practical way to estimate a project cost ( I mean time cost)?

Question

What is the practical way to estimate the time required for a project ( I am a web developer working alone most of the time) I find difficulties in estimating tasks and projects,

Answer 1

I am wondering what you mean by practical.

There is no easy way out of estimating and there is no way of estimating that will yield 100% accuracy 100% of the time (in fact, it'll yield 100% accuracy about 0.00003% of the time). It is an iterative process using ALL available resources and methods that pretty much point to a general area of where you should end up.

Break your work down into smaller chunks; use historical data from similar projects; use rule of thumb parametrics if you have them and they are reliable; use multiple people from multiple disciplines to contribute their opinions; avoid single-point estimates at all costs in favor of multi-point, probabilistic estimates; use simulation if you can; and most importanly iterate your work several times until you have a group consensus.

I cannot stress the single-point estimate enough. A single-point estimate is NOT an estimate; it is a target. That should be done AFTER your multi-point, probabilistic estimate. There is never a case in our very stochastic world where a single-point estimate is acceptable.

Answer 2

If its for a pitch, do not forget contingency. In the real world first hit estimates often carry 50-100% contingency.

As you do more work, you will see things come up more often and you will have something close to base it on. Until then, as said, break it into small tasks, work out dependency and any delays that are set in stone (such as waiting for a server build etc), over estimate everything (within reason of course) - much safer than underestimating. Work it out over your personal man hours (if working alone) per day minus 2 hours (so if you work 10 hours a day, call it 8). Put in estimates based on various scenarios/requirements. Review it, resist chipping (oh I could probably do that in 1 day if I don't have a lunch break and work hard), review it again. Then add your contingency. You should be giving a range rather than a date usually.

//Edit: To Add => Oh, and if you have written something similar before and have some code ready, do not take the build time away for doing that piece of work unless you are not interested in getting paid for it (i.e. you are happy to give it away) and you are very sure you need to make no changes to it and that it will work seemlessly.

Answer 3

Start breaking the project into sub tasks. Break up to a level, where no sub task is of more than 4 hours. In the beginning of the project you may find this a daunting task. As your understanding about project will grow with time, the best thing will be to revise your older estimates.

Answer 4

Some suggestions in no particular order:

• Figure out what your planning horizon is and schedule plan review meetings for when you anticipate that the plan will start to break down.
• Try to only estimate for simple tasks with clearly defined products deliverable by one person or functional unit. Where you have complex tasks decompose them until they are simple.
• Where possible use past experience (yours, the company's, the SME's) to guide your estimate.
• Challenge the estimates from your SMEs, but remember that they may be underestimating instead of overestimating (depending on the personality of the SME). Time estimates should be made by the person(s) actually delivering the product generated by a given task.
• Remember that people aren't 100% efficient. Make sure time estimates assume that a person working "full time" on a project will only be productive e.g. 75% of the time.
• When you get time estimates ask for "best", "worst" and "most likely" cases for each task. Use either the "best" case to develop your critical path, use the difference between the "best" case and somewhere between the "most likely" and "worst" cases as contingency reserves. Alternatively, use the "most likely" case for the critical path and the difference between that and the "worst" case for contingency reserves.

• Factor in your own management reserve to account for the fact that SMEs tend to use a goodly chunk of their contingency reserves. Have more management reserve as the number of tasks on the critical path increases, or when you have a large number of tasks outside of your planning horizon.

• Make sure to associate a name/role with each task to make sure everyone is clear on who does what when and can be held accountable.

Answer 5

In addition to the above: learn from your past estimates. I think this is the most efficient method for developing the skill. Make it as simple as possible, that is: use a simple table with four columns:

• Task name
• Estimate (before doing the task)
• Work effort (after doing the task)
• Deviation (in any form)

I think you will need a few months to see that your estimates are getting better.

Needless to say - you need to be very consistent.