How to estimate a VB projects time

[SpiderFlight]

Hi everyone, Not really sure if this is the appropriate forum for this question. So I apologize if it isn't. Is there a standard rule of thumb in estimating VB projects times. I have written a number of VB projects and usually I under estimate or over estimate the time needed. Any direction or resources are greatly appreciated.

Thanks to all

 

[abaldwin]

Not really. Project by project with experience, the type of application and how much re-usable code you have in your library.

We have become somewhat accurate at quoting time but the first thing you have to have is a good completed SPEC before quoting the job.

Most of the time (IMHO) that there are overruns are because the program kept getting addins and further request for "OH we can do that....well how about X?"

We ususally put 2 hours of design time into forms gui design, after that it is really dependant on DB design, integration, navigation desires, platform, etc.

Compare the current spec to previous apps and the time it took. I never cut any time even if the previous app had plenty of re-usable code since it will have to be modified somewhat anyway.



Andy Baldwin

"Testing is the most overlooked programming language on the books!

 

[Perilous1]

I see this question alot, and many coders all have a different take on it. My opinion is that time spent is irrelevant. The App is worth what someone will pay for it. If you have a specific buyer for it, then it's all about what it's worth to them. If it's intended for open market, then you have to think in terms of general value for what it does for them.

 

[strongm]

>My opinion is that time spent is irrelevant

Sure, you may offer a fixed rate for a job, but you can only be confident that the fixed fee is reasonable is if you can estimate how long it will take you.

There's no point taking agreeing to a $2500 fixed fee for an international hedge fund reconciliation package, , only to discover that it takes you 100 days to design, code, debug, integrate, document and deliver - since what you've done is unwittingly agree to work for $25 a day.

 

[BobRodes]

Essentially, the issue at hand is where risk is going to be assigned. Whoever is risking the most has the potential to make the most. So, if you're doing a fixed price project, you are risking more than if you are paid by the hour. This means you should expect to be paid more for your time (quite a bit more), if someone wants to hold you to a fixed price for a project. This also means that the features have to be set in blood, and that there is a firm understanding that any departures from the feature set will require a new quotation.

So, as a corollary to what strongm says, if your client won't settle on the features ahead of time, you will need to resist giving a fixed price. Let the client know that you're more than willing to work out a fixed price, once the features of the program are equally strongly fixed.

From a sales standpoint, I've often found that charging by the hour to define features prior to coming up with a fixed price quote is a fairly easy sell. The deliverable is a document that includes a problem statement, and a detailed list of features. You tell the customer that you'll give them a quote based on those features, once we have them in place, and that they can feel free to shop the quote around if they like. By the time it comes to that, you've gotten paid so they've gone through the process of setting you up as a vendor, they like you, they feel like you understand their problem better than your competitors do, etc. so not using you to develop the product feels like changing vendors in mid stream.