Page 1 of 2

Estimating Projects

Posted: Tue Apr 29, 2008 4:29 pm
by Luke
Do you guys have a specific method for estimating how long a project will take (both hourly and monetarily)? What is your formula (if you dont mind sharing)? I have historically had a very difficult time accurately estimating the time a project will take, so was wondering what the pros do. :)

Re: Estimating Projects

Posted: Tue Apr 29, 2008 8:35 pm
by califdon
The Ninja Space Goat wrote:Do you guys have a specific method for estimating how long a project will take (both hourly and monetarily)? What is your formula (if you dont mind sharing)? I have historically had a very difficult time accurately estimating the time a project will take, so was wondering what the pros do. :)
This topic was the constant subject of traffic 15 years ago when I was active in Small Business Consultants newsgroup, and I think nobody ever agreed on an answer. The smart-ass answer is to use any method you want, then triple it! But I think many developers settle in on a rough formula that may include measures like x hours per web page, y hours per interactive script, z hours per database table, etc. Then you would probably have add-ons, like data importing, specs changes after acceptance of contract, additional time for demos, also a multiplier for complexity that requires logic testing, etc. Finally, you're back to tripling it. :?

Re: Estimating Projects

Posted: Tue Apr 29, 2008 10:30 pm
by supermike
RATE

1. Look at the going salaries for PHP web developers in a kind of middle market area of your country. I mean, avoid the big city salaries, and not the rural economy, and look for something kind of middle-of-the-road.

2. Drop $10K from that annual number if you're a freelancer because most of your clients will be either designers or affiliate marketers, and they do have a good bit of cash sometimes, but often don't have the kind of cash you would expect with a regular job in a cubicle. There is also intense competition by countries that know English but have a recent population of poor people who have suddenly learned how to become half-a**ed web developers.

3. Now divide that by 52 weeks and then by 40 hours to get your hourly rate.

4. If you're trying to get a "portfolio client" that you can list on your site, and especially if you're starting out, lower that rate by $10 per hour.

5. If you're having a low sales quota* month, either lower that rate by $10 per hour or reduce the slack time on your project schedules -- meaning, run it really close on time or reduce your rate by $10 per hour. If that won't fly, and you really need a customer in that month, then drop it by $5 more but go no further unless you're insane. The only way I'm able to drop that rate even further is if I sublet the work to offshore guys who do it for peanuts, but that requires a lot of micromanagement, tweaks, and is a general pain.

6. If you're over your sales quota in a month, and you're sort of halfway busy in a week, and especially if you think a particular client looks like they have the budget, then raise that rate by $10 per hour.

MONTHLY SALES QUOTA

1. Look at the number you'd get in the "RATE" section after step # 3. Drop that rate by $10 per hour. Now compute that rate for 40 hour work weeks times 4 weeks (in other words, the number of hours for a month). So, if I charge $x after step # 3, then you first get a value of ($x - $10), and then you multiply times the number of hours in a month, and come up with ($x - $10) * (4 * 40).

2. Take that value and multiply it times 2 when first starting out and when you're learning the ropes. That means you're working for about 2 clients a month at the same time. Now, as you get more experienced after a year of learning the ropes, multiply that number times 3 because you'll be working about 3 clients a month. (Now, granted, you may end up working about 15 clients in a month, but they'll be short gigs -- I'm just using 2 and 3 because in a given week, that's about all you can mentally stand at the same time without being completely confused or missing deadlines terribly.) So, the monthly sales quota you need to generate is ($x - $10) * (4 * 40) * 2, or use * 3 after your first year.

HOURS


1. In general, if it's a "tweak", then I say, minimum, go no less than 4 hours. For anything else, it's an automatic 16 hours to start from.

2. Break up the project into what I call "features". These are things like, login system, contact us, about us, drawing home page, publishing something, catalog, shopping cart, etc. I call these "entities". Each entity likely has CRUD attached to it, which means Create, Read, Update, Delete. It may or may not have an applicable concept for that, but then again it may. I typically find that I need 6 hours per CRUD per entity if I want to do a good job and do a little unit testing. You need to experiment with how long it takes for you to do CRUD on these typical things, and you'll get better as you develop a framework, use jQuery for your Javascript needs, use Smarty for your page templates (or comparable system to separate out your presentation layer), have repeat, reusable code, etc. Now, if you don't have full CRUD on something, or the CRUD concept doesn't apply, then you might be looking at 3-4 hours per item.

