4 ms·
One sticking point I rarely see discussed with the prevailing line of thinking (noted by tptacek, patio11 and others), is that a week is a measure of time. If
by hardwaresofton 8y ago
One sticking point I rarely see discussed with the prevailing line of thinking (noted by tptacek, patio11 and others), is that a week is a measure of time.
If that's true, there is only time-based billing, and project-based billing. I've done both types, and project-based billing has been much more dangerous for me due to the need to accurately scope (or eat costs), usually for a client that has no idea how difficult "simple" additions can be (and often when you yourself cannot). Software scoping is effectively impossible to do accurately, and I've found the only way to get close is when you have already built the system in question before (or better yet, have a codebase you can reuse to hit 90% of the features in the first ~week of "work").
Hourly billing (whether you roll it up into a day/week/month) provides a way to cover myself from bad estimation, but limits you to charging for time to build and screws up incentives.
Project billing means I eat costs from bad estimation, but with the possibility of reward from over-estimation, along with the fact that you can charge for what the deliverable is worth (i.e. the value you deliver, not the time it took you to build the product).
As far as weeding out clients who aren't serious -- you can do that with a high-enough hourly billing (and generally you can get a feel for this from the client themselves)...
Could someone explain how I'm understanding the avoid-hourly-billing ideas wrong? It seems reasonable but it just doesn't seem to work for me in practice with the estimation thing, never mind the fact that clients need regular updates and rarely value good software development practices (so may seem like you've spent a week doing nothing if they can't immediately see the result/how it will save them time over the lifetime of the project).
[EDIT] - Another thing that I've realized when I was last thinking about this that I didn't include was that as complexity unfolded (and I realized my estimation was wrong), I did not increase prices/communicate this effectively to the business -- maybe that's where I'm getting it wrong? It feels like it would chip away at client trust to do so.
For those who are wondering what I actually do when I take projects on these days -- I just set a high hourly rate, possibly bundle it into weeks/months, and avoid project-based estimation because of the difficulty of scoping and the likelihood of scope changes. This also gives me an edge when the scope changes -- it's no longer "can this fit", and it's more "sure we can fit this in, it will take longer though".
- groestl 8y ago> avoid project-based estimation You'll have happier clients as well, because with experience, the buffer in project-based estimations needs to be large enough that no possible hidden complexity can deplete it (barring complete show stoppers). Clients will usually be better off with time-based billing when the per-project cost estimate would come from an experienced provider.
- hardwaresofton 8y agoOK, so then in my head the advice is now: "do time-based billing but avoid hourly increments, instead opting for weekly/monthly but never disclose how many hours per week you work". It seems inevitable that clients wonder/ask why you can't get X, Y, and Z done in a "week", when they hold a definition of what a "week" means to them. If you're billing for a week, they're going to assume you're billing for 5x8 hour days -- is the idea just to let them assume that, but you actually work however many hours it takes to get the deliverables for the week done? If so, that's basically forcing you to over estimate, or work a full work-week anyway, and then you might as well be pricing by hour (whether you show them or not). What I've done recently is charge for X days/week, with a written agreement specifying what constitutes a "work day" for me. Clients normally don't care/micro-manage (there's enough mutual trust), and when we meet to show/discuss progress, I let them know how how "on schedule" we are (so at "based on how quickly I'm working at the current clip of 3 days/week, it looks like everything will be done in 4 weeks"). This formula would be wrong according to the usual HN advice though -- it's way too easy to translate X days/week w/ a set amount of hours that constitute a work day to X-per-hour billing.
- ascar 8y agoI think the important point is not that it can't be broken down to a hourly rate, but that the smallest incrememt is 1 week or a day. They simply can't book you by the hour. Specifying what a week or day is, is up to you. In regards to time as well as money.
- lmm 8y ago> What I've done recently is charge for X days/week, with a written agreement specifying what constitutes a "work day" for me. Clients normally don't care/micro-manage (there's enough mutual trust), and when we meet to show/discuss progress, I let them know how how "on schedule" we are (so at "based on how quickly I'm working at the current clip of 3 days/week, it looks like everything will be done in 4 weeks"). This formula would be wrong according to the usual HN advice though -- it's way too easy to translate X days/week w/ a set amount of hours that constitute a work day to X-per-hour billing. Why do you need that "written agreement specifying what constitutes a "work day" for me."? That sounds like it's just encouraging the client to micromanage; you don't want a client that doesn't trust that you'll do a decent week's work in a billed week. And it gives you the disadvantages of a conventional job: you're now tied to working X hours/day Y days/week rather than taking a long lunch some days, working late some days, stopping early some days, and trusting that it'll all average out.