Page 1 of 1
estimating project. how to charge / estimate workload
Posted: Thu Oct 25, 2007 8:37 am
by jmut
I know this is not something you can learn on a forum as lot of experience is needed.
I wonder how you guys estimate a project requirement. Usually customer doesn't really know exactly what they want...one simple solution is just stay away fro such customers...ubt still
For exmaple a case I have right now...
"Simple script[they all say simple

] to click a link of a product to sell, form for filling customer data, send info to email...no payments or anything, very very simple".
Well based on this it is a bit hard to estimate anything...as things are usually never that simple...so I am thinking questions like:
- how many fields is this customer data
- is there any database...if at all needed or just per session
- as explained there aren't really users...anyone can order
- there should be flood protection against mass mailing and stuff - I guess one strong reason why there should be users..and not anyone to order...while captcha might do.
- will it be multilangul etc...
- will I do all administration - setting up database, configuring, deployment
- is html standard complient - nasty html can be pretty hard to make dynamic
What else can you think of... is there any rule you have when estimating time and money.
Thanks
Posted: Thu Oct 25, 2007 9:49 am
by John Cartwright
We've talked about this a couple times. Check out
viewtopic.php?t=71764
Re: estimating project. how to charge / estimate workload
Posted: Thu Oct 25, 2007 11:44 am
by Christopher
jmut wrote:What else can you think of... is there any rule you have when estimating time and money.
For programmers I think the rule of thumb for budgeting and scheduling is to do a reasonably detailed breakdown figure out how long you think it will take -- and then double it.
Posted: Thu Oct 25, 2007 12:16 pm
by s.dot
Yes. I've made the mistake of making a quote of only the hours I thought it would take. About 1 1/2 times the amount I projected is what I ended up with.
Doubling the amount of hours is a great idea.
Figuring out an hourly wage though is what I have a problem with.
Re: estimating project. how to charge / estimate workload
Posted: Thu Oct 25, 2007 12:32 pm
by alex.barylski
jmut wrote:I know this is not something you can learn on a forum as lot of experience is needed.
I wonder how you guys estimate a project requirement. Usually customer doesn't really know exactly what they want...one simple solution is just stay away fro such customers...ubt still
Clients that pay are worth your time.
That being said, here is what I now say: When they mention "simple script" I mention that whatever I write has no warranty. If bugs crop up after I sign off, I charge by the hour - make it high (70+/hour). I also explain that any other problems, security, integration, migration, etc and their on their own.
This will satify most cheapskates cause they software development is "easy".
Those that frown upon the idea of zero warranty will often ask why, at which point, I explain. There are several ways to develop software:
1) The wrong way. In which case the project never gets finished at all and still costs money.
2) The not so right way. A application gets finished but it's a hack and constantly needs more time invested to just keep it running. These projects typically consume up to 50% of your time just fixing bugs and eventually higher if the project grows.
3) The right way. In which you take the time to develop and application with an extensible, secure and solid architecture.
The first result is what happens when an over eager developer jumps the gun without experience. The second way is what happened when an experienced software developer with nerves of steel begins developing adhoc software and never bothers to learn about refactoring or architecture. This is arguably worse than complete software project failures.
The last requires both patience, time, money and experience on behalf of the software development team. Your paying for quality upfront but you get long term advantages.
Basically, if you cannot sell the client on the idea that software is a perpetual project constantly changing and evolving you will never sell them on the latter, so instead you write code as quick and as copy-paste as you can and remove yourself from any support agreements, etc...
You can win them all, but turning down a project is just less money in your pocket...if you don't do it somebody else will.
As for quoting...only previous experience can tell you that...even then it's incredibly inaccurate. Break everything down into atomic operations and estimate the time that way, then muliply by three.