3. Now, sometimes some of those items can be quite difficult and a CRUD of 6 hours per those particular entities may not be suitable. If you feel yourself thinking this even slightly, then double those hours to 12 per a particular entity.

4. Give yourself a week at the start of a project for the page design and XHTML/DIV/CSS chop work, unless you outsource this.

5. If you have a client who seems antsy, and the project is small, you could leave it at this number of hours if you feel you can make it and want to risk it. But if the project is medium sized or large, continue the rest of the steps.

6. Give yourself a week for data migration -- setting it up, building scripts to help do the imports, and doing the work.

7. Give yourself 2 weeks for bug reports, fixes, and further testing beyond the normal unit testing you'll do as you work on each feature. If the customer appears to be Mr. Moneybags, and the project is large, give yourself a total of 4 weeks, not 2.

8. For anything eCommerce related, give yourself at least another week.

9. Some project estimates are just not possible because you find some items are unknowns or have a high level or risk with them. For these, I often don't charge the customer and do some tests first before I can come up with an estimate. It sucks that I have to eat this cost, but I'd rather do this and get the time estimate right than risk losing the client because I tell them the wrong estimate, or an estimate too high.

10. Now this probably gives yourself PLENTY of hours. Try and see if that will fly with a client. If not, then reduce it by 24 hours (half a week) and see if that will fly (but only if you want to).

11. As you get better at doing projects, or can cookie-cutter things occasionally, or have actually timed yourself with CRUD on certain items, you'll be able to give more accurate estimates.

Re: Estimating Projects

Posted: Wed Apr 30, 2008 2:04 am
by matthijs
Supermike, nice list. But in my opinion you missed the most important one:

VALUE

What I mean with that, is that you have to look at each client individually and see what value you can bring to them. And base your estimates on that. It is not the only thing, but it does have to play a role in my opinion. Sometimes a big role.

The thing is, for many businesses, telling them your rate is $80/hr doesn't mean much to them. It only tells them you are $10 more expensive then the other guy charging $70/hr. So should they just go with that cheaper guy? No. They should go with you because you convince them that you will make sure that their investment in the project of 10.000 will give them on average 30.000/yr in profits. If they go with someone else, they might only get a ROI of 10.000 for a 5.000 investment.

The way you present your list is based on the fact that all developers are equal and that the main way to compete with each other is minimizing your rates.
3. Now divide that by 52 weeks and then by 40 hours to get your hourly rate.
This assumes you actually make 40 billable hours a week for 52 weeks a year. That's difficult if not impossible to achieve. What about all the time spend on running your business, marketing, cleaning your office, etc etc. With your estimate: say I want an income of $40.000/yr. Now with your calculation that makes my rate $19/hr. Now if I ever want to reach my income, I can have no sick time, no vacation, and have to work at nights to run overhead stuff of my business...

Anyway, I think there are 2 things at play here:
1) Estimate the amount of work a project takes: the only way to do that is break it down in small pieces and then add a bit more (tripling it like califdon said).

2) What you tell the client. And this can be way different then no1. If a big company comes to me for a website, I might charge them 10.000 for the website, while I build that same website for 1500 for a small non-profit client. Even though both projects take the same amount of time to build. Again, this is about value.

Re: Estimating Projects

Posted: Wed Apr 30, 2008 3:08 am
by onion2k
I just take a wild, and usually completely wrong, guess.

Re: Estimating Projects

Posted: Wed Apr 30, 2008 4:45 am
by matthijs
onion2k wrote:I just take a wild, and usually completely wrong, guess.
As long as it's wrong in the right direction. For your bank account I mean :)

Re: Estimating Projects

Posted: Wed Apr 30, 2008 8:49 am
by supermike
matthijs wrote:Supermike, nice list. But in my opinion you missed the most important one:

VALUE
How you pull that off in the few brief emails interacting with a potential client candidate -- that's a mystery to me. My client interaction has shown me that most will get annoyed with me and leave if I can't tell them either hours or rate at least by my third email interaction with them.

And how do you word such a thing? I mean, it would be like, "I offer a tremendous value because I am very experienced at least I believe in some of the things I read here in your initial project requirements. If you're wanting to compare my hours or rate to others, I will likely lose unless I know what your price range is and what the competition is claiming and how you actually verify if what the competition says is truthful. This is not to say that I can take on all projects at the rate or hours you desire, but it would help me to understand your budget and more detail on what it is you want, so that I could give you a fair estimate."

If someone were to take you up on a paragraph like that, I'd be wildly surprised. So surprise me! :)

Re: Estimating Projects

