How do you bill on a project basis? Half the people say that billing anything other than hourly is nuts, and the other group says anything other than fixed price is nuts.
When I get an inbound request we're not even talking price because anybody who contacts me has seen them. I'm leaving money on the table but I don't want to spend time negotiating, it lengthens the sales cycle.
I don't do custom work until a second phase. The phase 1 service I offer goes through my standardized process so I know how long it'll take to deliver. There's very little variance which makes it easier for me to know my cost to deliver.
Phase 2 (wireframes) can be custom but by that point I have a lot more context on what I need to deliver, how long it'll take, and how much it's worth to the client. If they're asking about phase 2 it means I've proven myself and the negotiation is short because we've built trust.
I tracked time for the first couple of projects because I wanted to see how long they took to deliver. So now I know my effective hourly rate.
Content has also worked but production has admittedly been anemic. Mostly because I've been so busy.
I bill on both a fixed price basis and time and materials basis (not programming to be open - but I do supply chain consulting where projects can also vary dramatically from the initial estimate!)
A few points:
- Fixed price is for a fixed scope. You can't have a fixed price without a fixed scope (this is why I do a mix - because poorly defined scopes are better under T&M).
- 50% billed upfront, 50% paid after a deliverable is delivered. The deliverable is clearly defined in the scope above, so there is no ambiguity about if the final deliverable is done. This can be negotiated with more payment milestones - but there is always an upfront payment if fixed price.
- I include a standard hourly rate in the contract, and then if there are changes, I just tell the client that these will be billed at the standard hourly rate and add these to the invoice. I try to be really fair here and not screw people over, and in general people respond by not challenging these invoices.
One additional advantage of a fixed price not listed elsewhere is that it makes sales a lot easier - clients often don't trust a T&M price and get their fingers burnt a lot - fixed prices can drive the right incentives if properly scoped and done with good intentions.
Do you just waterfall the requirements and don't start working until every i is dotted and every t is crossed in the requirements?
There a couple legitimately important "new" things which came up. Some got added on as T&M to one invoice or another, some I just did because they were just a few hours of work and not really worth the back and forth.
I would be very, very hesitant to start on a large fixed-price project without knowing a lot about the industry already.
Agile is not a match for the contract if the client values contract negotiation over customer collaboration, as that's the opposite of one of the Agile values. [1]
However, even with a fixed-price contract, one can use Agile approaches internally so that you finish pieces early and often, in an order prioritized by customer value. That way when the specific Tuesday in May arrives, you are most likely to have completed the pieces they most care about. And also have the flexibility to make tweaks if priorities change.