views:

238

answers:

4

I charge my clients by the hour when building them websites. It's the only reasonable way for me to do it without either ripping them off, or ripping myself off. They always ask: "How many hours do you think it will take?" and I usually don't know what to tell them without stressing myself out by putting myself on a time line. What do you guys tell them?

+3  A: 

As a professional, you can give an estimate without requiring that it be set in stone. You should make sure the client is aware that an estimate can have unknown dependancies and that unexpected events can occur to affect the results later on. That said, you should be capable of giving a reasonable estimate, assuming the requirements are well specified. The actual process of coming up with an estimate is some kind of a black art however, but it usually requires writing down a really detailed list of all the things you need to do and then coming up with estimates for each of the individual parts. I found that painless software schedules are a good way of doing that.

1800 INFORMATION
+1  A: 

If I have a good specifications, I can plan my time accurately and can tell how much time job will take.

But its an ideal case. In most of the cases I find parts that can be estimated and counting hours for them. Also trying to roughly make an estimation for unclear parts and give the total sum as an approximate: 50hrs +/- 10hrs. If approximate values are not suitable, we discussing all unclear points till I'll understand them completely.

And, of course, I'm trying to split the whole process in iterations - it allow me to plan more precisely and have many other benefits.

maxnk
+1  A: 

There is an agile approach to this that is used in a lot of projects I know.

You break down the functionality into tasks and each task is estimated at a number of story points. You can prioritize these, and typically end up with the following result:

Pri A 450 points Pri B 200 points Pri C 250 points

The argument is as follows: We believe that we're capable of delivering 45 points per 2-week sprint (known as velocity). If your budget is 30 weeks then it looks like we'll be able to reach pri C within your budget. After 3 sprints (6 weeks) we will be able to give a fairly accurate prognosis of what the actual velocity is going to be and give feedback as to how far you'll get (or final cost). You always give the customer the option to back out of the project at the end of each sprint, even though the customer should be aware that the first sprint or 2 may have odd progress.

krosenvold
I just find the agile estimation in "story points" weird. What is a point?? How do you know how many story points can you deliver per week? Customers pay you per dev per day not per some "point". How do you correlate? Just sounds like more agile mumbo jumbo to bait the corp. IT herd. <rant/> :)
Strelok
Nice comment ;) If your projects have never gone way over budget or failed then I suppose you're right; you don't even consider the freedom of agile methods valuable. You normally let development teams estimate the points, using earlier stuff as comparison. It doesn't have to be accurate from start!
krosenvold
A: 

It is a trust-thing.

The client will only hire you by-the-hour if he knows that you are not going to rip him off. Fair enhough, since he can't check if you work at peak efficiency.

Try to start a new project as small as possible. Sell it like this: "We give you something that is useful in the shortest amount of time. After that you can choose to add the features you need. This way you stay in control."

What you try to do is get the customer to trust you after that intial interation and then start new small iterations. Smaller iteration are easier to estimate, so you gain even more trust.

It's not a easy game.

Florian