Posted: Wed Apr 30, 2008 9:41 am
by matthijs
Well it's really not that difficult.

What I mean is: my client doesn't care about my hourly rate. He cares about getting value for money. It's the same as when you buy a TV. You walk into the shop with a budget in your mind of, say $1000. Now you start talking with the salesman. More probably he starts talking with you. After half an hour you walk out of the store with a $2000 TV. You paid 1000 more and are still happy about that. Why? Because the salesman convinced you that you get much better value for your money with that $2000 TV. It will last twice as long, is 10" bigger and has 3 remote controls instead of one.

Now, of course there are always people who want the cheapest of the cheapest. They go for the $200 TV they find at a dump in the supermarket between the coffee and sandwiches. These TV's are made in India or Pakistan. Now the question is: are you going to compete with these TV's on price? No. Because the only way you could pull that off is also go live in Pakistan on bread and water, hire a bunch of kids tie them up in a factory and let them work 20 hrs/day 7dy/wk.

Re: Estimating Projects

Posted: Wed Apr 30, 2008 10:36 am
by Kieran Huggins
Custom software estimates are inherently inaccurate, since you never know exactly what the finished product will look like. Neither the client nor the developer ever has all the information or skills required at the outset.

What I do is give them a very loose estimation f how long the project sounds like it'll take (days, weeks, months) and then charge an hourly rate, billing weekly. That way feature creep never kills you, and the weekly iterations keep the client involved in the direction of the project, as well as in control of the cost. No surprises == happy clients == relaxed programmers.

I would never work on a fixed price or an RFP for this reason, it leads to badness and stress. Sometimes it's hard to turn down a seemingly juicy contract, but its worth it in the long run. Trust yourself, there are good clients out there.

Re: Estimating Projects

Posted: Wed Apr 30, 2008 11:14 am
by supermike
Matthijs - looks like you hold out for $3000 and $4000 projects and up and then start talking. Yeah, if I held out like that, then I suppose I could start pitching value rather than hourly rate. But I repeatedly don't get this kind of opportunity except perhaps twice a month, and then again I am pressed with questions like, "Yes, but when will you give me your hour estimation, and what is your rate?!??!?" clearly showing the client is frustrated by me pitching value.

Kieran - I always only bill by the hour, but I am then often asked, "How many hours will it take?!??" clearly showing a frustrated client. So I set an expectation up front, but then I find I'm 3 weeks over in time every once in awhile, and I have to say something like, "Okay, we've hit the expected due date of the project, but I don't see an end in sight for another 3 weeks...." (BTW, the client already knows how well I'm doing or not because I give my clients short status update emails every 2-3 days unless they want me to let them know about things in a longer duration.) So I continue, "...I'll need $x amount of dollars because my hourly rate is $y and will need 3 more weeks (anticipated) to complete this project." Sometimes that flies, sometimes it doesn't.

All and all, my experience shows me yes, to bill by the hour, but clients always want to start discussing rate and hour estimations, or talk about giving me a functional spec to make that determination, by the third email at the latest. Lofty talk about value is something I attempt with a customer here or there, depending on customer type, but that is a 33/33/34 chance that it backfires, making me look too expensive and scaring away a client candidate, or belabors the point, frustrating the client candidate, or, I get lucky, and it works.

I also have a rule of thumb that I learned from a mentor:

$2K USD or every 2 weeks I get paid, whichever come first. I do this even with well-established clients because there's nothing more scary than doing either 4 weeks of unpaid work, or $4K USD (and more), and the client swears they Paypal'd the cash or sent it by wire, and I haven't received it.

If I'm nervous about a client, then I ask for 20% up front and I think that's fair.

Re: Estimating Projects

Posted: Wed Apr 30, 2008 12:36 pm
by matthijs
supermike wrote:Matthijs - looks like you hold out for $3000 and $4000 projects and up and then start talking. Yeah, if I held out like that, then I suppose I could start pitching value rather than hourly rate. But I repeatedly don't get this kind of opportunity except perhaps twice a month, and then again I am pressed with questions like, "Yes, but when will you give me your hour estimation, and what is your rate?!??!?" clearly showing the client is frustrated by me pitching value.
No, it works the same for lower budget clients who want to get something done for $600. They have to see the value in what I provide for that $600. Otherwise they might be tempted to go for another solution some were else which will cost them $400.

I am not saying that you don't give a price estimate. I am just saying that telling a client I bill $50/hr doesn't mean anything. If I bill 50 and the job takes me 20 hours, and someone else bills $100 and estimates 10 hours, the end price is the same. But who do they pick you think? Maybe the $100/hr guy. He is probably much better, isn't it?

