Why we bill by the hour

On the product end of things a fixed price makes a lot of sense. Squeejee builds custom web applications...billing hourly for that is a no brainer.

Much of everything else is a hybrid. I would expect that I could get a reasonably accurate estimate for painting my house based on the experience of a painter. With a fixed set of requirements and a familiar problem domain, I would think Squeejee could do the same.

The only downside that I see so far is that as you get better as what you do you tend to get quicker as well, which in an hourly arrangement means you make less. You can always raise your rates as your experience grows but for previous clients it can be hard to explain.

Many customers will prefer a higher priced fixed bid, rather than a lower prices hourly based estimate, because they can budget for it (or get budget for it) without worrying about overruns. Many less scrupulous development firms (or people who just can't estimate very well) end up billing well over the initial estimate when doing hourly invoicing, and many customers have been bitten by that before.

In my experience smaller client will be more likely to go for the hourly approach, due to the initial estimate being lower, and feeling like they have more control over the costs during the course of the project. Larger companies almost always work with fixed size budgets approved on a project by project basis, and so having a fixed cost (even if it's potentially higher) is key for their internal budgeting and resourcing. Plus it protects against the overruns hourly project can bring. I've never seen a Fortune 500 outsource a full development project on an hourly basis. It's almost ALWAYS fixed price, just due to how they handle their own budgets.

The trick, imho, to good fixed price cost estimating is to get the best requirements you can up-front, and restate them yourself in your SOW, broken out by task groupings instead of however the client structured them. Clarify any potentially nebulous requirements/tasks yourself, and let the client know if they want to change the way you've filled in the gaps, they can do so, but you will need to submit an addendum to the invoice for any changes they make (unless otherwise agreed upon - i.e. same effort swaps of un-developed areas). Once you have the overall task list figured out, do your internal task breakdown and estimates. Then, pad your estimates out by perhaps 50% (this depends on how good you are at estimating, and how many times you've done task/feature X before).

If I have a task doing something that I haven't done before (i.e. some sort of crazy-cool ajax front-end wizardry (I'm a back-end guy)), I'll pad that out a bit more, since I'm likely to run into a snag or two along the way. If it's something I've done 100 times before (i.e. user registration/login/logout/forgot password flows), I don't need to pad that, since I can estimate that pretty exactly.

Also, don't worry if your padding seems high, or your SOW price seems too high. The client always has the option of doing an hourly approach instead. It's up to them. The more projects like this you do, the better you'll get at estimating, and it becomes second nature.

As we all know, succinctness = power. Everybody lose in the long run when developers are not motivated to solve the problem in less time with less code and as simple as possible.

I'm amazed that some people treat it as something "so basic".

Though the customer may be afraid that the developer can just start piling hours without real productive work. Still, I think the customer has the possibility of asking for a replacement of the consultants if he does not see good results. Later on in the project may be harder but still possible.

Having said that, the argument put forward in this article is nowhere near complete. Yes, when you're getting paid by the hour the client has his foot on the gas pedal, but in reality he's already sunk a big hunk of money on you, from his standpoint on a long project it can easily look like throwing good money after bad.

Yes, agile techniques make clients happy faster. But it all depends on where the risk is. And there is a difference between the client and the users. If the users have a hard time making up their mind what they want? Then the software process becomes part of a business decision support system. The team interviews multiple stakeholders and facilitates negotiation and conflict resolution.

You might say "that's not software work," but that's the real world with real humans in it. In that case, it could be easy for the client to see bills every week or two for what he thinks is just a lot of talking, From his standpoint, he just wants the coding done -- and of course the users should be happy. (grin)

Because it is so complex hourly is the most straightforward way of working. I've been watching this scene for many years, though, and I have the sneaking suspicion that fixed price bids are what separate the men from the boys when it comes to delivering technology solutions -- mainly because the profitability can swing wildly from rolling-in-the-bucks to sucking-wind.

except the url that gets copied into the clipboard on winxp foxit pdf readed is www.sparkwildire.com

I have no idea why.