Hourly Billing is Nuts
blog.arkency.com
blog.arkency.com
If your development is in any way exploratory or creative, my experience is that hourly billing frees everyone up to focus on making the best product. It also lets the developers and designers be creative and figure out the best way to build something, rather than having to build exactly what was drawn up by some idiot (usually me!) who isn't actually the one doing the work.
Yes, you have to trust that the hourly worker isn't wasting your time. Yes, they may have to raise their rates as they get more experienced and more busy.
On a fixed price build, as you say, every small detail becomes a negotiating point.
I do think time and materials can be better, but I think the trust you mention can take a long time to earn. Some things seem simple but take longer than expected. Some things seem hard and come together quickly. It can sometimes feel for clients like they're being taken for a ride on a particular piece of work, even though in other cases the work will have been done for less than initially expected and it notionally balances out. These are tricky problems to get back on a case by case basis. And, truthfully, in my experience the clients who were fussy about costs were usually fussy about quality too, and I would say generally came out ahead because of it. So the incentives are still tricky.
It's also challenging, because in an agency context the client inconsistencies do exist. Some people do work faster or slower. Some people do better or worse work. Sometimes the person who is already up to speed on the project isn't available and someone else has to do the work instead. A lot of these problems are internal to the agency, and it's frustrating to the client when they affect their expenditure.
I don't really have a good solution to it. Honestly, my takeaway from the experience was that the client/agency dynamic just kinda sucks, and it isn't a dynamic I enjoy working in.
What do you prefer? Single employer + Salary?
But yeah, I prefer working in-house to working for an agency. Besides the fact that I think the work tends to be more interesting and generally done to a higher standard, I don't think the same dynamics exist. Maybe this is just my experience, but I don't find the boss <-> employee relationship to be nearly as adversarial as the client <-> supplier relationship. Additionally, I think most managers are just less penny-conscious about their employees are than most clients are about their agencies, probably because the budgeting processes are different.
I mention this, because I'm conscious that you can frame salaried employment in equivalent terms to client <-> agency dynamics. I just don't think that framing tends to be true, because I think there are other social and economic dynamics at work.
https://www.acquisition.gov/?q=browse/far/16
These contract structures apply to more than just federal contracts and have helped me dramatically understanding different contract structures. Anyway, long story short, each contract type has a different amount of risk and reward and it's extremely important that both parties understand and choose the contract type most appropriate for the work. Even fixed priced contracts have a lot of variation:
http://www.acq.osd.mil/dpap/ccap/cc/jcchb/Files/Topical/Cont...
Anyway, it does take time to learn this language, but the there are many local chapters of the National Contract Management Association (http://www.ncmargc.org/) that run seminars and study groups that can help understand this kind of language.
Normally as a contractor, part of my value is that I can adapt to fill in the gaps left in the project. Thats almost always the best thing for both parties. Instead of pointing at a flaw and screaming that it needs to be fixed before I can work, I just fix it.
On a fixed bid, depending on the difference between the reality and expectations, that can put me underwater pretty quickly.
So I end up calling them and saying:"I assumed you had tests, and the board was working, and that I wouldn't have to drive back and forth to your office 6 times. Now my hourly is $7.50 assuming I could finish right now. So are we going to fix this or am I going to walk away from this giant sunk cost."
This conversation never goes well.
This is exactly right! And the theory behind it is actually one of the papers behind this year's economics Nobel Prize.
Different billing models aren't about paying for outcomes - they're about how to both incentivize and compensate when 1) there is uncertainty about the effort and ability required and 2) there is uncertainty about the degree to which effort and ability will lead to outcomes and 3) outcomes are costly or difficult to measure.
Different ways of billing are really about who takes on the risk (and gets both the upside or the downside), as well as how to align incentives between the service provider and the recipient. Oftentimes risk-sharing and incentive-alignment are in conflict with each other, which is why this isn't an easy topic.
I am very, very careful now to guard my rate as a software developer. As crazy as it sounds, I would rather work for free than work for a low rate.
That's not crazy at all. Most of us help other people in many ways, and that's ok. I'll be glad to spend 6 hours to help a friend move house, but I'd certainly not do it for $20. Similarly, I develop FLOSS for fun, but would not do it for $10/hour.
In simpler terms, the best way to win a negotiation is to be willing to walk away from the project. As your opportunity cost grows, you are willing to walk away from higher and higher paying projects, which leads to better paying projects.
Dan Kennedy writes,"If you lose a client on price, you lost them long beforehand!"
and only a fraction of the thought that needs to go into a balanced risk-reward consideration.
- Risk of cost overrun.
- Risk of completion.
- Risk of delivering a result vs. a service.
- Risk of claims being enforced against you or your legal shell. Money at risk.
- Risk of customer willing or able to pay.
- Ability to enforce contract terms from your side.
- Risk of badly managed change.
...
There are clearly opportunities out there. Also some carefully considered hybrid models can work. But it takes more than a fraction of thoughts.
Based on the example scenario given, it shouldn't be that hard. You just give a lower time estimate.
For small stuff, the hours may be negligible. For larger stuff, they may not believe you. This is where marketing, referrals, testimonials, etc come in.
From my perspective, I want to work on your project as little as possible, because it's likely tedious and boring, so I'll charge a higher rate and plan to get done ASAP. Clients see high rate and think "ah... he's going to run up as many hours as possible" (well, some do).
With most projects I'm involved in, there's some reasonable upper limit on budget regardless of hours or rates. They may have a few months to get something done, and $x. When I can to the level of knowledge and trust, we can prioritize the work and scope. Those engagements end up a bit more like 'fixed bid', but the bid is "best effort on these items, in this order, by this date, for $x". Everyone's expectations are known up front, and they have the "gotta haves" and "nice to haves" prioritized. Doesn't mean nothing ever changes, but that approach - when I can get there - has been great.
Here's a tip I learned for getting clients to pay a retainer. Have an hourly spot rate, and a discounted retainer rate. I charged $100/hr for the service I provided as the spot rate, and $85/hour on retainer. Almost every client switched to the retainer, because "Hey, 15% off!"
Hourly pricing revolves around cost to deliver, not value created, so it's usually going to be better for the client and worse for the developer...
The only time this balance changes is when the developers opportunity cost nears the value created...so the hourly rate captures most of the value...
of course both sides can mitigate their risk by giving up this advantage. (i.e. if a developer charges hourly, they can make sure they dont end up under water on the project but in exvhange they wont capture the full value and vice versa.)
In my experience it's rarely a technical challenges that negatively impact project timelines. Usually it's changes and revisions coming from the client side (though all parties can and should submit changes). The randomness (and hence risk) in a project doesn't come from the initial scope agreed upon. It comes from the fact that people are dynamic, and the act of building software is dynamic. A feature that appears complete at origin will almost always accrue changes, tweaks, and revisions.
These dynamics are difficult to map to a fixed cost project.
Additionally, as a worker, you are always measured by hourly rate, whether or not you charge by the hour. A $5000 project that takes 500 hours to complete values developer time at $10/hr. If you can get the job done in 50 hours, the labor is worth $100/hr. Your technical acumen is not the sole determinant of this time variance, instead it depends on the behavior and temperament of all the project stakeholders.
If memory serves, I've read of positive experiences with this right here on HN.
Keep in mind though, I'm not a full time contractor. I do a few hours of freelance work a week (10-20 hours a month, for 1-3 clients), in the evenings, mostly on small projects that just take a few hours.
In addition, I'm unusual because I focus in a small specialty: web scraping, data collection, and data sourcing. I write web bots and design data architectures, basically. This is great, because I do variations on the same thing over and over again, it means that I very very rarely run into hidden problems and can very accurately estimate how long it will take me to collect a set of information from a particular source. I've actually walked away from work that was outside of this scope (even though I have a master's in software engineering, have done it for 10 years, and was perfectly capable of the job) just because I knew it would be a higher risk to bill for accurately, and didn't want a potential headache for the client or for me.
So I strike a middle ground between hourly billing and "fixed cost" that I believe benefits both sides: "This will take 3-4 hours, the deliverables will be <blah>, I bill $x/hour. If I find something that proves to be a huge blocker that, for whatever reason, I didn't see before, I reserve the right to revise this estimate upwards and ask for your approval on the revised estimate, but, in that case, you will not be obligated to pay for any work done up to that point, until you accept the revised estimate, if you choose to do that."
It's not uncommon that I discover that there's a method of collecting data from a site that I didn't see before, that is drastically faster than I had originally anticipated. Of course, I could do as the author suggested and bill for the original estimate, reveling in my loads of cash and free time, but here's the rub: I don't.
I actually really enjoy telling the client: "Hey, check this out! It only took half an hour! Anything else you want me to do?" and clients appreciate it. I get paid fairly for my time, and fairly for the difficulty of the project. In theory, I figure, if the clients were to shop this project around on the open market, someone else could figure out the "trick" and underbid anyone pricing based on "value to the client," and, of course, there's the danger that clients could figure out that this was NOT a 3-4 hour project at some point down the line, and I'd like to maintain their trust.
In addition, I've found that clients who get a "surprise bargain" are more likely to recommend me through word of mouth, they're more likely to add on extra work/features to meet their original budget anyway, and I feel good about myself. Is "feeling good about yourself" worth an extra few hundred bucks here and there? Maybe not, but, like I said, I'm getting paid exactly what I wanted to get paid my time, so it doesn't bother me too much.
But I am also billing based on value, and always keep that in the back of my mind. Over the last couple years, I've actually doubled my hourly billing rate, as I create tools, shortcuts, develop better techniques, and even add more value as a consultant for the client.
I've certainly toyed with the idea of creating web scraping tools that I can monetize as software (although it's a crowded space), moving towards the "fixed cost for the value this adds to your life" model, but for my freelance work, I just really enjoy sitting in my pajamas in bed, Netflix playing in the background, mindlessly cranking out some code and exploring new techniques while getting paid to do it.
I'll be the first to admit that hourly billing doesn't make sense for everyone, and every project, but I think I've found a good balance of risk for myself and the client that's appropriate for my skill level, specialty, and financial needs, and I'm just fine with that.