Posted: Thu Oct 25, 2007 12:42 pm
by feyd
I avoid making a generalized (project level) quote. No matter what, it will often bite someone in the butt. If you can, stick to quoting an hourly rate. Be flexible in it, but not to the point of sacrificing it significantly. Those jobs just aren't worth the hassle.
Posted: Thu Oct 25, 2007 5:24 pm
by Kieran Huggins
Hourly FTW. Stay in close contact and try to do rapid iterations.
Fixed quotes always lead to friction.
On the plus side, youll have to worry about feature creep ever again!
Posted: Fri Oct 26, 2007 12:53 am
by jmut
Thank you all for great input.
Posted: Fri Oct 26, 2007 1:23 am
by wei
In addition, quote a rate that is above the average. Round up the time to the nearst hour (not even 0.5 hours) since there are also non-billable time in most instances.
Posted: Sat Oct 27, 2007 3:27 pm
by califdon
Kieran Huggins wrote:Hourly FTW. Stay in close contact and try to do rapid iterations.
Fixed quotes always lead to friction.
On the plus side, youll have to worry about feature creep ever again!
With the greatest respect, I would differ on this. When I was actively consulting, I avoided hourly bids and found that (a) I made more money on fixed price, and (b) I developed better relations with my clients, some of whom I served on follow on contracts for years. I do acknowledge that fixed quotes have the
potential for problems, if you don't adequately define the project and make it crystal clear up front that changes in requirements will always cost extra. But I found that if I prepared a thorough requirements document and got agreement from the client, the project went more smoothly, with less "nibbling" at the definitions, because they knew in advance that it would be costly for them to make even small changes, once a quote had been given. I also found that clients really want to know what the project will cost them, before they start, rather than an hourly based fee that can creep upwards and upwards. When a fixed bid client comes back and asks for even the tiniest change or reinterpretation of the requirements, they usually do so with the full knowledge that it's going to cost them, providing an opportunity to evaluate whether it's worth it to them.
Oh, and you don't need to account for your time, sometimes an irritating requirement.
Posted: Sat Oct 27, 2007 5:07 pm
by Kieran Huggins
The problem stems from the fact that clients rarely understand the exact nature of what they want or need. If you tear apart any RFP you'll find it fraught with misconceptions, inconsistencies, and nonsensical buzz words (web 2.0 anyone?).
I've found that the best way to have a successful outcome is to try and work together with a client to understand their business goals/problems and use my web expertise to identify appropriate solutions. This is not usually a simple matter of identifying an existing product and applying it. If it were, Microsoft Web2.0 would have shipped with Office 2007 and we'd all be out of business.
Further to that, business goals are rarely perfect out of the gate, and business models often need to be refactored, if not changed altogether in mid-execution. PayPal started as a way to send people money between PDAs. If you're part of the solution process, and not a solution provider, you'll be in a better position to serve the interests of your clients.
This indicates that a different business model needs to exist for web developers, with less focus on "deliverables" and more focus on consulting and execution. I like to think of it more like a law practice and less like an auto-body shop. With this model in mind there will always be small, well understood solutions that have a predictable cost, but more often than not will be an agile "work-in-progress" type of relationship.
@Don: You're lucky to have worked for people with a good understanding of what they wanted. A fixed quote can be done in such cases without much danger. Unfortunately, clients like that are becoming increasingly few and far between IMO, more so as the bubble grows.
Posted: Sat Oct 27, 2007 9:40 pm
by califdon
You make a convincing argument, Kieran, and I must admit that (1) I've been out of active consulting for several years now, and (2) I developed relatively small and not too complicated databases, certainly not ground-breaking new concepts; but I still reserve my skepticism that a thorough RFP is not the best way to go for the common single proprietor developer, in many circumstances. I coordinate a monthly Access User Group at Microsoft (don't throw things at me!! I'm trying to quit!!), so I am still reasonably in touch with what is going on, at least in that narrow branch of the field. Some of our group are employees and some are independent practitioners, but past discussions seemed to favor fixed price quotes where feasible.
One thing to note is that when the requirements are not clear, it is sometimes useful to charge a fixed fee for analyzing their requirements and preparing a formal RFP. I haven't actually done that myself, but a few of our group say that they have and that it worked well.
But it is unquestionably true that the circumstances determine how you should interact with a client. I would venture to say that one size doesn't ever fit all. If the task is so complex that a crystal clear RFP cannot be written, or if a client is so vague about the desired results, then surely a fixed quote is not practical. And if the client really wants a temporary employee to work along on a concept while the goals or details shift, then that's the thing to do. In other circumstances, though, I think that "deliverables" is still a valid concept.
Re: estimating project. how to charge / estimate workload
Posted: Mon Jan 14, 2008 10:53 pm
by chas688
Clients like firm, bottom-line numbers. Decision makers always ask, how much is this going to cost me? Trying to explain php or coding or database development goes so far over some clients' heads, sometimes you can't find that common ground. So, what they do know, hopefully, is what they want to have done. How you get there, as a developer, is up to you.
First, let's talk profit. A products company takes parts or raw materials and then makes something with it. Then, they sell that finished item for more than the sum of the parts - sometimes, way more. Someone is willing to pay for that product what the company asks for it. When you buy a dell or a laptop, wouldn't it tic you off to know that it cost exactly $150.00 to make the computer you just bought for $1,200? You don't think about that, though. Who cares, right - it does what you wanted it to and that's why you thought it fair and paid for it.
Now, as a developer, I consider myself selling a service. Time is my greatest enemy and, essentially, my raw material. I can't make any more and it is in short supply. How do I make a profit off my time? I heard someone mention to get it down to a gnats ass and then double it. OK. If that works for you. What I do is figure out how much it is going to take me and then I add 30% to that. I then multiply that number of total hours by my hourly rate and bid the project. I tell them that based on the requirements we have here and have discussed, if I go over, then it's on me. If you add additional requirements then we will add a block of hours onto the project estimate. Now, there I am and I have come up with a fixed number for my client. I have some padding for myself (1/2 of my profit (i'll get to the other half in a sec)), and a safety net should scope creep come in.
The other half of my profit is if I can reduce my time by finding reusable components, classes such as ZF that will handle some of the common stuff or PEAR, etc, or other efficient ways to do things. Then, I can find time for that other client and use those extra hours to be working on another project where I have applied the same principle (30%). Therefore, If I double up, I am making twice the amount I originally charged, both clients are happy, and so am I.
Now, how is that different than marking up a tangible product to make a profit? There is nothing wrong with making a profit on your time, you just have to get creative with it.
Chas
Re: estimating project. how to charge / estimate workload
Posted: Tue Feb 12, 2008 10:01 pm
by Attilitus
The problem is that 90% of the time you will be unable to gain a good perspective on the scope of a project before making a bid. It is so hard, that you might as well accept that you are never going to get it exactly right. Once you place a bid, it is set in stone in the mind of the client. The client assumed that you "knew" that some feature logically would be included under a certain section of his project. He considers that feature to be a vital component of that site's section and simple to implement, in reality that "little" feature ends up adding hours and hours to the project.
This will happen numerous times, almost ALL the time in any medium to long term project.
If you are working on a flat-fee basis you have two options:
1) Lie down and take the potentially unlimited abuse of project creep.
2) Re-Negociate the project price to a client who doesn't understand "what the big deal is".
Both of these solutions cause conflict between the client and the coder. Flat Fee projects just cause bad feelings on both sides.
Charging by the hour allows you to incrementally billy your client. The client understands how much time was spent on which feature. The client is generally more involved with the project. (At least in my experience.)
Re: estimating project. how to charge / estimate workload
Posted: Wed Feb 13, 2008 9:28 pm
by chas688
It is hard to dispute your experience there. I think especially the large projects are harder to bid on, simply because all of the unknowns that arise when you enter into a project. I'm not contradicting myself here, I think that either way has its advantages / disadvantages to some extent. I try to get things estimated as closely as possible and spell things out in a proposal, before the contract is signed, that way, the contract has the clarity to fully define what the client is getting exacltly. Though, that being said, it is easier said than done when you get into the midst of it all...
Just this week, I started scoping out a rather large project. On the surface, it seemed pretty straightforward. THe further I looked into the thing, the more complex it became and suddenly, I ended up calling the guy and telling him that in order to meet the June deadline, that I believed that he would have to hire a shop with at least three developers working rather diligently to get all the features he wanted by that timeframe. Over the weekend I realized that I wasn't looking for a job and that I needed to pass this large project up so that I could focus on the several pokers in the fire at once approach, rather than get wrapped up in one project altogether.
So, I guess that if you can focus on one thing at a time and do well by it, by the hour is the best bet. For me, though, I don't know if I could make it like that, because I couldn't leverage myself more than the hourly rate that I was charging.
Thanks for the reply,
Chas