All in all there's not a single solution. It will depend on the client and on the job. As I do more front-end stuff (designing and building websites), often clients want to know a) the total price and b) what they can expect (looking at my previous work) c) have trust in me (am i reliable, what time line do I keep, do I give them guarantees, etc)

Re: Estimating Projects

Posted: Wed Apr 30, 2008 1:10 pm
by califdon
Mattijs, you just must be one of the guys from the old SBC Usenet discussion group! :D I am in complete agreement with your approach.

That said, this discussion reminds me of the 3 blind men who were taken to the circus and were led to the big elephant and permitted to walk around and feel the elephant, since they couldn't see it. When they got home, they were discussing their experience. The first blind man, who had felt the side of the elephant, said, "An elephant is quite like a wall!" The second, who had put his arms around one of the legs, said, "No! An elephant is more like a tree!" The third, who had grasped its tail, said, "What's wrong with you two? It's obvious that an elephant is like a rope!"

You must certainly approach a web developer who needs some script written, very differently than you would an end user who wants a complete website developed. And you would treat the local dry cleaners differently than you would a major division of General Motors. Then there are differences in what you perceive to be the client's sophistication and the complexity of their requirements. One thing that I think all of us in the old discussion group agreed on was that there really ARE some jobs that any sensible consultant/programmer should just turn around and walk away from.

Re: Estimating Projects

Posted: Fri May 02, 2008 1:41 pm
by RobertGonzalez
I am a simple guy. I talk with the client a lot before giving an estimate. It has been my experience that a client doesn't really know what they completely ahead of time. Many will say "I want a user area behind a login screen so that users can come to my site and download files reserved just for those that subscribe to my site". That is all well and good, but do they REALLY want?

After assessing what they want I consider how long it takes me to make the pieces of they want, how much of the project can be open sourced, how much can be reused from other code bases of mine that will not infringe on the clients (or former clients) agreements with me, yadda yadda.

Once I have a decent idea of the time I usually float it by 30% to accommodate for even more things that they didn't know they wanted.

Then I take the number of hours and put it to the customer like this:
Option 1
$125 per hour, payable weekly and the end of the next week for code, completed or not, up to that point. Code will continue to come as long as A) payments are made; and B) there is need for code to complete the project.
Option 2
$100 per hour, payable in three installments, as follows:
40% of the estimated time (in hours) X $100 per hour, up front.
30% of the estimated time (in hours) X $100 per hour, when the application is bought off in my development environment.
30% (or remaining amount) of the estimated time (in hours) X $100 per hour, when the application has been successfully installed on your server and is known to work.
Option 2 is only available for projects that are estimated at or more than 30 hours. This seems to work pretty well for me.

Re: Estimating Projects

Posted: Fri May 02, 2008 4:58 pm
by supermike
Everah, you're either a demigod in the PHP world for those kinds of rates, or you were speaking figuratively, or you are referring to a non-USD currency. If I could charge more than $60/hr, that would be a good day. I've never had that kind of day yet.

I'm realizing that most clients don't like a lot of email interaction back and forth as I try to do the *right* thing and ascertain what they are looking for, and they especially don't like lists of rules like payment options, 3 times you want to get paid, and rigid stuff like that. Many clients get very angry about that and move on. So, I try to feel the client out and do the best I can, but Everah, you are right, for some things you have to stand your ground and ask the essentials.

Re: Estimating Projects

Posted: Fri May 02, 2008 5:07 pm
by RobertGonzalez
Those rates are on par for professional development right now. General range is between $95 and $175 per hour. That is for design, development, DB modeling... the works.

Those that are looking for service in these categories know what the pro rates are and they pay those rates. Folks that nickel and dime you on your rates are going to nickel and dime you in other areas too. It makes sense to let the $10 per hour script kiddie take those clients. In my opinion.

On a side note, I know my comment above my have sounded somewhat arrogant. I am not trying to be that way. I am only saying that as a professional my rates are what they are. Take you car to a mechanic and ask him to only charge you $30 per hour instead of his normal $85. What will he say? Could you get someone to work on your car for $30 per hour? Sure. How will that work out for you?

For full time work these number are dramatically different. Most full time developers/programmers should expect to earn according to their local markets. That could range from $35K a year in the midwest and the south to $120K per year in Silicon Valley/Boston/Large metro areas.

But freelancing... I won't budge. My rates are what they are. If someone doesn't want to spend it, they can find someone else.