[edanm]

I'm completely on board with the "bill by the day, not the hour" idea. Having implemented it in our own consultancy, it's done wonders.

But it hasn't gotten us to the stage you're talking about - we're definitely making headway in establishing ourselves as (Python) experts, but I don't think we're really at the stage where we can sell based solely on the customer's value - building software is simply too replaceable a commodity (See note). Nor do I think we necessarily want to be there - lawyers don't sell on value, after all, nor do most professional services firms.

Also, increasing the billing increment too much and selling based on value starts taking you into "fixed-project pricing" territory, which is a whole different field. Not that it's better or worse, just different, with its own set of needs. This we discovered in retrospect after practically switching all our work to fixed-pricing, then realizing what a big difference that was (that we weren't equipped to handle).

Note: Building software is too replaceable in the sense that there are plenty of alternatives to get some software built (hiring, cheaper freelancers, etc). We certainly manage to sell ourselves as better than alternatives because of speed an expertise. But that's a far cry from building projects and selling on value, which IMO is again, a whole other field which is hard to shift into from any old software consultancy (different customers, different sales pitch, different needs). I mention this because tptacek's basic point of "switch to daily billing" is better advice in that sense - it's easy to do from just about any position with just about any set of clients, and by magic improves your life.

[tptacek]

Yep, that's exactly what I'm trying to say. Thanks!

[lifeisstillgood]

What I would suggest though is to bill by the day and find a way to measure what you have delivered against changes to a business goal

This is the next step after bill-by-day/week - linking your work to something they care about - using evidence collected by software.

To be fair this works even as an employee, a permie / contractor or a actual, gone next week contractor.

[tocomment]

What didn't you like with fixed price billing?

[tonyedgecombe]

The problem with fixed price work is you create a conflict of interests from the start. It's in your interest to do as little as possible for the price and it's in your customers interest to get as much as possible for the price.

That and all the issues of requirements gathering up front.

[gabemart]

Isn't it also true that hourly or daily billing creates a conflict of interests from the start, because it's in the customer's interests for you to finish as fast as possible and in your interests to finish as slowly as possible?

[sokoloff]

Yes, but those are smaller than the converse, where the conversation is about whether something ambiguous/new is in or out of scope (strictly adversarial discussion), rather than whether such ambiguous items are worth it or not to the client (simply a resource allocation discussion).

[tptacek]

I have a hard time believing that the potential conflict of interest situation that emerges from a fixed-price engagement, where the customer ultimately can accept or reject the work, would be worse than the elemental conflict of interest that emerges from hourly billing, where customers have little control or even insight into hours billed.

[edanm]

It's not about likes and dislikes, both are workeable systems. But they're very different. Some obvious and not so obvious ways:

1. The obvious way - in one you get paid no matter what, and your entire job is to keep the customer happy enough with you that they'll happily continue paying you. With fixed-price, you have a "semi-conflict-of-interests" as others mentioned.

2. These different incentives cause a lot more work up-front for requirement gathering, a lot more work on contracts that are well specified, etc. Btw, that also means billing at much, much higher margins to cover the uncertainty.

3. Not so obvious - doing fixed-price projects requires a lot of focus around managing multiple projects at the same time. When managing X employees on multiple projects, this gets tricky. Why? Because fixed-price projects tend to have lots of waiting: build some infrastructure, wait for design, build and deliver first milestone, wait for feedback, deliver final project, wait for bugs, fix bugs, wait for final confirmation.

So you're basically learning to juggle multiple projects at the same time. And all projects have points where their schedules shift - I've had clients who are completely desperate to get things off the ground, where I would've put 90% chance of their e.g. graphical designs being ready for us, who suddenly had business emergencies that required them to slow down. This happens ALL THE TIME, as does the converse (10 designs arrive at the same time and now you have 10 clients waiting eagerly for updates).

4. Another non-obvious difference - the kind of clients you can take on tend to be very different for these two methods. You'll tend to get more non-technical clients looking to work project-based, and more technical clients looking for time and material, especially when what you are doing is augmenting their own technical staff with expert knowledge.

To summarise, each style of billing or more correctly each type of project you can take on has its own challenges, they're not better/worse, they're just different.

[patkai]

Very good points. I would add that one's relationship with customers is much more unpleasant when doing project pricing. The "out-of-scope" discussions are difficult and can make collaboration strained.