Calculating Time To Complete a Project

Question

Possible Duplicate:
What can I do to get better at estimating how long projects are going to take?

Though i am mainly interested in Iphone Projects but everyone is welcome to answer this.

So i was wondering how you calculate the Time in which a particular project will be completed? Well i know it depend a-lot on your experience but most of the time (well from last 3 month of experience) there are hell of unknowns down the roads which you don't know in advance and only come to surface when you start working on it, so in such condition how you deal with your client and give them right budget and time scale in which project will be completed? And after starting the project, it turn out that there is a particular part you technology which you don't know and have to learn it, so it just pop up in the middle, how to convince your client about extending the deadline and budget?

I am not sure if have put the question right, so please help me in correcting the question. thanks.

Answer 1

There are a couple of standard techniques you can use like Function Point Analysis etc... but you can get some pretty wild figures using them.

Experience running projects and knowing the capabilities of your team is your best bet.

Answer 2

Unfortunately, in order to estimate well, you need to not only have experience programming, but you also need experience estimating. Every time you over or under estimate, think about what went wrong and your estimates will improve over time.

As a less experienced developer, I find it takes me, best case, twice as long as I optimistically hope it will. Average case, 3 or 4 times as long. Worse case... well, it goes downhill from there.

Maybe this would help? http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=12774

Answer 3

There are a lot of variables here -- type of project, client, developers, management, your skill level, experience level of others involved, technology, etc.

Since these vary widely from individual to individual, project to project, and company to company, there is not going to be any estimator readily available that will be able to predict this for you.

The best way is to create an individual or organization wide historical database of projects, requirements, teams, historical requirements. Since requirements and teams change as projects evolve, you need a historical view of all of this data.

Then, you can attempt to predict final project time estimates based on the inital estimates, or predict final project time estimates from initial estimates, and then final project time costs from final project estimates, etc.

If you don't have enough data to make good estimaates, then these won't be accurate estimates. But, as time goes on, you should be able to make better and better estimates.

Otherwise, you have to do it seat of the pants - write the project plan, try and make sure that all items have been accounted for, and all precedences, then fill in work estimates for each item, run PERT, and get your estimated project date. It should be within a factor of 100 of being correct :)

Of course, if you are an experienced project manager and you have broken things down into work items that you can estimate accurately from your past experience, you can come up with a considerably better estimate. This is classic project planning. However, I think the predictive apprach based on historical data should yield better estimates in the long run.

Answer 4

Divide the project into several stages if you can and let the customer know when a stage is complete.

Beforehand you can tell him at what date you expect a phase to end. So he always knows if you are late or just in time.

If something goes wrong it's pretty easy to tell him what caused the delay and why you'd have to extend the deadline.

When you break it down into smaller project stages it's usually easier to estimate the time needed for a stage and better to see the progress. The earlier you can tell your customer that you can't meet the deadline the better.

By making him part of the development(by letting him see the results of each stage) it's usually easier to communicate time problems. At least that's my opinion on this.

Answer 5

Break every step of the development down into as small a segment as possible. If you can get the entire thing into segments shorter than a day, you will know when you are on or off track. At the same time, you'll identify where you might need more time because you'll see segments of the project you aren't sure how long they'll take, because you've never done that task before...those will be the things that will likely cause you to fall behind. Schedule in a half day (or what you feel you will need) for research at these points plus time to complete the task. Not only does that give you time to hopefully learn the skills needed, but if you happen to get the research and implementation done sooner than your schedule, you'll be ahead. And when you hit another tougher research segment, you'll have a little extra time...hopefully

...but, it really comes with experience. The more you work on or with a system or type of system the better you can estimate. Everything new, is your best guess, and you'll resort to planning it out as best you can ahead of time...or throwing out wildly inaccurate guesses!